Re: [U-Boot] Unable to boot the new FIT image
Hi Simon,
I have added the next patch in the series i.e., (....../339610/) But the result is still the same. This particular patch just created a device tree In the arch/arm/dts folder For the beaglebone. I have already tried creating for am335x-evmsk and was able to build the u-boot-dtb.bin.
I have noticed that MLO is configured to read only the u-boot.img not any other binaries (eg U-boot.bin or u-boot-dtb.bin). It gives me the following error.. spl_load_image_fat: error reading image u-boot.img, err - -1 Which part of the configuration I should change so that MLO tries to read the u-boot-dtb.bin as the third stage bootloader?? I tried loading MLO->u-boot.img first, but this time it reads the u-boot.img but gives the following error..
reading u-boot.img reading u-boot.img 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 ###
I tried applying the next patch in the series to add that extra padding to the image size (ie., .......org/patch/339611) But could not successfully apply the patch.. harsha@harshakiran_kasha:/abb/Experiments/u-boot$ sudo patch -p1 -R < patch3.patch patching file tools/fit_image.c Hunk #1 FAILED at 35. Hunk #2 FAILED at 60. Hunk #3 succeeded at 38 (offset -137 lines). Hunk #4 FAILED at 210. Hunk #5 succeeded at 115 (offset -123 lines). 3 out of 5 hunks FAILED -- saving rejects to file tools/fit_image.c.rej patching file tools/image-host.c
and then the compilation gave the following errors.. harsha@harshakiran_kasha:/abb/Experiments/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=./am335x-boneblack.dtb CHK include/config/uboot.release CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CHK include/generated/version_autogenerated.h HOSTCC tools/dumpimage.o HOSTCC tools/fit_image.o HOSTCC tools/image-host.o HOSTCC tools/mkenvimage.o HOSTCC tools/mkimage.o tools/fit_image.c: In function ‘fit_handle_file’: tools/fit_image.c:74:3: error: ‘destfd’ undeclared (first use in this function) destfd = mmap_fdt(params->cmdname, params->keydest, tools/fit_image.c:74:3: note: each undeclared identifier is reported only once for each function it appears in tools/fit_image.c:75:8: error: ‘dest_blob’ undeclared (first use in this function) &dest_blob, &sbuf, 1); ^ tools/fit_image.c:75:20: error: ‘sbuf’ undeclared (first use in this function) &dest_blob, &sbuf, 1); ^ tools/fit_image.c:78:3: error: ‘destfd_size’ undeclared (first use in this function) destfd_size = sbuf.st_size; ^ tools/fit_image.c:81:2: error: ‘tfd’ undeclared (first use in this function) tfd = mmap_fdt(params->cmdname, tmpfile, &ptr, &sbuf, 1); ^ tools/fit_image.c:81:44: error: ‘ptr’ undeclared (first use in this function) tfd = mmap_fdt(params->cmdname, tmpfile, &ptr, &sbuf, 1); ^ tools/fit_image.c:98:3: error: label ‘err_add_timestamp’ used but not defined goto err_add_timestamp; ^ tools/fit_image.c:91:3: error: label ‘err_add_hashes’ used but not defined goto err_add_hashes; ^ tools/fit_image.c:83:3: error: label ‘err_mmap’ used but not defined goto err_mmap; ^ tools/fit_image.c:77:4: error: label ‘err_keydest’ used but not defined goto err_keydest; ^ tools/fit_image.c:42:6: warning: unused variable ‘ret’ [-Wunused-variable] int ret; ^ tools/fit_image.c:41:9: warning: unused variable ‘size_inc’ [-Wunused-variable] size_t size_inc; ^ make[1]: *** [tools/fit_image.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [tools] Error 2
Sorry for deleting the previous messages. U-boot mailing list is rejecting my emails If I include them
Thanks, Harsha
--
Hi Harsha,
On 21 May 2014 06:46, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
I have added the next patch in the series i.e., (....../339610/) But the result is still the same. This particular patch just created a device tree In the arch/arm/dts folder For the beaglebone. I have already tried creating for am335x-evmsk and was able to build the u-boot-dtb.bin.
I have noticed that MLO is configured to read only the u-boot.img not any other binaries (eg U-boot.bin or u-boot-dtb.bin). It gives me the following error.. spl_load_image_fat: error reading image u-boot.img, err - -1 Which part of the configuration I should change so that MLO tries to read the u-boot-dtb.bin as the third stage bootloader?? I tried loading MLO->u-boot.img first, but this time it reads the u-boot.img but gives the following error..
reading u-boot.img reading u-boot.img 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 ###
I tried applying the next patch in the series to add that extra padding to the image size (ie., .......org/patch/339611) But could not successfully apply the patch.. harsha@harshakiran_kasha:/abb/Experiments/u-boot$ sudo patch -p1 -R < patch3.patch patching file tools/fit_image.c Hunk #1 FAILED at 35. Hunk #2 FAILED at 60. Hunk #3 succeeded at 38 (offset -137 lines). Hunk #4 FAILED at 210. Hunk #5 succeeded at 115 (offset -123 lines). 3 out of 5 hunks FAILED -- saving rejects to file tools/fit_image.c.rej patching file tools/image-host.c
You will need to resolve these problems and manually apply the patch. Probably you don't need sudo.
and then the compilation gave the following errors.. harsha@harshakiran_kasha:/abb/Experiments/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=./am335x-boneblack.dtb CHK include/config/uboot.release CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CHK include/generated/version_autogenerated.h HOSTCC tools/dumpimage.o HOSTCC tools/fit_image.o HOSTCC tools/image-host.o HOSTCC tools/mkenvimage.o HOSTCC tools/mkimage.o tools/fit_image.c: In function ‘fit_handle_file’: tools/fit_image.c:74:3: error: ‘destfd’ undeclared (first use in this function) destfd = mmap_fdt(params->cmdname, params->keydest, tools/fit_image.c:74:3: note: each undeclared identifier is reported only once for each function it appears in tools/fit_image.c:75:8: error: ‘dest_blob’ undeclared (first use in this function) &dest_blob, &sbuf, 1); ^ tools/fit_image.c:75:20: error: ‘sbuf’ undeclared (first use in this function) &dest_blob, &sbuf, 1); ^ tools/fit_image.c:78:3: error: ‘destfd_size’ undeclared (first use in this function) destfd_size = sbuf.st_size; ^ tools/fit_image.c:81:2: error: ‘tfd’ undeclared (first use in this function) tfd = mmap_fdt(params->cmdname, tmpfile, &ptr, &sbuf, 1); ^ tools/fit_image.c:81:44: error: ‘ptr’ undeclared (first use in this function) tfd = mmap_fdt(params->cmdname, tmpfile, &ptr, &sbuf, 1); ^ tools/fit_image.c:98:3: error: label ‘err_add_timestamp’ used but not defined goto err_add_timestamp; ^ tools/fit_image.c:91:3: error: label ‘err_add_hashes’ used but not defined goto err_add_hashes; ^ tools/fit_image.c:83:3: error: label ‘err_mmap’ used but not defined goto err_mmap; ^ tools/fit_image.c:77:4: error: label ‘err_keydest’ used but not defined goto err_keydest; ^ tools/fit_image.c:42:6: warning: unused variable ‘ret’ [-Wunused-variable] int ret; ^ tools/fit_image.c:41:9: warning: unused variable ‘size_inc’ [-Wunused-variable] size_t size_inc; ^ make[1]: *** [tools/fit_image.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [tools] Error 2
Sorry for deleting the previous messages. U-boot mailing list is rejecting my emails If I include them
The objective is to get u-boot-dtb.bin packed into the .img file. I had this booting fine, but it was some weeks ago. I will give it another go when I get back from my trip next week.
Regards. Simon
Hi,
On 21 May 2014 15:12, Simon Glass sjg@chromium.org wrote:
Hi Harsha,
On 21 May 2014 06:46, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
I have added the next patch in the series i.e., (....../339610/) But the result is still the same. This particular patch just created a device tree In the arch/arm/dts folder For the beaglebone. I have already tried creating for am335x-evmsk and was able to build the u-boot-dtb.bin.
I have noticed that MLO is configured to read only the u-boot.img not any other binaries (eg U-boot.bin or u-boot-dtb.bin). It gives me the following error.. spl_load_image_fat: error reading image u-boot.img, err - -1 Which part of the configuration I should change so that MLO tries to read the u-boot-dtb.bin as the third stage bootloader?? I tried loading MLO->u-boot.img first, but this time it reads the u-boot.img but gives the following error..
reading u-boot.img reading u-boot.img 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 ###
Also I wonder if this is related to Heiko's patch? Worth trying.
http://patchwork.ozlabs.org/patch/350541/
Regards, Simon
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?
I will start working on the secure u-boot with FIT signatures soon on am335xsk EVM.
Thanks, Harsha
On Fri, May 23, 2014 at 7:08 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 21 May 2014 15:12, Simon Glass sjg@chromium.org wrote:
Hi Harsha,
On 21 May 2014 06:46, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
I have added the next patch in the series i.e., (....../339610/) But the result is still the same. This particular patch just created a device
tree
In the arch/arm/dts folder For the beaglebone. I have already tried
creating
for am335x-evmsk and was able to build the u-boot-dtb.bin.
I have noticed that MLO is configured to read only the u-boot.img not
any
other binaries (eg U-boot.bin or u-boot-dtb.bin). It gives me the following error.. spl_load_image_fat: error reading image u-boot.img, err - -1 Which part
of
the configuration I should change so that MLO tries to read the u-boot-dtb.bin as the third stage bootloader?? I tried loading MLO->u-boot.img first, but this time it reads the
u-boot.img
but gives the following error..
reading u-boot.img reading u-boot.img 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 ###
Also I wonder if this is related to Heiko's patch? Worth trying.
http://patchwork.ozlabs.org/patch/350541/
Regards, Simon
--
Hi,
On 24 May 2014 20:15, Harsha Kiran harshakiran443@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
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/+/eb6321...) 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@1 { description = "3.12 Kernel RT"; data = /incbin/("./zImage"); type = "kernel"; arch = "arm"; os = "linux"; compression = "none"; load = <0x80008000>; entry = <0x80008000>; hash@1 { algo = "sha1"; }; signature@1 { algo = "sha1,rsa2048"; key-name-hint = "dev"; }; }; fdt@1 { description = "Flattened Device Tree blob"; data = /incbin/("./am335x-evmsk.dtb"); type = "flat_dt"; arch = "arm"; compression = "none"; hash@1 { algo = "sha1"; }; signature@1 { algo = "sha1,rsa2048"; key-name-hint = "dev"; }; }; };
configurations { default = "conf@1"; conf@1 { description = "Boot Linux kernel with FDT blob"; kernel = "kernel@1"; fdt = "fdt@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@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@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@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@1' configuration Trying 'fdt@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@chromium.org wrote:
Hi,
On 24 May 2014 20:15, Harsha Kiran harshakiran443@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
--
Hi Harsha,
On 31 May 2014 07:45, Harsha Kiran harshakiran443@gmail.com wrote:
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/+/eb6321...) 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 ###.
This is likely another missing patch.
I just sent out a new series (available in u-boot-x86.git branch 'bone') which adds some step-by-step documentation. It also collects all the fixes in one place.
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@1 { description = "3.12 Kernel RT"; data = /incbin/("./zImage"); type = "kernel"; arch = "arm"; os = "linux"; compression = "none"; load = <0x80008000>; entry = <0x80008000>; hash@1 { algo = "sha1"; }; signature@1 { algo = "sha1,rsa2048"; key-name-hint = "dev"; }; }; fdt@1 { description = "Flattened Device Tree blob"; data = /incbin/("./am335x-evmsk.dtb"); type = "flat_dt"; arch = "arm"; compression = "none"; hash@1 { algo = "sha1"; }; signature@1 { algo = "sha1,rsa2048"; key-name-hint = "dev"; }; }; }; configurations { default = "conf@1"; conf@1 { description = "Boot Linux kernel with FDT blob"; kernel = "kernel@1"; fdt = "fdt@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@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@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@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@1' configuration Trying 'fdt@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 ...
I worry that you are loading a zImage to 80008000 which is the intended load address of the kernel itself. Does the zImage wrapper handle that?
In my example, I use the Image rather than zImage, so that U-Boot can decompress it.
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.
Yes but you didn't use the -r flag for mkimage, so the verification is optional.
I not really sure if the veification part is done correctly. Am i following the correct procedure or missing something??
Mostly I think. See my documentation in the series mentioned above - hopefully it will help.
Regards, Simon
Hi Simon,
I was able to succesfully test the Secure u-boot on the beaglebone black from the u-boot-x86 Bone git. Thanks for all the help and it was a great beaglebone_vboot.txt file !
I have some of minor things i would like to mention when i followed the procedure.
1) in the 7th step
7. Put U-Boot and the kernel onto the board ------------------------------------------- The MLO information is missing..
2)
I was not able to boot with kernel (image.lzo) in the FIT. it gave me the following error U-Boot# bootm 0x82000000 ## Loading kernel from FIT Image at 82000000 ... Using 'conf@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@1' kernel subimage Description: unavailable Created: 2014-06-04 1:28:38 UTC Type: Kernel Image Compression: lzo compressed Data Start: 0x820000a8 Data Size: 8543704 Bytes = 8.1 MiB Architecture: ARM OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 Hash algo: sha1 Hash value: 9504d8fefcec81c054e2d0fb4e9d9b6bcfb9b4b7 Verifying Hash Integrity ... sha1+ OK ## Loading fdt from FIT Image at 82000000 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: beaglebone-black Created: 2014-06-04 1:28:38 UTC Type: Flat Device Tree Compression: uncompressed Data Start: 0x82825f68 Data Size: 34352 Bytes = 33.5 KiB Architecture: ARM Hash algo: sha1 Hash value: 4b14973cf0fe4a40dc420ed55d2441c6f51f586b Verifying Hash Integrity ... sha1+ OK Booting using the fdt blob at 0x82825f68 Uncompressing Kernel Image ... LZO: uncompress or overwrite error -1 - must RESET board to recover resetting ...
U-Boot SPL 2014.07-rc2 (Jun 03 2014 - 20:09:15) reading u-boot.img reading u-boot.img
But when i switch it back to the zImage it worked good. I will check again on this.
Thanks, Harsha Kiran
On Mon, Jun 2, 2014 at 11:46 PM, Simon Glass sjg@chromium.org wrote:
Hi Harsha,
On 31 May 2014 07:45, Harsha Kiran harshakiran443@gmail.com wrote:
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/+/eb6321... )
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 ###.
This is likely another missing patch.
I just sent out a new series (available in u-boot-x86.git branch 'bone') which adds some step-by-step documentation. It also collects all the fixes in one place.
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@1 { description = "3.12 Kernel RT"; data = /incbin/("./zImage"); type = "kernel"; arch = "arm"; os = "linux"; compression = "none"; load = <0x80008000>; entry = <0x80008000>; hash@1 { algo = "sha1"; }; signature@1 { algo = "sha1,rsa2048"; key-name-hint = "dev"; }; }; fdt@1 { description = "Flattened Device Tree blob"; data = /incbin/("./am335x-evmsk.dtb"); type = "flat_dt"; arch = "arm"; compression = "none"; hash@1 { algo = "sha1"; }; signature@1 { algo = "sha1,rsa2048"; key-name-hint = "dev"; }; }; }; configurations { default = "conf@1"; conf@1 { description = "Boot Linux kernel with FDT blob"; kernel = "kernel@1"; fdt = "fdt@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@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@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@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@1' configuration Trying 'fdt@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 ...
I worry that you are loading a zImage to 80008000 which is the intended load address of the kernel itself. Does the zImage wrapper handle that?
In my example, I use the Image rather than zImage, so that U-Boot can decompress it.
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.
Yes but you didn't use the -r flag for mkimage, so the verification is optional.
I not really sure if the veification part is done correctly. Am i
following
the correct procedure or missing something??
Mostly I think. See my documentation in the series mentioned above - hopefully it will help.
Regards, Simon
--
Hi Harsha,
On 3 June 2014 20:29, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
I was able to succesfully test the Secure u-boot on the beaglebone black from the u-boot-x86 Bone git. Thanks for all the help and it was a great beaglebone_vboot.txt file !
Good!
I have some of minor things i would like to mention when i followed the procedure.
- in the 7th step
- Put U-Boot and the kernel onto the board
The MLO information is missing..
In my case I already had this on the card. Do you have instructions for what you followed?
I was not able to boot with kernel (image.lzo) in the FIT. it gave me the following error U-Boot# bootm 0x82000000
## Loading kernel from FIT Image at 82000000 ... Using 'conf@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@1' kernel subimage Description: unavailable Created: 2014-06-04 1:28:38 UTC Type: Kernel Image Compression: lzo compressed Data Start: 0x820000a8 Data Size: 8543704 Bytes = 8.1 MiB
Architecture: ARM OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 Hash algo: sha1 Hash value: 9504d8fefcec81c054e2d0fb4e9d9b6bcfb9b4b7Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 82000000 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: beaglebone-black Created: 2014-06-04 1:28:38 UTC
Type: Flat Device Tree Compression: uncompressed Data Start: 0x82825f68 Data Size: 34352 Bytes = 33.5 KiB Architecture: ARM Hash algo: sha1 Hash value: 4b14973cf0fe4a40dc420ed55d2441c6f51f586bVerifying Hash Integrity ... sha1+ OK Booting using the fdt blob at 0x82825f68 Uncompressing Kernel Image ... LZO: uncompress or overwrite error -1 - must RESET board to recover resetting ...
U-Boot SPL 2014.07-rc2 (Jun 03 2014 - 20:09:15) reading u-boot.img reading u-boot.img
But when i switch it back to the zImage it worked good. I will check again on this.
It might be the maximum image size:
#define CONFIG_SYS_BOOTM_LEN (16 << 20)
Is it possible that your kernel is larger than 16MB? Or that you forgot to compress it with lzop?
Regards, Simon
Hi Simon,
On Tue, Jun 3, 2014 at 9:58 PM, Simon Glass sjg@chromium.org wrote:
Hi Harsha,
On 3 June 2014 20:29, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
I was able to succesfully test the Secure u-boot on the beaglebone black from the u-boot-x86 Bone git. Thanks for all the help and it was a great beaglebone_vboot.txt file !
Good!
I have some of minor things i would like to mention when i followed the procedure.
- in the 7th step
- Put U-Boot and the kernel onto the board
The MLO information is missing..
In my case I already had this on the card. Do you have instructions for what you followed?
Harsha: I have formated my SD card into 2 partitions(boot and rootfs). in my boot partition, i have MLO,u-boot.img,image.fit,uEnv.txt and in the other partition i have the root filesystem. Instructions: I just copied them directly harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86$ sudo cp MLO /media/harsha/boot/ harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86$ sudo cp u-boot.img /media/harsha/boot/ harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo cp image.fit /media/harsha/boot/
i used fatload command. i have to modify my uEnv.txt to load it without stoping in u-boot prompt. U-Boot# fatload mmc 0 0x82000000 image.fit reading image.fit 8580350 bytes read in 474 ms (17.3 MiB/s) U-Boot# bootm 0x82000000 ## Loading kernel from FIT Image at 82000000 ... Using 'conf@1' configuration
I was not able to boot with kernel (image.lzo) in the FIT. it gave me the following error U-Boot# bootm 0x82000000
## Loading kernel from FIT Image at 82000000 ... Using 'conf@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@1' kernel subimage Description: unavailable Created: 2014-06-04 1:28:38 UTC Type: Kernel Image Compression: lzo compressed Data Start: 0x820000a8 Data Size: 8543704 Bytes = 8.1 MiB
Architecture: ARM OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 Hash algo: sha1 Hash value: 9504d8fefcec81c054e2d0fb4e9d9b6bcfb9b4b7Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 82000000 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: beaglebone-black Created: 2014-06-04 1:28:38 UTC
Type: Flat Device Tree Compression: uncompressed Data Start: 0x82825f68 Data Size: 34352 Bytes = 33.5 KiB Architecture: ARM Hash algo: sha1 Hash value: 4b14973cf0fe4a40dc420ed55d2441c6f51f586bVerifying Hash Integrity ... sha1+ OK Booting using the fdt blob at 0x82825f68 Uncompressing Kernel Image ... LZO: uncompress or overwrite error -1 - must RESET board to recover resetting ...
U-Boot SPL 2014.07-rc2 (Jun 03 2014 - 20:09:15) reading u-boot.img reading u-boot.img
But when i switch it back to the zImage it worked good. I will check
again
on this.
It might be the maximum image size:
#define CONFIG_SYS_BOOTM_LEN (16 << 20)
Is it possible that your kernel is larger than 16MB? Or that you forgot to compress it with lzop?
Harsha: I am working on the TI SDK7 and took tisdk_am335x-evm_defconfig
as my config file. The default kernel compression mode is Gzip. My Image is 8 MB and zImage is 4.1MB. Which compression mode is the best? I usually use the XZ mode as it gives me smallest binary (uImage 2.9 MB).
Regards, Simon
I have modified my signed image.fit in a HEX editor and loaded the image and it fails to load with the correct error.. .... Entry Point: 0x80008000 Hash algo: sha1 Hash value: 3d72bc90b8afb5464cb03de2952d1bba90cd542e Verifying Hash Integrity ... sha1 error! Bad hash value for 'hash@1' hash node in 'kernel@1' image node Bad Data Hash ERROR: can't get kernel image! U-Boot# U-Boot SPL 2014.07-rc2 (Jun 03 2014 - 20:09:15)
But, this time i did not sign my image.fit. i just converted my kernel_fdt.its to image.fit file (To test the unsigned images) harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo ../../b/am335x_boneblack_vboot/tools/mkimage -f kernel_fdt.its image.fit I am still able to load the image.fit successfully.! Should the singed u-boot.img allow the unsigned images to load??
To sign my u-boot i used the following command. (there is -r to make it compulsary)
harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo ../../b/am335x_boneblack_vboot/tools/mkimage -f kernel_fdt.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit. I am i still missing anything??
harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo ../../b/am335x_boneblack_vboot/tools/mkimage Usage: ../../b/am335x_boneblack_vboot/tools/mkimage -l image -l ==> list image header information ../../b/am335x_boneblack_vboot/tools/mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) ../../b/am335x_boneblack_vboot/tools/mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot options: [-k keydir] [-K dtb] [ -c <comment>] [-r] -k => set directory containing private keys -K => write public keys to this .dtb file -c => add comment in signature node -F => re-sign existing FIT image -r => mark keys used as 'required' in dtb ../../b/am335x_boneblack_vboot/tools/mkimage -V ==> print version information and exit
Thanks, Harsha
--
Hi Harsha,
On 3 June 2014 22:40, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
On Tue, Jun 3, 2014 at 9:58 PM, Simon Glass sjg@chromium.org wrote:
Hi Harsha,
On 3 June 2014 20:29, Harsha Kiran harshakiran443@gmail.com wrote:
Hi Simon,
I was able to succesfully test the Secure u-boot on the beaglebone black from the u-boot-x86 Bone git. Thanks for all the help and it was a great beaglebone_vboot.txt file !
Good!
I have some of minor things i would like to mention when i followed the procedure.
- in the 7th step
- Put U-Boot and the kernel onto the board
The MLO information is missing..
In my case I already had this on the card. Do you have instructions for what you followed?
Harsha: I have formated my SD card into 2 partitions(boot and rootfs). in my boot partition, i have MLO,u-boot.img,image.fit,uEnv.txt and in the other partition i have the root filesystem.
OK - in the instructions I talk about copying the Angstrom image to the SD card and it has these. Do you think I should add instructions on how to do this yourself from scratch, instead of using the image?
Instructions: I just copied them directly harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86$ sudo cp MLO /media/harsha/boot/ harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86$ sudo cp u-boot.img /media/harsha/boot/ harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo cp image.fit /media/harsha/boot/
i used fatload command. i have to modify my uEnv.txt to load it without stoping in u-boot prompt. U-Boot# fatload mmc 0 0x82000000 image.fit reading image.fit 8580350 bytes read in 474 ms (17.3 MiB/s)
U-Boot# bootm 0x82000000 ## Loading kernel from FIT Image at 82000000 ... Using 'conf@1' configuration
I was not able to boot with kernel (image.lzo) in the FIT. it gave me the following error U-Boot# bootm 0x82000000
## Loading kernel from FIT Image at 82000000 ... Using 'conf@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@1' kernel subimage Description: unavailable Created: 2014-06-04 1:28:38 UTC Type: Kernel Image Compression: lzo compressed Data Start: 0x820000a8 Data Size: 8543704 Bytes = 8.1 MiB
Architecture: ARM OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 Hash algo: sha1 Hash value: 9504d8fefcec81c054e2d0fb4e9d9b6bcfb9b4b7Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 82000000 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: beaglebone-black Created: 2014-06-04 1:28:38 UTC
Type: Flat Device Tree Compression: uncompressed Data Start: 0x82825f68 Data Size: 34352 Bytes = 33.5 KiB Architecture: ARM Hash algo: sha1 Hash value: 4b14973cf0fe4a40dc420ed55d2441c6f51f586bVerifying Hash Integrity ... sha1+ OK Booting using the fdt blob at 0x82825f68 Uncompressing Kernel Image ... LZO: uncompress or overwrite error -1
must RESET board to recover resetting ...
U-Boot SPL 2014.07-rc2 (Jun 03 2014 - 20:09:15) reading u-boot.img reading u-boot.img
But when i switch it back to the zImage it worked good. I will check again on this.
It might be the maximum image size:
#define CONFIG_SYS_BOOTM_LEN (16 << 20)
Is it possible that your kernel is larger than 16MB? Or that you forgot to compress it with lzop?
Harsha: I am working on the TI SDK7 and took tisdk_am335x-evm_defconfig as my config file. The default kernel compression mode is Gzip. My Image is 8 MB and zImage is 4.1MB. Which compression mode is the best? I usually use the XZ mode as it gives me smallest binary (uImage 2.9 MB).
Yes XZ is good, but does U-Boot support it? It looks to be like you didn't compress your kernel 'Image' file with lzop?
Regards, Simon
I have modified my signed image.fit in a HEX editor and loaded the image and it fails to load with the correct error.. ....
Entry Point: 0x80008000 Hash algo: sha1 Hash value: 3d72bc90b8afb5464cb03de2952d1bba90cd542e Verifying Hash Integrity ... sha1 error! Bad hash value for 'hash@1' hash node in 'kernel@1' image node Bad Data Hash ERROR: can't get kernel image! U-Boot# U-Boot SPL 2014.07-rc2 (Jun 03 2014 - 20:09:15)
But, this time i did not sign my image.fit. i just converted my kernel_fdt.its to image.fit file (To test the unsigned images) harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo ../../b/am335x_boneblack_vboot/tools/mkimage -f kernel_fdt.its image.fit I am still able to load the image.fit successfully.! Should the singed u-boot.img allow the unsigned images to load??
To sign my u-boot i used the following command. (there is -r to make it compulsary)
harsha@harshakiran_kasha:/abb/Verified-uboot/u-boot-x86/doc/uImage.FIT$ sudo ../../b/am335x_boneblack_vboot/tools/mkimage -f kernel_fdt.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit. I am i still missing anything??
Do you actually have a signature node in the .its file?
[snip]
Regards, Simon
participants (2)
-
Harsha Kiran -
Simon Glass