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

Hal Martin hal.martin at gmail.com
Mon May 28 08:06:41 CEST 2018


Hi Nico and Julius,

Copying the fmd file from siemens/mc_apl1 is enough to build a coreboot
image:


Created CBFS (capacity = 12179416 bytes)
    CBFS       fallback/romstage
    CBFS       cpu_microcode_blob.bin
    CBFS       fallback/ramstage
    CBFS       config
    CBFS       revision
    CBFS       fspm.bin
    CBFS       fsps.bin
    CBFS       fallback/postcar
    CBFS       fallback/dsdt.aml
    CBFS       fallback/payload
    Compile IFDTOOL
    HOSTCC     util/ifdfake/ifdfake
    DD         Adding Intel Firmware Descriptor
    IFDTOOL    Unlocking Management Engine
File build/coreboot.pre is 16777216 bytes
Writing new image to build/coreboot.pre.new
    CBFS       coreboot.rom
    UPDATE-FIT
    CBFSLAYOUT  coreboot.rom

This image contains the following sections that can be manipulated with
this tool:

'SI_DESC' (size 4096)
'IFWI' (size 3141632)
'COREBOOT' (CBFS, size 12179456)
'RECOVERY_MRC_CACHE' (size 65536)
'RW_MRC_CACHE' (size 65536)
'RW_VAR_MRC_CACHE' (size 4096)
'BIOS_UNUSABLE' (size 262144)
'DEVICE_EXTENSION' (size 1048576)
'UNUSED_HOLE' (size 4096)

It is possible to perform either the write action or the CBFS add/remove
actions on every section listed above.
To see the image's read-only sections as well, rerun with the -w option.
    CBFSPRINT  coreboot.rom

Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           28228 none
cpu_microcode_blob.bin         0x6f00     microcode           0 none
fallback/ramstage              0x6f80     stage           71536 none
config                         0x18740    raw               630 none
revision                       0x18a00    raw               575 none
fspm.bin                       0x18c80    fsp            364544 none
fallback/dsdt.aml              0x71cc0    raw                99 none
(empty)                        0x71d80    null             2584 none
fsps.bin                       0x727c0    fsp            172032 none
fallback/postcar               0x9c800    stage           17204 none
fallback/payload               0xa0b80    payload        633503 none
(empty)                        0x13b680   null         10854680 none
bootblock                      0xb957c0   bootblock       32768 none
    HOSTCC     cbfstool/ifwitool.o
    HOSTCC     cbfstool/ifwitool (link)

Built compulab/fitlet2 (Fitlet2)

compulab/fitlet2 is a copy of intel/apollolake_rvp with RVP2 removed as it
uses LPDDR3 and the Fitlet2 uses DDR3L (RVP1). Apparently the vendor used
Oxbow Hill CRB, but this platform was never added to coreboot.

The resulting image does not appear to boot, there is no output on the
uart. I can inspect it with ifdtool, but not with ifwitool.

Is it expected that ifwitool will not work on the coreboot generated image?
Or does this indicate I've made a mistake somewhere?

Thanks,
Hal

On Tue, May 22, 2018 at 9:04 PM, Hal Martin <hal.martin at gmail.com> wrote:

> 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/20180528/7aff3dd0/attachment.html>


More information about the coreboot mailing list