<div dir="ltr">Hi Nico and Julius,<div><br></div><div>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.</div><div><br></div><div>I'll update you on any progress (or lack thereof).</div><div><br></div><div>Cheers,</div><div>Hal</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 19, 2018 at 4:57 PM, Nico Huber <span dir="ltr"><<a href="mailto:nico.h@gmx.de" target="_blank">nico.h@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 19.05.2018 02:27, Julius Werner wrote:<br>
> Apollolake looks quite different, and I don't really know all the details,<br>
> but somehow the reset vector is interwoven with that IFWI thing near the<br>
> front of the ROM. You can see an example Chrome OS Apollolake FMAP in<br>
> src/mainboard/google/reef/<wbr>chromeos.fmd, and compare it to a normal Chrome<br>
> OS x86 FMAP like src/mainboard/google/glados/<wbr>chromeos.fmd . The Apollolake<br>
> support was added by Chrome OS folks, so maybe they didn't bother adapting<br>
> the default-x86.fmd mechanism to work with it because all the Chrome OS<br>
> boards have their own FMAP anyway. You may be able to get further in your<br>
> build if you copy the reef/chromeos.fmd file, adapt it to your mainboard if<br>
> necessary, and then point to it with CONFIG_FMDFILE.<br>
<br>
</span>I'm not an expert for Apollo Lake either, but I know other Intel plat-<br>
forms and my way around their documentation.<br>
<br>
I too believe that adding an .fmd file like Julius described, will<br>
fix your problem. Though, there are already some non-CrOS boards in<br>
the tree. Might be more worth looking at their (simpler) .fmd (e.g.<br>
`src/mainboard/siemens/mc_<wbr>apl1/mc_apl1.fmd`).<br>
<br>
Regarding the details, I've digged around a little. Here is what I found<br>
out so far (stop reading here unless you really want to know, it might<br>
confuse you even more):<br>
<br>
Apollo Lake uses a Firmware Descriptor (IFD) like other Intel platforms,<br>
but the IFD's layout is used much less. One region amidst this layout<br>
is the IFWI. The IFWI is partitioned by other means and contains code<br>
for some integrated controllers and also what used to be the BIOS. The<br>
latter is divided into IBB and OBB. The IBB partition is used for core-<br>
boot's bootblock. The OBB partition for everything else in coreboot. The<br>
OBB is the last part of the IFWI.<br>
<br>
To make the situation even more confusing, somebody had the great idea<br>
to use the same term, IFWI, for something slightly different. I guess to<br>
separate the read-only from updateable parts better, IFWI in the notion<br>
of coreboot's .fmd files is the actual IFWI minus the OBB. I will refer<br>
to it as the RO_CORE_IFWI (might not be the worst idea to rename it like<br>
this in coreboot). So what happens during build (cf. `soc/intel/<br>
apollolake/Makefile.inc:125`):<br>
<br>
  - coreboot is provided an IFWI image (that has to contain all the<br>
    coreboot-unrelated code for the extra chipset controllers, those<br>
    are just passed through by our build system).<br>
<br>
  - Our build system crafts the RO_CORE_IFWI with the provided IFWI:<br>
      o The OBB is stripped off.<br>
      o The IBB is replaced with coreboot's bootblock.<br>
<br>
  - The final image is build with<br>
      o the RO_CORE_IFWI in place of IFWI in the .fmd and<br>
      o all other coreboot parts in their respective place in the .fmd.<br>
<br>
Looking at the `mc_apl1.fmd` again:<br>
<br>
  - SI_DESC is like the Intel Firmware Descriptor.<br>
  - IFWI is the RO_CORE_IFWI (IFWI minus OBB with replaced IBB).<br>
  - Everything else before DEVICE_EXTENSION is the OBB.<br>
  - DEVICE_EXTENSIONS is another partition in the IFD, that I've just<br>
    learned about.<br>
<br>
Nico<br>
<br>
PS. This is how I would have written such .fmd (currently not compatible<br>
    to `apollolake/Makefile.inc`):<br>
<br>
    FLASH 16M {<br>
        SI_DESC@0x0 0x1000<br>
        IFWI@0x1000 0xefe000 {<br>
            RO_CORE_IFWI@0x0 0x2ff000<br>
            OBB@0x2ff000 0xbff000 {<br>
                FMAP@0x0000 0x800<br>
                COREBOOT(CBFS)@0x800 0xb9d800<br>
                UNIFIED_MRC_CACHE@0xb9e000 0x21000 {<br>
                    RECOVERY_MRC_CACHE@0x0 0x10000<br>
                    RW_MRC_CACHE@0x10000 0x10000<br>
                    RW_VAR_MRC_CACHE@0x20000 0x1000<br>
                }<br>
                BIOS_UNUSABLE@0xbbf000 0x40000<br>
            }<br>
        }<br>
        DEVICE_EXTENSION@0xeff000 0x100000<br>
        UNUSED_HOLE@0xfff000 0x1000<br>
    }<br>
</blockquote></div><br></div>