Single device tree blob between linux and u-boot

Thu Oct 27 03:21:41 AEDT 2016

Excellent.  Thank you for testing.  Even though you mentioned using qemu
previously, I kept overlooking that I could do that myself.

Now the question is when and how should we switch to using FIT?  Do we want
to switch all boards at once or select it on a per-board basis?  At a
minimum, obmc-phosphor-image_type_uboot.bbclass needs to be refactored to
not include the initramfs directly in the flash image when using a kernel
fitImage.

I think we can safely remove the initrd segment from the flash layout on
all boards without breaking backward compatibility.  Basically, initrd
would be removed from the flash layout in aspeed-bmc-opp-flash-layout.dtsi
and obmc-phosphor-image_type_uboot would stop including the build initramfs
directly in the flash image.  For cuImage, we'd set INITRAMFS_IMAGE_BUNDLE
so the initrd gets built into the cuImage via the kernel's
CONFIG_INITRAMFS_SOURCE option.  fitImage already bundles the initramfs as
a separate image in the FIT.  As long as nothing in userspace is assuming
it can access the initramfs via mtd, everything should still work.

On Tue, Oct 25, 2016 at 10:22 PM, Joel Stanley <joel at jms.id.au> wrote:

> Hey Rick,
>
> On Fri, Oct 14, 2016 at 6:07 AM, Rick Altherr <raltherr at google.com> wrote:
> > I've been working on signed kernel images which depends on building FIT
> > images that include the kernel, initrd, and dtb.  The kernel_fitimage
> branch
> > of my tree (https://github.com/kc8apf/openbmc) will build an unsigned
> FIT
> > image by including the dtb specified in the machine config (usually from
> the
> > kernel).  There are also provisions in there for u-boot being built in
> two
> > stages so a control dtb that includes the public signing keys can be
> > combined into the final u-boot binary.  From how that is structure, I
> > suspect Maxim is right that there will be some differences between
> u-boot's
> > dtb and linux's dtb.  That shouldn't be an issue as the u-boot dtb gets
> > built into the u-boot image while the kernel dtb is loaded from the FIT
> > image.
>
> I finally got around to testing your FIT changes.
>
> I had to build my own u-boot, as we don't have FIT support enabled. We
> should make sure to add that to your patch series (in fact, we could
> enable it now interdependently of the other changes).
>
> I created an image like this:
>
> $ dd if=/dev/zero of=flash-test bs=1M count=32
> $ dd if=/home/joel/dev/u-boot/u-boot.bin of=flash-test conv=notrunc bs=1
> $ dd if=/home/joel/dev/obmc/fit/fitImage-core-image-minimal-
> initramfs-palmetto.bin
> of=flash-test conv=notrunc bs=1K seek=512
>
> Here it is booting in Qemu:
>
> $ qemu-system-arm -m 256M -M palmetto-bmc -nographic -nodefaults -net
> nic -net user,hostfwd=:127.0.0.1:2222-:22,hostname=qemu -serial stdio
> -drive file=~/dev/obmc/flash-test,format=raw,if=mtd
>
>
> U-Boot 2016.11-rc2-02954-g9f82ceb7118d (Oct 26 2016 - 15:36:23 +1030)
>
> SOC : AST2400-A0
> RST : Power On
> PLL :     24 MHz
> CPU :    384 MHz
> MEM :      0 MHz, EEC:Disable
> VGA :    16 MiB
> DRAM :   init by SOC
> Model: Palmetto BMC
> DRAM:  240 MiB
> WARNING: Caches not enabled
> Flash: 32 MiB
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   aspeednic#0
> Error: aspeednic#0 address not set.
>
> Hit any key to stop autoboot:  0
> ast# bootm 0x80000
> ## Loading kernel from FIT Image at 00080000 ...
>    Using 'conf at 1' configuration
>    Trying 'kernel at 1' kernel subimage
>      Description:  Linux kernel
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x00080124
>      Data Size:    1511416 Bytes = 1.4 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x40008000
>      Entry Point:  0x40008000
>      Hash algo:    sha1
>      Hash value:   1ab23fabb23234a21cd80651cd3c96a9b58a9e4c
>    Verifying Hash Integrity ... sha1+ OK
> ## Loading ramdisk from FIT Image at 00080000 ...
>    Using 'conf at 1' configuration
>    Trying 'ramdisk at 1' ramdisk subimage
>      Description:  ramdisk image
>      Type:         RAMDisk Image
>      Compression:  uncompressed
>      Data Start:   0x001f62b8
>      Data Size:    4724736 Bytes = 4.5 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: unavailable
>      Entry Point:  unavailable
>      Hash algo:    sha1
>      Hash value:   202c90e945a883ba8ff73fa4e197a17d6a9ce9f4
>    Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 00080000 ...
>    Using 'conf at 1' configuration
>    Trying 'fdt at 1' fdt subimage
>      Description:  Flattened Device Tree blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x001f1210
>      Data Size:    20463 Bytes = 20 KiB
>      Architecture: ARM
>      Hash algo:    sha1
>      Hash value:   63054f0970e89a70a15d1faac53fe9544a83e2e5
>    Verifying Hash Integrity ... sha1+ OK
>    Booting using the fdt blob at 0x1f1210
>    Loading Kernel Image ... OK
>    Loading Ramdisk to 4e700000, end 4eb81800 ... OK
>    Loading Ramdisk to 4e27e000, end 4e6ff800 ... OK
>    Loading Device Tree to 4e276000, end 4e27dfee ... OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.7.10-32ede9ab3deda73c484c4e2d372863bb73d0f7e0
> (joel at ka3.ozlabs.ibm.com) (gcc version 5.3.0 (GCC) ) #1 Wed Oct 26
> 13:57:23 AEDT 2016
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
> CPU: VIVT data cache, VIVT instruction cache
> Machine model: Palmetto BMC
> Memory policy: Data cache writeback
> SOC Rev: 02000303
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 60960
> Kernel command line: console=ttyS4,115200n8 root=/dev/ram rw
>
>
> Looks good!
>
> Cheers,
>
> Joel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161026/f61931cc/attachment-0001.html>