[U-Boot] Unable to boot the new FIT image

Harsha Kiran harshakiran443 at gmail.com
Sat May 31 15:45:40 CEST 2014


Hi Simon,

I started working on the secure u-boot loading the FIT images and there are
some of the issues i observed.

I took the latest U-Boot 2014.07-rc2 and applied the below mentioned
patches..

(..http://patchwork.ozlabs.org/patch/339609/)
(..http://patchwork.ozlabs.org/patch/339610/)
(..http://patchwork.ozlabs.org/patch/339611/) I had to do a work around to
apply this patch. if i apply the patched directly to the latest u-boot it
failed in the fit_image.c file.
I searched online and found fit_image.c from  (..
https://kernel.googlesource.com/pub/scm/linux/kernel/git/maz/u-boot/+/eb63218b9b95a59baa8b241f3a88e4415dabf833/tools/fit_image.c)
and applied the patch and it was perfect.
Then i applied http://patchwork.ozlabs.org/patch/350541/

With these patches and removing CONFIG_OF_CONTROL in am335x_evm.h,  i was
able to load my FIT image successfully. if i include CONFIG_OF_CONTROL, i
get the following error
No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin
or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb> ### ERROR ###
Please RESET the board ###.

Now for the secure u-boot i added the CONFIG_FIT_SIGNATURE and CONFIG_RSA.
i modified the doc/uImage.FIT/kernel_fdt.its file to include the signature
content.
Here is the file..

/*
 * Simple U-boot uImage source file containing a single kernel and FDT blob
 */

/*
 * Simple U-boot uImage source file containing a single kernel and FDT blob
 */

/dts-v1/;

/ {
    description = "Simple image with single Linux kernel and FDT blob";
    #address-cells = <1>;

    images {
        kernel at 1 {
            description = "3.12 Kernel RT";
            data = /incbin/("./zImage");
            type = "kernel";
            arch = "arm";
            os = "linux";
            compression = "none";
            load = <0x80008000>;
            entry = <0x80008000>;
            hash at 1 {
                algo = "sha1";
            };
            signature at 1 {
                algo = "sha1,rsa2048";
                key-name-hint = "dev";
            };
        };
        fdt at 1 {
            description = "Flattened Device Tree blob";
            data = /incbin/("./am335x-evmsk.dtb");
            type = "flat_dt";
            arch = "arm";
            compression = "none";
            hash at 1 {
                algo = "sha1";
            };
            signature at 1 {
                algo = "sha1,rsa2048";
                key-name-hint = "dev";
            };
        };
    };

    configurations {
        default = "conf at 1";
        conf at 1 {
            description = "Boot Linux kernel with FDT blob";
            kernel = "kernel at 1";
            fdt = "fdt at 1";
        };
    };
};

Then, i signed my images with the keys generated from openssl,


DTC_OPS="-I dts -O dtb -p 2000"
sudo mkimage -D "${DTC_OPS}" -f kernel_fdt.its -k dev-keys -K
u-boot-pubkey.dtb -r kernel_fdt.itb

build the u-boot again with the signed binary..

harsha at harshakiran_kasha:/abb/Experiment_Secure/u-boot$ sudo make ARCH=arm
CROSS_COMPILE=/abb/compilers/gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux/bin/arm-linux-gnueabihf-
-j8 DEV_TREE_BIN=./u-boot-pubkey.dtb


Now, while booting, i was able to load the u-boot-dtb.bin file from the
u-boot prompt and it loaded the FIT image.

U-Boot# fatload mmc 0 0x82000000 u-boot-dtb.bin
reading u-boot-dtb.bin
466611 bytes read in 36 ms (12.4 MiB/s)
U-Boot# go 0x82000000
## Starting application at 0x82000000 ...


U-Boot 2014.07-rc2 (May 31 2014 - 02:16:18)

I2C:   ready
DRAM:  256 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
2481 bytes read in 7 ms (345.7 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading kernel_fdt.itb
4157190 bytes read in 267 ms (14.8 MiB/s)
## Loading kernel from FIT Image at 82000000 ...
   Using 'conf at 1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel at 1' kernel subimage
     Description:  3.12 Kernel RT
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x820000e4
     Data Size:    4117728 Bytes = 3.9 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80008000
     Entry Point:  0x80008000
     Hash algo:    sha1
     Hash value:   3d72bc90b8afb5464cb03de2952d1bba90cd542e
     Sign algo:    sha1,rsa2048:dev
     Sign value:   unavailable
   Verifying Hash Integrity ... sha1+ sha1,rsa2048:dev- OK
## Loading fdt from FIT Image at 82000000 ...
   Using 'conf at 1' configuration
   Trying 'fdt at 1' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x823ed6f8
     Data Size:    38048 Bytes = 37.2 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   01d8a7481ac4ae281e68383776287a94bd5f2d78
     Sign algo:    sha1,rsa2048:dev
     Sign value:   unavailable
   Verifying Hash Integrity ... sha1+ sha1,rsa2048:dev- OK
   Booting using the fdt blob at 0x823ed6f8
   Loading Kernel Image ... OK
   Loading Device Tree to 8f611000, end 8f61d49f ... OK

Starting kernel ...


it says that the hash integrity is verified but when i tried with an
unsigned kernel_fdt.bin  with signed u-boot-dtb.bin i was still able to
load the FIT and the logs are the same.
I not really sure if the veification part is done correctly. Am i following
the correct procedure or missing something??

Thanks and appreciate your time
Harsha




On Mon, May 26, 2014 at 10:24 PM, Simon Glass <sjg at chromium.org> wrote:

> Hi,
>
> On 24 May 2014 20:15, Harsha Kiran <harshakiran443 at gmail.com> wrote:
> > Hi Simon.
> > I am able to successfully load the FIT image now :) Thanks for the help.
> >
> > I applied Heiko's patch. If CONFIG_OF_CONTROL is defined, the behaviour
> of
> > the board is same as i mentioned in my previous emails. I tried removing
> the
> > CONFIG_OF_CONTROL from the config file and it was able to read the
> > u-boot.img. I modifed my uEnv.txt file and i was able to load my FIT
> image.
> >
> > I was wondering if we use CONFIG_OF_SEPERATE and
> CONFIG_DEFAULT_DEVICE_TREE
> > is it fine not to use the CONFIG_OF_CONTROL? and how should i use the
> > u-boot-dtb.bin file? I tried stopping the u-boot and entered the
> following
> > in the u-boot prompt to load the u-boot-dtb.bin
> >
> > u-boot# fatload mmc 0 0x81000000 u-boot-dtb.bin
> >
> > U-Boot#
> > U-Boot#
> > U-Boot# fatload mmc 0 0x81000000 u-boot-dtb.bin
> > reading u-boot-dtb.bin
> > 460759 bytes read in 43 ms (10.2 MiB/s)
> > U-Boot# go 0x81000000
> > ## Starting application at 0x81000000 ...
> >
> >
> > U-Boot 2014.07-rc1 (May 25 2014 - 00:46:36)
> >
> > I2C:   ready
> > DRAM:  1 GiB
> >
> > and it hangs here.. Which address should i use to load the
> u-boot-dtb.bin?
>
> Check that you disabled the cache with 'dcache off' before the 'go'
> command (if the cache was enabled). I'm not sure what the address
> should be, but given that it gets that far, it is probably fine. As a
> rule of thumb, load it low in memory - it will relocate to high in
> memory.
>
> >
> > I will start working on the secure u-boot with FIT signatures soon on
> > am335xsk EVM.
>
> OK. I will break out my Beaglebone also, perhaps this week. I really
> want to get these patches applied so it works smoothly on TI
> platforms.
>
> Regards,
> Simon
>



--


More information about the U-Boot mailing list