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