`cbfstool <filename> layout` will show the regions in the FMAP, use `cbfstool <filename> read -r IFWI -f ifwi.bin` to extract.
I would use the exact same microcode file as the recovery image; coreboot isn't guaranteed to include all applicable cpuids, and APL/GLK seem weird about updating in the FIT FSP/GOP display init requires the vbt to be included/added, it should be an option from the menu. vbgfx.bin is only used by depthcharge, it's not needed for any other payload. On Fri, Jun 18, 2021, 8:31 PM James Feeney <ja...@nurealm.net> wrote: > > On 6/18/21 11:00 AM, Matt DeVillier wrote: > > hi James, > > > > I've built working upstream coreboot images for both APL and GLK > > Chromebooks (reef and octopus boards respectively). > > > > Starting with a recovery image for the board you're working with, > > you'll need to extract the ifwi.bin, vbt.bin, fspm.bin/fsps.bin (GLK > > only; APL can use 3rdparty fsp repo), CPU microcode, and all audio/dsp > > blobs. use cbfstool for this. Then you'll need to set your config to > > use the extracted blobs / place them in the expected locations, set > > display init to FSP/GOP, and set the payload to Tianocore. Here's my > > defconfig for google/ampton (GLK) as an example: > > > > CONFIG_VENDOR_GOOGLE=y > > CONFIG_NO_POST=y > > > CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/google/ampton/flashdescriptor.bin" > > CONFIG_BOARD_GOOGLE_AMPTON=y > > # CONFIG_CONSOLE_SERIAL is not set > > CONFIG_INCLUDE_NHLT_BLOBS=y > > CONFIG_INTEL_GMA_ADD_VBT=y > > > CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/google/ampton/vbt.bin" > > CONFIG_NEED_IFWI=y > > CONFIG_IFWI_FILE_NAME="3rdparty/blobs/mainboard/google/ampton/ifwi.bin" > > CONFIG_HAVE_IFD_BIN=y > > CONFIG_ADD_FSP_BINARIES=y > > CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/google/ampton/fspm.bin" > > CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/google/ampton/fsps.bin" > > CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y > > > CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/soc/intel/glk/cpu_microcode_blob.bin" > > CONFIG_LOCK_MANAGEMENT_ENGINE=y > > CONFIG_PAYLOAD_TIANOCORE=y > > > > APL would be almost the exact same, but without the 3 FSP-related lines. > > > > cheers, > > Matt > > > > > Thanks very much for that. Hmm - some questions: > > My chromebook is the google octopus casta bluebird. Running "cbfstool > bios-casta.ro-11297-193-0.rw-11297-193-0.bin print" does not show any kind > of ifwi.bin file. Running "ifwitool > bios-casta.ro-11297-193-0.rw-11297-193-0.bin print -d" only gives > references to the components, those shown with "ifwitool -h", under "NAME > should be one of:". That's why I was asking about how to extract an > ifwi.bin. > > Did your Ampton recovery image include a distinct "ifwi.bin" file, by > using cbfstool? > > I'm building u-boot as the payload, instead of Tianocore, but I don't > expect that that make any difference. > > However, "cbfstool build/coreboot.rom print" does show a > cpu_microcode_blob.bin file, built by coreboot. I'm guessing that this > microcode file is as good as the one in the recovery image? > > The recovery image also has a vbgfx.bin. I'm wondering if I should do > something with this? "make nconfig" fails to offer any gfx settings, > though several gfx settings can be seen when manually editing the .config. > > So, I'm stuck trying to understand sourcing this ifwi.bin file. Any > suggestions? > > James > > > > > On Fri, Jun 18, 2021 at 11:13 AM James Feeney <ja...@nurealm.net> wrote: > >> > >> Back in 2017 there was some brief discussion of how to compile coreboot > for apollolake, with some uncertainty about the IFWI segment. Does anyone > know the current status of coreboot support for apollolake/geminilake? In > particular, to replace a Chromebook boot rom? > >> > >> The coreboot configuration options are confusing in the sense that the > intended outcome of particular settings is not explained. For instance, > there is coreboot code compiled addressing the Intel FSP, but there are no > FSP files generated in the resulting coreboot.rom. > >> > >> Working from a Chromebook bios upgrade image, it seems that many > components might simply be copied from there, but then, there seems to be > no tool to extract the complete IFWI segment from an existing bios image, > except in pieces that would require reassembly. Is there some way that an > existing IFWI segment can be extracted and used in another compiled > coreboot image? Or, is there "security" code in the IFWI segment that will > prevent a compatible working coreboot rom built in this way? > >> > >> James > >> _______________________________________________ > >> coreboot mailing list -- coreboot@coreboot.org > >> To unsubscribe send an email to coreboot-le...@coreboot.org >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org