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
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
