Raspberrypi 4: meta-raspberrypi/dunfell - in 3 days from no network in U-Boot to dhcp/tftp

-

Introduction

This work is sponsored by Reliable Embedded Systems. You can find more information about our training/consulting services here.

Objectives

My favorite development setup is to have the boot loader load kernel/device tree over tftp and mount the rootfs over NFS. The first part does not work out of the box on a Raspberrypi 4 with meta-raspberrypi/dunfell since the default U-Boot (2020.01) does not yet support it.

What to do in such a case?


Interact with the community

Report your problem

I opened this issue at the meta-raspberrypi repo with that content:

U-Boot does not seem to support networking on the Raspberry Pi 4 - 64 Bit

Steps to reproduce the issue:

U-Boot> setenv autoload no
U-Boot> dhcp
No ethernet found.
U-Boot> ping 192.168.42.1
No ethernet found.
ping failed; host 192.168.42.1 is not alive
U-Boot>

Describe the results you received:

No ethernet found.

Describe the results you expected:

pong

Additional information you deem important (e.g. issue happens only occasionally):
Happens always

Additional details (revisions used, host distro, etc.):
Are there any plans to fix this?
If so what's the time frame?

Try some things

As it's not unusual with some communities I was pretty quickly put in touch with the right contact person and tried what was suggested.

Upgrade U-Boot Version

Network support is available in a more recent U-Boot version.

I found a newer U-Boot recipe (2020.07) at poky/master, but I work with poky/dunfell. Hmm let's see if/how we can back-port this.

It turned out that U-Boot 2020.07 requires some function which was introduced in a class which is not present in poky/dunfell. Now what? Back-porting!

poky: new cml1.bbclass required by new U-Boot recipe

Brave as I am I took the cml1.bbclass from poky/master and updated poky/dunfell as you can see here. As far as I can tell it did not break things so far, but I need more testing.

meta-raspberrypi-ml-bsp: new U-Boot recipe + patches

Initially I just copied over the U-Boot 2020.07 recipe from poky/master to my meta-raspberrypi-ml-bsp/dunfell branch as you can see here. Then it was necessary to add a few patches to make network work which I did via this bbappend.

meta-raspberrypi: hack for U-Boot

Finally I added a hack in my meta-raspberrypi fork in order to automatically get the kernel/device tree via tftp. I turned boot.cmd.in into a symlink which either points to boot.cmd.in.sdcard or boot.cmd.in.tftp now.

My boot.cmd.in.tftp to boot with kernel/device tree over tftp instead of sd card looks like this:

fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs
setenv autoload no && dhcp && setenv serverip @@SERVERIP@@
setenv kernel @@KERNEL_IMAGETYPE@@ && setenv bootfile ${hostname}/${kernel}
setenv kernel_netload tftp ${kernel_addr_r} ${bootfile}
setenv fdt bcm2711-rpi-4-b.dtb && setenv myfdtfile ${hostname}/${fdt}
setenv fdt_netload tftp ${fdt_addr_r} ${myfdtfile}
run kernel_netload && run fdt_netload
@@KERNEL_BOOTCMD@@ ${kernel_addr_r} - ${fdt_addr}

as you can see here.

local.conf: kernel command line

In order to have U-Boot load the kernel/device tree over tftp instead of sd card you need to adjust the symlink above and this in local.conf:

# boot with rootfs on SD card:
# CMDLINE = "dwc_otg.lpm_enable=0 ${SERIAL} root=/dev/mmcblk1p2 rootfstype=ext4 rootwait"
# boot with rootfs over nfs:
SERVERIP="192.168.42.108"
CMDLINE = "dwc_otg.lpm_enable=0 ${SERIAL} root=/dev/nfs rootfstype=nfs nfsroot=${SERVERIP}:/opt/poky/raspi-4-rootfs,v3,tcp ip=dhcp rootwait"

Conclusion

Did you ever try to get a fix from your board/chip manufacturer? How was your experience with that? 

That's another example of the power of "the Open Source community". It took (only) 3 days (and I am responsible for at least 1 day delay) to get the network  in U-Boot to work on the raspberrypi 4. 

Wow - simply wow! 

Thank you community and especially Andrei and Matthias and please keep up the hard work.

Comments

Post a Comment

Popular posts from this blog

Yocto: BitBake and Dependencies - e.g. One recipe to use output of another recipe

-
Image
It feels weird to help some get their working build to fail and then for them to be happy about it... (RP) Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to look into BitBake dependencies. As an example let's take recipe A ( u-boot-phytex-imx ) which needs the output of recipe B ( firmware-imx-8m ) for a successful compilation. (Please don't ask why.) To be more precise here is an excerpt of recipe A ( u-boot-phytex-imx ): # --> this funny u-boot from Phytec needs the ddr_firmware binaries in ${S} # Note: here we copy deployed stuff from another recipe # to the source dir of this recipe! # # DEPENDS deals with build-time depenencies # Read my blog post to find out why DEPENDS does not work here # # DEPENDS += " \ # firmware-imx-8m \ # " # RDEPENDS is wrong anyhow for what I want
Read more

Yocto: kernel modules not showing up in the rootfs

-
Image
Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to point out a well known and documented issue with kernel modules not ending up on the root file system which is likely overseen by people until they stumble over it.   Kernel module(s) So you created a brand new kernel module, or you just wanted to include all the kernel modules in the root file system, or just one of them. You reach out to the community mailing list or chat with something like this: I have MACHINE_EXTRA_RRECOMMENDS + = "kernel-modules" in my machine configuration. When I look into the rootfs I see no modules installed in /lib/modules/ $( uname -r ) . I get only a modules tarball in the deploy directory. I also tried MACHINE_EXTRA_RDEPENDS + = "kernel-modules" and it still does not work. What am I doing wrong? Check the Mega Manual If things d
Read more

Yocto/Qt5: hello-qt part2 - Licensing

-
Image
Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to show my journey trying to build a hello-qt application and reasons why I don't like Qt . As far as I can tell this is going to be a multi part blog post. You might want to have a look at part one as well. Disclaimer: I am not a lawyer, so I can not give legal advice. GPL and LGPL licenses LGPL v2.x Typically libraries are licensed with this license You need to provide the source code (including modifications) and instructions on how to build the LGPL v2.1 licensed code In case your application links statically against LGPL licensed code you need to provide the object files of your applications to be able to replace the LGPL'ed code with different versions In case your application links dynamically against LGPL licensed code you can replace the LGPL'ed libraries without the objec
Read more