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
