Re: [coreboot] Regarding offset adjustment for building coreboot.

[Martin Roth]

Not knowing which platform this is makes it a little harder to
determine what's locked in place.  We'd also need to know if this is
getting built from the top of the coreboot.org tree, an old
coreboot.org commit or an private repo with many changes from
coreboot.org.

Microcode should be able to be placed in any area for most of the FSP
platforms, but it might need to be changed in Kconfig or the Makefile
so that the system knows where it is.  You might also want to look at
just including the necessary microcode patches for your particular
board if possible.  Many of the FSP platforms include all available
microcode back to some pre-production parts by default.

The mrc cache can be moved at build time, but needs to be on the
correct boundary, and CANNOT have anything else in the same sector on
the flash.  The cache gets erased, so moving it to an odd boundary or
putting other things in the same sector will cause interesting issues.

The FSP itself can also be moved, but it needs to be rebased with
intel's FITC tool, and coreboot needs to know the location at build
time.

Finally, you might want to look at leaving out the small or
non-essential files, and add them after the build completes to make
sure that there is contiguous space for your essential components:
bootsplash.img, config, fspd.bin and cmos_layout.bin

Martin

On Fri, Apr 8, 2016 at 4:29 AM, Patrick Georgi via coreboot
<[e-mail]> wrote:
> 2016-04-08 11:17 GMT+02:00 Nico Huber <[e-mail]>:
> > you also stripped:
> >
> > fallback/payload               0x1b140    payload      769955
> >
> > I guess he means that a fresh build with a bigger (865KiB instead of
> > 752KiB) payload fails.
> > Of course you're right. I misunderstood the original issue.
>
> It's hard to tell how locked down various files are. There's at least
> some alignment going on for  cpu_microcode_blob.bin, mrc.cache,
> uefi_nvs.bin and fsp.bin, but there may be more to it.
>
> Tweaking -position and -align values for mrc.cache and uefi_nvs.bin
> should provide enough space for a larger payload.
> Given that uefi_nvs.bin is not mentioned in current master, I have no
> idea how that came to be.
>
> Patrick