[U-Boot] FIT Image Crashing
Kipper, Matthew
Matthew.Kipper at gd-ms.ca
Mon Dec 19 22:23:13 CET 2016
Hi all,
I'm working on a Zynq-7000 system that currently performs a "legacy" boot - the kernel, device tree and initramfs are loaded independently into RAM, and then they're all loaded by passing their addresses into 'bootm'. I'd like to update this to a "moderm" boot, where the system loads a single FIT image instead. This is my first exposure to FIT images - I thought I figured out how to do this, but my system is crashing so I'm beginning to doubt myself ;)
This is the "legacy" load sequence (output omitted):
setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x1600000 earlyprintk init=/sbin/init"
tftpboot 0x2000000 devicetree.dtb
tftpboot 0x2080000 uImage
tftpboot 0x4000000 initramfs.img
Here's the output when I actually boot:
Zynq> bootm 0x2080000 0x4000000 0x2000000
## Booting kernel from Legacy Image at 02080000 ...
Image Name: Linux-4.0.0-00011-gcfd1f62
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3297728 Bytes = 3.1 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
Image Name: Ramdisk Image
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 22569621 Bytes = 21.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Kernel Image ... OK
Loading Ramdisk to 1ea79000, end 1ffff295 ... OK
Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
[Omitted]
The kernel boots. All is well.
To replace this with a FIT image, I created a '.its' file and compiled it with 'mkimage'. If it matters...
* I'm using the 'mkimage' binary in my u-boot/tools directory
* 'which dtc' points to the 'scripts/dtc' directory in the kernel tree that I'm using for my build
I won't post the entire '.its' file, but here is the output from 'mkimage':
FIT description: Test FIT Image
Created: Mon Dec 19 14:09:14 2016
Image 0 (kernel at 1)
Description: Linux Kernel
Created: Mon Dec 19 14:09:14 2016
Type: Kernel Image
Compression: uncompressed
Data Size: 3297792 Bytes = 3220.50 kB = 3.15 MB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Image 1 (fdt at 1)
Description: Device Tree Blob
Created: Mon Dec 19 14:09:14 2016
Type: Flat Device Tree
Compression: uncompressed
Data Size: 11170 Bytes = 10.91 kB = 0.01 MB
Architecture: ARM
Image 2 (ramdisk at 1)
Description: initramfs
Created: Mon Dec 19 14:09:14 2016
Type: RAMDisk Image
Compression: gzip compressed
Data Size: 22569685 Bytes = 22040.71 kB = 21.52 MB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Default Configuration: 'conf at 1'
Configuration 0 (conf at 1)
Description: Boot Linux kernel with FDT blob
Kernel: kernel at 1
Init Ramdisk: ramdisk at 1
FDT: fdt at 1
To me, it looks like the FIT image was built correctly. The load addresses and entry points line up with what U-Boot reports during a "legacy" boot. But this is my first time using FIT images, so I'm not 100% sure that this is correct.
To load this image, I changed the command sequence to the following (output omitted):
setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x1600000 earlyprintk init=/sbin/init"
tftpboot 0x2000000 image.itb
All my bootargs are the same as before, but now I'm only loading a single FIT image into RAM rather than three separate images.
Here's what happens when I try to boot:
Zynq> bootm 0x2000000
## Loading kernel from FIT Image at 02000000 ...
Using 'conf at 1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel at 1' kernel subimage
Description: Linux Kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x020000c4
Data Size: 3297792 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Verifying Hash Integrity ... OK
## Loading ramdisk from FIT Image at 02000000 ...
Using 'conf at 1' configuration
Trying 'ramdisk at 1' ramdisk subimage
Description: initramfs
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x02327f88
Data Size: 22569685 Bytes = 21.5 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Verifying Hash Integrity ... OK
## Loading fdt from FIT Image at 02000000 ...
Using 'conf at 1' configuration
Trying 'fdt at 1' fdt subimage
Description: Device Tree Blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x02325370
Data Size: 11170 Bytes = 10.9 KiB
Architecture: ARM
Verifying Hash Integrity ... OK
Booting using the fdt blob at 0x2325370
Loading Kernel Image ... OK
Loading Ramdisk to 1ea79000, end 1ffff2d5 ... OK
Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK
Starting kernel ...
undefined instruction
pc : [<0000800c>] lr : [<3ff2b834>]
reloc pc : [<c40dd00c>] lr : [<04000834>]
sp : 3f30acb0 ip : 0000000c fp : 3ff2b8c0
r10: 00000000 r9 : 3f30aee0 r8 : 020000c4
r7 : 00000000 r6 : 00008000 r5 : 3ff9c868 r4 : 00000000
r3 : 00002ba2 r2 : 1ea73000 r1 : 00000000 r0 : 3f30afb0
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
Everything looks good up until "Starting kernel...". U-Boot reads the FIT image header and it lines up with my expectation. The kernel's load address matches the legacy boot's load address, but when U-Boot actually starts the kernel, the system crashes and resets.
The 'pc' and 'reloc pc' values are the only real hint I'm seeing - does this mean that U-Boot is looking for the first kernel instruction at an offset of 0xC from the load address? Does relocation fit into this somehow?
I do know that U-Boot is loading the kernel to 0x8000 before crashing. Here's a memory read before loading the FIT image:
Zynq> md 0x8000
00008000: dfdc3ffc dd5ffbfe ff7fbabe ffffd7fe .?...._.........
00008010: 777fccfb fbbfeefb dde9f8cf ffffeee7 ...w............
00008020: ffcefebc f76ffffb ffadf2ed f5f776ff ......o......v..
00008030: eb31fdd9 fff28fff df5fb77f ffdbeeeb ..1......._.....
00008040: dedfef7f ebeffebe fddfbbbf f7f7d4ff ................
And here it is after the crash/reset:
Zynq> md 0x8000
00008000: 56190527 3328f51d dc265858 c0513200 '..V..(3XX&..2Q.
00008010: 00800000 00800000 368dbc5f 00020205 ........_..6....
00008020: 756e694c 2e342d78 2d302e30 31303030 Linux-4.0.0-0001
00008030: 63672d31 66316466 00003236 00000000 1-gcfd1f62......
00008040: e1a00000 e1a00000 e1a00000 e1a00000 ................
When loading the FIT image, 'bootm' reported that the kernel data started at an offset of 0xc4 from the start of the FIT image. And lo and behold, if I read the memory at that address, 0x20000c4, it lines up with the data at 0x8000 after the (failed) boot.
As I mentioned, this is my first time trying to boot from a FIT image, so I feel like I may have some major misunderstanding for how I should handle the load address, etc. Any guidance would be appreciated.
As an aside, this is the output from my kernel build when creating the uImage that's inside the FIT image:
/bin/sh ./scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x8000 -e 0x8000 -n 'Linux-4.0.0-00011-gcfd1f62' -d arch/arm/boot/zImage arch/arm/boot/uImage
Image Name: Linux-4.0.0-00011-gcfd1f62
Created: Mon Dec 19 13:32:30 2016
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3297728 Bytes = 3220.44 kB = 3.14 MB
Load Address: 00008000
Entry Point: 00008000
More information about the U-Boot
mailing list