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?