We used cbfstool from coreboot 4.13, because it was the
last version to work with the particular format used
for stage files, before the CBFS standard changed in newer
releases of cbfstool.

When I added this board to Libreboot, it was source-only at
first so it didn't matter. I didn't want to do a standalone
cbfstool binary, in case some people decided to use that one
on newer boards, which would cause all sorts of issues.

So I bodged it and just included an import of coreboot 4.13.

Well, the cbfstool from coreboot 4.11, as used for FAM15H
AMD boards, is compatible. I checked the code diff between
the two, and there is no meaningful difference.

I've tested this, and it works, since the last release or
two now includes 820 G2 images, so I  was able to use those
with ./mk inject, to verify whether the refcode file is
still grabbed properly. We need the refcode to handle MRC
on Broadwell platform, but we extract it from an old Google
Chromebook image, that uses the old CBFS stage file layout.

This change solves my problem: the problem was that releases
are bloated further, due to including this extra coreboot
version. This should reduce the size of the next release
considerably, especially after decompressing the tarball.

Signed-off-by: Leah Rowe <leah@libreboot.org>

Signed-off-by: Leah Rowe <leah@libreboot.org>

Instead of calling fe_, prefix x_ as indicated.

Signed-off-by: Leah Rowe <leah@libreboot.org>

sh macros ftw

Signed-off-by: Leah Rowe <leah@libreboot.org>

See, coreboot bug report:

https://ticket.coreboot.org/issues/590

We hadn't noticed this for quite a while, since we always
just booted with iomem=relaxed when needing to run cbmem,
since in practise it was always combined with other tasks
that require access to lower memory.

GRUB currently matches coreboot's own mmap for cbmem, but
for example SeaBIOS marks cbmem as E820 reserved. Therefore,
this change replicates the SeaBIOS behaviour.

Without this patch, Linux needs to boot with iomem=relaxed
for cbmem access, for example when running ./cbmem -1

With this patch, cbmem is now accessible regardless. This
patch also prevents Linux from overwriting parts of CBMEM.

Thanks go to Paul Menzel, who wrote this GRUB patch.

Thanks also go to Nicholas Chin, who provided testing, all
the way from Coreboot 25.03 back to Coreboot 4.20. It seems
that this is just something the payloads have to handle.

This means that both SeaBIOS and GRUB no longer have this
bug, in Libreboot; now what remains is to replicate the
test with our U-Boot payload.

Signed-off-by: Leah Rowe <leah@libreboot.org>

This is similar to the 9020SFF, but this board has ECC support.
However, the native raminit isn't used here, even though it is
otherwise compatible, because the native init doesn't do ECC yet.

The broadwell mrc.bin has ECC support, which is also used on the
HP EliteBook 820 G2. The MRC for broadwell can be used on haswell
boards such as the T1700.

Add both the SFF and MT variants. Since these are identical to the
9020 variants, except for slightly different PCH enabling ECC, we
can just re-use the 9020 port without issue.

We *could* add a variant to coreboot, for T1700, but there is not
really any pressing need. It is simply the 9020sff/mt with mrc.bin

Signed-off-by: Leah Rowe <leah@libreboot.org>