I followed the instructions in README.hardware with my MPC8315E-RDBA using a minimal image from master, and unfortunately the machine does not boot correctly from NFS, apparently because it can't find eth0 - despite it being clearly initialised earlier in the kernel log. The log of my entire interaction with the system is attached. (If I've done something wrong here it may just be a case of fixing the instructions.)
Created attachment 185 [details] Log of interaction with u-boot and boot process
If you boot with an on disk image does the interface come up properly?
Bruce, can you find someone to take a look at this? I think there are only 3 of these things working at the moment.
Here's the error in the log: IP-Config: Failed to open eth0 IP-Config: Device `eth0' not found. The ethernet isn't being brought up properly, but from the kernel point of view, the driver is loading and initializing the gianfar properly. I'm betting that this is a MAC address problem, what does the DTB have for the MAC ?
Not sure if you mean the dts file from which the dtb is produced - ${WORKDIR}/linux/arch/powerpc/boot/dts/mpc8315erdb.dts - if so, it has some lines like the following: local-mac-address = [ 00 00 00 00 00 00 ];
Aha. So that is the issue (most likely). There's two ways that the mac gets to the kernel. On a modern u-boot it is pulled from nvram and then passed to the kernel via the right OF structures. The uboot here is likely to old for that. If you update the dts with the mac off the board (there should be a sticker with it), you'll have more like. I also recall a command line way to set this, but can't find it at the moment.
OK, this worked, thanks. My MPC8315E-RDBA had no sticker with the MAC addresses (to be fair I did not unscrew the board and examine the underside, but it's likely there wasn't one there either) so in the end I just booted the factory OS and grabbed them that way. We'd probably rather not have to get users to patch the kernel source in order to get working ethernet at boot, however. Presumably the proper solution is to tell people to upgrade their u-boot? If that's the case, Darren ran into problems doing this so I don't necessarily want to try it until we have some confidence that his experiences won't be repeated. (As an aside, the MAC addresses were 04:00:00:00:00:0A and 04:00:00:00:00:0B - these don't look valid; maybe the rules are different for reference platforms rather than actual products.)
The MACs can be 'whatever' and largely semi-random on the dev boards. unlike many platforms, they can be easily changed/controlled from both linux and the bootloader on these boards. This is worth documenting the the README.hardware, want to send a quick patch with your experience / technique ? We should just point out that the default is "unset" (all zeros) and with the vendor u-boot, you need to modify the dts to have a mac address that works in your configuration. And yes, a u-boot udpate would address the issue, and we are getting ready to try to look into this here, but need to have an ICE handy to un-brick the board if it goes bad. so at the moment, we can stick with the documentation route, with plans to address it properly in the future.
Have posted patches to add a workaround and updated README.hardware to the poky ML.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=76942c0080d3d68f0c39bb8fde80f9779c2080bb and http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8af286885353d5740971f137f8c1ada2b43dd2a8
NFS boot works.