[U-Boot] Complete verified uboot example
Ron Brash
ron.brash at gmail.com
Tue Feb 28 19:09:46 UTC 2017
Hello,
Still for some reason - there is an issue with booting from the FIT. With
a version of Uboot without the FIT related CONFIGs enabled; everything
works.
Here is me taking my zImage and converting it to a u-image ( I am not sure
on the addresses)
mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
linux-4.4.36b \
-d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2
My .its:
/dts-v1/;
/{
description = "Configuration to load a Basic Kernel";
#address-cells = <1>;
images {
linux_kernel at 1 {
description = "Linux zImage";
data =
/incbin/("../../../../bin/targets/myboard/legacy/myboard-legacy-zImage-nDTB2");
type = "kernel";
arch = "arm";
os = "linux";
compression = "none";
load = <0x23008000>;
entry = <0x23008000>;
kernel-version = <1>;
hash at 1 {
algo = "sha256";
};
};
fdt at 1 {
description = "FDT blob";
data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
load = <0x28000000>;
fdt-version = <1>;
hash at 1{
algo = "sha256";
};
};
};
configurations {
default = "config at 1";
config at 1{
description = "Plain Linux";
kernel = "linux_kernel at 1";
fdt = "fdt at 1";
signature at 1{
algo = "sha256,rsa2048";
key-name-hint = "dev_key";
sign-images = "fdt", "kernel";
};
};
};
};
Then
set -ex
key_dir="/tmp/keys"
key_name="dev_key"
rm -rf ${FIT_IMG}
rm -rf ${key_dir}
mkdir ${key_dir}
rootdir="/home/dev/usr"
MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
DTC="/usr/bin/dtc"
CPP="/usr/bin/cpp"
OPENSSL="/usr/bin/openssl"
#Generate a private signing key (RSA2048):
$OPENSSL genrsa -F4 -out \
"${key_dir}"/"${key_name}".key 2048
# Generate a public key:
$OPENSSL req -batch -new -x509 \
-key "${key_dir}"/"${key_name}".key \
-out "${key_dir}"/"${key_name}".crt
# Control FDT (u-boot.dts) - hits uboot to have keys etc...
BD_NAME="at91sam9260-plx35"
PATH_TO_BIN="${rootdir}/lede/bin/targets/myboard/legacy"
#
# This is the uboot-nodtb.bin (just renamed)
#
UBOOT_NAME="lede-myboard.bin"
UBOOT_WITH_DTB="${PATH_TO_BIN}/${UBOOT_NAME}"
PATH_TO_CTRL_FDT="${rootdir}/lede/build_dir/target-arm_arm926ej-s_musl-1.1.15_eabi/linux-myboard/myboard-uboot-2016.05/arch/arm/dts/"
CTRL_FDT="${PATH_TO_CTRL_FDT}${BD_NAME}"
FIT_ITS="at91sam9260"
FIT_IMG="${rootdir}/lede/bin/targets/myboard/legacy/lede-at91-image.fit"
DOPTS="-I dts -O dtb -p 2000"
# Generate fitImage with space for signature:
echo "create FIT with space - no signing"
echo " --------------------------------"
$MKIMG -D "${DOPTS}" \
-f "${FIT_ITS}".its "${FIT_IMG}"
echo ""
echo ""
# Now add them and sign them
echo "Sign images with our keys"
echo " --------------------------------"
$MKIMG -D "${DOPTS}" -F \
-k "${key_dir}" -K "${CTRL_FDT}".dtb -r "${FIT_IMG}"
echo ""
echo ""
# Add FDT to image
cp ${UBOOT_WITH_DTB} ${UBOOT_WITH_DTB}-wDTB
cat ${PATH_TO_CTRL_FDT}/${BD_NAME}.dtb >> ${UBOOT_WITH_DTB}-wDTB
Then I flash the uboot-WDTB to the board and also the FIT image. Following
that, then I load the FIT into RAM and execute it with the command:
cp.b 0xD0084000 0x22000000 0x186A00;setenv my_bootcount 0; bootm 0x22000000
Initial value for argc=3
Final value for argc=3
## Current stack ends at 0x23f119b8 * kernel: cmdline image address =
0x22000000
## Loading kernel from FIT Image at 22000000 ...
No configuration specified, trying default...
Found default configuration: 'config at 1'
Using 'config at 1' configuration
Trying 'linux_kernel at 1' kernel subimage
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x220000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x23008000
Entry Point: 0x23008000
Hash node: 'hash at 1'
Hash algo: sha256
Hash value:
52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
* ramdisk: using config 'config at 1' from image at 0x22000000
* ramdisk: no 'ramdisk' in config
* fdt: using config 'config at 1' from image at 0x22000000
## Checking for 'FDT'/'FDT Image' at 22000000
## Loading fdt from FIT Image at 22000000 ...
Using 'config at 1' configuration
Trying 'fdt at 1' fdt subimage
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x22165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash at 1'
Hash algo: sha256
Hash value:
c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
Loading fdt from 0x22165ea4 to 0x28000000
Booting using the fdt blob at 0x28000000
of_flat_tree at 0x28000000 size 0x000054b1
Initial value for argc=3
Final value for argc=3
Loading Kernel Image ... OK
CACHE: Misaligned operation at range [23008000, 2316dcc8]
kernel loaded at 0x23008000, end = 0x2316dcc8
using: FDT
## initrd_high = 0x24000000, copy_to_ram = 1
ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
## device tree at 28000000 ... 280054b0 (len=33969 [0x84B1])
Loading Device Tree to 23f08000, end 23f104b0 ... OK
Initial value for argc=3
Final value for argc=3
## Transferring control to Linux (at address 23008000)...
Starting kernel ...
undefined instruction
pc : [<23008028>] lr : [<23f44ca4>]
reloc pc : [<20fc3028>] lr : [<21effca4>]
sp : 23f11980 ip : 23f9472c fp : 00000000
r10: 23f1e61c r9 : 23f17ef0 r8 : 23f4585c
r7 : 00000000 r6 : 23008000 r5 : 23f9b0f4 r4 : 00000081
r3 : 000054b1 r2 : 23f08000 r1 : 00000658 r0 : 23900000
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
With iminfo:
#> cp.b 0xD0084000 0x22000000 0x186A00
#> iminfo
## Checking Image at 22000000 ...
FIT image found
FIT description: Configuration to load a Basic Kernel
Image 0 (linux_kernel at 1)
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x220000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x23008000
Entry Point: 0x23008000
Hash node: 'hash at 1'
Hash algo: sha256
Hash value:
52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
Hash len: 32
Image 1 (fdt at 1)
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x22165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash at 1'
Hash algo: sha256
Hash value:
c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Default Configuration: 'config at 1'
Configuration 0 (config at 1)
Description: Plain Linux
Kernel: linux_kernel at 1
FDT: fdt at 1
## Checking hash(es) for FIT Image at 22000000 ...
Hash(es) for Image 0 (linux_kernel at 1): sha256+
Hash(es) for Image 1 (fdt at 1): sha256+
Any input? This seems like offsets and not knowing where various
components need to be looking.
On 27 February 2017 at 16:53, Rick Altherr <raltherr at google.com> wrote:
> You set the load address for the linux image to the same location as the
> FIT. U-Boot verified the hashes on the FIT and then tried to copy the
> kernel over top the FIT. I assume you put the FIT in flash. Pick a
> location in RAM for the kernel's load address.
>
> On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.brash at gmail.com> wrote:
>
>> Looks like far more progress:
>>
>> #> setenv my_bootcount 0; bootm 0xD0084000
>> Initial value for argc=3
>> Final value for argc=3
>> ## Current stack ends at 0x23f11db8 * kernel: cmdline image address =
>> 0xd0084000
>> Reading image header from dataflash address d0084000 to RAM address
>> 22000000
>> FIT/FDT format image found at 0x22000000, size 0x0016c0b1
>> Reading image remaining data from dataflash address d0084040 to RAM
>> address 22000040
>> ## Loading kernel from FIT Image at 22000000 ...
>> No configuration specified, trying default...
>> Found default configuration: 'config at 1'
>> Using 'config at 1' configuration
>> Trying 'linux_kernel at 1' kernel subimage
>> Description: Linux zImage
>> Type: Kernel Image
>> Compression: uncompressed
>> Data Start: 0x220000dc
>> Data Size: 1465544 Bytes = 1.4 MiB
>> Architecture: ARM
>> OS: Linux
>> Load Address: 0x22000000
>> Entry Point: 0x22008000
>> Hash node: 'hash at 1'
>> Hash algo: sha256
>> Hash value: 5dcf9a4328bca6fe5c3405e03b9a58
>> 402dce36f3a4f0c757e52091b050d2bcb2
>> Hash len: 32
>> Verifying Hash Integrity ... sha256+ OK
>> kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
>> * ramdisk: using config 'config at 1' from image at 0x22000000
>> * ramdisk: no 'ramdisk' in config
>> * fdt: using config 'config at 1' from image at 0x22000000
>> ## Checking for 'FDT'/'FDT Image' at 22000000
>> ## Loading fdt from FIT Image at 22000000 ...
>> Using 'config at 1' configuration
>> Trying 'fdt at 1' fdt subimage
>> Description: FDT blob
>> Type: Flat Device Tree
>> Compression: uncompressed
>> Data Start: 0x22165ea4
>> Data Size: 21681 Bytes = 21.2 KiB
>> Architecture: ARM
>> Hash node: 'hash at 1'
>> Hash algo: sha256
>> Hash value: c7f32d039871d858dda8d397c3b6a6
>> 85bc914c78cf70f03d1860f61ecfe9c689
>> Hash len: 32
>> Verifying Hash Integrity ... sha256+ OK
>> Loading fdt from 0x22165ea4 to 0x28000000
>> Booting using the fdt blob at 0x28000000
>> of_flat_tree at 0x28000000 size 0x000054b1
>> Initial value for argc=3
>> Final value for argc=3
>> Loading Kernel Image ... OK
>> CACHE: Misaligned operation at range [22000000, 22165cc8]
>> kernel loaded at 0x22000000, end = 0x22165cc8
>> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
>> images.os.load = 0x22000000, load_end = 0x22165cc8
>> ERROR: new format image overwritten - must RESET the board to recover
>> resetting ...
>>
>> This appears to be an addressing issue. Anyone care to comment?
>>
>> I'll put up how I got to this point after, but I am curious on how all of
>> the addresses are leveraged, is there an order they follow and more?
>>
>>
>>
>> On 27 February 2017 at 15:58, Rick Altherr <raltherr at google.com> wrote:
>>
>>> The projects I'm working on are based on Yocto so I've been using the
>>> u-boot signing support that is built in there. I believe the magic you are
>>> looking for is in http://git.yoctoproject.org
>>> /cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.
>>> Specifically, when you run 'mkimage -F -k <key-name> -K <control-dtb> -r
>>> <fit>', the public keys will be inserted into the control dtb. You can
>>> then rebuild u-boot with 'make EXT_DTB=<control-dtb>' which will use the
>>> dtb that includes the keys.
>>>
>>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash at gmail.com> wrote:
>>>
>>>> Okay - it seems, after working my way through a bunch of the
>>>> documentation and examples in /doc/uImage.FIT - I noticed a discrepancy
>>>>
>>>> /dts-v1/;
>>>> /{
>>>> description = "Configuration to load a Basic Kernel";
>>>> #address-cells = <1>;
>>>> images {
>>>> linux_kernel at 1 {
>>>> description = "Linux zImage";
>>>> data = /incbin/("zImage");
>>>> type = "kernel";
>>>> arch = "arm";
>>>> os = "linux";
>>>> compression = "none";
>>>> load = <0x20000000>;
>>>> entry = <0x20008000>;
>>>> kernel-version = <1>;
>>>> hash at 1 {
>>>> algo = "sha256";
>>>> };
>>>> };
>>>> fdt at 1 {
>>>> description = "FDT blob";
>>>> data = /incbin/("myboard.dtn");
>>>> type = "flat_dt";
>>>> arch = "arm";
>>>> compression = "none";
>>>> fdt-version = <1>;
>>>> hash at 1{
>>>> algo = "sha256";
>>>> };
>>>> };
>>>> };
>>>> configurations {
>>>> default = "config at 1";
>>>> config at 1{
>>>> description = "Plain Linux";
>>>> kernel = "linux_kernel at 1";
>>>> fdt = "fdt at 1";
>>>> signature at 1{
>>>> algo = "sha256,rsa2048";
>>>> key-name-hint = "dev_key";
>>>> sign-images = "fdt", "kernel";
>>>> };
>>>> };
>>>> };
>>>> };
>>>>
>>>> Does NOT equal (for brevity - I just used the node)
>>>>
>>>> fdt at 1 {
>>>> description = "FDT blob";
>>>> data = /incbin/("myboard.dtn");
>>>> type = "flat_dt";
>>>> arch = "arm";
>>>> compression = "none";
>>>> fdt-version = <1>;
>>>> hash at 1{
>>>> algo = "sha256";
>>>> };
>>>> signature at 1{
>>>> algo = "sha256,rsa2048";
>>>> key-name-hint = "dev_key";
>>>> };
>>>> };
>>>>
>>>> Apparently, this causes the mkimage tooling in my particular instance
>>>> to explain invalid blob messages. The large example above indeed does work
>>>> once this nuance was noticed.
>>>>
>>>> Next, once the final CTRL FDT is created, how does one get it back
>>>> into the actual u-boot binary. Does/can mkimage insert it into the binary
>>>> image at a particular offset? What is the command to do so?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 23 February 2017 at 12:27, Rick Altherr <raltherr at google.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello all (and thanks Mr. Altherr for this insight),
>>>>>>
>>>>>> Excellent feedback and I agree that all of this needs to find a home
>>>>>> either on the global docs on the website and/or the text-only
>>>>>> documentation. Regardless, this leads me to a few questions.
>>>>>>
>>>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD
>>>>>> even in Mr. Altherr's email is confusion provoking. One term to rule them
>>>>>> all is needed ;)
>>>>>>
>>>>>
>>>>> Agreed. Technically a flattened device tree (FDT) can be described in
>>>>> an ASCII form (dts) or binary form (dtb).
>>>>>
>>>>>
>>>>>>
>>>>>> 1.) What if a board doesn't have OR has ever been configured to use
>>>>>> u-boot DTS (could we call this a UDTS or something friendly to
>>>>>> differentiate that fact?); this was a point of misunderstanding until I
>>>>>> started scampering around into arch/arm/dts/?
>>>>>>
>>>>>> * For example, my board is a derivative of an Atmel at91sam9g20. It
>>>>>> had a very generic implementation of a DTS that covered reference boards in
>>>>>> the Linux kernel, but required a fair bit of modification to make it work.
>>>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for a DTS -
>>>>>> what would someone like me need to do - do we have a barebones tutorial
>>>>>> (again I don't mind publishing such with proofing)? Is it even required if
>>>>>> we have a platform/board already working in the traditional u-boot way?
>>>>>>
>>>>>> I believe (but have no verified) that if your board is supported by
>>>>> U-Boot without a control FDT today, you can just create one that contains
>>>>> only the public keys. I've gathered from the mailing list that using a
>>>>> control FDT and the driver model is how all new boards should be
>>>>> implemented.
>>>>>
>>>>>
>>>>>> 2.) Just to summarise - everything winds up in two binaries: u-boot
>>>>>> and the FIT image. So the partition scheme would more or less would look
>>>>>> like:
>>>>>>
>>>>>> /-----------------
>>>>>> * Bootstrap/ROM (optional)
>>>>>> /----------------
>>>>>> * U-boot
>>>>>> * Control DTB
>>>>>> * Has keys
>>>>>>
>>>>>
>>>>> Only the public keys. The private keys are never stored on the target
>>>>> device.
>>>>>
>>>>>
>>>>>> * Driver loadout/init
>>>>>>
>>>>> The control FDT only describes the hardware (see
>>>>> https://www.devicetree.org/ and http://git.kernel.org/cgit/lin
>>>>> ux/kernel/git/torvalds/linux.git/tree/Documentation/devicetr
>>>>> ee/usage-model.txt). U-Boot's driver model matches device drivers
>>>>> against nodes in the FDT and starts them.
>>>>>
>>>>>
>>>>>> /----------------
>>>>>> * U-boot env
>>>>>> *----------------
>>>>>> * FIT image
>>>>>>
>>>>> The FIT shouldn't be in the U-Boot env section. That's used by U-Boot
>>>>> to store its persistent environment. The FIT is a replacement for the
>>>>> kernel image. Keep a separate place allocated in the flash for kernel but
>>>>> store the FIT there.
>>>>>
>>>>>
>>>>>> * ITS
>>>>>>
>>>>> I never really thought of it this way, but yes, that's true. The ITS
>>>>> is itself written in device tree syntax and gets compiled to binary form.
>>>>> dtb tends to get used only to describe device trees in binary form that
>>>>> describe hardware. Maybe we need to introduce ITB to clarify this is the
>>>>> device tree in binary form describing the image.
>>>>>
>>>>>
>>>>>> * Kernel
>>>>>> * DTS
>>>>>>
>>>>>
>>>>> Prefer the terms FDT or DTB. Only the compiled form is stored in the
>>>>> FIT.
>>>>>
>>>>>
>>>>>> * ....
>>>>>> /---------------
>>>>>> * Rootfs etc...
>>>>>> * ...
>>>>>> /---------------
>>>>>>
>>>>>>
>>>>>> 3.) What people used to use to load X address into Z location in
>>>>>> memory is now removed by the usage of a DTB in u-boot correct? I assume
>>>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially done
>>>>>> away with - as its arguments are augmented by said file.
>>>>>>
>>>>>
>>>>> Not quite. bootarg/bootcmd is still used. What is different is that
>>>>> booting linux with a FDT with legacy images required multiple arguments to
>>>>> bootm. In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
>>>>> With a FIT, you only provide the address of the FIT itself to bootm so
>>>>> bootarg is set to 'bootm <fit_addr>'.
>>>>>
>>>>>
>>>>>>
>>>>>> Anybody have the spare cycles to organise a
>>>>>> web-tutorial/presentation/recording with me on a play-by-play to
>>>>>> make all of this make sense? I'm aiming to be in Prague for the 2017
>>>>>> conference in October, might be a good place to showcase this fine-tuning.
>>>>>>
>>>>>>
>>>>> I'm not clear on what you are asking. I probably have time to review
>>>>> docs and presentations and maybe a few phone or video conference meetings.
>>>>>
>>>>>
>>>>>> Ron
>>>>>>
>>>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr at google.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> I am adding verified kernel support on a board we are using and I am
>>>>>>>> struggling to fully understand all of the concepts and steps
>>>>>>>> required to
>>>>>>>> pull everything together (on ARM, using ZImages and booting with a
>>>>>>>> working
>>>>>>>> DTB on 4.4.3x). I also looked at the test script inside of
>>>>>>>> examples, but
>>>>>>>> it left me with more questions than understanding.
>>>>>>>>
>>>>>>>> Please correct me where appropriate in my understanding, but if I am
>>>>>>>> confused, likely others are too and I hope this helps everyone
>>>>>>>> involved
>>>>>>>> overall.
>>>>>>>>
>>>>>>>
>>>>>>> You've asked some really good questions. Hopefully this discussion
>>>>>>> will end up with patches to clarify the docs.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Steps:
>>>>>>>> ---------------------------------------------------------------
>>>>>>>>
>>>>>>>> First, u-boot needs to have the appropriate features enabled and to
>>>>>>>> be
>>>>>>>> built using them. At a minimum, I suspect:
>>>>>>>>
>>>>>>>> CONFIG_RSA=y
>>>>>>>> CONFIG_FIT=y
>>>>>>>> CONFIG_FIT_SIGNATURE=y
>>>>>>>> CONFIG_OF_CONTROL=y
>>>>>>>>
>>>>>>>>
>>>>>>> Yup. That looks right.
>>>>>>>
>>>>>>>
>>>>>>>> Next, we need to derive the appropriate cryptographic
>>>>>>>> primitives/keys.
>>>>>>>>
>>>>>>>> #Generate a private signing key (RSA2048):
>>>>>>>> openssl genrsa -F4 -out \
>>>>>>>> "${key_dir}"/"${key_name}".key 2048
>>>>>>>>
>>>>>>>> # Generate a public key:
>>>>>>>> openssl req -batch -new -x509 \
>>>>>>>> -key "${key_dir}"/"${key_name}".key \
>>>>>>>> -out "${key_dir}"/"${key_name}".crt
>>>>>>>>
>>>>>>>>
>>>>>>> So far so good. In general, I suggest having multiple signing
>>>>>>> keys. You can put all the public keys in your u-boot so an image signed
>>>>>>> with any of those keys will be accepted. If you happen to have a signing
>>>>>>> key compromised, you can switch to one of the other ones. With that other
>>>>>>> key, you can sign an update the removes the compromised public key from
>>>>>>> future images.
>>>>>>>
>>>>>>>
>>>>>>>> Then we derive the ITS or image source file - a file that
>>>>>>>> hints/describes
>>>>>>>> the elements that will be verified and/or inside of the FIT image?
>>>>>>>> Lets
>>>>>>>> call this $FIT_ITS
>>>>>>>>
>>>>>>>> FIT is a container format. Generally, you'll create a FIT that
>>>>>>> contains the zImage, dtb, initramfs, etc. With FIT support enabled in
>>>>>>> u-boot, you only need to provide the single FIT image address to 'bootm'.
>>>>>>> u-boot will use the config section to find the individual elements, load
>>>>>>> them into RAM as needed, and boot.
>>>>>>>
>>>>>>>
>>>>>>>> / dts - v1 /;
>>>>>>>> / {
>>>>>>>> description = "Configuration to load a Xen Kernel";
>>>>>>>> #address-cells = <1>;
>>>>>>>> images {
>>>>>>>> linux_kernel @ 1 {
>>>>>>>> description = "Linux zImage";
>>>>>>>> data = /incbin / ("pathToImage/zImage");
>>>>>>>> type = "kernel";
>>>>>>>> arch = "arm";
>>>>>>>> os = "linux";
>>>>>>>> compression = "none";
>>>>>>>> load = <0xaf600000 >;
>>>>>>>> entry = <0xaf600000 >;
>>>>>>>> hash @ 1 {
>>>>>>>> algo = "sha1";
>>>>>>>> };
>>>>>>>> };
>>>>>>>> fdt @ 1 {
>>>>>>>> description = "FDT blob";
>>>>>>>> data = /incbin / ("PathToDTBUsedByBootingKernel/ex.dtb");
>>>>>>>> type = "flat_dt";
>>>>>>>> arch = "arm";
>>>>>>>> compression = "none";
>>>>>>>> load = <0xaec00000 >;
>>>>>>>>
>>>>>>>
>>>>>>> You generally don't need a 'load' property for the FDT or an
>>>>>>> initramfs. Without one, U-Boot will allocate RAM dynamically, if needed,
>>>>>>> and pass the relocated address to the kernel.
>>>>>>>
>>>>>>> hash @ 1 {
>>>>>>>> algo = "sha1";
>>>>>>>> };
>>>>>>>> };
>>>>>>>> };
>>>>>>>> configurations {
>>>>>>>> default = "config at 1";
>>>>>>>> config @ 1 {
>>>>>>>> description = "Plain Linux";
>>>>>>>> kernel = "linux_kernel at 1";
>>>>>>>> fdt = "fdt at 1";
>>>>>>>> loadables = "linux_kernel at 1";
>>>>>>>>
>>>>>>>
>>>>>>> 'loadables' is for other types of firmware. You only need the
>>>>>>> 'kernel' property for loading and booting the kernel.
>>>>>>>
>>>>>>>
>>>>>>>> };
>>>>>>>> };
>>>>>>>> };
>>>>>>>>
>>>>>>>> Question: Does a signature section go into this as well? underneath
>>>>>>>> the
>>>>>>>> hash node for each value?
>>>>>>>
>>>>>>>
>>>>>>>> signature at 1 {
>>>>>>>> algo = "sha1,rsa2048";
>>>>>>>> value = <...kernel signature 1...>
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> You add a signature section to each image you want signed within the
>>>>>>> FIT. In your case, add one for both the kernel and FDT images. Signatures
>>>>>>> go _next_ to the hash section, not in it. Omit the 'value' property as it
>>>>>>> will be generated for you later.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Then using the device-tree-compiler (dtc), I create a DTB for
>>>>>>>> u-boot. This
>>>>>>>> is the control FDT and this defines what keys are used etc..
>>>>>>>>
>>>>>>>
>>>>>>> The control FDT is used for U-Boot's driver model _as well as_
>>>>>>> providing public keys for verifying images. Your board may not currently
>>>>>>> use a control FDT in which case you create one from scratch.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> #Assemble control FDT for U-Boot with space for public key:
>>>>>>>> $DTC -p 0x1000 u-boot.dts -O dtb -o u-boot.dtb
>>>>>>>>
>>>>>>>> Question: What is required inside of the u-boot.dts for u-boot? Is
>>>>>>>> it
>>>>>>>> simply the same .dts used by the booting kernel, but with a section
>>>>>>>> proclaiming the keys?
>>>>>>>>
>>>>>>>
>>>>>>> This depends on the board you are using. For example, an AST2500
>>>>>>> requires a DTB for U-Boot to load the right drivers. The DTB used by
>>>>>>> U-Boot is slightly different from that used by Linux as the Linux DTB often
>>>>>>> includes addition configuration information. When using verified boot, the
>>>>>>> U-Boot DTB includes the public keys whereas the FDT/DTB stored in the FIT
>>>>>>> does not as Linux doesn't need them.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Question: Where will the compiled u-boot.dtb eventually go? Is
>>>>>>>> this put
>>>>>>>> into a FIT image, or flashed onto the board alongside the u-boot
>>>>>>>> bootloader
>>>>>>>> itself?
>>>>>>>>
>>>>>>>
>>>>>>> The U-Boot control FDT is compiled into the U-Boot binary. The FDT
>>>>>>> in the FIT is the FDT that is provided to Linux.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Next, given that the above steps are completed, I need to create a
>>>>>>>> FIT
>>>>>>>> image with space for the signature.
>>>>>>>>
>>>>>>>> # Generate fitImage with space for signature:
>>>>>>>> $MKIMG -D "-I dts -O dtb -p 2000" \
>>>>>>>> -f f$FIT_ITS $FIT_IMG
>>>>>>>>
>>>>>>>> Question: Is the FIT_IMAGE the actual zimage or is it an output
>>>>>>>> image that
>>>>>>>> contains all of the values contained within the ITS?
>>>>>>>>
>>>>>>>
>>>>>>> The latter. It will have a compiled version of the ITS as well as
>>>>>>> the actual images specified in the ITS (kernel, fdt).
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Next this FIT_IMAGE (assuming that this is the final FIT image that
>>>>>>>> contains the FDT and zImage) needs to be signed and the public key
>>>>>>>> added to
>>>>>>>> it; given that that the key information is in the uboot.
>>>>>>>>
>>>>>>>
>>>>>>> You sign the FIT_IMAGE and put the public keys in the control DTB.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> # Sign fitImage and add public key into u-boot.dtb:
>>>>>>>> $MKIMG -D "-I dts -O dtb -p 2000" -F \
>>>>>>>> -k "${key dir}" -K u-boot.dtb -r $FIT_IMG
>>>>>>>>
>>>>>>>
>>>>>>> This is putting the public keys used by the FIT image into the
>>>>>>> control DTB
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Then, we sign the subsequent fitImage again - correct?
>>>>>>>>
>>>>>>>> # Signing subsequent fitImage:
>>>>>>>> $MKIMG -D "-I dts -O dtb -p 2000" \
>>>>>>>> -k "${key dir}" -f $FIT_ITS -r $FIT_IMG
>>>>>>>>
>>>>>>>
>>>>>>> This is generating signatures for the images in the FIT and storing
>>>>>>> those signatures in the FIT.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Now that all of the above is done - we need to:
>>>>>>>> 1. Write our uboot to the flash
>>>>>>>> 2. Write our FIT_IMAGE to flash
>>>>>>>>
>>>>>>>> Question: Do we write anything else to persistent storage? The ITS?
>>>>>>>> etc..
>>>>>>>>
>>>>>>>
>>>>>>> No. Everything is contained in the U-Boot binary (control FDT
>>>>>>> including public keys) and the FIT (images, signatures)
>>>>>>>
>>>>>>>>
>>>>>>>> Question: Do we just boot using anything else or just bootm
>>>>>>>> 0xLocationOfTheFitImageInRAM
>>>>>>>>
>>>>>>>
>>>>>>> The latter. bootm will check the config section in the FIT and use
>>>>>>> the kernel, fdt, etc specified there.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Greatly appreciate any assistance to all of these questions and I'm
>>>>>>>> sure
>>>>>>>> this threat will be of interest to anyone else too.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>> U-Boot mailing list
>>>>>>>> U-Boot at lists.denx.de
>>>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Ron Brash
>>>> CTO & Co-founder of Atlants Embedded Inc.
>>>> www.atlantsembedded.com
>>>> ------------------------------------------------------------------
>>>>
>>>> Cell +1 438 880 6441 <(438)%20880-6441>
>>>> Email ron.brash at gmail.com
>>>> Blog www.pacificsimplicity.ca
>>>> LinkedIn ca.linkedin.com/in/ronbrash/
>>>>
>>>>
>>>>
>>>> This communication is intended for the use of the recipient to which it
>>>> is
>>>> addressed, and may contain confidential, personal, and or privileged
>>>> information. Please contact the sender immediately if you are not the
>>>> intended recipient of this communication, and do not copy, distribute,
>>>> or
>>>> take action relying on it. Any communication received in error, or
>>>> subsequent reply, should be deleted or destroyed.
>>>>
>>>
>>>
>>
>>
>> --
>>
>>
>> Ron Brash
>> CTO & Co-founder of Atlants Embedded Inc.
>> www.atlantsembedded.com
>> ------------------------------------------------------------------
>>
>> Cell +1 438 880 6441 <(438)%20880-6441>
>> Email ron.brash at gmail.com
>> Blog www.pacificsimplicity.ca
>> LinkedIn ca.linkedin.com/in/ronbrash/
>>
>>
>>
>> This communication is intended for the use of the recipient to which it is
>> addressed, and may contain confidential, personal, and or privileged
>> information. Please contact the sender immediately if you are not the
>> intended recipient of this communication, and do not copy, distribute, or
>> take action relying on it. Any communication received in error, or
>> subsequent reply, should be deleted or destroyed.
>>
>
>
--
Ron Brash
CTO & Co-founder of Atlants Embedded Inc.
www.atlantsembedded.com
------------------------------------------------------------------
Cell +1 438 880 6441
Email ron.brash at gmail.com
Blog www.pacificsimplicity.ca
LinkedIn ca.linkedin.com/in/ronbrash/
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
More information about the U-Boot
mailing list