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<mailto: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<mailto: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<mailto: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<mailto:devel-bounces@sel4.systems>> On Behalf
> > > Of Mike Clark
> > > Sent: Friday, January 10, 2020 3:22 PM
> > > To: devel@sel4.systems<mailto: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<mailto:Devel@sel4.systems>
> https://sel4.systems/lists/listinfo/devel
_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel
