HiFive Unmatched: U-Boot stuck when loading Ramdisk
Hello,
I hope this is the right way to report u-boot issues. I tried to reach out to the RISC-V subsystem maintainer beforehand but didn't receive a response, hence sending this to the ML.
We are currently working on Alpine Linux support for the Hifive Unmatched and at least two of our developers have access to a board presently. While working on Alpine support, we noticed that U-Boot with sifive_unmatched_defconfig gets stuck while loading the Alpine initramfs. The last message received on the SiFive UART is:
Loading Ramdisk to ffa72000, end fffffc19 ...
Afterwards, U-Boot is stuck. We ran into this problem on two different boards independently. Both with u-boot-2021.10 as well as u-boot master (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set initrd_high manually (i.e. change the address region the Ramdisk is loaded to) everything works as expected. For example, `setenv initrd_high 0x85000000`. Maybe the default address region used for the Ramdisk overlaps with the U-Boot stack/text region or something?
I am not familiar with U-Boot internals, but briefly looking at the code and how the default Ramdisk address region is calculated, it seems to me that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration for the Unmatched and Unleashed doesn't. If I set it manually everything works as expected. For example:
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index d63a5f62fb..e1d3cb4ec4 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -25,6 +25,7 @@
#endif
+#define CONFIG_SYS_BOOTMAPSZ (256 << 20) #define CONFIG_SYS_SDRAM_BASE 0x80000000 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)
This causes the Ramdisk to be loaded to 8f9f7000, end 8ffffb3d by default which, looking at the Unmatched memory map, seems to be a more sensible address region for the Ramdisk:
Moving Image from 0x84000000 to 0x80200000, end=811a9000 ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8f9f7000, end 8ffffb3d ... OK Loading Device Tree to 000000008f9f1000, end 000000008f9f660b ... OK
If there is a better place to report this issue let me know. If you need more information to reproduce/debug this issue I would be very happy to help.
Greetings, Sören
On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel soeren@soeren-tempel.net wrote:
Hello,
I hope this is the right way to report u-boot issues. I tried to reach out to the RISC-V subsystem maintainer beforehand but didn't receive a response, hence sending this to the ML.
We are currently working on Alpine Linux support for the Hifive Unmatched and at least two of our developers have access to a board presently. While working on Alpine support, we noticed that U-Boot with sifive_unmatched_defconfig gets stuck while loading the Alpine initramfs. The last message received on the SiFive UART is:
Loading Ramdisk to ffa72000, end fffffc19 ...Afterwards, U-Boot is stuck. We ran into this problem on two different boards independently. Both with u-boot-2021.10 as well as u-boot master (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set initrd_high manually (i.e. change the address region the Ramdisk is loaded to) everything works as expected. For example, `setenv initrd_high 0x85000000`. Maybe the default address region used for the Ramdisk overlaps with the U-Boot stack/text region or something?
I am not familiar with U-Boot internals, but briefly looking at the code and how the default Ramdisk address region is calculated, it seems to me that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration for the Unmatched and Unleashed doesn't. If I set it manually everything works as expected. For example:
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index d63a5f62fb..e1d3cb4ec4 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -25,6 +25,7 @@ #endif +#define CONFIG_SYS_BOOTMAPSZ (256 << 20) #define CONFIG_SYS_SDRAM_BASE 0x80000000 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)This causes the Ramdisk to be loaded to 8f9f7000, end 8ffffb3d by default which, looking at the Unmatched memory map, seems to be a more sensible address region for the Ramdisk:
Moving Image from 0x84000000 to 0x80200000, end=811a9000 ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8f9f7000, end 8ffffb3d ... OK Loading Device Tree to 000000008f9f1000, end 000000008f9f660b ... OKIf there is a better place to report this issue let me know. If you need more information to reproduce/debug this issue I would be very happy to help.
Could you try these two changes together (see below)?
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 7157295..7254e06 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -67,7 +67,7 @@ "scriptaddr=0x88100000\0" \ "pxefile_addr_r=0x88200000\0" \ "ramdisk_addr_r=0x88300000\0" \ - "kernel_comp_addr_r=0x90000000\0" \ + "kernel_comp_addr_r=0x90300000\0" \ "kernel_comp_size=0x4000000\0" \ "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \ "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 7254e06..3b72304 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -62,6 +62,8 @@ "name=system,size=-,bootable,type=${type_guid_gpt_system};" #define CONFIG_EXTRA_ENV_SETTINGS \ + "fdt_high=0xffffffffffffffff\0" \ + "initrd_high=0xffffffffffffffff\0" \ "kernel_addr_r=0x84000000\0" \ "fdt_addr_r=0x88000000\0" \ "scriptaddr=0x88100000\0" \
Greetings, Sören
On Fri, Oct 15, 2021 at 06:29:09PM +0300, David Abdurachmanov wrote:
On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel soeren@soeren-tempel.net wrote:
Hello,
I hope this is the right way to report u-boot issues. I tried to reach out to the RISC-V subsystem maintainer beforehand but didn't receive a response, hence sending this to the ML.
We are currently working on Alpine Linux support for the Hifive Unmatched and at least two of our developers have access to a board presently. While working on Alpine support, we noticed that U-Boot with sifive_unmatched_defconfig gets stuck while loading the Alpine initramfs. The last message received on the SiFive UART is:
Loading Ramdisk to ffa72000, end fffffc19 ...Afterwards, U-Boot is stuck. We ran into this problem on two different boards independently. Both with u-boot-2021.10 as well as u-boot master (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set initrd_high manually (i.e. change the address region the Ramdisk is loaded to) everything works as expected. For example, `setenv initrd_high 0x85000000`. Maybe the default address region used for the Ramdisk overlaps with the U-Boot stack/text region or something?
I am not familiar with U-Boot internals, but briefly looking at the code and how the default Ramdisk address region is calculated, it seems to me that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration for the Unmatched and Unleashed doesn't. If I set it manually everything works as expected. For example:
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index d63a5f62fb..e1d3cb4ec4 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -25,6 +25,7 @@ #endif +#define CONFIG_SYS_BOOTMAPSZ (256 << 20) #define CONFIG_SYS_SDRAM_BASE 0x80000000 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)This causes the Ramdisk to be loaded to 8f9f7000, end 8ffffb3d by default which, looking at the Unmatched memory map, seems to be a more sensible address region for the Ramdisk:
Moving Image from 0x84000000 to 0x80200000, end=811a9000 ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8f9f7000, end 8ffffb3d ... OK Loading Device Tree to 000000008f9f1000, end 000000008f9f660b ... OKIf there is a better place to report this issue let me know. If you need more information to reproduce/debug this issue I would be very happy to help.
Could you try these two changes together (see below)?
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 7157295..7254e06 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -67,7 +67,7 @@ "scriptaddr=0x88100000\0" \ "pxefile_addr_r=0x88200000\0" \ "ramdisk_addr_r=0x88300000\0" \
- "kernel_comp_addr_r=0x90000000\0" \
- "kernel_comp_addr_r=0x90300000\0" \
"kernel_comp_size=0x4000000\0" \ "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \ "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 7254e06..3b72304 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -62,6 +62,8 @@ "name=system,size=-,bootable,type=${type_guid_gpt_system};" #define CONFIG_EXTRA_ENV_SETTINGS \
- "fdt_high=0xffffffffffffffff\0" \
- "initrd_high=0xffffffffffffffff\0" \
"kernel_addr_r=0x84000000\0" \ "fdt_addr_r=0x88000000\0" \ "scriptaddr=0x88100000\0" \
This second one is a hard NAK. The root problem is, I believe, that risc-v, until the current dev tree (so v2022.01) doesn't set the flag to prevent itself from being overwritten when preparing to boot the OS. So the correct change is indeed to set CONFIG_SYS_BOOTMAPSZ as this does tell U-Boot to always contain kernel/dtb/initrd to within that size window, from start of memory (roughly). Disabling dtb/initrd relocation on the otherhand introduces the different frequent failure of dtb being loaded at 4-but-not-8-byte-aligned addresses and thus being unusable.
Tom Rini trini@konsulko.com wrote:
I believe, that risc-v, until the current dev tree (so v2022.01) doesn't set the flag to prevent itself from being overwritten when preparing to boot the OS.
If I understand your comment correctly, this means that the issue has been fixed in the v2022.01 dev tree? If so: Could you point me to the commit fixing the issue?
So the correct change is indeed to set CONFIG_SYS_BOOTMAPSZ as this does tell U-Boot to always contain kernel/dtb/initrd to within that size window, from start of memory (roughly).
Alright, I guess we are applying this CONFIG_SYS_BOOTMAPSZ change downstream then until v2022.01 is released.
Greetings, Sören
On Sat, Oct 16, 2021 at 01:22:35PM +0200, Sören Tempel wrote:
Tom Rini trini@konsulko.com wrote:
I believe, that risc-v, until the current dev tree (so v2022.01) doesn't set the flag to prevent itself from being overwritten when preparing to boot the OS.
If I understand your comment correctly, this means that the issue has been fixed in the v2022.01 dev tree? If so: Could you point me to the commit fixing the issue?
It's a series actually: https://patchwork.ozlabs.org/project/uboot/list/?series=258110&state=*
So the correct change is indeed to set CONFIG_SYS_BOOTMAPSZ as this does tell U-Boot to always contain kernel/dtb/initrd to within that size window, from start of memory (roughly).
Alright, I guess we are applying this CONFIG_SYS_BOOTMAPSZ change downstream then until v2022.01 is released.
Sounds like a good plan, yes.
On Fri, Oct 15, 2021 at 7:16 PM Tom Rini trini@konsulko.com wrote:
On Fri, Oct 15, 2021 at 06:29:09PM +0300, David Abdurachmanov wrote:
On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel soeren@soeren-tempel.net wrote:
Hello,
I hope this is the right way to report u-boot issues. I tried to reach out to the RISC-V subsystem maintainer beforehand but didn't receive a response, hence sending this to the ML.
We are currently working on Alpine Linux support for the Hifive Unmatched and at least two of our developers have access to a board presently. While working on Alpine support, we noticed that U-Boot with sifive_unmatched_defconfig gets stuck while loading the Alpine initramfs. The last message received on the SiFive UART is:
Loading Ramdisk to ffa72000, end fffffc19 ...Afterwards, U-Boot is stuck. We ran into this problem on two different boards independently. Both with u-boot-2021.10 as well as u-boot master (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set initrd_high manually (i.e. change the address region the Ramdisk is loaded to) everything works as expected. For example, `setenv initrd_high 0x85000000`. Maybe the default address region used for the Ramdisk overlaps with the U-Boot stack/text region or something?
I am not familiar with U-Boot internals, but briefly looking at the code and how the default Ramdisk address region is calculated, it seems to me that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration for the Unmatched and Unleashed doesn't. If I set it manually everything works as expected. For example:
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index d63a5f62fb..e1d3cb4ec4 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -25,6 +25,7 @@ #endif +#define CONFIG_SYS_BOOTMAPSZ (256 << 20) #define CONFIG_SYS_SDRAM_BASE 0x80000000 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)This causes the Ramdisk to be loaded to 8f9f7000, end 8ffffb3d by default which, looking at the Unmatched memory map, seems to be a more sensible address region for the Ramdisk:
Moving Image from 0x84000000 to 0x80200000, end=811a9000 ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8f9f7000, end 8ffffb3d ... OK Loading Device Tree to 000000008f9f1000, end 000000008f9f660b ... OKIf there is a better place to report this issue let me know. If you need more information to reproduce/debug this issue I would be very happy to help.
Could you try these two changes together (see below)?
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 7157295..7254e06 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -67,7 +67,7 @@ "scriptaddr=0x88100000\0" \ "pxefile_addr_r=0x88200000\0" \ "ramdisk_addr_r=0x88300000\0" \
- "kernel_comp_addr_r=0x90000000\0" \
- "kernel_comp_addr_r=0x90300000\0" \
"kernel_comp_size=0x4000000\0" \ "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \ "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 7254e06..3b72304 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -62,6 +62,8 @@ "name=system,size=-,bootable,type=${type_guid_gpt_system};" #define CONFIG_EXTRA_ENV_SETTINGS \
- "fdt_high=0xffffffffffffffff\0" \
- "initrd_high=0xffffffffffffffff\0" \
"kernel_addr_r=0x84000000\0" \ "fdt_addr_r=0x88000000\0" \ "scriptaddr=0x88100000\0" \
This second one is a hard NAK. The root problem is, I believe, that risc-v, until the current dev tree (so v2022.01) doesn't set the flag to prevent itself from being overwritten when preparing to boot the OS. So the correct change is indeed to set CONFIG_SYS_BOOTMAPSZ as this does tell U-Boot to always contain kernel/dtb/initrd to within that size window, from start of memory (roughly). Disabling dtb/initrd relocation on the otherhand introduces the different frequent failure of dtb being loaded at 4-but-not-8-byte-aligned addresses and thus being unusable.
Yes, it seems to be the correct approach.
I believe all RISC-V boards (in upstream U-Boot and downstream too) disable relocation. The only exception is probably SiFive Unmatched right now and that causes some problems for distros (randomly).
I assume once LMB patchset lands someone will clean up riscv board configs.
david
-- Tom
participants (3)
-
David Abdurachmanov -
Sören Tempel -
Tom Rini