I'm not an x86 guy so I don't really know the details here, but I think this might just not work for non-Chrome OS builds yet. The error you get suggests that the problem is about you not having an IFWI section in your FMAP.
The FMAP describes the high-level layout of the ROM. Chrome OS has a bunch of custom requirements about what goes into its ROM, so Chrome OS boards usually have a custom "chromeos.fmd" file to supply the FMAP. For normal x86 builds, the build system uses util/cbfstool/default-x86.fmd where a bunch of values get filled in by the toplevel Makefile.inc. This mechanism was designed for the old-style Intel flash layout where the reset vector was at the end of the ROM.
Apollolake looks quite different, and I don't really know all the details, but somehow the reset vector is interwoven with that IFWI thing near the front of the ROM. You can see an example Chrome OS Apollolake FMAP in src/mainboard/google/reef/chromeos.fmd, and compare it to a normal Chrome OS x86 FMAP like src/mainboard/google/glados/chromeos.fmd . The Apollolake support was added by Chrome OS folks, so maybe they didn't bother adapting the default-x86.fmd mechanism to work with it because all the Chrome OS boards have their own FMAP anyway. You may be able to get further in your build if you copy the reef/chromeos.fmd file, adapt it to your mainboard if necessary, and then point to it with CONFIG_FMDFILE. On Thu, May 10, 2018 at 11:33 PM Hal Martin hal.martin@gmail.com wrote:
Hi all,
I am trying to build coreboot for an Apollo Lake platform. I've read the
coreboot presentation on Apollo Lake, and some of the threads about the IFWI on the coreboot mailing list:
https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf https://mail.coreboot.org/pipermail/coreboot/2017-November/085482.html https://mail.coreboot.org/pipermail/coreboot/2017-September/085217.html
After reading this and digesting the information for a week, I'm still no
closer to understanding how the build process is supposed to work.
I have extracted the descriptor from the SPI image, and put the entire
16MB image in the 3rdparty directory. When I try to build coreboot, I'm getting the following error:
Image written successfully to build/cbfs/fallback/ifwi.bin.tmp. Image does not contain sub-partition OBBP(6). Sub-partition IBBP(4) entry IBBL replaced from file
build/cbfs/fallback/bootblock.bin.
Image written successfully to build/cbfs/fallback/ifwi.bin.tmp. E: Image is missing 'IFWI' region E: The image will be left unmodified. src/soc/intel/apollolake/Makefile.inc:137: recipe for target
'files_added' failed
make: *** [files_added] Error 1
Attached is the output of ifdtool and ifwitool for the SPI dump of the
vendor firmware for platform I'm working on.
A few interesting observations (from my perspective):
- There doesn't seem to be an OBBP in this image.
- My ifwitool output seems to match the output of others (e.g.
https://mail.coreboot.org/pipermail/coreboot/2017-September/085210.html )
- This platform (CompuLab Fitlet 2) only has SPI flash, no EMMC. My
understanding is that IFWI is the same whether it's on EMMC or SPI.
Some open questions I have:
- Is it possible to build a flashable image using only coreboot and a
dump of the vendor firmware, or does one need to use the Intel FSP and FIT tools and some "stitching" to get a flashable image with a coreboot payload?
- Is there any public documentation available describing the FSP 2.0/IFWI
flash layout?
- Is it possible to obtain FIT for Apollo Lake without having an NDA or
corporate account with Intel? It seems that absolutely everything about Apollo Lake is classified as "confidential" on Intel's website:
https://www.intel.com/content/www/us/en/design/products-and-solutions/proces...
Can anyone who was working on an FSP 2.0 platform (e.g. Cameron Craig,
Paul Penz, Morris) follow up on how they managed to build a flashable image?
Thanks, Hal -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot