Hi all,

One additional update. I noticed updates to the camkes-arm-vm-manifest project today, so I pulled those in and tried a few things. I still have EFI turned off in the build. When I do init-build, if I have -DTk1Insecure=TRUE set, then when I try to boot the resulting image, I noticed that the cpu resets almost immediately. On the other hand, if I remove that flag, then when I try to boot the resulting image, I get nothing on the screen at all after issuing the bootelf command.

Not sure if that helps trigger any thoughts. I'm at a loss for how to get the latest versions to boot.

Mike

On Mon, Jan 27, 2020 at 11:27 AM Mike Clark <undefinedspace@gmail.com> wrote:
One update on this. I pulled the sel4test-manifest project and built that for the TK1. When it built the efi image, I wasn't able to get it to work on my TK1 device. When I made the changes to the settings and got it to build the elf file instead, the tests ran just fine.

I did double check to make sure I had done this. I am still not able to boot the ARM VMM.
setenv bootm_boot_mode nonsec
saveenv

On Mon, Jan 27, 2020 at 10:41 AM Mike Clark <undefinedspace@gmail.com> wrote:
Hi Chris,

Thank you for the suggestion. I removed tk1 from the efi_list (so now it is the empty string). I rebuilt everything. Now when I run file on the resulting image I get: capdl-loader-image-arm-tk1: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

Running readelf -h on the file returns:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x817f0000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          20647556 (bytes into file)
  Flags:                             0x5000200, Version5 EABI, soft-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         20
  Section header string table index: 19

I copied that image to the SD card and tried to boot with fatload followed by bootelf. It sits there doing nothing for a little while (maybe a minute) then resets the CPU:

Tegra124 (Jetson TK1) # bootelf ${loadaddr}
## Starting application at 0x817f0000 ...
data abort
pc : [<817f7590>]          lr : [<817f7650>]
reloc pc : [<019ba590>]    lr : [<019ba650>]
sp : 81809f98  ip : 00000002     fp : 81809fb4
r10: 00000000  r9 : fd7ffed0     r8 : 00000014
r7 : fda60610  r6 : 00000000     r5 : 823b117c  r4 : 81000000
r3 : ffffffff  r2 : ffffefff     r1 : fda60610  r0 : 82b7aa40
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Code: e50b300c e51b3018 e5932000 e51b300c (e5933000)
Resetting CPU ...

resetting ...

U-Boot SPL 2020.01-00442-gc00bd81ae0 (Jan 10 2020 - 11:10:18 -0500)
Trying to boot from RAM

This is all with basically a fresh clone of the camkes-arm-vm-manifest git project then doing "../init-build.sh -DAARCH32=TRUE -DTk1Insecure=TRUE -DCAMKES_VM_APP=vm_minimal -DPLATFORM=tk1" then "ninja" in the build folder.

Mike

On Mon, Jan 27, 2020 at 9:58 AM Chris Guikema <Chris.Guikema@dornerworks.com> wrote:

Mike,

 

Do you happen to have the “ApplyData61ElfloaderSettings()” command in your project files?

 

function(ApplyData61ElfLoaderSettings kernel_platform kernel_sel4_arch)

    set(

        binary_list

        "tx1;hikey;am335x;odroidc2;imx8mq-evk;rockpro64;imx8mm-evk;hifive"

    )

    set(efi_list "tk1")

    set(uimage_list "tx2")

 

That sets any compiled images for the tk1 to be efi. You can remove the “tk1” from the “efi_list” and running “ccmake .” should allow you to choose the output setting as an elf. I’ve seen some issues where efi images don’t boot properly, but not with u-boot, so I can’t be sure your exact problem.

 

Thanks,

Chris Guikema

 

DornerWorks

 

From: Mike Clark <undefinedspace@gmail.com>
Sent: Monday, January 27, 2020 8:53 AM
To: Shen, Yanyan (Data61, Kensington NSW) <Yanyan.Shen@data61.csiro.au>
Cc: Chris Guikema <Chris.Guikema@dornerworks.com>; devel@sel4.systems
Subject: Re: [seL4] Problem booting camkes arm vmm on TK1 from SD Card

 

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Thanks.

 

I checked the output of file and it does list it as MS-DOS executable.

 

Now I tried

# fatload mmc 1 ${loadaddr} capdl-loader-image-arm-tk1

# bootefi ${loadaddr}

 

After that I get nothing. The system just sits there and I get no further output.

 

Anything else I can try? Is there any way to change the type of image that is getting created? I never had any issues with bootelf before and my old elf images still work.

 

Mike

 

On Sat, Jan 25, 2020 at 10:03 AM Shen, Yanyan (Data61, Kensington NSW) <Yanyan.Shen@data61.csiro.au> wrote:

Hi Mike,

Could you run "file images/capdl-loader-image-arm-tk1"?
If you see "images/capdl-loader-image-arm-tk1: MS-DOS executable", the
image is an EFI image, so bootefi command should help.

Also, the link, https://docs.sel4.systems/Hardware/jetsontk1.html, may
be helpful.


Regards,
Yanyan

On Fri, 2020-01-24 at 15:24 -0500, Mike Clark wrote:
> Chris,
>
> Looks like I might have spoken too soon. When I use go instead of
> bootelf, the board actually resets. Here are the log messages:
>
> Tegra124 (Jetson TK1) # fatload mmc 1 0x82000000 capdl-loader-image-
> arm-tk1
> 20435184 bytes read in 964 ms (20.2 MiB/s)
> Tegra124 (Jetson TK1) # go 0x82000000
> ## Starting application at 0x82000000 ...
> data abort
> pc : [<82000110>]          lr : [<fff51d84>]
> reloc pc : [<021c3110>]    lr : [<80114d84>]
> sp : fd7f8610  ip : 00000002     fp : fff6be40
> r10: 00000002  r9 : fd7ffed0     r8 : fffcbe9c
> r7 : fda60420  r6 : 82000000     r5 : 00000001  r4 : 00000000
> r3 : 82000000  r2 : fda60424     r1 : fda60424  r0 : 00006090
> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
> Code: 00000000 00000000 00000000 42100040 (7865742e)
> Resetting CPU ...
>
> resetting ...
>
> U-Boot SPL 2020.01-00442-gc00bd81ae0 (Jan 10 2020 - 11:10:18 -0500)
> Trying to boot from RAM
>
>
> U-Boot 2020.01-00442-gc00bd81ae0 (Jan 10 2020 - 11:10:18 -0500)
>
> SoC: tegra124
> Reset cause: SW_MAIN
> Model: NVIDIA Jetson TK1
> Board: NVIDIA Jetson TK1
> DRAM:  2 GiB
> MMC:   sdhci@700b0400: 1, sdhci@700b0600: 0
> Loading Environment from MMC... OK
> In:    serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> Tegra124 (Jetson TK1) #
>
> Doing readelf on the image that is being built doesn't work either
>
> $ readelf -h capdl-loader-image-arm-tk1
> readelf: Error: Not an ELF file - it has the wrong magic bytes at the
> start
>
> My old images from a year ago still boot just fine with bootelf. Any
> thoughts?
>
> Mike
>
> On Fri, Jan 10, 2020 at 3:46 PM Mike Clark <undefinedspace@gmail.com>
> wrote:
> > That did the trick Chris. Thanks!
> >
> > On Fri, Jan 10, 2020 at 3:30 PM Chris Guikema <
> > Chris.Guikema@dornerworks.com> wrote:
> > > Mike,
> > >
> > > 
> > >
> > > Can you do a readelf of your outputted image to make sure its not
> > > compiling as a binary? If it is, you’ll have to use the “go”
> > > command in u-boot instead.
> > >
> > > 
> > >
> > > Thanks,
> > >
> > > Chris Guikema
> > >
> > > 
> > >
> > > DornerWorks
> > >
> > > 
> > >
> > > From: Devel <devel-bounces@sel4.systems> On Behalf Of Mike Clark
> > > Sent: Friday, January 10, 2020 3:22 PM
> > > To: devel@sel4.systems
> > > Subject: [seL4] Problem booting camkes arm vmm on TK1 from SD
> > > Card
> > >
> > > 
> > >
> > > CAUTION: This email originated from outside the organization. Do
> > > not click links or open attachments unless you recognize the
> > > sender and know the content is safe.
> > > I'm using the docker image to build the CAmkES ARM VMM project
> > > using roughly the instructions here: 
> > > https://docs.sel4.systems/VM/CAmkESARMVM.html (they are slightly
> > > out of date).
> > >
> > > 
> > >
> > > I do:
> > >
> > > 
> > >
> > > ../init-build.sh -DAARCH32=TRUE -DCAMKES_VM_APP=vm_minimal
> > > -DPLATFORM=tk1
> > >
> > > ninja
> > >
> > > 
> > >
> > > Then I copy the resulting image from the images directory to an
> > > SD card and put that in my TK1.
> > >
> > > 
> > >
> > > When U-Boot starts I use the following commands to try to boot
> > >
> > > 
> > >
> > > fatload mmc 1 0x10000000 capdl-loader-image-arm-tk1
> > >
> > > bootelf 0x10000000
> > >
> > > 
> > >
> > > To which I get an error: No elf image at address 0x10000000
> > >
> > > 
> > >
> > > I tried with an older version of U-Boot (that worked following
> > > this same procedure about a year ago). It is U-Boot SPL 2014.10-
> > > rc2-g3127911 (Jun 07 2016 - 21:00:01)
> > >
> > > 
> > >
> > > I also tried updating U-Boot to U-Boot SPL 2020.01-00442-
> > > gc00bd81ae0 (Jan 10 2020 - 11:10:18 -0500). Same error.
> > >
> > > 
> > >
> > > Any thoughts or suggestions on how I get this to boot?
> > >
>
> _______________________________________________
> Devel mailing list
> Devel@sel4.systems
> https://sel4.systems/lists/listinfo/devel