Gaisler Linux 5.10 + mklinuximg u-boot incompatability?

General - Software
1

I’ve been working on updating a UT700 project that was based on the older 4.9 kernel with mklinuximg 2.11. It was setup to use u-boot to load, verify, and use the u-boot ‘bootelf’ command to load the image produced by mklilnuximg. This setup has worked quite well for a number of years. I realize that u-boot lost SPARC support back in 2017 and it isn’t officially supported in any way, but I’m unsupported doesn’t mean incompatible and that I can find a path forward without starting over on the boot loader.

After updating our project and driver to the 5.10 kernel and newer buildroot setup, I am able to boot the images produced by mklinuximg 2.0.17 or 2.0.18 using grmon without issue. If I attempt to boot the same image from u-boot I quickly hit an unimplemented or illegal instruction trap.

Comparing the elf images produced by the older mklinuximg and current versions, it seems this may be related to the addresses in that file:

mklinuximg 2.0.11:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000f50  40000000  40000000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000050  40000f50  40000f50  00010f50  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000010  40000fa0  40000fa0  00010fa0  2**2
                  ALLOC
  3 .mmu_tables   00000a00  40002000  40002000  00010fa0  2**0
                  ALLOC
  4 .vmlinux      00f1cc34  40004000  40004000  00014000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  5 .startup_prom 00006f90  40f20c40  40f20c40  00f30c40  2**3
                  CONTENTS, ALLOC, LOAD, CODE

mklinuximg 2.0.17:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000f40  40000000  40000000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000070  40000f40  40000f40  00010f40  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000010  40000fb0  40000fb0  00010fb0  2**2
                  ALLOC
  3 .mmu_tables   00000a00  40002000  40002000  00010fb0  2**0
                  ALLOC
  4 .vmlinux      014e6a14  40004000  40004000  00014000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  5 .startup_bss  00000170  ffd03000  ffd03000  01513000  2**2    
                  ALLOC
  6 .ps_move_startup 00008770  ffd03170  414eaa20  01503170  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  7 .ps_move_prom 000013d0  ffd0b8e0  414f3190  0150b8e0  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  8 .prom_bss     00000050  ffd0ccb0  414f4560  0150ccb0  2**3
                  ALLOC
  9 .ps_stack     00001300  ffd12d00  414fa5b0  0150ccb0  2**0
                  ALLOC
 10 .comment      00000035  00000000  00000000  0150ccb0  2**0
                  CONTENTS, READONLY

Getting a stack trace out of grmon shows it attempting to call the start of the .ps_move_startup section and failing.

  IU in error mode (tt = 0x02, illegal instruction)
  0x40000800: 91d02000  ta  0x0

      TIME     ADDRESS   INSTRUCTION                   RESULT      SYMBOL
    491341863  40000954  be  0x4000096C                [00000000]  -
    491341891  40000958  nop                           [00000000]  -
    491341896  4000095C  sethi  %hi(0xFFD03000), %g1   [FFD03000]  -
    491341906  40000960  or  %g1, 0x170, %g1           [FFD03170]  -
    491342001  40000964  call  %g1                     [40000964]  -
    491342003  40000968  nop                           [00000000]  -
    491342029  FFD03170  unimp                         [  TRAP  ]  -
    491342105  40000020  ba  0x40000800                [00000000]  -
    491342107  40000024  mov  2, %o0                   [00000002]  -
    491342109  40000800  ta  0x0                       [  TRAP  ]  -

Since u-boot doesn’t support the MMU - does that call to a high memory addresses make my quest to get this setup working hopeless? Or am I missing something?
I have tried using older versions of mklinuximg with the newer kernel, but unfortunately the linker is not compatible.

Thanks!!
-Bryan