Re: [PATCH v4 0/6] rpi5: initial support
Hi Ivan,
first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
Best regards,
Jens
Hi,
On 01-12 14:10, Jens Maus wrote:
Hi Ivan,
first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
Yes, I am using rpi_arm64_defconfig for building the U-Boot. And as I wrote in the cover letter I am using openSUSE Tumbleweed image[1], [2]. Once you copy image to uSD card mount EFI uSD partition and copy new u-boot.bin over existing one. That it is. Just make sure you clearly sync, unmount the card. You can find config.txt file in the EFI partition.
Regards, Ivan
[1] https://en.opensuse.org/HCL:Raspberry_Pi4 [2] http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tu...
Hi,
Am 17.01.2024 um 16:07 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-12 14:10, Jens Maus wrote:
Hi Ivan,
first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
Yes, I am using rpi_arm64_defconfig for building the U-Boot. And as I wrote in the cover letter I am using openSUSE Tumbleweed image[1], [2]. Once you copy image to uSD card mount EFI uSD partition and copy new u-boot.bin over existing one. That it is. Just make sure you clearly sync, unmount the card. You can find config.txt file in the EFI partition.
That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?
Best Regards,
Jens
Hi,
On 17 Jan 2024, at 17:13, Jens Maus mail@jens-maus.de wrote:
Hi,
Am 17.01.2024 um 16:07 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-12 14:10, Jens Maus wrote:
Hi Ivan,
first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
Yes, I am using rpi_arm64_defconfig for building the U-Boot. And as I wrote in the cover letter I am using openSUSE Tumbleweed image[1], [2]. Once you copy image to uSD card mount EFI uSD partition and copy new u-boot.bin over existing one. That it is. Just make sure you clearly sync, unmount the card. You can find config.txt file in the EFI partition.
That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?
Unfortunately on RPi5 they moved UART debug port to separate connector [1], [2].
Let me update my Tumbleweed image and check again.
Just to reiterate that if not properly syncing content to uSD card could have strange side effects.
Regards, Ivan
[1] https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html [2] https://www.youtube.com/watch?v=kP2S3JUH-qk
Hi,
Am 17.01.2024 um 16:23 schrieb Ivan T. Ivanov iivanov@suse.de:
That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?
Unfortunately on RPi5 they moved UART debug port to separate connector [1], [2].
I know. In fact, I already have such a rpi debug probe [1] at my desk. Nevertheless, haven’t tried to fire up the rpi5 with your u-boot.bin to see if anything sensible comes up at that special UART debug port which could explain the stalling and no HDMI output I saw here last time I checked.
Let me update my Tumbleweed image and check again.
Thx. Can you perhaps also elaborate on your build environment for that particular u-boot.bin build? Or perhaps put a binary of it somewhere so that I could check if it works with your u-boot.bin build.
Just to reiterate that if not properly syncing content to uSD card could have strange side effects.
I am aware of these kind of issues. But in fact, I am quite sure I synced all content properly to the microSD card.
Best Regards,
Jens
[1] https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html
Hi,
On 17 Jan 2024, at 17:30, Jens Maus mail@jens-maus.de wrote:
Hi,
Am 17.01.2024 um 16:23 schrieb Ivan T. Ivanov iivanov@suse.de:
That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?
Unfortunately on RPi5 they moved UART debug port to separate connector [1], [2].
I know. In fact, I already have such a rpi debug probe [1] at my desk. Nevertheless, haven’t tried to fire up the rpi5 with your u-boot.bin to see if anything sensible comes up at that special UART debug port which could explain the stalling and no HDMI output I saw here last time I checked.
Let me update my Tumbleweed image and check again.
Thx. Can you perhaps also elaborate on your build environment for that particular u-boot.bin build? Or perhaps put a binary of it somewhere so that I could check if it works with your u-boot.bin build.
I have aarch64 based machine at hand running openSUSE, thus I am building U-boot “natively”, no cross-compiling.
$ make rpi_arm64_defconfig $ make
I just dumped latest Tumbleweed[1] to uSD card and copied u-boot.bin to EFI. I can see the HDMI output.
One thing which I forgot to mention is that once I see Grub2 prompt I change console parameter from ttyS0 to ttyAMA0 and usually add “ignore_loglevel earlycon”.
Regards, Ivan
[1] b66d5fa70e5cab998bc6000737015746c636e4b622397b407225b9de73f4a9be openSUSE-Tumbleweed-ARM-XFCE-raspberrypi.aarch64.raw.xz
Hi,
Am 17.01.2024 um 17:45 schrieb Ivan T. Ivanov iivanov@suse.de:
I have aarch64 based machine at hand running openSUSE, thus I am building U-boot “natively”, no cross-compiling.
$ make rpi_arm64_defconfig $ make
I just dumped latest Tumbleweed[1] to uSD card and copied u-boot.bin to EFI. I can see the HDMI output.
I actually just did that. Installed a fresh Tumbleweed on a microSD card, booted it up with a rpi4 and after installing all necessary build tools I applied your patches to u-boot 2024.01 sources, and then executed these two commands to let it compile a u-boot.bin file which I then put in /boot/efi to replace the u-boot.bin which is/was already there. Then I pulled the SD card and moved it over to the RaspberryPi5 in trying to get it booted up. However, again no HDMI output at all and unfortunately also the serial output on the debug probe does not show U-boot popping up at all. Interestingly, using the patched u-boot.bin with a RaspberryPi4 still works and it boots up perfectly fine, but not with the RaspberryPi5 I have here.
Any idea why this might be the case here while you report that the above mentioned procedure works for you? In fact, the RaspberryPi5 I have here is a 8GB model and with the rpi-eeprom version from 2024/01/05 [1] in case this might be relevant.
Best Regards,
Jens
[1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest
Hi,
On 18 Jan 2024, at 1:06, Jens Maus mail@jens-maus.de wrote:
Hi,
Am 17.01.2024 um 17:45 schrieb Ivan T. Ivanov iivanov@suse.de:
I have aarch64 based machine at hand running openSUSE, thus I am building U-boot “natively”, no cross-compiling.
$ make rpi_arm64_defconfig $ make
I just dumped latest Tumbleweed[1] to uSD card and copied u-boot.bin to EFI. I can see the HDMI output.
I actually just did that. Installed a fresh Tumbleweed on a microSD card, booted it up with a rpi4 and after installing all necessary build tools I applied your patches to u-boot 2024.01 sources, and then executed these two commands to let it compile a u-boot.bin file which I then put in /boot/efi to replace the u-boot.bin which is/was already there. Then I pulled the SD card and moved it over to the RaspberryPi5 in trying to get it booted up. However, again no HDMI output at all and unfortunately also the serial output on the debug probe does not show U-boot popping up at all. Interestingly, using the patched u-boot.bin with a RaspberryPi4 still works and it boots up perfectly fine, but not with the RaspberryPi5 I have here.
Any idea why this might be the case here while you report that the above mentioned procedure works for you? In fact, the RaspberryPi5 I have here is a 8GB model and with the rpi-eeprom version from 2024/01/05 [1] in case this might be relevant.
EEPROM version on mine device is older[1], but I suspect that size of the RAM is what make a difference, mine have only 4GB of RAM.
I am afraid you will have to connect that UART debug cable and share what is the memory map on your device :-)
Regards, Ivan
[1] RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
Hi,
Am 18.01.2024 um 09:33 schrieb Ivan T. Ivanov iivanov@suse.de:
I actually just did that. Installed a fresh Tumbleweed on a microSD card, booted it up with a rpi4 and after installing all necessary build tools I applied your patches to u-boot 2024.01 sources, and then executed these two commands to let it compile a u-boot.bin file which I then put in /boot/efi to replace the u-boot.bin which is/was already there. Then I pulled the SD card and moved it over to the RaspberryPi5 in trying to get it booted up. However, again no HDMI output at all and unfortunately also the serial output on the debug probe does not show U-boot popping up at all. Interestingly, using the patched u-boot.bin with a RaspberryPi4 still works and it boots up perfectly fine, but not with the RaspberryPi5 I have here.
Any idea why this might be the case here while you report that the above mentioned procedure works for you? In fact, the RaspberryPi5 I have here is a 8GB model and with the rpi-eeprom version from 2024/01/05 [1] in case this might be relevant.
EEPROM version on mine device is older[1], but I suspect that size of the RAM is what make a difference, mine have only 4GB of RAM.
This can be also of course the reason why it works for you while it doesn’t for me.
I am afraid you will have to connect that UART debug cable and share what is the memory map on your device :-)
No problem. Here is the output of the RPI bootloader boot up until the system stalls:
— cut here — RPi: BOOTSYS release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 boardrev d04170 stc 923866 AON_RESET: 00000003 PM_RSTS 00001000 RP1_BOOT chip ID: 0x20001927 PM_RSTS: 0x00001000 part 00000000 reset_info 00000000 PMIC reset-event 00000000 rtc 00000000 alarm 00000000 enabled 0 uSD voltage 3.3V Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 4267 DDR 4267 1 0 64 152 RP1_BOOT chip ID: 0x20001927
RP1_BOOT chip ID: 0x20001927 RP1_BOOT: fw size 25968 PCI2 init PCI2 reset PCIe scan 00001de4:00000001 RP1_CHIP_INFO 20001927
RPi: BOOTLOADER release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 boardrev d04170 stc 3892985 AON_RESET: 00000003 PM_RSTS 00001000 M.2 PCIe HAT not detected. usb_pd_init status 3 USB_PD CONFIG 0 41 Boot mode: SD (01) order f4 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276 OCR c0ff8000 [291] CID: 00035344534536344780519441cb0123 CSD: 400e00325b590001dbd37f800a404000 SD: bus-width: 4 spec: 2 SCR: 0x02458443 0x00000000 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2 MBR: 0x00002000, 131072 type: 0x0c MBR: 0x00022000, 1024000 type: 0x82 MBR: 0x0011c000,123572224 type: 0x83 MBR: 0x00000000, 0 type: 0x00 USB-PD: src-cap PDO object1 0x0a0191f4 Current 5000 mA Voltage 5000 mV USB-PD: src-cap PDO object2 0x0002d12c Current 3000 mA Voltage 9000 mV USB-PD: src-cap PDO object3 0x0003c0e1 Current 2250 mA Voltage 12000 mV USB-PD: src-cap PDO object4 0x0004b0b4 Current 1800 mA Voltage 15000 mV Trying partition: 0 type: 16 lba: 8192 'mkfs.fat' ' V ^ ' clusters 32695 (4) rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512 FAT16 clusters 32695 [sdcard] autoboot.txt not found Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0 Trying partition: 0 type: 16 lba: 8192 'mkfs.fat' ' V ^ ' clusters 32695 (4) rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512 FAT16 clusters 32695 Read config.txt bytes 3046 hnd 0x123c Read ubootconfig.txt bytes 35 hnd 0x468 [sdcard] extraconfig.txt not found [sdcard] pieeprom.upd not found usb_max_current_enable default 0 max-current 5000 Read bcm2712-rpi-5-b.dtb bytes 79357 hnd 0x139f dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd NOTICE: BL31: Built : 14:26:57, Jun 22 2023 — cut here —
Best Regards,
Jens
On 01-18 18:18, Jens Maus wrote:
I am afraid you will have to connect that UART debug cable and share what is the memory map on your device :-)
No problem.
Thanks, but could you apply attached patch and send me the logs when there is HDMI monitor connected to the board and one when cable is unplugged.
Regards, Ivan
Hi,
Am 19.01.2024 um 06:29 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-18 18:18, Jens Maus wrote:
I am afraid you will have to connect that UART debug cable and share what is the memory map on your device :-)
No problem.
Thanks, but could you apply attached patch and send me the logs when there is HDMI monitor connected to the board and one when cable is unplugged.
I applied that patch, but unfortunately no U-Boot specific output on the special debug UART of the rpi5 at all. As I have shown in my earlier email, the output ends with the „NOTICE: BL31…“ messages and there is no single line coming from U-boot at all. Also tried to add „#define DEBUG“ to the fdtdec.c file and added CONFIG_LOG=y as well as raising the maximum debug level to 9 to the U-boot build. This for some reason this does not end up in any additional U-boot debug line output on the RPi debug probe connected to the special UART of the rpi5. I even tried to connect the debug probe to the UART pins of the GPIO but also there no U-Boot debug output at all, I am afraid.
So where should that U-Boot debug output actually appear with your u-boot.bin patched version?
Best Regards, jens
Hi,
Am 19.01.24 um 08:21 schrieb Jens Maus:
Hi,
Am 19.01.2024 um 06:29 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-18 18:18, Jens Maus wrote:
I am afraid you will have to connect that UART debug cable and share what is the memory map on your device :-)
No problem.
Thanks, but could you apply attached patch and send me the logs when there is HDMI monitor connected to the board and one when cable is unplugged.
I applied that patch, but unfortunately no U-Boot specific output on the special debug UART of the rpi5 at all. As I have shown in my earlier email, the output ends with the „NOTICE: BL31…“ messages and there is no single line coming from U-boot at all. Also tried to add „#define DEBUG“ to the fdtdec.c file and added CONFIG_LOG=y as well as raising the maximum debug level to 9 to the U-boot build. This for some reason this does not end up in any additional U-boot debug line output on the RPi debug probe connected to the special UART of the rpi5. I even tried to connect the debug probe to the UART pins of the GPIO but also there no U-Boot debug output at all, I am afraid.
i don't know the reason for this issue, but here are some thoughts:
According to this issue [1] the 4 GB and the 8 GB variant uses completely different RAM ICs. Not sure this is relevant here or a red herring, because i would assume the VideoCore firmware would care about this.
Another idea could be to dump the runtime DT of both variants via sysfs (using official RPi OS) and compare them with each other. In the past there was a lot DT firmware hackery for the Raspberry Pi 4.
Regards
[1] - https://github.com/raspberrypi/firmware/issues/1854
So where should that U-Boot debug output actually appear with your u-boot.bin patched version?
Best Regards, jens
Hi,
Am 19.01.2024 um 10:20 schrieb Stefan Wahren wahrenst@gmx.net:
Another idea could be to dump the runtime DT of both variants via sysfs (using official RPi OS) and compare them with each other. In the past there was a lot DT firmware hackery for the Raspberry Pi 4.
Good idea indeed. I just did that and executed "dtc -I fs /sys/firmware/devicetree/base“ in a quick RaspberryPiOS installation.
See [1] for the corresponding output. Hopefully Ivan can do the same so that we can see if there are any differences that might explain why his u-boot patches are working for him while they does not for me.
Best Regards, Jens
[1] https://gist.github.com/jens-maus/497e03cf1305ffe8a07e3196c27d6ebd
participants (3)
-
Ivan T. Ivanov -
Jens Maus -
Stefan Wahren