lbmk.git/config/coreboot/t1650_12mb, branch 20240612rev1

grub: only enable nvme if needed on a board

2024-06-11T23:58:22+00:00

remove nvme support from the "default" grub tree

now there are three trees:

* default: no xhci or nvme patches
* nvme: contains nvme support
* xhci: contains xhci and nvme support

this is in case a bug like lbmk issue #216 ever occurs
again, as referenced before during lbmk audit 5

there is no indication that the nvme patch causes any
issues, but after previous experience i want to be sure

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 grub_scan_disk in all target.cfg files

2024-05-27T19:41:11+00:00

A subsequest revision will set them again as needed,
per coreboot target.

Signed-off-by: Leah Rowe

coreboot: only run GRUB as a secondary payload

2024-05-27T13:24:26+00:00

See:
https://codeberg.org/libreboot/lbmk/issues/216

Almost all users will be OK running GRUB, but a
minority of users have experienced a fatal error
pertaining to grub_free() or grub_realloc() (as
my investigation of GRUB sources reveal when grepping
the error reported in the link above).

We don't yet know what the bug is, only that the
error occurs, leading to an effective brick if the
user has GRUB as their primary payload.

So far, it has only been reported on some Intel
SandyBridge-based Dell Latitudes in Libreboot, but
we can't be too sure.

The user reported that memtest86+ passes just fine,
and SeaBIOS works; BIOS GRUB also works, which means
that the bug is likely only in an area of GRUB that
runs specifically on the coreboot payload, so it's
probably a driver in GRUB when running on the metal
rather than BIOS/UEFI.

The build system supports a configuration whereby
SeaBIOS is the primary payload, but GRUB is available
in the SeaBIOS boot select menu, and an additional
configuration is available where GRUB is what SeaBIOS
executes first (while still providing boot select);
both of these are now the *only* configurations
available, on all x86 targets except QEMU.

The QEMU target is fine because if the bug occurs there,
you can just close QEMU and try a different image.

Even after this bug is later identified and fixed,
the GRUB source code is vastly over-engineered and there
are likely many more such bugs. SeaBIOS is a reliable
payload; the code is small and robust. Remember always:

Code

equals

bugs

Therefore, this configuration change is likely going
to be permanent. This will apply in the next release.

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

update more board statuses before release

2024-04-27T14:26:18+00:00

what's left to properly test are pineview/x4x/i945 and
some of the ivy/sandy elitebooks/hp workstations

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

config: Add Dell Latitude E5420

2024-03-05T01:28:58+00:00

Signed-off-by: Nicholas Chin

config: Add Dell Latitude E5520

2024-02-08T19:27:12+00:00

Tested by Minimum_Baseball_629 on Reddit

Signed-off-by: Nicholas Chin

Merge pull request 'Add Latitude E6420, E6520, and E5530' (#183) from nic3-14159/lbmk:latitude-ports into master

2024-02-07T12:07:10+00:00

Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/183