On Wed, Jan 29, 2014 at 3:49 PM, John Lewis <[email protected]> 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 properly. 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. > > John. > > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
