UC20's uboot and bootdelay

On a Raspberrypi 4 running UC20, I’d like to modify the uboot bootdelay parameter (so it never enters the uboot shell). On UbuntuServer, I would simply enter the shell and type in

setenv bootdelay -2 

which would create an uboot.env.

However, I am struggling to get this on UC20:

  • I cannot enter the uboot shell (ignores my key-presses)
  • copying uboot.env (from a UbuntuServer) results in failure to boot

Doing a bit of digging in the pi-gadget I found that uboot.env’s been replaced with uboot/ubuntu/boot.sel, I tried generating my own boot.sel with mkenvimage (and setting bootdelay=-2) without success.

I noticed a comment about snapd taking care of installing boot.sel (which is why the gadget’s one is empty). Is there a way to inform snapd that I would like it to change the bootdelay parameter?

here is a gadget that uses bootdelay=-2 (to allow using a RAK2245 HAT that uses GPS on serial (preventing any boot in a similar way))

particulary you want to look at the snapcraft.yaml changes in that commit to re-build u-boot:

sadly it was decided to use boot.scr instead of a uboot.env binary file with UC20, so you can not easily override any early-boot config anymore like bootdelay= is one …

UC20 also does not build u-boot from upstream source anymore but uses the binary deb from the ubuntu archive so it is not easily customizable for special hardware, the patch above re-builds the deb and allows adding additional patches as needed during that build…

1 Like

I’m happy I asked, this workaround is way beyond anything I would’ve tried. I’ll give it a try.

Is this something that snapd will eventually take care of using a system config option snap set system ... ?

Most likely not, we tend to not expose gadget (i.e. bootloader) configuration like this in snap set system ... (the pi-config stuff withstanding, that was arguably something of a mistake for us to start supporting, but now we are stuck with it). Of course this is not to stop a gadget from exposing it’s own config via something like

snap set pi uboot.bootdelay=...

which then fiddles with the bootloader config via a configure hook in the pi gadget snap. That would require some new interfaces perhaps, but is more likely to happen than snapd exposing uboot config through the system config.

I can imagine the idea is to get people to make their own gadget with their needed special configs instead of supporting a general pi-gadget with user settable configurations. Indeed, I don’t imagine ever needing to change this once a product using the gadget snap is set for production.

Trying to build the linked pi-gadget-loragw gives me this:

Building noserial-uboot
+ set -x
+ sed -i 's/# deb-src/deb-src/' /etc/apt/sources.list
+ apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease
Hit:2 http://ppa.launchpad.net/snappy-dev/image/ubuntu focal InRelease
Hit:3 http://ports.ubuntu.com/ubuntu-ports focal InRelease
Hit:4 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
+ apt-get source u-boot-rpi
Reading package lists... Done
E: You must put some 'deb-src' URIs in your sources.list
Failed to run 'override-build': Exit code was 100.

Opening a shell into the lxd container, I can confirm /etc/apt/sources.list is empty. I built with

snapcraft --use-lxd --debug --enable-experimental-package-repositories

thats very weird … though i do never use --use-lxd but run snapcraft manually inside the container, i documented this here:

must be that the lxd containers that snapcraft spawns when using --use-lxd are using a smaller/more cut down image then … (the normal focal lxd image comes with deb-src lines inluded but commented in sources.list)

Alright, looks like there are two lxd container variants. I tried to get it working with the --use-lxd flag by injecting the the src url instead of uncommenting it from sources.list

#sed -i 's/# deb-src/deb-src/' /etc/apt/sources.list
echo "deb-src http://archive.ubuntu.com/ubuntu/ focal main restricted universe" >> /etc/apt/sources.list

And things are looked better, until…

+ /usr/bin/echo -e 'arm64\trpi\t\trpi_3\t\tu-boot.bin'
/bin/bash: line 50: /usr/bin/echo: No such file or directory
Failed to run 'override-build': Exit code was 127.

Which was easily remedied by removing the full path to echo (that’s not present in the lightweight container). After another error, I added bc in the build-packages since it’s used in uboot’s Makefile (and it’s not shipped in the lightweight container).
After a while of compiling, I’m greeted with

*** Can't find default configuration "arch/../configs/rpi_arm64_defconfig"!

I’m now considering using the “heavyweight” lxd container to build snaps (lxc launch ubuntu:20.04 focal), as it resembles more the Ubuntu Server development environment that I’m more used to.
It feels a bit upside-down to create a full UbuntuServer 20.04 container inside UC20 as opposed to a lightweight container inside a full UbuntuServer 20.04 host. I think I can see how it makes sense though, as building the snap this way can never “contaminate” the host (UC20) and offers a familiar environment.
(fingers crossed)

EDIT: It snapped successfully. Now to make an UC20 image with it…

1 Like