I've been swamped this week. I hope to pick this up with you next week.
On Tue, Feb 28, 2017 at 4:06 PM, Ron Brash <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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@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@1 { >> > algo = "sha256"; >> > }; >> > }; >> > fdt@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@1{ >> > algo = "sha256"; >> > }; >> > }; >> > }; >> > configurations { >> > default = "config@1"; >> > config@1{ >> > description = "Plain Linux"; >> > kernel = "linux_kernel@1"; >> > fdt = "fdt@1"; >> > signature@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@1' >> > Using 'config@1' configuration >> > Trying 'linux_kernel@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@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@1' from image at 0x22000000 >> > * ramdisk: no 'ramdisk' in config >> > * fdt: using config 'config@1' from image at 0x22000000 >> > ## Checking for 'FDT'/'FDT Image' at 22000000 >> > ## Loading fdt from FIT Image at 22000000 ... >> > Using 'config@1' configuration >> > Trying 'fdt@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@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@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@1' >> > Hash algo: sha256 >> > Hash value: >> > 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe >> > Hash len: 32 >> > Image 1 (fdt@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@1' >> > Hash algo: sha256 >> > Hash value: >> > c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689 >> > Hash len: 32 >> > Default Configuration: 'config@1' >> > Configuration 0 (config@1) >> > Description: Plain Linux >> > Kernel: linux_kernel@1 >> > FDT: fdt@1 >> > ## Checking hash(es) for FIT Image at 22000000 ... >> > Hash(es) for Image 0 (linux_kernel@1): sha256+ >> > Hash(es) for Image 1 (fdt@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 <[email protected]> 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 <[email protected]> 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@1' >> >>> Using 'config@1' configuration >> >>> Trying 'linux_kernel@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@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@1' from image at 0x22000000 >> >>> * ramdisk: no 'ramdisk' in config >> >>> * fdt: using config 'config@1' from image at 0x22000000 >> >>> ## Checking for 'FDT'/'FDT Image' at 22000000 >> >>> ## Loading fdt from FIT Image at 22000000 ... >> >>> Using 'config@1' configuration >> >>> Trying 'fdt@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@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 <[email protected]> >> >>> 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 <[email protected]> >> >>>> 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@1 { >> >>>>> description = "Linux zImage"; >> >>>>> data = /incbin/("zImage"); >> >>>>> type = "kernel"; >> >>>>> arch = "arm"; >> >>>>> os = "linux"; >> >>>>> compression = "none"; >> >>>>> load = <0x20000000>; >> >>>>> entry = <0x20008000>; >> >>>>> kernel-version = <1>; >> >>>>> hash@1 { >> >>>>> algo = "sha256"; >> >>>>> }; >> >>>>> }; >> >>>>> fdt@1 { >> >>>>> description = "FDT blob"; >> >>>>> data = /incbin/("myboard.dtn"); >> >>>>> type = "flat_dt"; >> >>>>> arch = "arm"; >> >>>>> compression = "none"; >> >>>>> fdt-version = <1>; >> >>>>> hash@1{ >> >>>>> algo = "sha256"; >> >>>>> }; >> >>>>> }; >> >>>>> }; >> >>>>> configurations { >> >>>>> default = "config@1"; >> >>>>> config@1{ >> >>>>> description = "Plain Linux"; >> >>>>> kernel = "linux_kernel@1"; >> >>>>> fdt = "fdt@1"; >> >>>>> signature@1{ >> >>>>> algo = "sha256,rsa2048"; >> >>>>> key-name-hint = "dev_key"; >> >>>>> sign-images = "fdt", "kernel"; >> >>>>> }; >> >>>>> }; >> >>>>> }; >> >>>>> }; >> >>>>> >> >>>>> Does NOT equal (for brevity - I just used the node) >> >>>>> >> >>>>> fdt@1 { >> >>>>> description = "FDT blob"; >> >>>>> data = /incbin/("myboard.dtn"); >> >>>>> type = "flat_dt"; >> >>>>> arch = "arm"; >> >>>>> compression = "none"; >> >>>>> fdt-version = <1>; >> >>>>> hash@1{ >> >>>>> algo = "sha256"; >> >>>>> }; >> >>>>> signature@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 <[email protected]> >> >>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <[email protected]> >> >>>>>> 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 <[email protected]> >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <[email protected]> >> >>>>>>>> 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@1"; >> >>>>>>>>> config @ 1 { >> >>>>>>>>> description = "Plain Linux"; >> >>>>>>>>> kernel = "linux_kernel@1"; >> >>>>>>>>> fdt = "fdt@1"; >> >>>>>>>>> loadables = "linux_kernel@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@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 >> >>>>>>>>> [email protected] >> >>>>>>>>> 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 [email protected] >> >>>>> 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 [email protected] >> >>> 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 [email protected] >> > 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 [email protected] > 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. _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
