[U-Boot] One u-boot.bin for Raspberry PI 3 and 4 - possible?
Hi List,
TLDR: As subject
I've been following Alexander Graf's uEFI+grub2 presentation on Raspberry PI[1]. I have it working on PI 3 and 4 and its great but I need to re-compile u-boot for each board which means lots of images.
I would like create a single image to boot grub on PI 3 and 4.
I did my own investigation but hit a wall. In board/raspberrypi/rpi/rpi.c there is a #IFNDEF..#ELSE around the definition of bcm283x_mem_map which selects a different memory layout to expose as extern struct mem_map for PI 4 vs anything else.
I did some hacking to expose two mem_map extern structs and pick the right one at runtime[2]. Of course this experiment is horrible and breaks all other boards:
board/raspberrypi/rpi/rpi.c static uint32_t rev_type;// = 0x11;
struct mm_region *mem_map_b = other_bcm283x_mem_map; /* other PIs */ struct mm_region *mem_map_a = bcm2711_bcm283x_mem_map; /* PI 4 */
uint32_t get_rpi_hw_ref(void) { /* doesn't work get_board_rev(); */ return rev_type; }
arch/arm/cpu/armv8/cache_v8.c /* before every use of mem_map... */
/* nasty hack */ struct mm_region *mem_map; if (get_rpi_hw_ref() == 0x11) { mem_map = mem_map_a; } else { mem_map = mem_map_b; }
rev_type gets set by get_board_rev() but I don't believe this function has been called before mem_map is used[3] so my hack always chooses the else branch.
I'm new to bootloader programming and waiting for a serial cable to arrive so am working blind but I suspect I'm up against some kind of chicken and egg problem where the memory map needs to be set before the board revision can be extracted using the mailbox driver, is anyone able to confirm this or suggest another approach?
My dream is to be able to compile a single u-boot.bin compiled as armv8-a and be able to boot any Raspberry PI 3/4 to grub2 from it. Is this realistic?
Cheers, Geoff
[1] https://www.youtube.com/watch?v=bNL1pd-rwCU [2] https://github.com/GeoffWilliams/u-boot/tree/nasty [3] If I initialise rev_type as 0x11 then it works on Raspberry PI 4 but if its commented boot fails with rainbow screen which tells me that rev_type wasn't assigned (or didn't contain 0x11...?) before mem_map was used.
Hi Geoff,
On 27/09/2019 04:16, Geoff Williams wrote:
Hi List,
TLDR: As subject
I've been following Alexander Graf's uEFI+grub2 presentation on Raspberry PI[1]. I have it working on PI 3 and 4 and its great but I need to re-compile u-boot for each board which means lots of images.
I would like create a single image to boot grub on PI 3 and 4.
I did my own investigation but hit a wall. In board/raspberrypi/rpi/rpi.c there is a #IFNDEF..#ELSE around the definition of bcm283x_mem_map which selects a different memory layout to expose as extern struct mem_map for PI 4 vs anything else.
I did some hacking to expose two mem_map extern structs and pick the right one at runtime[2]. Of course this experiment is horrible and breaks all other boards:
board/raspberrypi/rpi/rpi.c static uint32_t rev_type;// = 0x11;
struct mm_region *mem_map_b = other_bcm283x_mem_map; /* other PIs */ struct mm_region *mem_map_a = bcm2711_bcm283x_mem_map; /* PI 4 */ uint32_t get_rpi_hw_ref(void) { /* doesn't work get_board_rev(); */ return rev_type; }arch/arm/cpu/armv8/cache_v8.c /* before every use of mem_map... */
/* nasty hack */ struct mm_region *mem_map; if (get_rpi_hw_ref() == 0x11) { mem_map = mem_map_a; } else { mem_map = mem_map_b; }rev_type gets set by get_board_rev() but I don't believe this function has been called before mem_map is used[3] so my hack always chooses the else branch.
I'm new to bootloader programming and waiting for a serial cable to arrive so am working blind but I suspect I'm up against some kind of chicken and egg problem where the memory map needs to be set before the board revision can be extracted using the mailbox driver, is anyone able to confirm this or suggest another approach?
My dream is to be able to compile a single u-boot.bin compiled as armv8-a and be able to boot any Raspberry PI 3/4 to grub2 from it. Is this realistic?
Yes it is. I was working on this the last weeks and just posted the patches today. Would be nice if you could test and provide feedback :)
You can find the patch series here: https://patchwork.ozlabs.org/cover/1168351/
Regards, Matthias
Cheers, Geoff
[1] https://www.youtube.com/watch?v=bNL1pd-rwCU [2] https://github.com/GeoffWilliams/u-boot/tree/nasty [3] If I initialise rev_type as 0x11 then it works on Raspberry PI 4 but if its commented boot fails with rainbow screen which tells me that rev_type wasn't assigned (or didn't contain 0x11...?) before mem_map was used. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Matthias,
My dream is to be able to compile a single u-boot.bin compiled as armv8-a and be able to boot any Raspberry PI 3/4 to grub2 from it. Is this realistic?
Yes it is. I was working on this the last weeks and just posted the patches today. Would be nice if you could test and provide feedback :)
Thanks heaps for this! I'll make some time to test it over the weekend.
Cheers, Geoff
Hi Matthias,
Yes it is. I was working on this the last weeks and just posted the patches today. Would be nice if you could test and provide feedback :)
The patch works for me on Raspberry PI 4B 1GB and a Raspberry PI 3B v1.2 (BCM2837RIFBG) when applied to dfd590075c and using the rpi_4_defconfig I am able to boot to Linux via grub2 on both boards with the same u-boot.bin.
I did run into a couple of little problems though:
1. On the PI 4 with mainline u-boot the screen turns yellow and wraps around on itself a second or so into the linux boot (grub screen is fine). With the patch applied I get the same behaviour on the PI3. Everything still works the screen is just messed up.
If I instead use rpi_3_defconfig, I get a rainbow screen on the PI4 and the screen goes switches off instead of just turning yellow on the PI3.
2. USB wireless keyboard doesn't work until Linux loads on both systems if built with rpi_4_defconfig. I tried copying settings from rpi_3_defconfig[1] but then keyboard didn't work on either system.
Anyways, this is great thanks for fixing this.
Cheers, Geoff
[1] CONFIG_PREBOOT="usb start" CONFIG_CMD_USB=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_DWC2=y CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_LAN78XX=y CONFIG_USB_ETHER_SMSC95XX=y
On 28/09/2019 13:32, Geoff Williams wrote:
Hi Matthias,
Yes it is. I was working on this the last weeks and just posted the patches today. Would be nice if you could test and provide feedback :)
The patch works for me on Raspberry PI 4B 1GB and a Raspberry PI 3B v1.2 (BCM2837RIFBG) when applied to dfd590075c and using the rpi_4_defconfig I am able to boot to Linux via grub2 on both boards with the same u-boot.bin.
Nice! Happy to hear that I'm not the only one that sees this working :)
I did run into a couple of little problems though:
- On the PI 4 with mainline u-boot the screen turns yellow and wraps around on
itself a second or so into the linux boot (grub screen is fine). With the patch applied I get the same behaviour on the PI3. Everything still works the screen is just messed up.
Ok, the problem on the RPi3 honestly surprising. I'll have to check myself what's happening there. BTW when you talk about linux, do you use the downstream kernel for that?
If I instead use rpi_3_defconfig, I get a rainbow screen on the PI4 and the screen goes switches off instead of just turning yellow on the PI3.
It's exepcted that RPi4 won't boot with rpi_3_defconfig. Background is, that RPi3 defconfig uses still embedded device tree which does not boot on RPi4. On the other hand RPi4 defconfig uses the devicetree provided by the FW, that's why it also (somehow) works on RPi3. It's on my todo-list to create one single config for both RPi3 and RPi4, that wasn't done until now.
I'm not sure if you mean that the screen getting switched off on the RPi3 with rpi_3_defconfig is a regression or if this is the behaviour you expect.
- USB wireless keyboard doesn't work until Linux loads on both systems if
built with rpi_4_defconfig. I tried copying settings from rpi_3_defconfig[1] but then keyboard didn't work on either system.
Anyways, this is great thanks for fixing this.
Cheers, GeoffOn the RPi4 we don't have
[1] CONFIG_PREBOOT="usb start" CONFIG_CMD_USB=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_DWC2=y CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_LAN78XX=y CONFIG_USB_ETHER_SMSC95XX=y
Try to add CONFIG_USE_PREBOOT=y but that should only give you USB on the type-c connector. USB on the type-b connector isn't expect to work.
Regards, Matthias
Hi Matthias,
- On the PI 4 with mainline u-boot the screen turns yellow and wraps around on
itself a second or so into the linux boot (grub screen is fine). With the patch applied I get the same behaviour on the PI3. Everything still works the screen is just messed up.
Ok, the problem on the RPi3 honestly surprising. I'll have to check myself what's happening there. BTW when you talk about linux, do you use the downstream kernel for that?
I've been using a self-compiled kernel using sources from https://github.com/raspberrypi/linux and tag raspberrypi-kernel_1.20190819-1. I re-tested this by swapping to downstream kernel 4.19.75 from https://github.com/raspberrypi/firmware commit f5c626c64874d6e1482edf4a76aa22e5e54be63d (latest). Tried hdmi_safe=1 and same problem. I have copied all of the DTB files and overlays from upstream to the root of the memory card FAT partition and the kernel modules from firmware modules directory to /lib/modules - same result
If I instead use rpi_3_defconfig, I get a rainbow screen on the PI4 and the screen goes switches off instead of just turning yellow on the PI3.
It's exepcted that RPi4 won't boot with rpi_3_defconfig. Background is, that RPi3 defconfig uses still embedded device tree which does not boot on RPi4.
That makes sense, this problem will probably go away once a combined defconfig is available.
On the other hand RPi4 defconfig uses the devicetree provided by the FW, that's why it also (somehow) works on RPi3. It's on my todo-list to create one single config for both RPi3 and RPi4, that wasn't done until now.
This would be perfect, at the moment I'm just using the RPi4 version for both systems and this works fine apart from the screen and keyboard issues.
I'm not sure if you mean that the screen getting switched off on the RPi3 with rpi_3_defconfig is a regression or if this is the behaviour you expect.
I would expect the screen to stay on ;-). rpi_3_defconfig causes the screen to switch off right after the bcm2835-codec kernel module loads whereas rpi_4_defconfig causes a yellow screen on both boards almost instantly.
- USB wireless keyboard doesn't work until Linux loads on both systems if
built with rpi_4_defconfig. I tried copying settings from rpi_3_defconfig[1] but then keyboard didn't work on either system.
Try to add CONFIG_USE_PREBOOT=y but that should only give you USB on the type-c connector. USB on the type-b connector isn't expect to work.
My wireless keyboard has a type-a dongle so that's why it won't work yet.
Thanks, Geoff
On 29/09/2019 07:13, Geoff Williams wrote:
Hi Matthias,
- On the PI 4 with mainline u-boot the screen turns yellow and wraps around on
itself a second or so into the linux boot (grub screen is fine). With the patch applied I get the same behaviour on the PI3. Everything still works the screen is just messed up.
Ok, the problem on the RPi3 honestly surprising. I'll have to check myself what's happening there. BTW when you talk about linux, do you use the downstream kernel for that?
I've been using a self-compiled kernel using sources from https://github.com/raspberrypi/linux and tag raspberrypi-kernel_1.20190819-1. I re-tested this by swapping to downstream kernel 4.19.75 from https://github.com/raspberrypi/firmware commit f5c626c64874d6e1482edf4a76aa22e5e54be63d (latest). Tried hdmi_safe=1 and same problem. I have copied all of the DTB files and overlays from upstream to the root of the memory card FAT partition and the kernel modules from firmware modules directory to /lib/modules - same result
If I instead use rpi_3_defconfig, I get a rainbow screen on the PI4 and the screen goes switches off instead of just turning yellow on the PI3.
It's exepcted that RPi4 won't boot with rpi_3_defconfig. Background is, that RPi3 defconfig uses still embedded device tree which does not boot on RPi4.
That makes sense, this problem will probably go away once a combined defconfig is available.
On the other hand RPi4 defconfig uses the devicetree provided by the FW, that's why it also (somehow) works on RPi3. It's on my todo-list to create one single config for both RPi3 and RPi4, that wasn't done until now.
This would be perfect, at the moment I'm just using the RPi4 version for both systems and this works fine apart from the screen and keyboard issues.
I'm not sure if you mean that the screen getting switched off on the RPi3 with rpi_3_defconfig is a regression or if this is the behaviour you expect.
I would expect the screen to stay on ;-). rpi_3_defconfig causes the screen to switch off right after the bcm2835-codec kernel module loads whereas rpi_4_defconfig causes a yellow screen on both boards almost instantly.
And with a U-Boot based on f5c626c64874d6e1482edf4a76aa22e5e54be63d without my patches you see correct behavior?
Regards, Matthias
- USB wireless keyboard doesn't work until Linux loads on both systems if
built with rpi_4_defconfig. I tried copying settings from rpi_3_defconfig[1] but then keyboard didn't work on either system.
Try to add CONFIG_USE_PREBOOT=y but that should only give you USB on the type-c connector. USB on the type-b connector isn't expect to work.
My wireless keyboard has a type-a dongle so that's why it won't work yet.
Thanks, Geoff _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
And with a U-Boot based on f5c626c64874d6e1482edf4a76aa22e5e54be63d without my patches you see correct behavior?
The screen turning off issue was caused by a deployment script copying the wrong u-boot binary to the SD card! The patch does not introduce a regression on RPI 3 (tested before/after patch).
Once I switched over to the the real u-boot image the grub graphical font didn't load (irrespective of patch) I was able to fix this by changing the rpi_3_defconfig:
-CONFIG_OF_EMBED=y -CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" +CONFIG_OF_BOARD=y
I suspect my issues are to do with DTBs and that all these problems will go away once a single defconfig is available. The screen turning off issue I have no idea about but its from a much older version of u-boot and probably relates to something in the image I built.
Sorry for the noise - lets park this one.
Cheers, Geoff
On 03/10/2019 03:44, Geoff Williams wrote:
And with a U-Boot based on f5c626c64874d6e1482edf4a76aa22e5e54be63d without my patches you see correct behavior?
The screen turning off issue was caused by a deployment script copying the wrong u-boot binary to the SD card! The patch does not introduce a regression on RPI 3 (tested before/after patch).
Once I switched over to the the real u-boot image the grub graphical font didn't load (irrespective of patch) I was able to fix this by changing the rpi_3_defconfig:
-CONFIG_OF_EMBED=y -CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" +CONFIG_OF_BOARD=y
I suspect my issues are to do with DTBs and that all these problems will go away once a single defconfig is available. The screen turning off issue I have no idea about but its from a much older version of u-boot and probably relates to something in the image I built.
Sorry for the noise - lets park this one.
No problem, thanks for the feedback.
Regards, Matthias
Hi Geoff,
On 03/10/2019 03:44, Geoff Williams wrote:
And with a U-Boot based on f5c626c64874d6e1482edf4a76aa22e5e54be63d without my patches you see correct behavior?
The screen turning off issue was caused by a deployment script copying the wrong u-boot binary to the SD card! The patch does not introduce a regression on RPI 3 (tested before/after patch).
Once I switched over to the the real u-boot image the grub graphical font didn't load (irrespective of patch) I was able to fix this by changing the rpi_3_defconfig:
-CONFIG_OF_EMBED=y -CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" +CONFIG_OF_BOARD=y
I suspect my issues are to do with DTBs and that all these problems will go away once a single defconfig is available. The screen turning off issue I have no idea about but its from a much older version of u-boot and probably relates to something in the image I built.
In U-Boot master you should find now a rpi_arm64_defconfig which should boot on both RPi3 and RPi4.
Regards, Matthias
participants (2)
-
Geoff Williams -
Matthias Brugger