boards/RPi: switch to the u-boot aarch64 combined image #192
Conversation
|
You should probably rebase against the development branch, instead of the release branch. |
|
(changing the branch brough yet-to-be merged documentation commits, don't worry too much until it's "ready") Converting to draft since it's WIP. |
|
Hi, sorry it took a while to come back to this.
If we directly depend on the "thing", we should import the package locally. Like we're doing with a few things like TF-A and firmwarey bits. I think we should own a copy of the firmware packages to ensure that we are testing specific versions, and that we can upgrade them without causing other changes. The main things we should rely on from Nixpkgs should be the toolchain, e.g. compilers and generic libraries for toolchain use mainly. |
That sounds like the most sensible approach, indeed! I didn't want to sound rude though, so I did not propose it :p |
The current version of the raspberryPi-aarch64 image only works on a couple of RaspberryPi boards: 3b and 4b. Adding support for other boards can be achieved by using u-boot's `rpi_arm64_defconfig`, which supports: - Raspberry Pi 3b - Raspberry Pi 3b+ - Raspberry Pi 4b - Raspberry Pi 400 - Raspberry Pi CM 3 - Raspberry Pi CM 3+ - Raspberry Pi CM 4 - Raspberry Pi CM 4s - Raspberry Pi zero 2 w This however requires shipping the .dtb files along with the overlays inside the shared image, which this commit also adds. Unfortunately, the raspberrypifw package is now outdated, so rather than depending on nix OS packages, we also vendor our own copy of it.
Tow-boot's user interface requires USB support to interact with the
boot configuration menu, which is unfortunately disabled by default
on the CM4, as can be seen in page 7 of the CM4 datasheet[1]:
The firmware disables the USB interface by default to save power.
In recent versions of Raspberry Pi OS (Bullseye) it is
automatically enabled by the otg_mode=1 setting in the config.txt
file. If you are using a different OS, or an older version of
Raspberry Pi OS, you will need to add this to config.txt to enable
the USB interface.
In my experience on a CM4, setting otg_mode=1 was not sufficient to get
my keyboard to work in both Linux or Tow-Boot, while using
worked in all cases `dtoverlay=dwc2,dr_mode=host`. This is why I opted
to use this setting.
As per this comment[2], it also seems to apply to the CM4S.
[1] https://datasheets.raspberrypi.com/cm4/cm4-datasheet.pdf
[2] https://www.jeffgeerling.com/comment/31588#comment-31588
mupuf
changed the title
|
@samueldr: Sorry for the delay! I think I have done what you wanted me to do, although I must admit that I am wholly unfamiliar with the nix build system. I merely duplicated what you did with the armlogic, and pretty-much copy/pasted the upstream raspberrypi-firmware package (I just kept the relevant files and dropped all the rest). In any case, this is a nice improvement: it works both on my cm4 and my raspberry Pi 3+ |
|
@samueldr: gentle ping :) |
|
Trying to boot a recent nixos iso image: https://hydra.nixos.org/build/211623536/download/1/nixos-minimal-new-kernel-no-zfs-23.05pre460365.3c5319ad3aa-aarch64-linux.iso using your PR in a Rpi B3+. OS Stage 1 boot hangs in: EDIT: More tests:
EDIT 2: Adding |
|
Thank you for testing the series!
Not sure what defaults the tow-boot project should go for (upstream or vendor). I think we should prefer upstream, given that the vendor-recommended way of booting the vendor-recommended kernel would be directly through If we go this route, this would mean we need to create another nix package to download kernel-generated dtbs for the RPi, and we'll need to keep them relatively up to date. Anyway, mind trying to add the upstream dtbs and see if this solves your "weird" keyboard behaviour? |
|
Thanks for reply, some interesting things I've discovered: I put the mainline dtbs in Reading docs seems like Also reading this comment #53 (comment) I'm starting to be confused about how Tow-Boot wants to manage this. |
Ha, good that you are starting to figure out what is going on!
I see! So, the adaptation overlay is not compatible with newer kernels anymore? I can't say I am surprised, as this definitely feels like a hack. Would be good if you could figure out if using the upstream dtbs actually solve your keyboard weirdness!
I agree with the objective of the project. This BS should not go in the way of users! According to https://elinux.org/Device_Tree_Linux#forward_and_backward_dts_compatibility, newer kernels need to work with old dtbs, but the opposite is not guaranteed. So, from this PoV, we want the kernel we want to boot to come with its own dtbs (so that they are the most feature-complete), but we could also select a kernel that we consider good-enough for most boards and vendor its dtb. The problem with asking kernels to come with their own dtbs is that, of course, the firmware doesn't know ahead of time which dtbs to load... so that means tow-boot would have to load the right one once it would have selected the kernel to boot. I wonder if there is a way for us to know which board we are running on so that we could be responsible for loading the right dtb (and overlays) at runtime (there must be an RPC for that, but not sure if it is documented). Additionally, if we can't rely on config.txt to select which overlays to load, we'll have to add a way for users to select which overlays they want to load at boot time, akin to what a BIOS config screen would be. This may be a little too much to ask from tow-boot? |
|
@samueldr: May we ask for your thoughts on this matter? |
The current version of the raspberryPi-aarch64 image only works on a couple of RaspberryPi boards: 3b and 4b.
Adding support for other boards can be achieved by using u-boot's
rpi_arm64_defconfig, which supports:This however requires shipping the .dtb files along with the overlays inside the shared image, which this commit also adds.
Unfortunately, the raspberrypifw needs to be updated to achieve this goal, which explains why this commit is marked at WIP: