[PATCH v3 0/4] mvebu: Add network support for Armada 370/XP
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Tue Nov 11 01:06:49 PST 2014
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 at 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 at 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 at ..@``. at .
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/ |
More information about the barebox
mailing list