[coreboot] C720 swapparoo
adurbin at chromium.org
Wed Jan 29 23:03:41 CET 2014
On Wed, Jan 29, 2014 at 3:49 PM, John Lewis <jlewis at johnlewis.ie> wrote:
> On 29/01/14 20:54, Duncan Laurie wrote:
>> - The SPI flash descriptor, which lives at the bottom 4K of the SPI
>> chip in the SI_DESC region of the flashmap. It is readable from the
>> host but not writable.
>> - The Management Engine binary, which lives at the bottom 2MB (-4K for
>> the descriptor) of the SPI chip in the SI_ME region of the flashmap.
>> It is neither readable or writable from the host.
> Okay, I have the descriptor and ME binaries already (I guess it doesn't
> matter too much about the ME anyway, since it being missing wouldn't prevent
> boot, just cause half-hourly power-off).
>> For the basic coreboot+payload (BOOT_STUB region in flashmap) the
>> binaries are all in CBFS and can be read out with the usual 'cbfstool
>> bios.bin extract -n NAME -f NAME'
>> - The mainboard-specific DIMM SPDs, stored as "spd.bin" (also checked
>> in to the mainboard directory in coreboot)
>> - The reference code binary, which is stored as "mrc.bin"
>> - The Video BIOS, which is stored as "pci8086,0406.rom"
>> - The microcode, which is stored as "cpu_microcode_blob.bin" (with
>> recent changes this may be handled differently upstream now)
> This is where we reach the crux of the matter - In the stock/shellball
> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in
> upstream coreboot or CrOS coreboot can decipher. Looking at the file in
> hexedit it appears to be almost identical to a CBFS that is recognised, but
> that's it. I have managed to extract the SVGA binary from the CBFS in the
> RW_LEGACY slot, and I've made an educated guess as to where the system-agent
> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE
> mrc.bin" or similar with the binary itself following, surrounded by FF's)
> copying and pasting it to a file. I would like to know if I am correct in my
> assumptions about extracting that file manually and what size it should be,
> in bytes?
That's interesting. It is just a regular 'ol cbfs. The images that
shipped with your device is an 8MiB SPI. First 2MiB Duncan covered.
The next 5 have nothing to do w/ coreboot proper -- all the extra
vboot firmware bits. The last 1MiB is the cbfs.
The issue w.r.t. cbfstool complaining is that in the header of the
cbfs there is a field which states 8MiB rom. So you need to make an
8MiB file with that upper 1MiB cbfs at the top. It should then read
In other words: rom size != cbfs size.
> Further more, trying to use upstream coreboot to compile with that 2 MB
> management engine yields:
> Created CBFS image (capacity = 8386544 bytes)
> E: Not enough space for content.
> E: Could not add [c720-me.bin, 2093056 bytes (2044 KB)@0x7a0000]; too big?
> E: Failed to add 'c720-me.bin' into ROM image.
> I have tried 2, 4, 6, and 8 MB CBFS in coreboot menuconfig. Not sure why
> building for Peppy tries to put the ME in CBFS when other builds don't.
> Building using CrOS coreboot works, but I am loath to recommend someone
> foolhardy with a C720 try it, unless I know there is a reasonable chance the
> binaries are okay/correct.
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot