U-Boot: Arm64: bootm gets stuck if RANDOMIZE_BASE is disabled
Hello,
I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.MX8QXP) and the results remain consistent.
I'm able to boot kernel when I use booti command. However when I use bootm to boot a U-Boot fitImage (with kernel and fdt load addresses/entrypoint in .its file same as I used for booti command; also tried disabling relocation for fdt by setting fdt_high=~0UL), the boot gets stuck at "Starting kernel ...". On disabling RANDOMIZE_BASE kconfig in Linux the same fitImage is able to boot.
I've tried enabling earlycon and U-Boot debug messages in common/bootm.c and arch/arm/lib/bootm.c but found no helpful difference in both boot flows. Please let me know if I'm missing something obvious or where do I start looking to debug this issue.
Best regards, Ehson
On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
Hello,
I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.MX8QXP) and the results remain consistent.
I'm able to boot kernel when I use booti command. However when I use bootm to boot a U-Boot fitImage (with kernel and fdt load addresses/entrypoint in .its file same as I used for booti command; also tried disabling relocation for fdt by setting fdt_high=~0UL), the boot gets stuck at "Starting kernel ...". On disabling RANDOMIZE_BASE kconfig in Linux the same fitImage is able to boot.
Can you say which address you're trying to load the kernel to?
I've tried enabling earlycon and U-Boot debug messages in common/bootm.c and arch/arm/lib/bootm.c but found no helpful difference in both boot flows. Please let me know if I'm missing something obvious or where do I start looking to debug this issue.
IIUC, the booti command respects the text_offset from the kernel header, whereas bootm will not. If you have a hard-coded offset, it's possible you're violating the offset the kernel expects, and where the kernel is not relocatable, if can't fix itself up.
I suspect you have a hard-coded offset of 0x80000, whereas recent kernels have a text offset of 0x00000. Your bootloader *should* read this dynamially rather than hard-coding it.
For details, see:
https://www.kernel.org/doc/html/v5.4/arm64/booting.html#call-the-kernel-imag...
Thanks, Mark.
On 7/13/21 2:25 PM, Mark Rutland wrote:
On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
Hello,
I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.MX8QXP) and the results remain consistent.
I'm able to boot kernel when I use booti command. However when I use bootm to boot a U-Boot fitImage (with kernel and fdt load addresses/entrypoint in .its file same as I used for booti command; also tried disabling relocation for fdt by setting fdt_high=~0UL), the boot gets stuck at "Starting kernel ...". On disabling RANDOMIZE_BASE kconfig in Linux the same fitImage is able to boot.
Can you say which address you're trying to load the kernel to?
At 0xf0000000, towards the end of first DRAM bank which starts at 0x40000000.
I've tried enabling earlycon and U-Boot debug messages in common/bootm.c and arch/arm/lib/bootm.c but found no helpful difference in both boot flows. Please let me know if I'm missing something obvious or where do I start looking to debug this issue.
IIUC, the booti command respects the text_offset from the kernel header, whereas bootm will not. If you have a hard-coded offset, it's possible you're violating the offset the kernel expects, and where the kernel is not relocatable, if can't fix itself up.
A minor correction is that when CONFIG_RANDOMIZE_BASE is _enabled_ the issue is gone. It is only observed when RANDOMIZE_BASE is _disabled_. Both booti and bootm calculate text_offset the same way based on arm64 image header->image_size field, in booti_setup() routine from U-Boot arch/arm/lib/image.c.
Regards, Ahsan
Hello folks,
Any insight would be highly appreciated.
On 7/13/21 2:53 PM, Ahsan Hussain wrote:
On 7/13/21 2:25 PM, Mark Rutland wrote:
On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
Hello,
I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.MX8QXP) and the results remain consistent.
I'm able to boot kernel when I use booti command. However when I use bootm to boot a U-Boot fitImage (with kernel and fdt load addresses/entrypoint in .its file same as I used for booti command; also tried disabling relocation for fdt by setting fdt_high=~0UL), the boot gets stuck at "Starting kernel ...". On disabling RANDOMIZE_BASE kconfig in Linux the same fitImage is able to boot.
Can you say which address you're trying to load the kernel to?
At 0xf0000000, towards the end of first DRAM bank which starts at 0x40000000.
I've tried enabling earlycon and U-Boot debug messages in common/bootm.c and arch/arm/lib/bootm.c but found no helpful difference in both boot flows. Please let me know if I'm missing something obvious or where do I start looking to debug this issue.
IIUC, the booti command respects the text_offset from the kernel header, whereas bootm will not. If you have a hard-coded offset, it's possible you're violating the offset the kernel expects, and where the kernel is not relocatable, if can't fix itself up.
A minor correction is that when CONFIG_RANDOMIZE_BASE is _enabled_ the issue is gone. It is only observed when RANDOMIZE_BASE is _disabled_. Both booti and bootm calculate text_offset the same way based on arm64 image header->image_size field, in booti_setup() routine from U-Boot arch/arm/lib/image.c.
Regards, Ahsan
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
participants (2)
-
Ahsan Hussain -
Mark Rutland