it will already fail if the coreboot download did.
if the coreboot download succeeds, the directory exists.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i'm pretty much finished now
there might be a few more changes later,
like stricter error handling, more verbose
error messages, etc
right now, it relies on -e to kill lbmk
on error, and uses the exit command
another planned change it to support
other upstreams besides coreboot.org,
such as the dasharo codebase
the latter is *why* i refactored this
download script, for asus kgped-d16
to my knowledge, this feature has never been used,
but lbmk permits resources/coreboot/boardname/extra.sh
to execute, as provided by the maintainer, with working
directory set to: coreboot/boardname
this could be used to extend lbmk in a number of ways
for example, it could be used to patch 3rdparty/
it could also be used to break coreboot in creative
and novel ways. hint hint.
the "board" variable in prepare_new_coreboot_tree()
is also declared in fetch_coreboot_trees
for the one in prepare_new_coreboot_tree, it's passed
as an argument to the function, so give it a new name
i learned that some shells have a global scope, when
using variables of the same name between functions
this should download all trees:
./download coreboot
without this patch, it doesn't
with this patch, it works
i overlooked this during earlier
refactoring. auditing revealed it.
top-down order, and *still* rfc 3676 compliant
i finished simplifying the logic, and
i split everything into smaller functions
there is still more more polishing to do
final touches will be done in new revisions
coreboot trees/patching is still handled
specifically by "./download coreboot"
command now available in lbmk:
./gitclone coreboot
this *only* creates the directory at:
coreboot/coreboot
this directory is never used in builds.
it is only used by download/coreboot to
create patched trees for each mainboard
consistent indentation, and 80-line character limit
(RFC 2646)
top-down order, a main() is introduced, split into
more functions
non-zero-status exit (with message) now, when a non-
defined target is provided, e.g. nonexistentboard_4mb
puffy!
the cbfstool command within subshell now also
exits with non-zero status, if it fails (most
likely because extraction failed, for some reason,
of the coreboot rom image for running through it)
the previous code merely exited from the subshell,
but the intended behaviour is for the entire script
to halt execution, and exit with non-zero status.
this patch fixes that bug.
top-down order for all logic, and shorter code lines,
conforming to rfc 2646 (no more than 80 characters)
the 80-character rule is violated for variables containing
long strings, such as wayback machine urls (can't be helped)
a few bugs were discovered, which will be fixed in follow-up
revisions, such as:
* exit status not handled inside subshell
* in general, exit status should be handled
more explicitly, rather than relying on -e
for our purposes, grub and gnulib are one in the same
if one fails, both have failed
exit with non-zero status if gnulib fails
the script sets -e so it will fail if grub fails to
download, which is tried before gnulib, and if that
happens, the grub directory is not created
the old code was specifing an absolute offset for
insertion of mrc.bin - cbfstool interprets anything
above 0x80000000 as top-aligned memory address in
x86, and anything below as an obsolute offset in
the flash, like with the old number
where a top-aligned address is provided to cbfstool,
the absolute position is calculated for the flash,
and cbfstool inserts it in the correct rom location
the benefit of this change is that the absolute
offset is now calculated automatically, which means
that the code will be correct even if the flash
size changes. for example, if 16MB flash is used
whereas 12MB is currently the default an support
haswell hardware
coreboot does not provide anything readably like
Kconfig, for extracting this value. it's baked
into the source code of coreboot, so you have to
find it. the correct location is hardcoded for
each platform, and always the same on each platform,
regardless of mainboard
top-down function order, with specific functions for
each type of blob. startup logic moved into main(),
also split into smaller functions
"write one program that does one thing well"
blobutil is like that, and has this added philosophy:
"write one function that does one thing well"
during the course of this re-factoring, several bugs
and issues were found, that are pre-existing. these
will be corrected in follow-up revisions
previously, "normal" initmode relied on the vgarom-based
seabios config, which enables option roms, but then lbmk
would insert pci-optionrom-exec 0 for vgarom, and 2 for normal
in libreboot, coreboot roms with "vgarom" in the filename do
pci option rom execution from coreboot, and "normal" roms
do execution from seabios(where seabios is the only payload
provided on normal setups)
this is because payloads like grub can also be used, on vgarom
setups, where coreboot must handle oprom execution
i downloaded this file from git manually at some point,
when rebasing changes (i think it was the ec ones)
the logic in the file is correct but i forgot to mark
it executable
without this commit, lbmk fails utterly, on all the newer
intel boards
This is useful for e.g. HP EliteBook 2560p.
In coreboot config, enable e.g. (for lbmk blobutil):
CONFIG_KBC1126_FW1="../../ec/hp2560p/ec.bin.fw1"
CONFIG_KBC1126_FW2="../../ec/hp2560p/ec.bin.fw2"
In resources/blobs/sources you would have these entries:
EC_url
EC_url_bkup
EC_hash
In cases where the vendor update file contains a full
ROM image encompassing IFD+GbE+ME+BIOS, blobutil was
saving the *entire* ROM containing those, as me.bin.
For example, if it's an 8MB ROM, blobutil would create
a me.bin file that is actually the whole ROM containing:
* Vendor IFD region
* Vendor GbE(if it has one)
* Vendor ME region
* Vendor BIOS region
This fix tries with -M and -O first. In this combination,
me_cleaner shall extract me.bin (neutered) and save it.
If that fails, then the normal method with just -O is
tried, which by this logic would always be a lone ME
image if it succeeds.
I tested downloading ME images on existing boards with
this, and it didn't break them, and this fixes the bug.
This is done for HP 8200 SFF which Riku_V is adding to
lbmk. I'm on IRC with Riku_V as I write this commit
message! Super hot hotfix patch.
don't download it. keep it in lbmk.
libreboot moved to codeberg for git hosting,
and i didn't want to keep lugging around an
extra git repo just for one tiny project.
Leah Rowe