Hi Nico and Julius, Thank you for the helpful tips. I will look into the fmd files in the tree and see if I can come up with something sensible for this board.
I'll update you on any progress (or lack thereof). Cheers, Hal On Sat, May 19, 2018 at 4:57 PM, Nico Huber <[email protected]> wrote: > Hi, > > On 19.05.2018 02:27, Julius Werner wrote: > > 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. > > I'm not an expert for Apollo Lake either, but I know other Intel plat- > forms and my way around their documentation. > > I too believe that adding an .fmd file like Julius described, will > fix your problem. Though, there are already some non-CrOS boards in > the tree. Might be more worth looking at their (simpler) .fmd (e.g. > `src/mainboard/siemens/mc_apl1/mc_apl1.fmd`). > > Regarding the details, I've digged around a little. Here is what I found > out so far (stop reading here unless you really want to know, it might > confuse you even more): > > Apollo Lake uses a Firmware Descriptor (IFD) like other Intel platforms, > but the IFD's layout is used much less. One region amidst this layout > is the IFWI. The IFWI is partitioned by other means and contains code > for some integrated controllers and also what used to be the BIOS. The > latter is divided into IBB and OBB. The IBB partition is used for core- > boot's bootblock. The OBB partition for everything else in coreboot. The > OBB is the last part of the IFWI. > > To make the situation even more confusing, somebody had the great idea > to use the same term, IFWI, for something slightly different. I guess to > separate the read-only from updateable parts better, IFWI in the notion > of coreboot's .fmd files is the actual IFWI minus the OBB. I will refer > to it as the RO_CORE_IFWI (might not be the worst idea to rename it like > this in coreboot). So what happens during build (cf. `soc/intel/ > apollolake/Makefile.inc:125`): > > - coreboot is provided an IFWI image (that has to contain all the > coreboot-unrelated code for the extra chipset controllers, those > are just passed through by our build system). > > - Our build system crafts the RO_CORE_IFWI with the provided IFWI: > o The OBB is stripped off. > o The IBB is replaced with coreboot's bootblock. > > - The final image is build with > o the RO_CORE_IFWI in place of IFWI in the .fmd and > o all other coreboot parts in their respective place in the .fmd. > > Looking at the `mc_apl1.fmd` again: > > - SI_DESC is like the Intel Firmware Descriptor. > - IFWI is the RO_CORE_IFWI (IFWI minus OBB with replaced IBB). > - Everything else before DEVICE_EXTENSION is the OBB. > - DEVICE_EXTENSIONS is another partition in the IFD, that I've just > learned about. > > Nico > > PS. This is how I would have written such .fmd (currently not compatible > to `apollolake/Makefile.inc`): > > FLASH 16M { > SI_DESC@0x0 0x1000 > IFWI@0x1000 0xefe000 { > RO_CORE_IFWI@0x0 0x2ff000 > OBB@0x2ff000 0xbff000 { > FMAP@0x0000 0x800 > COREBOOT(CBFS)@0x800 0xb9d800 > UNIFIED_MRC_CACHE@0xb9e000 0x21000 { > RECOVERY_MRC_CACHE@0x0 0x10000 > RW_MRC_CACHE@0x10000 0x10000 > RW_VAR_MRC_CACHE@0x20000 0x1000 > } > BIOS_UNUSABLE@0xbbf000 0x40000 > } > } > DEVICE_EXTENSION@0xeff000 0x100000 > UNUSED_HOLE@0xfff000 0x1000 > } >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
