On Sat, Jun 19, 2021 at 9:41 AM James Feeney <ja...@nurealm.net> wrote: > > Hey Matt > > You recommend extracting all audio/dsp blobs, which appears straightforward, > but then, how can these blobs be referenced in the .config for inclusion in > coreboot? > > I only see "Include blobs for audio" with "make nconfig", symbol > INCLUDE_NHLT_BLOBS. Enabling this, the coreboot compile ends with "make: *** > No rule to make target > '3rdparty/blobs/soc/intel/glk/nhlt-blobs/dmic-2ch-48khz-16b.bin', needed by > 'build/coreboot.pre'. Stop."
I extracted these audio files from the recovery image, and placed them into the hardcoded path referenced by the makefile, as shown above in the error. see: src/soc/intel/apollolake/Makefile.inc around ln 151 for the list of files needed > > How did you include the chromeos recovery image audio blobs into coreboot? > > Thanks > James > > > On 6/18/21 9:16 PM, James Feeney wrote: > > On 6/18/21 8:25 PM, Matt DeVillier wrote: > >> `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. > >> > >> > > > > Ha! Many thanks Matt. That is very useful information, every point! The > > process is so simple, given the proper instructions - and seems > > insurmountably opaque without them. Definitely information that would be > > useful to find in the wiki! > > > > I'll let you know how it works. > > > > James > > > > > >> On Fri, Jun 18, 2021, 8:31 PM James Feeney <ja...@nurealm.net > >> <mailto: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 > >> <mailto: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 > >> <mailto:coreboot@coreboot.org> > >> >> To unsubscribe send an email to coreboot-le...@coreboot.org > >> <mailto:coreboot-le...@coreboot.org> > >> > > _______________________________________________ > > 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
