[U-Boot] Chain loading U-Boot on ARM v7, data abort

[Neil Stainton]

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