lbmk.git/config/coreboot/kgpe-d16-rdimm_16mb, branch master

do not allow dashes in coreboot target names

2024-05-29T02:15:25+00:00

Command: ./vendor download kcma-d8-rdimm_16mb

Output was:

include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory

That will have to be audited later on, but the recent
more stringent error checking in vendor.sh triggered
this previously untriggered error message. The error
was in fact already occuring before, silently.

Anyway, mitigate by renaming all coreboot targets so
that they do not contain hyphens in the name. This
should avoid triggering errors in that eval command,
on line 115 in lib.sh

Signed-off-by: Leah Rowe

re-configure grub_scan_disk on various targets

2024-05-27T20:33:53+00:00

Signed-off-by: Leah Rowe

remove all status checks. only handle release.

2024-05-11T17:53:12+00:00

the release variable is all we need, turning a target on
or off for a given release.

the status checks were prone to bugs, and unnecessary; it
also broke certain benchmark scripts.

it's better to keep the lbmk logic simpler. board status
will be moved to the documentation instead.

Signed-off-by: Leah Rowe

kcma-d8/kgpe-d16: mark as tested(unstable)

2024-04-27T05:08:07+00:00

raminit has never been fully reliable on this board, and so
this board has never been stable. so, now that lbmk specifies
such status per board, mark these boards as such.

Signed-off-by: Leah Rowe

build/roms: report status when building images

2024-04-26T19:36:42+00:00

export LBMK_VERSION_TYPE=x
x can be: stable, unstable

in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, lbmk defaults to "unknown"

if LBMK_VERSION_TYPE is set, no confirmation is asked
if the given target matches what's set (but what's set
in that environmental variable can only be stable or
unstable)

if LBMK_RELEASE="y", no confirmation is asked, unless
the target is something other than stable/unstable

"unstable" means it works, but has a few non-breaking
bugs, e.g. broken s3 on dell e6400

whereas, if raminit regularly fails or it is so absolutely
unreliable as to be unusable, then the board should be
declared "broken"

untested means: it has not been tested

With this change, it should now be easier to track whether
a given board is tested, in preparation for releases. When
working on trees/boards, status can be set for targets.

Also: in the board directory, you can add a "warn.txt" file
which will display a message. For example, if a board has a
particular quirk to watch out for, write that there. The message
will be printed during the build process, to stdout.

If status is anything *other* than stable, or it is unstable
but LBMK_VERSION_TYPE is not set to "unstable", and not building
a release, a confirmation is passed.

If the board is not specified as stable or unstable, during
a release build, the build is skipped and the ROM is not
provided in that release; this is in *addition* to
release="n" or release="y" that can be set in target.cfg,
which will skip the release build for that target if "n"

Signed-off-by: Leah Rowe

enable serial console on fam15h boards

2024-02-27T18:52:31+00:00

Signed-off-by: Leah Rowe

fix amd mainboard configs

2024-01-21T20:45:44+00:00

in a build test, canoeboot 0.1 builds, but master doesn't,
and neither does lbmk. i changed a few of them when doing
the crossgcc build optimisation patches.

i'm just copying the configs from there. unlike in the
canoeboot version of this patch, i've re-enabled microcode
updates in these lbmk configs.

Signed-off-by: Leah Rowe

update/trees: further simplify crossgcc handling

2023-12-27T16:07:32+00:00

arch no longer needs to be set, on multi-tree projects,
and it has been renamed to xarch

the new behaviour is: if xarch is set, treat it as a
list of crossgcc targets and go through the list. set
the first one as the target, for what lbmk builds, but
build all of the defined crossgccc targets

crossgcc_ada is now xlang, and defines which languages
to build, rather than whether to build gcc-gnat

Signed-off-by: Leah Rowe

don't delete microcode updates in rom images

2023-12-23T06:59:48+00:00

at present, lbmk can remove microcode updates on images for
a given target, if the target specifies
microcode_required="n" in target.cfg

lbmk then provides images with microcode, and images without,
in a given release. although the user can also remove them
manually, this just makes it a bit more convenient, for those
users who do wish to run without the updates. this functionality
is provided only on those platforms where no-microcode is tested.

well, this behaviour implements a compromise on libreboot policy,
which is to always include microcode updates by default. see:
Binary Blob Reduction Policy

the *canoeboot* project now exists, developed in parallel with
libreboot, and it ships without microcode updates, on the same
targets where lbmk also handled this.

running without microcode updates is foolish, and should not
be encouraged. clean up lbmk by not providing this kludge.

the libreboot documentation will be updated, telling such users
to try canoeboot instead, or to remove the update from a given
libreboot rom - this is still possible, and mitigations such as
PECI disablement on GM45 are still in place (and will be kept),
so that this continues to work well.

Signed-off-by: Leah Rowe

build/roms: remove modify_coreboot_rom()

2023-12-21T19:26:22+00:00

don't handle "romtype" at all, in board target.cfg files

add /dev/null as pike2008 rom on amd boards. this serves
the same purpose, adding them as empty vga roms, to add
an empty rom in cbfs. pike2008 cards cause seabios to hang,
when their oproms are executed, so we insert a fake rom

on i945 thinkpads, use the coreboot config option:
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK

when set, this enables the same bootblock copy, for use
with bucts. these two cases, namely pike2008 roms and
i945 bootblock copies, no longer need to be handled in code

Signed-off-by: Leah Rowe