Hello Sebastian, On Mon, Nov 10, 2014 at 08:36:07PM +0100, Sebastian Hesselbarth wrote: > On 11/10/2014 07:43 PM, Uwe Kleine-König wrote: > >On Mon, Nov 10, 2014 at 03:10:56PM -0300, Ezequiel Garcia wrote: > >>On 11/10/2014 05:06 AM, Uwe Kleine-König wrote: > >>>I tested this series on top of 784b352aeeed with a patch to support my > >>>ReadyNAS 104 (by Netgear, Armada 370 system, currently only second stage > >>>booting from U-Boot, similar to mirabox with > >>>armada-370-netgear-rn104.dts from next-20141106). > >>> > >>> Marvell>> tftp start_netgear_rn104.pblx > >>> Using egiga1 device > >>> TFTP from server 192.168.77.157; our IP address is 192.168.77.133 > >>> Filename 'start_netgear_rn104.pblx'. > >>> Load address: 0x2000000 > >>> Loading: #################### > >>> done > >>> Bytes transferred = 292148 (47534 hex) > >>> Marvell>> go 0x2000000 > >>> ## Starting application at 0x02000000 ... > >>> > >>> barebox 2014.11.0-00123-g422a0a9d46a8 #3 Sun Nov 9 21:35:11 CET 2014 > >>> > >>> Board: NETGEAR ReadyNAS 104 > >>> SoC: Marvell 6710 rev 1 > >>> mdio_bus: miibus0: probed > >>> eth1: got preset MAC address: 28:c6:8e:36:df:57 > >>> of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 > >>> of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 > >>> of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 > >>> of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 > >>> malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB) > >>> environment load /dev/env0: No such file or directory > >>> Maybe you have to create the partition. > >>> no valid environment found on /dev/env0. Using default environment > >>> running /env/bin/init... > >>> /env/bin/init not found > >>> barebox:/ ethact eth1 > >>> barebox:/ dhcp > >>> eth1: 1000Mbps full duplex link detected > >>> T T T T T T T T T T T T T T T T T T T T dhcp failed: Connection timed out > >>> dhcp: Connection timed out > >>> barebox:/ eth1.ipaddr=192.168.77.133 > >>> barebox:/ eth1.netmask=255.255.255.0 > >>> barebox:/ echo $eth1.ethaddr > >>> 28:c6:8e:36:df:57 > >>> barebox:/ ping 192.168.77.157 > >>> T T T T T ping failed: Connection timed out > >>> barebox:/ > >>> > >>>tcpdump on 192.168.77.157 (which is connected via a switch) worked just > >>>fine from U-Boot, after all it served the barebox image. > >>> > [...] > >>Hm, not really. I've tested this with my Armada 370 Mirabox and Armada > >>XP Openblocks AX3-4 boards (I use kwboot to load the barebox image, so I > >>don't jump from U-Boot). > > >I would expect to use second stage booting to be more robust, because a > >missing gpio to enable some hardware component in barebox is already > >setup by U-Boot. > > > >Do you have a command line for me? I used > > > > scripts/kwboot -b images/barebox-netgear-rn104-uart.img /dev/ttyUSB0 > > > >which took much longer than I expected (didn't time it, but I'd say in > >the several minutes range). And I didn't know what to do then. Ctrl-C > >and then connecting microcom was wrong. Adding -t to the command line > >above, too. Any hints on how kwboot is used? It loads the binary into RAM and runs it from there, right? I timed my above command and it took 38m28.225s for my image (341304 bytes). > >>I guess we must be missing some config. What's confusing is that the > >>Mirabox and the RN104 should be pretty similar in this regard (e.g. they > >>use the same phy mode). > >How do you know which phy is used? I assume from Arnaud's webpage? > > > >Any hints how I can debug this apart from using a dtb without pinmuxing > >stuff? (OTOH the same dtb works with linux, hmm.) > > If you use barebox as first-stage BL, then you definitely need the > pinmuxing. If you use it as second-stage BL, u-boot should have set > it up already. The log above suggests that you already used the same > egiga/mvneta controller before on u-boot so that should be fine. right. > Currently, I cannot tell what is the problem here. I never tried 2nd > stage booting. Can you add the pinmuxing and try uart booting? Also, I have the pinmuxing, the dts I used is https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/armada-370-netgear-rn104.dts?id=b0187bd33fba065ec736dc33085914a137d390d3 And arch/arm/dts/armada-370-rn104-bb.dts contains: #include "arm/armada-370-netgear-rn104.dts" / { chosen { stdout-path = "/soc/internal-regs/serial@12000"; }; }; Double checking using dtc -I dtb -O dts arch/arm/dts/armada-370-rn104-bb.dtb shows that not all nodes (e.g. serial@12000) have pinctrl-* nodes, but the same applies to armada-370-mirabox.dts. > can you connect the RN104 directly to a PC and run wireshark on the > interface? You should see packets from the MAC above when e.g. ping > from RN104. Running tcpdump -i br-lan -vvv not ip6 and not host 192.168.77.177 and not host 192.168.77.157 and not host 192.168.77.151 on my router (which isn't a PC, but still should be good enough, shouldn't it? It has the address 192.168.77.1). Running "ping 192.168.77.1" seems to result in packages like this: 10:01:30.233928 42:40:00:10:40:60 > 00:00:00:34:00:12, ethertype MOP RC (0x6002), length 60: 0x0000: 0000 0034 0012 4240 0010 4060 6002 4000 ...4..B@..@``.@. 0x0010: 0054 8080 0012 4100 0002 c095 08e8 01a0 .T....A......... 0x0020: 1420 0020 8001 1020 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ which is utter nonsense. Will debug that further later today. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox