[coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region

[Hal Martin]

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 <nico.h at gmx.de> 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 at 0x0 0x1000
>         IFWI at 0x1000 0xefe000 {
>             RO_CORE_IFWI at 0x0 0x2ff000
>             OBB at 0x2ff000 0xbff000 {
>                 FMAP at 0x0000 0x800
>                 COREBOOT(CBFS)@0x800 0xb9d800
>                 UNIFIED_MRC_CACHE at 0xb9e000 0x21000 {
>                     RECOVERY_MRC_CACHE at 0x0 0x10000
>                     RW_MRC_CACHE at 0x10000 0x10000
>                     RW_VAR_MRC_CACHE at 0x20000 0x1000
>                 }
>                 BIOS_UNUSABLE at 0xbbf000 0x40000
>             }
>         }
>         DEVICE_EXTENSION at 0xeff000 0x100000
>         UNUSED_HOLE at 0xfff000 0x1000
>     }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180522/c3108b3a/attachment.html>