Re: Re: [PATCH v4 0/6] rpi5: initial support
+ u-boot@lists.denx.de
I am not sure how I drop the list in my last email, sorry.
On 01-19 12:56, Jens Maus wrote:
Hi Ivan,
Am 19.01.2024 um 12:22 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-19 11:49, Jens Maus wrote:
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
Thanks! Unfortunately at least first 2 memory banks looks the same as in 4GB version:
memory@0 { device_type = "memory"; reg = <0x00 0x00 0x3f800000 0x00 0x40000000 0xc0000000>; };
Jens, could you please, disconnect HDMI cable and capture devicetree file again.
Sure. Here the diff against the other device tree at gist:
— cut here — --- device-tree 2024-01-19 11:33:41.831797039 +0100 +++ device-tree2 2024-01-19 12:53:11.333845039 +0100 @@ -2,7 +2,7 @@
/ { #address-cells = <0x02>;
- memreserve = <0x3f800000 0x800000>;
- memreserve = <0x3fc00000 0x400000>; model = "Raspberry Pi 5 Model B Rev 1.0"; serial-number = "6b206ca09127ae99"; #size-cells = <0x01>;
@@ -41,7 +41,7 @@
memory@0 { device_type = "memory";
reg = <0x00 0x00 0x3f800000 0x00 0x40000000 0xc0000000 0x01 0x00 0x80000000 0x01 0x80000000 0x80000000>;
reg = <0x00 0x00 0x3fc00000 0x00 0x40000000 0xc0000000 0x01 0x00 0x80000000 0x01 0x80000000 0x80000000>;
Same here, expect that they are more memory banks, of course. It is really strange that you don't seen even single message from the U-Boot..
Hm... Ivan
Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov iivanov@suse.de:
Same here, expect that they are more memory banks, of course. It is really strange that you don't seen even single message from the U-Boot..
Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?
Perhaps it is really dependent on the eeprom version? Can you perhaps try to bump your eeprom version to the latest version to see if this might be the culprit?
regards, jens
Hi,
On 01-19 14:54, Jens Maus wrote:
Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov iivanov@suse.de:
Same here, expect that they are more memory banks, of course. It is really strange that you don't seen even single message from the U-Boot..
Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?
Yes, there is even small submarine on the top right side of the screen while U-Boot is running.
Perhaps it is really dependent on the eeprom version? Can you perhaps try to bump your eeprom version to the latest version to see if this might be the culprit?
Yes, will do this.
Regards, Ivan
Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-19 14:54, Jens Maus wrote:
Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov iivanov@suse.de:
Same here, expect that they are more memory banks, of course. It is really strange that you don't seen even single message from the U-Boot..
Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?
Yes, there is even small submarine on the top right side of the screen while U-Boot is running.
On the HDMI port, right? But what about the serial UART output? Is there anything U-Boot outputs right after the rpi boot loader is done? Here not. And as said, the same u-boot.bin boots up perfectly with a rpi4 and I can see the U-Boot submarine logo on the HDMI.
regards, jens
On 19 Jan 2024, at 16:08, Jens Maus mail@jens-maus.de wrote:
Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-19 14:54, Jens Maus wrote:
Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov iivanov@suse.de:
Same here, expect that they are more memory banks, of course. It is really strange that you don't seen even single message from the U-Boot..
Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?
Yes, there is even small submarine on the top right side of the screen while U-Boot is running.
On the HDMI port, right? But what about the serial UART output?
Yes, I can see serial output from U-Boot. I am using one of these simple USB<->UART cables. You can see serial output when you boot with RPiOS, when you use "Raspberry Pi Debug Probe”, right?
Ivan
Am 19.01.2024 um 15:24 schrieb Ivan T. Ivanov iivanov@suse.de:
On 19 Jan 2024, at 16:08, Jens Maus mail@jens-maus.de wrote:
On the HDMI port, right? But what about the serial UART output?
Yes, I can see serial output from U-Boot. I am using one of these simple USB<->UART cables. You can see serial output when you boot with RPiOS, when you use "Raspberry Pi Debug Probe”, right?
Yes, when booting up RPiOS I can first see the same serial debug output regarding the rpi boot loader until the same „NOTICE: BL31: …“ lines. Then RPiOS comes up and in the end I get an interactive serial console login "raspberrypi login:“ prompt on the RaspberryPi Debug Probe connection to that special UART port on the rpi5 pcb.
So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
regards, jens
On 01-19 17:12, Jens Maus wrote:
On the HDMI port, right? But what about the serial UART output?
Yes, I can see serial output from U-Boot. I am using one of these simple USB<->UART cables. You can see serial output when you boot with RPiOS, when you use "Raspberry Pi Debug Probe”, right?
Yes, when booting up RPiOS I can first see the same serial debug output regarding the rpi boot loader until the same „NOTICE: BL31: …“ lines. Then RPiOS comes up and in the end I get an interactive serial console login "raspberrypi login:“ prompt on the RaspberryPi Debug Probe connection to that special UART port on the rpi5 pcb.
Yeah, I don't know why I asked even though I saw those messages in your log.
So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
Yes :-) See attached log file.
Regards, Ivan
Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov iivanov@suse.de:
So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
Yes :-) See attached log file.
Really strange that in your case U-Boot seems to come up nicely and outputs something on the debug UART. Here definitely not. And the only difference in the rpi boot loader log outputs I could spot between yours and mine is:
— cut here — --- uboot2.log 2024-01-19 17:36:18.099674743 +0100 +++ uboot1.log 2024-01-19 17:33:06.794258533 +0100 @@ -1,13 +1,13 @@ -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 930201 +RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10 +BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede boardrev c04170 stc 815886 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 +Initialising SDRAM 'Samsung' 16Gb x2 total-size: 32 Gbit 4267 +DDR 4267 1 0 32 152 RP1_BOOT chip ID: 0x20001927
RP1_BOOT chip ID: 0x20001927 @@ -17,18 +17,17 @@ 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 3949421 +RPi: BOOTLOADER release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10 +BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede boardrev c04170 stc 3726990 AON_RESET: 00000003 PM_RSTS 00001000 -M.2 PCIe HAT not detected. usb_pd_init status 1 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 [310] -CID: 00035344534536344780519441cb0123 -CSD: 400e00325b590001dbd37f800a404000 -SD: bus-width: 4 spec: 2 SCR: 0x02458443 0x00000000 +OCR c0ff8000 [118] +CID: 00035344534e33324780fa570bda0169 +CSD: 400e00325b590000edb07f800a400000 +SD: bus-width: 4 spec: 2 SCR: 0x02358483 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 @@ -39,7 +38,6 @@ 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 @@ -52,6 +50,7 @@ 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 +PM_RSTS 00001000 Selecting USB low current limit
NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd — cut here —
So lets see if after you updated to a more recent rpi eeprom U-boot is still able to boot…
regards, jens
Hi,
Am 19.01.2024 um 17:53 schrieb Jens Maus mail@jens-maus.de:
Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov iivanov@suse.de:
So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
Yes :-) See attached log file.
Really strange that in your case U-Boot seems to come up nicely and outputs something on the debug UART. Here definitely not. And the only difference in the rpi boot loader log outputs I could spot between yours and mine is:
Replying to myself after having analysed this a bit further this evening...
[…]
So lets see if after you updated to a more recent rpi eeprom U-boot is still able to boot…
I actually do have some good and bad news:
1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
Best regards, jens
[1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest
Hi Jens,
Am 19.01.24 um 22:26 schrieb Jens Maus:
Hi,
Am 19.01.2024 um 17:53 schrieb Jens Maus mail@jens-maus.de:
Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov iivanov@suse.de:
So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
Yes :-) See attached log file.
Really strange that in your case U-Boot seems to come up nicely and outputs something on the debug UART. Here definitely not. And the only difference in the rpi boot loader log outputs I could spot between yours and mine is:
Replying to myself after having analysed this a bit further this evening...
[…]
So lets see if after you updated to a more recent rpi eeprom U-boot is still able to boot…
I actually do have some good and bad news:
Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
thanks for your work, but i think you are wasting your time. The rpi-eeprom release 2024/01/15 seems to be broken [1]
:-(
[1] - https://github.com/raspberrypi/rpi-eeprom/issues/523
Best regards, jens
[1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest
Hi,
Am 20.01.2024 um 10:22 schrieb Stefan Wahren wahrenst@gmx.net:
Am 19.01.24 um 22:26 schrieb Jens Maus:
I actually do have some good and bad news:
Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
thanks for your work, but i think you are wasting your time. The rpi-eeprom release 2024/01/15 seems to be broken [1]
:-(
Thanks for that info. However, I also tested older eeprom versions to identify when the issue that u-boot cannot boot a rpi5 started to appear. And I am afraid, it already starts with version 2023-11-20 right after the 2023-10-30 which currently seems to work fine with Ivan’s patches. Looking at the release notes of rpi-eeprom [1] one can see the following entries:
— cut here — 2023-11-20: Auto-detect support for PCIe expansion HAT (default + latest)
• Add autodetect support for PCIe expansion HATs • Add PCIE_PROBE=1 to the EEPROM config for custom PCIe exapansion designs that do not support the upcoming HAT spec. This gives similar behaviour to CM4 where PCIe x1 is enumerated to discover NVMe devices. • Fix loading of multiple initramfs images that are not 32-bit aligned sizes raspberrypi/firmware#1843 • Kernel load performance improvement - remove a memcpy — cut here —
So as I stated earlier, one probable catch for the u-boot patches here might be the mentioned PCIe changes with the rpi-eeprom 2023-11-20 version. Or it might be related to the „kernel load performance improvements“ mentioned?!?
For now I am of course using the 2023-10-30 rpi-eeprom version and so far it works flawlessly with Ivan’s u-boot patches. Still I hope Ivan or someone else can have a closer look why with the 2023-11-20 version of rpi-eeprom u-boot immediately stops working at all.
best regards, jens
[1] https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-...
Hi,
Am 20.01.24 um 10:48 schrieb Jens Maus:
Hi,
Am 20.01.2024 um 10:22 schrieb Stefan Wahren wahrenst@gmx.net:
Am 19.01.24 um 22:26 schrieb Jens Maus:
I actually do have some good and bad news:
Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
thanks for your work, but i think you are wasting your time. The rpi-eeprom release 2024/01/15 seems to be broken [1]
:-(
Thanks for that info. However, I also tested older eeprom versions to identify when the issue that u-boot cannot boot a rpi5 started to appear. And I am afraid, it already starts with version 2023-11-20 right after the 2023-10-30 which currently seems to work fine with Ivan’s patches. Looking at the release notes of rpi-eeprom [1] one can see the following entries:
sorry, i got it wrong. I thought only 2024-01-15 is affected. Unfortunately i'm not a U-Boot developer and i also don't have a RPi 5. So i only can give some (hopefully) smart advices :-)
One idea would be to enable early debug in U-Boot (no idea how to achieve this). I assume U-Boot crashes before it's able to print the first line, but it's hard to believe it crashes at the very first instruction of U-Boot. So with some luck we should be able to narrow done the cause.
Another point would be to open an Github issue on rpi-eeprom and ask them for advice, why 2023-11-20 stops to work in our case. Sure they don't want to support U-Boot, but they are also interested in Linux Mainline support.
Best regards
— cut here — 2023-11-20: Auto-detect support for PCIe expansion HAT (default + latest)
• Add autodetect support for PCIe expansion HATs • Add PCIE_PROBE=1 to the EEPROM config for custom PCIe exapansion designs that do not support the upcoming HAT spec. This gives similar behaviour to CM4 where PCIe x1 is enumerated to discover NVMe devices. • Fix loading of multiple initramfs images that are not 32-bit aligned sizes raspberrypi/firmware#1843 • Kernel load performance improvement - remove a memcpy— cut here —
So as I stated earlier, one probable catch for the u-boot patches here might be the mentioned PCIe changes with the rpi-eeprom 2023-11-20 version. Or it might be related to the „kernel load performance improvements“ mentioned?!?
For now I am of course using the 2023-10-30 rpi-eeprom version and so far it works flawlessly with Ivan’s u-boot patches. Still I hope Ivan or someone else can have a closer look why with the 2023-11-20 version of rpi-eeprom u-boot immediately stops working at all.
best regards, jens
[1] https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-...
Hi,
On 20 Jan 2024, at 12:50, Stefan Wahren wahrenst@gmx.net wrote:
Hi,
Am 20.01.24 um 10:48 schrieb Jens Maus:
Hi,
Am 20.01.2024 um 10:22 schrieb Stefan Wahren wahrenst@gmx.net:
Am 19.01.24 um 22:26 schrieb Jens Maus:
I actually do have some good and bad news:
Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
One idea would be to enable early debug in U-Boot (no idea how to achieve this). I assume U-Boot crashes before it's able to print the first line, but it's hard to believe it crashes at the very first instruction of U-Boot. So with some luck we should be able to narrow done the cause.
I was able to enable early debug UART in U-Boot and I will try to find what is happening, once I get some free cycles.
Regards, Ivan
Hi,
On 01-22 13:57, Ivan T. Ivanov wrote:
Am 20.01.24 um 10:48 schrieb Jens Maus:
Hi,
Am 20.01.2024 um 10:22 schrieb Stefan Wahren wahrenst@gmx.net:
Am 19.01.24 um 22:26 schrieb Jens Maus:
I actually do have some good and bad news:
Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
One idea would be to enable early debug in U-Boot (no idea how to achieve this). I assume U-Boot crashes before it's able to print the first line, but it's hard to believe it crashes at the very first instruction of U-Boot. So with some luck we should be able to narrow done the cause.
I was able to enable early debug UART in U-Boot and I will try to find what is happening, once I get some free cycles.
Ok, this was relatively easy to find :-)
New versions of EEPROM firmware change “kernel”/U-Boot load address from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is hardcoded to 0x80000 code run through the fields.
Hopefully simple patch like bellow make it work fine in older and newer EEPROM firmware versions.
Regards, Ivan
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 11ede9435d..ce64f9554f 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_BCM283X=y CONFIG_TEXT_BASE=0x00080000 +CONFIG_POSITION_INDEPENDENT=y
Date: Mon, 22 Jan 2024 16:16:34 +0200 From: "Ivan T. Ivanov" iivanov@suse.de
Hi,
On 01-22 13:57, Ivan T. Ivanov wrote:
Am 20.01.24 um 10:48 schrieb Jens Maus:
Hi,
Am 20.01.2024 um 10:22 schrieb Stefan Wahren wahrenst@gmx.net:
Am 19.01.24 um 22:26 schrieb Jens Maus:
I actually do have some good and bad news:
Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
One idea would be to enable early debug in U-Boot (no idea how to achieve this). I assume U-Boot crashes before it's able to print the first line, but it's hard to believe it crashes at the very first instruction of U-Boot. So with some luck we should be able to narrow done the cause.
I was able to enable early debug UART in U-Boot and I will try to find what is happening, once I get some free cycles.
Ok, this was relatively easy to find :-)
New versions of EEPROM firmware change “kernel”/U-Boot load address from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is hardcoded to 0x80000 code run through the fields.
Hopefully simple patch like bellow make it work fine in older and newer EEPROM firmware versions.
Regards, Ivan
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 11ede9435d..ce64f9554f 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_BCM283X=y CONFIG_TEXT_BASE=0x00080000 +CONFIG_POSITION_INDEPENDENT=y
Not sure if it really matters, but for the Apple M1 config I set CONFIG_TEXT_BASE to 0x00000000 (zero).
On Mon, Jan 22, 2024 at 03:30:00PM +0100, Mark Kettenis wrote:
Date: Mon, 22 Jan 2024 16:16:34 +0200 From: "Ivan T. Ivanov" iivanov@suse.de
Hi,
On 01-22 13:57, Ivan T. Ivanov wrote:
Am 20.01.24 um 10:48 schrieb Jens Maus:
Hi,
Am 20.01.2024 um 10:22 schrieb Stefan Wahren wahrenst@gmx.net:
Am 19.01.24 um 22:26 schrieb Jens Maus: > I actually do have some good and bad news: > > 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported. > > 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have. >
One idea would be to enable early debug in U-Boot (no idea how to achieve this). I assume U-Boot crashes before it's able to print the first line, but it's hard to believe it crashes at the very first instruction of U-Boot. So with some luck we should be able to narrow done the cause.
I was able to enable early debug UART in U-Boot and I will try to find what is happening, once I get some free cycles.
Ok, this was relatively easy to find :-)
New versions of EEPROM firmware change “kernel”/U-Boot load address from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is hardcoded to 0x80000 code run through the fields.
Hopefully simple patch like bellow make it work fine in older and newer EEPROM firmware versions.
Regards, Ivan
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 11ede9435d..ce64f9554f 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_BCM283X=y CONFIG_TEXT_BASE=0x00080000 +CONFIG_POSITION_INDEPENDENT=y
Not sure if it really matters, but for the Apple M1 config I set CONFIG_TEXT_BASE to 0x00000000 (zero).
It shouldn't matter. 0x0 is the default for TEXT_BASE in this case, but also a number of platforms set it to something else seemingly valid, but could I suspect still drop the setting as it should not matter at run time.
Hi,
Am 22.01.2024 um 15:16 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-22 13:57, Ivan T. Ivanov wrote:
I was able to enable early debug UART in U-Boot and I will try to find what is happening, once I get some free cycles.
Ok, this was relatively easy to find :-)
New versions of EEPROM firmware change “kernel”/U-Boot load address from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is hardcoded to 0x80000 code run through the fields.
Hopefully simple patch like bellow make it work fine in older and newer EEPROM firmware versions.
Thanks for this tiny but important fix on your patchset. In fact, I was able to verify that now with your latest v5 patchset for the initial rpi5 support even newer/latest rpi-eeprom versions work as expected and u-boot is chain loaded by the rpi boot loader.
So thanks again for that fix and I am looking forward to seeing your patchset integrated and hopefully also maintained in future so that USB boot and GPIO support will be added in the near future.
regards, jens
Hi Jens,
Am 23.01.24 um 12:11 schrieb Jens Maus:
Hi,
Am 22.01.2024 um 15:16 schrieb Ivan T. Ivanov iivanov@suse.de:
On 01-22 13:57, Ivan T. Ivanov wrote:
I was able to enable early debug UART in U-Boot and I will try to find what is happening, once I get some free cycles.
Ok, this was relatively easy to find :-)
New versions of EEPROM firmware change “kernel”/U-Boot load address from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is hardcoded to 0x80000 code run through the fields.
Hopefully simple patch like bellow make it work fine in older and newer EEPROM firmware versions.
Thanks for this tiny but important fix on your patchset. In fact, I was able to verify that now with your latest v5 patchset for the initial rpi5 support even newer/latest rpi-eeprom versions work as expected and u-boot is chain loaded by the rpi boot loader.
thank you for testing. Could you please give your Tested-by to v5 or at least parts of them?
So thanks again for that fix and I am looking forward to seeing your patchset integrated and hopefully also maintained in future so that USB boot and GPIO support will be added in the near future.
regards, jens
participants (5)
-
Ivan T. Ivanov -
Jens Maus -
Mark Kettenis -
Stefan Wahren -
Tom Rini