Although you still have to set mac addresses manually, mvneta works fine in 3.13.8 on a Mirabox. Using the exact same config to build 3.14 results in an mvneta that simply doesn't pass packets. No error messages, no problems configuring, it just doesn't pass packets. Configs and dmesgs attached.
Created attachment 131251 [details] config-3.13.8
Created attachment 131261 [details] config-3.14.0
Created attachment 131271 [details] dmesg-3.13.8
Created attachment 131281 [details] dmesg-3.14.0
Update: I just tried 3.13.9 and the problem appears so this must be related to commit 396b229b683fdc08d8705883860ec5a1b810546a Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Wed Mar 26 00:25:42 2014 +0100 net: mvneta: fix usage as a module on RGMII configurations
The problem is known: on Mirabox, setting the PCS bit breaks the network. However, on Armada XP GP, the PCS bit has to be set for the networking to work. In the past, the code was relying on having the PCS bit being set by the bootloader, and this patch changes that because relying on the bootloader to do the configuration no longer works when the driver is loaded as a module. This is because when the driver is loaded as a module, the networking clocks are gated during boot, and re-enabled only when the module is loaded. By gating the clock, all the register values of the hardware block are lost. Therefore, it must be the responsibility of the driver to reconfigure entirely the hardware block. Unfortunately, the hardware datasheet lacks details to understand clearly in which situations the PCS bit needs to be set, and in which situations it needs to be cleared. I've asked the hardware vendor already, but I haven't got an answer yet. Possible solutions: 1/ Wait a bit more for me to get more details about the hardware, in order to provide a fix that works in all situations, including when the driver is compiled as a module. 2/ Revert 396b229b683fdc08d8705883860ec5a1b810546a for now, which will restore networking on Armada 370, but will break usage of the driver as a module. I believe this could be a good temporary solution.
First, Thanks for all the work you've put into this platform. The boxes have great potential but they're still a bit quirky in certain areas, mac address propagation, having do a uboot dhcp to get any network at all when the kernel boots, and no working OpenOCD configuration. I've got 1 bootable unit and 3 bricks that BootROM just spits out a stream of "Booting from Nand". Anyway, I'm open to any solution really. I can stay at 3.13.8 for quite some time so I don't think there's a need to revert the patch for this reason and if I can't recover the 3 bricks I won't be buying any more of them anyway. If you need a tester I'm available for anything, or if you have a plan but no time to code, I'm up for that as well. Thanks again!
Thanks George for your feedback. I'm not sure this bug report is the best place to address all your comments, but I'll try to do so anyway: 1/ Regarding the MAC address propagation problem, there is unfortunately nothing we can do. The MAC addresses are passed from the bootloader to the kernel using vendor-specific ATAGs. The kernel maintainers have rejected patches that Willy Tarreau and myself had written to support those vendor-specific ATAGs, which allowed the kernel to get the MAC addresses assigned by the bootloader. The feedback of the kernel maintainers is that the bootloader should be Device Tree capable, and therefore that it should set the MAC addresses into the Device Tree. However, this suggestion completely fails the reality check: the Mirabox platform, today, is not shipped with a Device Tree capable bootloader, so users are left with no solution. However, as a workaround, you can in fact from the bootloader issue a certain number of "mw" U-Boot commands to assign the MAC addresses in a place where the kernel will find them again. I can give you more details about this if needed. 2/ The need to do a uboot dhcp to get any network at all. This used to be the case, but as of 3.13.x, I don't think this is valid anymore. Commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c is supposed to have fixed this problem. I can double check in my Mirabox here to make sure if you want. 3/ OpenOCD support. There was some discussion, and some success, in getting OpenOCD to work on the Mirabox. See the thread at https://www.mail-archive.com/openocd-devel@lists.sourceforge.net/msg04420.html for details. Regarding your bricked units, there is a way of recovering them by sending a bootloader through the serial port, and then reflashing a known-working version of U-Boot.
Thanks Thomas... 1) Currently my uboot script passes the mac addresses as kernel command line params and a udev rule in the initrd brings up the interfaces and calls 'ip link set' on both interface. Not pretty but it works. 2) Hey, what do you know. You're right about the dhcp but not specifying it breaks my mac address hack. ...Hmmm. If you're method with the "mw" works, I'd be interested. 3) I'followed that thread but never saw a working example posted. There is now a armada370.cfg target file in openocd that mirrors the one in the thread and it "seems" to work to a point. I created a board config for the mirabox which sets up the dram and nvram. In the only board I have left, it seems to work...I can upload programs to ram and run them ( a new uboot maybe) but on the bricked ones, I can onlyl halt, query and resume the target. Attempting to upload another uboot image fails about halfway through the upload. I also tried the serial method with kwuartboot but it always errors out around 30%. If you've got exact things to try on the uart boot front. I'd be grateful.
For the network problem, I've submitted a patch that reverts the problematic patch. See http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/246732.html. Regarding using "mw" to set up your MAC address, see http://www.spinics.net/lists/netdev/msg249552.html. Relevant part of it: For example, on a Mirabox, you can do: mw.l 0xD0072414 0x5C93; mw.l 0xD0072418 0xF0AD4E01; mw.l 0xD0076414 0x5C94; mw.l 0xD0076418 0xF0AD4E01; bootm Note however that this works only if the mvneta driver is built into the kernel. Compiled as a module, it will not work, because the clock of the network interface will be gated, which will lead to the loss of all its register values, including the registers that store the MAC address. Regarding the OpenOCD thing, I'd suggest you to get involved in the openocd mailing list discussion, since it has been revived this week. Which u-boot image are you trying to upload through kwuartboot?
Thanks Thomas. Your method for setting the mac address worked great. As for recovering my 3 dead boxes... I did manage to recover them but I'm not sure how. :) I swear I tried kwuartboot and kwboot with u-boot-db88f6710bp_uart.bin a hundred times over the past year but today it worked. I also finally got jtag to work. Go figure. :) Back to the original problem... I'll grab the patch and try it tomorrow. Thanks.
Tried the patch and it works. Closing the issue.
Patch http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/246732.html fixed the issue.