Hello list,
I am attempting to get U-Boot chain loading another instance of U-Boot and need a little help: I'm currently using the Freescale iMX6ULL EVK, but am developing for a custom platform which is intended to have a primary boot loader in ROM and a field-updatable secondary boot loader, with a redundant backup, both stored in flash. I am currently testing with QSPI.
I figured on storing the secondary boot loader in ELF format (stripped) at known offset in QSPI and have been attempting to get the bootelf command load and execute it, either directly from the mapped QSPI address space, or by 'sf reading' the ELF file into ${loadaddr} and bootelf it from there. I have ensured .text and $loadaddr don't overlap.
The problem I am seeing happens after the secondary image starts, during its relocation to the top of external RAM. The processor gets a data abort interrupt and U-Boot subsequently hard resets.
I switched on the debug messages just for common/board_f.c on an otherwise mostly mx6ull_14x14_evk_defconfig from the v2018.07 tag and this is what I see immediately prior to the reset:
Monitor len: 0005ACCC Ram size: 20000000 Ram top: A0000000 TLB table from 9fff0000 to 9fff4000 Reserving 363k for U-Boot at: 9ff95000 Reserving 16392k for malloc() at: 9ef93000 Reserving 80 Bytes for Board Info at: 9ef92fb0 Reserving 240 Bytes for Global Data at: 9ef92ec0
RAM Configuration: Bank #0: 80000000 DRAM: 512 MiB New Stack Pointer is: 9ef92ea0 Relocation Offset is: 18795000 Relocating to 9ff95000, new gd at 9ef92ec0, sp at 9ef92ea0 data abort pc : [<87800c5c>] lr : [<9ff9570c>] sp : 9ef92ea0 ip : 00000030 fp : 00000017 r10: 878538dc r9 : 9ef92ec0 r8 : 9ffe8e98 r7 : 9ef95460 r6 : 87800000 r5 : 87800320 r4 : 18795000 r3 : 8785c648 r2 : 8785acd0 r1 : 00000017 r0 : 18795000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: e20110ff e3510017 1a000003 e0800004 (e5901000) Resetting CPU ...
resetting ...
U-Boot 2018.07-00008-ga14c5cc-dirty (Aug 16 2018 - 14:03:26 +0100)
The PC points to somewhere in arch/arm/lib/relocate.S. Here's the excerpt of the disassembly:
87800c48 <fixloop>: fixloop: ldmia r2!, {r0-r1} /* (r0,r1) <- (SRC location,fixup) */ 87800c48: e8b20003 ldm r2!, {r0, r1} and r1, r1, #0xff 87800c4c: e20110ff and r1, r1, #255 ; 0xff cmp r1, #R_ARM_RELATIVE 87800c50: e3510017 cmp r1, #23 bne fixnext 87800c54: 1a000003 bne 87800c68 <fixnext>
/* relative fix: increase location by offset */ add r0, r0, r4 87800c58: e0800004 add r0, r0, r4 ldr r1, [r0] 87800c5c: e5901000 ldr r1, [r0] add r1, r1, r4 87800c60: e0811004 add r1, r1, r4 str r1, [r0] 87800c64: e5801000 str r1, [r0]
87800c68 <fixnext>: fixnext: cmp r2, r3 87800c68: e1520003 cmp r2, r3 blo fixloop 87800c6c: 3afffff5 bcc 87800c48 <fixloop>
87800c70 <relocate_done>:
What could be going wrong here? Could it be something to do with the MMU or cache being left in a non-reset state by bootelf? I did try adding a call to cleanup_before_linux in do_bootelf_exec, but it made no obvious difference.
Thanks for any insights,
Neil