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 <undefinedsp...@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 <undefinedsp...@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.guik...@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 <undefinedsp...@gmail.com>
>>> *Sent:* Monday, January 27, 2020 8:53 AM
>>> *To:* Shen, Yanyan (Data61, Kensington NSW) <yanyan.s...@data61.csiro.au
>>> >
>>> *Cc:* Chris Guikema <chris.guik...@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.s...@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 <undefinedsp...@gmail.com>
>>> > wrote:
>>> > > That did the trick Chris. Thanks!
>>> > >
>>> > > On Fri, Jan 10, 2020 at 3:30 PM Chris Guikema <
>>> > > chris.guik...@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
>>>
>>>
_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel
