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>

the resulting changes are what i will push. this prevents
the coreboot build system from asking for user input.

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>

This was only tested on the iGPU model, though a dGPU model does exist.
The vendor firmware used a 16KiB gbe.bin, which was modified with a
random MAC address as well as shrinking it to 8KiB. As with the E6400,
GRUB doesn't like the way the EC implements the keyboard controller and
thus GRUB payloads are disabled at this time. Suspend does not currently
work, and this is believed to be due to the EC controlling the DRAM
reset gate which is required to prevent DRAM from being reset on resume.

With some tweaks, the e6400-flash-unlock utility also works on this
system, though both flash chips can be accessed through removal of only
the keyboard.

Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>

i have in fact tested whether many of these targets (ivy,
sandy and haswell on intel) boot without microcode, and many
do, but it's not as well tested

the older targets like i945, x4x, pineview and gm45 are
well-tested without microcode; ditto fam10/15h amd.

lbmk supports providing roms with and/or without microcode.
for the targets touched in this commit, lbmk now only
provides images with microcode included by default.

manual removal (with cbfstool) is still possible, if you want
to do that.

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>

d510mo, g43t-am3 and ga-g41m-es2l did not have
the memtest86+ payload enabled

enable it!

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

and only where grub was already enabled; on boards
that did not enable grub, grub is still disabled

on desktops, it's possible that the user may insert
a graphics card. if their first payload was grub,
it won't work because lbmk doesn't configure coreboot
itself to execute vga roms at present

i found when testing t1650 (dell) that if a vgarom is
loaded from seabios (from a graphics card), the grub
payload still works; if booting in corebootfb mode,
text mode is still used when booting with the card

to decrease the probability of bricks with any given
set of users, make seabios the only payload that starts
first, but make grub available in the esc menu on seabios

it's possible to add a bootorder file and disable the
seabios menu, if you only want a grub payload accessible

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

Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>