Commit Graph

154 Commits (e67628c6a5e7a6ac23b4c519a753ead61beae116)

Author SHA1 Message Date
Leah Rowe 340eea0b1c grub: insert background in memdisk instead
the background is only a few kb. the whole rationale
before was to limit the space used in memdisk, but this
decision was made when the background was much bigger;
it has since been optimised greatly, and the grub modules
were heavily reduce, so it should be safe.

grub's memdisk breaks when you add too much data to it.
as part of simplifying the rest of lbmk, this change removes
some more bloat from the rest of lbmk. handling this in the
memdisk is much simpler than handling it with cbfstool.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-15 23:15:27 +01:00
Leah Rowe 79d5d83412 haswell: add Mate's patch fixing IGD port list
fixes DP++ and adds a DP that wasn't even there before,
on all currently supported variants of these machines

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12 07:39:14 +01:00
Leah Rowe 61a8f4b05e haswell: add Nico's patch for IGD PCI IDs
the patch fixes IGD on certain xeon processors

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12 07:36:43 +01:00
Leah Rowe 0b37653ab9 grub: only enable nvme if needed on a board
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 <leah@libreboot.org>
2024-06-12 00:58:22 +01:00
Leah Rowe ba36f26d62 handle build.list from config/data/, not config/
certain code checks for build.list, to skip it, for
example in items()

we already use config/data/grub to store grub config data
that applied to all trees

create these directories too:

config/data/coreboot
config/data/u-boot
config/data/seabios

move the respective build.list files in here, and also
to config/data/grub

now multi-tree projects contain, per directory, just the
target.cfg file and the patches directory. this is much
cleaner, because some of the logic can be simplified more

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06 02:35:36 +01:00
Leah Rowe 429e91f908 make GRUB multi-tree and re-add xhci patches
Re-add xHCI only on haswell and broadwell machines, where
they are needed. Otherwise, keep the same GRUB code.

The xHCI patches were removed because they caused issues
on Sandybridge-based Dell Latitude laptops. See:
https://codeberg.org/libreboot/lbmk/issues/216

The issue was not reported elsewhere, including on the
Haswell/Broadwell hardware where they are needed, but the
build system could only build one version of GRUB.

The older machines do not need xHCI patches, because they
either do not have xHCI patches, or work (in GRUB) because
they're in EHCI mode when running the payload.

So, the problem is that we need the xHCI patches for GRUB
on Haswell/Broadwell hardware, but the patches break
Sandybridge hardware, and we only had the one build of GRUB.
To mitigate this problem, the build system now supports
building multiple revisions of GRUB, with different patches,
and each given coreboot target can say which GRUB tree to use
by setting this in target.cfg:

grubtree="xhci"

In the above example, the "xhci" tree would be used. Some
generic GRUB config has been moved to config/data/grub/
and config/grub/ now looks like config/coreboot/ - also,
the grub.cfg file (named "payload" in each tree) is copied
to the GRUB source tree as ".config", then added to GRUB's
memdisk in the same way, as grub.cfg.

Several other design changes had to be made because of this:

* grub.cfg in memdisk no longer automatically jumps to one
  in CBFS, but now shows a menuentry for it if available

* Certain commands in script/trees are disabled for GRUB,
  such as *config make commands.

* gnulib is now defined in config/submodule/grub/, instead
  of config/git/grub - and this mitigates an existing bug
  where downloading gnulib first would make grub no longer
  possible to download in lbmk.

The coreboot option CONFIG_FINALIZE_USB_ROUTE_XHCI has been
re-enabled on: Dell OptiPlex 9020 MT, Dell OptiPlex 9020 SFF,
Lenovo ThinkPad T440p and Lenovo ThinkPad W541 - now USB should
work again in GRUB.

The GRUB payload has been re-enabled on HP EliteBook 820 G2.

This change will enable per-board GRUB optimisation in the
future. For example, we hardcode what partitions and LVMs
GRUB scans because * is slow on ICH7-based machines, due
to GRUB's design. On other machines, * is reasonably fast,
for automatically enumerating the list of devices for boot.

Use of * (and other wildcards) could enable our GRUB payload
to automatically boot more distros, with minimal fuss. This
can be done at a later date, in subsequent revisions.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-02 19:58:50 +01:00
Leah Rowe 7fbcb7be95 coreboot t440p/w541: enable nvme in grub_scan_disk
these laptops do not officially have nvme slots on them,
but there is an ngff wifi slot which is PCI-E x1, and you
can use a special adapter on it to run nvme ssds.

total throughput is retarded by the x1 PCI-E configuration,
but it's still faster than a sata ssd (nvmes are x4 PCI-E).

support it in grub_scan_disk on the off chance that some
users may make use of this. it should work just fine.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-29 23:42:48 +01:00
Leah Rowe e7cb10d68b do not allow dashes in coreboot target names
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 <leah@libreboot.org>
2024-05-29 03:15:25 +01:00
Leah Rowe 3998a3ba48 re-configure grub_scan_disk on various targets
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 21:33:53 +01:00
Leah Rowe 1c4d649848 remove grub_scan_disk in all target.cfg files
A subsequest revision will set them again as needed,
per coreboot target.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 20:41:11 +01:00
Leah Rowe c94cecd837 GRUB: remove XHCI patches for now (will re-add)
Fixes this bug:
https://codeberg.org/libreboot/lbmk/issues/216

Well, fix is the wrong word. We want xHCI ideally.

Mate is working on it as I write this. I've also:

* Disabled CONFIG_FINALIZE_USB_ROUTE_XHCI on Haswell
  boards (coreboot)
* Disabled the GRUB payload on HP 820 G2 for now

We will need to re-add the xHCI patches once fixed.
If Mate/we can't fix it, I'll contact Patrick
Rudolph who originally wrote the xHCI patches.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 17:11:33 +01:00
Leah Rowe ec761c88f2 coreboot: only run GRUB as a secondary payload
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 <leah@libreboot.org>
2024-05-27 14:24:26 +01:00
Nicholas Chin 9f50e36228
Fix E6400 display reference clock patches
The ones I submitted before seem to have been outdated ones
that don't actually build properly.

Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-21 18:58:28 -06:00
Nicholas Chin 8629873a60
Fix E6400 display issue with 1440 x 900 panel
The E6400 uses a 100 MHz reference clock on DPLL_REF_SSCLK, whereas
libgfxinit assumed that the reference was always 96 MHz. The frequency
difference caused by a 100 MHz reference with PLL config values
calculated assuming a 96 MHz reference were not significant enough to
cause noticable issues with the more common 1280 x 800 panels, but are
enough to matter for the 1440 x 900 panels which use a higher pixel
clock. This only affected the pre-OS graphics environment provided by
libgfxinit, as Linux drivers would determine the reference clock
frequency based on data in the VBT.

Fix this by making the reference clock frequency in libgfxinit
configurable for GM45 based on a new coreboot Kconfig, which is set to
100 MHz for the E6400.

Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-20 10:46:25 -06:00
Leah Rowe 190495d2e5 disable x301 for next release (for now)
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-12 04:15:01 +01:00
Leah Rowe cc33974150 remove haswell mrc blob (libre raminit stable now)
broadwell mrc is retained, because it's needed on 820 g2

it's no longer needed on haswell, because nri is stable. nri
is short for "native ram initialisation", and libreboot provides
this for: thinkpad t440p, thinkpad w541, dell optiplex 9020 mt,
and dell optiplex 9020 sff

remove, in line with libreboot's binary blob reduction policy

previous revisions, prior to the recent release, stated that
it would be retained for compatibility, but it's really not
right to retain it, because doing so violates libreboot's policy

the recent release excluded mrc-based rom images for haswell
machines, providing only those rom images that use the libre
raminit, while retaining support for mrc in the build system, so
that users could still run the lbmk inject script on older release
roms that use mrc

again: libreboot's binary blob reduction policy is very clear:

https://libreboot.org/news/policy.html

it is a policy that can be summarised, thus:

if a blob can be avoided, it must be avoided.

therefore, we will avoid the Haswell MRC raminit blob

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-11 19:12:11 +01:00
Leah Rowe 05fbd39298 remove all status checks. only handle release.
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 <leah@libreboot.org>
2024-05-11 18:53:12 +01:00
Leah Rowe 5bf25eac05 coreboot: update latitude release status
working s3 means i'm happy to mark it as being stable.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04 04:58:40 +01:00
Leah Rowe 7a955a4c72 d510mo and d945gclf: disable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04 04:54:09 +01:00
Leah Rowe 7e799e1f16 nb/haswell: lock policy regs when disabling IOMMU
Angel Pons told me I should do it. See comments here:
https://review.coreboot.org/c/coreboot/+/81016

I see no harm in complying with the request. I'll merge
this into the main patch at a later date and try to
get this upstreamed.

Just a reminder: on Optiplex 9020 variants, Xorg locks up
under Linux when tested with a graphics card; disabling
IOMMU works around the issue. Intel graphics work just fine
with IOMMU turned on. Libreboot disables IOMMU by default,
on the 9020, so that users can install graphics cards easily.

I'm pretty sure this is the correct way to do it. The machine
still seems to boot, in this configuration.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04 04:32:35 +01:00
Leah Rowe 985870297d deprecate MRC 9020MT/SFF (NRI 9020 is default now)
NRI is libre raminit

MRC is binary blob raminit

the libre raminit is stable enough now that it's default

the MRC-based targets will be removed in a future release

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04 01:15:26 +01:00
Leah Rowe d839bfa1ed mark 9020 sff/mt stable for release
i initially decided to say unstable, but the default
configuration is reliable; the only caveat is that if
you enable IOMMU, you must only be using intel graphics.

this is already documented in warn.txt files, and on
the website, so it's more than ok to call this stable.

i use one of these myself as my daily driver and it's
rock solid. i haven't had any problems with it. i also
sell these to people with libreboot. no problems.

mark it as stable, ready for a full release.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04 01:15:17 +01:00
Leah Rowe a9bc6b254b mark lenovo x301 as stable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04 01:15:08 +01:00
Nicholas Chin 67ddd3f2f6
coreboot/default: Add patches to fix S3 on SNB/IVB Latitudes
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-03 18:02:44 -06:00
Leah Rowe 780e03fe1e remove x220edp/x230edp (keep regular x220/x230)
nitrocaster boards are hard to find nowadays and i'm not
comfortable supporting the knockoff chinese gear; quality
varies greatly, and i can't know how reliable they are.

nitrocaster has been out of business so it's just not
viable to support this mod anymore. in fact, keeping the
eDP-based targets is a liability to libreboot.

regular x220/x230 (non-eDP-modded) are retained. the eDP
modkit from nitrocaster let you use eDP screens instead
of lvds, on thinkpad x220 and x230, letting you use
higher resolution screens.

older lbmk revs can still be used, if you happen to come
across one of these boards. i only recommend using the
official nitrocaster board, if youcan find one unused.

ymmv with the chinese gear. better just use an unmodded
x230 or get a different machine.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03 23:46:27 +01:00
Leah Rowe b379186a5c update hp machines to status=stable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03 23:46:25 +01:00
Leah Rowe 6e7b5c0b24 Enable WiFi on HP EliteBook 8560w (GPIO config)
angel pons said how to fix it. more info in the patch.

works perfectly. i still see that scancode in dmesg and i guess
i have to assign it to some function that sets software rfkill

hw rfkill is no longer set. it's unblocked, and i can use wifi.

just in time for the libreboot release.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03 23:45:59 +01:00
Leah Rowe 2d207c547c coreboot/x301: set release=n (will re-test)
was reported broken on canoeboot 0.1, which uses 2021
coreboot. we use much newer coreboot now in libreboot, but
still, better be cautious. set to release=n.

i'll set status and remove release=n if it works on testing

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03 14:27:50 +01:00
Leah Rowe 748b207215 mark x4x boards ready for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03 13:57:35 +01:00
Leah Rowe 4bf3da31c9 Merge pull request 'Fixed QEMU x86 target's SMBIOS informations' (#205) from livio/lbmk:qemux86_fix into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/205
2024-05-02 02:35:24 +00:00
livio 707d7ce7d0 Fixed QEMU x86 target's SMBIOS informations 2024-05-01 11:20:46 +02:00
livio d654a3e5ed Fixed QEMU x86 target's SMBIOS informations 2024-05-01 11:17:59 +02:00
Leah Rowe 5c3d81fff9 correct dell latitude status for release
it should be marked unstable, though these machines
are basically reliable; they have certain missing features
and quirky behaviour so it's important not to over-sell it

mark it as unstable, on all of the dell latitudes

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01 06:29:09 +01:00
Leah Rowe 6dfd8c7070 update release status for HP machines
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01 06:12:50 +01:00
Leah Rowe 50f6943ccd set gru bob/kevin stable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01 05:59:31 +01:00
Leah Rowe df5e321648 set dell latitudes stable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01 05:56:42 +01:00
Leah Rowe 7e7c3c235d mark i945 machines as stable for release
the previous issue was tested, and can no longer be reproduced

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01 00:37:03 +01:00
Leah Rowe 71f8e6530a eDP configs (x230/x220): don't release
set to release="n" for now until the eDP targets
are fixed.

the regular non-eDP targets are stable, and will be
released.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28 17:24:41 +01:00
Leah Rowe a5c7cc1a0b fix target.cfg files on dell latitudes
some latitudes still used the old style for variables
in target.cfg, specifically arch="x86_64" - lbmk used to
then check that on a big if/else and translate it to the
correct target name for crossgcc, e.g. i386-elf, arm-eabi

now it just puts the arch directly, in a new variable:
xarch

change arch="x86_64" to xarch="i386-elf" in these files.
also remove a few obsolete variables. should build now.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28 03:27:54 +01:00
Leah Rowe d923d31451 use mirrorservice.org for iasl downloads
github is unreliable. i host these files myself.

coreboot uses intel.com again now in the latest revisions, and
intel broke it before. i'm going to start backing up the acpica
releases onto my rsync server from now on, and keep patching
coreboot to use my files.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28 02:02:15 +01:00
Leah Rowe f22305fbf5 update macbook21/x60/t60 status
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27 17:01:38 +01:00
Leah Rowe ad7e3966b9 update 9020 sff/mt release status
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27 15:45:49 +01:00
Leah Rowe 3ace925e91 update more board statuses before release
what's left to properly test are pineview/x4x/i945 and
some of the ivy/sandy elitebooks/hp workstations

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27 15:26:18 +01:00
Leah Rowe e761922542 Set status=unstable on dell latitudes
also warn about issues, in a warn.txt file for each.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27 15:08:16 +01:00
Leah Rowe 1fd9ba9ae0 declare ivy/sandy thinkpads stable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27 14:51:59 +01:00
Leah Rowe 5218bfb0c8 declare gm45 thinkpads stable for release
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27 14:49:14 +01:00
Leah Rowe b99ebe0551 kcma-d8/kgpe-d16: mark as tested(unstable)
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 <leah@libreboot.org>
2024-04-27 06:08:07 +01:00
Leah Rowe ce7fd754a3 build/roms: report status when building images
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 <leah@libreboot.org>
2024-04-26 20:36:42 +01:00
Leah Rowe a2f4235358 i945: switch boards to 20230625 coreboot revision
On T60 with Libreboot 20231106 and the GRUB payload, a user
reported this error in GRUB when a battery was connected:

"alloc magic is broken at 0x7b1aedf0: 0"

This error disappears when a battery is not connected, or
when using Libreboot 20230625. The issue has persisted
through to LIbreboot 20240225 and after, and I believe the
issue will be somewhere in coreboot, not in GRUB itself.

For now, switch i945 laptops (X60, T60, Macbook2,1) back to
the February 2023 coreboot revision used in Libreboot 20230625.

A bisect can be done before the next Libreboot release, ETA
May 2024, if time permits. Otherwise, this revert should solve
the problem for now, at least so far as Libreboot is concerned.

The following coreboot patches have been backported:

    commit 29030d0f3dad2ec6b86000dfe2c8e951ae80bf94
    Author: Bill Xie <persmule@hardenedlinux.org>
    Date:   Sat Oct 7 01:32:51 2023 +0800

        drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume

    Further patches from upstream:

    commit 432e92688eca0e85cbaebca3232f65936b305a98
    Author: Bill Xie <persmule@hardenedlinux.org>
    Date:   Fri Nov 3 12:34:01 2023 +0800

        drivers/pc80/rtc/option.c: Reset only CMOS range covered by checksum

These patches fixed S3 on GM45 machines, though it will be useful on
the i945 machines aswell.

The reason I'm doing it this way it is because I don't have a battery
for my X60 or T60, and my T60 isn't in a very good state either,
so I can't reproduce the error myself yet.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-26 09:55:55 +01:00
Leah Rowe ddfe71a366 9020 sff/mt: actually enable the TPM (by default)
i added mkukri's patch but didn't enable it. this was intentional.

this patch enables tpm by default, on all 9020 sff/mt targets.

most users probably won't need it, but enabling it won't hurt.

Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-26 05:10:12 +01:00