[PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

Sebastian Hesselbarth sebastian.hesselbarth at gmail.com
Mon Nov 10 11:36:07 PST 2014


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.
>
>> 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.

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,
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.

Sebastian




More information about the barebox mailing list