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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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-image
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 7/13/21 2:25 PM, Mark Rutland wrote:
On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
quoted
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.
quoted
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
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:
quoted
On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
quoted
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.
quoted
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel