[U-Boot] Complete verified uboot example
Ron Brash
ron.brash at gmail.com
Wed Mar 1 00:06:41 UTC 2017
Hello,
Here is a list of things I have tried: The raw zImage (which is compressed
with XZ), various addresses from indeed load address 0x23000000, entry
at 0x23008000
(and the same), I've tried setting the FTD address since it sets itself
neatly at 0x22f and change, which will probably get itself clobbered.
I've tried playing with the "magic" variables of ftdaddr, loadaddr, and
verify. No luck other than a few loops, hangs and
illegitimate instructions being executed.
Something is missing from my system, documentation or more and it appears
to be uboot and/or the fit format + FDT/DTBs.
Is there a magic formula? Before FIT I could just copy my kernel to
0x22... and my DTB to another address that wouldn't be clobbered, use bootm
and everything would work given I set it to a uImage.
Question, does the FDT need a load address specified as well? Why does the
documentation use all 0's? Usually, all zeros is either an example, or
will be inherit some address from a variable? (perhaps this is not
obviously documented).
On 28 February 2017 at 16:51, Rick Altherr <raltherr at google.com> wrote:
> I've never seen the kernel load address (the start address for copying
> the kernel image into RAM) being the same as the entrypoint address
> (where U-Boot jumps to begin executing the kernel). I'd expect the
> load address to be 0x23000000.
>
> It looks like you are converting the zImage into a U-Boot legacy image
> and then storing the legacy image in the FIT. Don't do that. Store
> the zImage in the FIT directly.
>
> On Tue, Feb 28, 2017 at 11:09 AM, Ron Brash <ron.brash at gmail.com> wrote:
> > 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:
> >>> 5dcf9a4328bca6fe5c3405e03b9a58402dce36f3a4f0c757e52091b050d2bcb2
> >>> 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 [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/linux/kernel/git/torvalds/
> linux.git/tree/Documentation/devicetree/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
> >>>>> 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.
> >>
> >>
> >
> >
> >
> > --
> >
> >
> > 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.
>
--
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