Hi Kent,

Thanks for the suggestions. My loadaddr was set to 0x81000000. I tried using 0x84000000 and it booted just fine in secure mode. This is on the Nvidia TK1.

If I build with -DTk1Insecure=TRUE, I do have some issues. I get:

Undelivered IRQ: 85
Loading Linux: 'linux' dtb: 'linux-dtb'
install_linux_devices@main.c:613 module name: map_frame_hack
install_linux_devices@main.c:613 module name: plat
32 bit ARM insts not decoded
--------
Pagefault from [Linux]: write fault @ PC: 0x80226ab0 IPA: 0x40000000, FSR: 0x2000046
Context:
r0: 0xfe400000
r1: 0xc0020420
r2: 0x120
r3: 0xf10e01d3
r4: 0xe3006000
r5: 0xe3476000
r6: 0xe5966804
r7: 0xe2066cff
r8: 0xe1a06426
r9: 0xc0993e70
r10: 0x80000200
r11: 0x80008000
r12: 0xe3560020
pc: 0xc0226ab0
r14: 0x82050000
sp: 0x82000000
cpsr: 0x200000d3
m--------
Assertion failed: rt >= 0 (/host/latest-camkes-arm-vm/projects/seL4_projects_libs/libsel4vm/src/arch/arm/fault.c: fault_get_width: 623)

On Mon, Feb 3, 2020 at 1:27 AM Mcleod, Kent (Data61, Kensington NSW) <Kent.Mcleod@data61.csiro.au> wrote:

Hi Mike,
> You mentioned that "A reason why ELF works for seL4test and not for camkes-arm-vm is potentially because the Elfloader doesn't get started in monitor mode and is unable to start the kernel in Hyp mode. " What I don't understand about that is that I have a couple of images that I built back in August 2018 that still work just fine on this device when I use bootelf to boot them. seL4 starts up and drops to the VM and I can log into the VM.
Ok.

> Tegra124 (Jetson TK1) # fatload mmc 1 ${loadaddr} capdl-loader-image-arm-tk1
What is loadaddr set to? Does it fail with loadaddr set to 0x81000000?

>Tegra124 (Jetson TK1) # bootelf ${loadaddr}
> ## Starting application at 0x817f0000 ...
When trying to load an ELF with bootelf, I'm not sure what different versions of U-Boot do with regards to giving you an error if it unpacks the ELF over the top of the ELF. How does elfloading work with a loadaddr of around 0x84000000?

Which Jetson-tk1 board are you using?