Age | Commit message (Collapse) | Author |
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it doesn't really make sense for them to be under
blobs/ - nominally, they are blobs, but they are
well-understood data files containing config data,
that is easily parsed by tools like ich9show or
ifdtool (and tools like bincfg or nvmutil)
blobs/ has been re-purposed: this directory no longer
exists in lbmk, but it is created (and on .gitignore)
when needed, by blobutil
thus, the blobs/ directory shall only contain vendor
files, and only those files that libreboot scrubs from
releases. therefore, build/release/src can (and has
been) simplified; it currently copies just the ifd and
gbe files from blobs/, selectively, and this logic is
quite error prone, requiring maintenance. now, the
build/release/src script simply copies config/ (which
only ever contains distributable files) and entirely
ignores the blobs/ directory
the blob download script already creates the required
directory, except for the sch5545 download; this is
now fixed
lbmk code size is slightly smaller, due to this patch
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This cuts down on build time, and it will allow libreboot
to remove large chunks of code.
these ifd/gbe configs are just binary-encoded config files,
in a format well-understood. they can easily be opened up
and displayed, using ich9show or ifdtool, and manipulated
by these tools; bincfg can generate them from scratch, and
nvmutil can change mac addresses, for example.
so, do this and remove from lbmk the following:
* ich9utils (which contains ich9gen) - not needed anymore
* code in lbmk for handling ich9gen and insertions; the
coreboot build system is now used, for this same purpose,
so remove such code from lbmk
this results in a massive code size reduction (thousands of
lines) in lbmk; smaller when only looking at the build
system, but much larger when you consider that ich9utils
is also removed (about 3k sloc)
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The same ROM images that you flash on Intel GPU variants,
are now flashed on Nvidia models. The same ROM will work
on both. If an Intel GPU variant is present, libgfxinit
is used, and the VGA ROM is used if an Nvidia GPU variant;
however, release ROMs will scrub the nvidia option ROM,
so release ROMs will only work on Intel GPUs unless you
run the blobutil inject command.
I decided to no longer have this under WIP, but to put
it in master. The issue with it pertains to video drivers,
which is not Libreboot's problem.
Nouveau crashes under Linux, so use "nomodeset" if it does.
The "nv" drivers in BSD systems work very well.
The nvidia model of E6400 isn't recommended for other
reasons, namely: poor thermal cooling (thermal pad on
the GPU) and that Nvidia GPU doesn't get very good
performance on any libre drivers anyway. The Intel GPU
variant is better, in terms of power efficiency and
software support; the intel variant also works with
native graphics initialisation in coreboot.
This board port already only enables SeaBIOS, which will
simply execute the VGA ROM. Blobutil already supports
reading the config, detecting that a VGA ROM is needed,
because that part of the WIP E6400 branch was already
merged in lbmk master.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
coreboot revision:
d86260a134575b083f35103e1cd5c7c7ad883bce
from 2 August 2023
The patches were updated. HP 8300 USDT has now been merged upstream,
so that patch is no longer included in lbmk.
SD card fix for E6400 merged upstream, so now it's removed in lbmk.
The nvidia E6400 patch (devicetree.cb) has not yet merged upstream.
The ifdtool --nuke option has been rebased.
Patches as follow-ups to earlier patches removed; for example, patches
that set VRAM to 352MB on GM45 have been removed, and replaced with
patches that just set 256MB in the first place (this is more stable).
This was mostly a clean rebase, of all the patches. It went smooth.
I haven't updated cros/haswell yet; the 4.11_branch revision used
on fam15h will also remain, for now.
The coreboot configurations have been updated, for this new
revision of coreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This reverts commit 1497ae045104145de677fd151da4de6e92be4e5a.
The blanket GRUB patch seems to break PS/2 keyboard handling across
other platforms, so revert it.
|
|
This introduces a patch to grub which disables the coreboot
specific handling, allowing PS/2 keyboards to be handled the
same as i386-pc. However this alone breaks the keyboard in
Linux, requiring coreboot to perform PS/2 initialization.
I think GRUB may be restoring the original configuration of
the PS/2 controller once it exits, and if coreboot doesn't
initialize the controller then it's restored to the default
state which Linux doesn't seem to like. I think the emulated
keyboard interface provided by the EC on the E6400 behaves
in a non-standard way that is incompatible with the old
coreboot specific handling.
|
|
Tested the 4MiB ROMs but not the 8 or 16 MiB ones. This uses the same
board.cfg as the GM45 ThinkPads with an IFD+GBE from ich9gen.
Known issues:
- The internal keyboard does not work properly in GRUB. It seems like
the keyboard controller is outputing set 1 (XT) scancodes, but GRUB
is interpreting them as set 2 (AT) scancodes. This may also have
something to do with scancode translation. However, the keyboard works
fine in SeaBIOS and Linux. USB keyboards also work properly.
- The subsystem IDs in the GBE region are hardcoded for a Thinkpad in
ich9gen, though this doesn't seem to cause issues in Linux. The vendor
IFD and GBE region do have some differences from the generated
binaries, though they do not appear to be critical.
|