| Age | Commit message (Collapse) | Author |
|---|
|
when make-all is being executed on a coreboot tree,
the "./vendor download target" command is used, where
target is the tree/board name.
that script then checks whether cbfstool and ifdtool
are built, and if they're not, they then call
./update trees -b coreboot utils bla bla bla
in this scenario, project=coreboot and mode="", meaning
make-all, and the same check that checks whether the
vendor download script should be run, is executed,
which in turn then checks cbutils again
fix the infinite loop by checking whether it was coreboot
utils, as opposed to *firmware*, that is to be built, before
running ./vendor download
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
the x_ function doesn't handle arguments with spaces
well, and this cd command is going to an asterisk, so
it's unknown what the resultant string will be.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
at present, lbmk can remove microcode updates on images for
a given target, if the target specifies
microcode_required="n" in target.cfg
lbmk then provides images with microcode, and images without,
in a given release. although the user can also remove them
manually, this just makes it a bit more convenient, for those
users who do wish to run without the updates. this functionality
is provided only on those platforms where no-microcode is tested.
well, this behaviour implements a compromise on libreboot policy,
which is to always include microcode updates by default. see:
Binary Blob Reduction Policy
the *canoeboot* project now exists, developed in parallel with
libreboot, and it ships without microcode updates, on the same
targets where lbmk also handled this.
running without microcode updates is foolish, and should not
be encouraged. clean up lbmk by not providing this kludge.
the libreboot documentation will be updated, telling such users
to try canoeboot instead, or to remove the update from a given
libreboot rom - this is still possible, and mitigations such as
PECI disablement on GM45 are still in place (and will be kept),
so that this continues to work well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
the purpose of script/update/release is not to test the
build system, but to build release archives.
testing of lbmk is done during the course of development.
remove this bloat from the release script. we run the nuke
mode anyway, to scrub blobs from releases, which will more
or less test the logic in that script (the only difference
is that it runs e.g. ifdtool --nuke instead of -i).
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
why are we distributing gcc at all?
the coreboot build system downloads it at build time,
and the GNU rsync mirrors aren't going anywhere.
simplify script/update/release by not handling gcc.
this means: release archives will no longer contain gcc.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
don't handle "romtype" at all, in board target.cfg files
add /dev/null as pike2008 rom on amd boards. this serves
the same purpose, adding them as empty vga roms, to add
an empty rom in cbfs. pike2008 cards cause seabios to hang,
when their oproms are executed, so we insert a fake rom
on i945 thinkpads, use the coreboot config option:
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK
when set, this enables the same bootblock copy, for use
with bucts. these two cases, namely pike2008 roms and
i945 bootblock copies, no longer need to be handled in code
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
only call crossgcc for coreboot and u-boot, but use
hostcc for everything else. simplify the checking of
which architecture to compile for. "arch" in target.cfg
files has been modified, to allow further simplification.
without this patch, the logic currently only *barely* avoids
using crossgcc on things like utils, and only works in practise
because, in practise, lbmk only works on x86_64 anyway.
the new logic, as per this patch, is simpler and more robust.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
remove unnecessary "continue" command. it's written
at the end of a for loop, where it'll continue anyway
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
all it did was set -v in the shell, which doesn't yield
very useful results. this is a relic of very old design
in the libreboot build system, that is no longer needed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
lbmk didn't quote certain arguments in commands, or
used ! -z instead of -n, things like that. simple fixes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
most of these are probably redundant, and will never
be called, but lbmk needs to be as safe as possible
under fault conditions. fail early, fail hard.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
in cases where lbmk must always return from a function,
there are some cases where it relies on non-zero exit
status, which in practise is always the case, but may
change in the future if the relevant part is modified
e.g. do_something && return 0
the proper form is:
do_something
return 0
also do this for unconditional exits
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it didn't work in the past, but it does work nowadays;
specifically, it only worked with libgfxinit in the past,
but not on VGA ROMs.
now it does work on VGA ROMs, tested on e6400 and t1650 so
it was enabled there.
in this setup, a special image is provided where SeaBIOS is
the main payload, but it only loads GRUB; nothing else, every.
this is called SeaGRUB. this setup is useful in cases where
the user only has a GPU that lacks libgfxinit support.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
when printing the name of the rom being created, it's
done before the check to rename based on vendorfiles
in target.cfg. this patch fixes that bug.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
this makes the build work, for releases.
this is not done during regular builds, only releases.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
note: me6_update_parser needs to be written, similar
to me7_update_parser, to generate the partition
tables within intel me6 on lenovo bios updates.
the current logic in lbmk goes like this:
mkdir -p vendorfiles/cache/
and save your factory dump as:
vendorfiles/cache/x201_factory.rom
the build system has been modified, in such a way
as to support extracting me.bin (which is the full
one) and then neutering from this.
this is done automatically, if the file is present,
but you must first insert that file there, which means
you'll need a dump of the original boot flash on your
thinkpad x201
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it wasn't being copied right
the roms under elf/ were being copied, but not the ones
under bin/ - i need to audit it further
for now, i run modify_coreboot_roms from build/roms
instead of update/trees
so, the ones under elf/ no longer have bootblocks copied.
it's only done in bin/
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
when building only for u-boot, the current script
works just fine. however, when building for other
payloads in additional to u-boot, the final u-boot
stage fails because other payloads are already
inserted via cbfs.
when we build u-boot, we do that last because we want
u-boot setups to only be u-boot, nothing else.
this patch enables qemu x86 to build properly with
u-boot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
keymaps weren't being set in keymay.cfg of cbfs, due
to use of x_ in the rom script, and x_ doesn't handle
quotes or spaces in arguments well.
i'm going to remove use of x_ and xx_ (it's in my todo),
for next release.
for now, hot patch the release. i've gone through and
replaced use of x_ with || err, in some places.
not just the keymap.cfg command, but others too. in case
there are more issues we missed.
this commit is being tagged "20231021fix" and i'm using
this tag to re-build the 20231021 release. i'll just
replace the tarballs in rsync and add errata to the news
page announcing the release. all i did was break peoples
umlauts, i didn't brick their machines fortunately!
very minor bug. anyway, x_/xx_ is a great idea, but sh
isn't really designed for that style of programming. i'll
go back to using just || err in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
clean it up after copying the tarballs
i really hate how this logic is written, it's clunky
but it should work; the only issue is that it's quite
slow, and inefficient on use of disk space.
however, i've not yet figured out how to reproducible
add files to a tarball, once the tarball has been created,
and i rely on sorting (of file names) when creating them.
it's really not a problem because normal people won't
use this script, only i or anyone who wants to test out
the libreboot release infrastructure. this script is
largely intended to *work*
but i'm still annoyed by how crappy it is. i'll fix it
after the Libreboot 20231021 release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
everything downloaded, then tarballed, then built,
now crossgcc is downloaded by coreboot.
now extract, copy crossgcc tarballs, re-compress.
TODO: simply add files to the archive, without re-
compressing the whole thing.
this is still more efficient than the old way: build
everything, then clean and compress, making another
build test on the release archive necessary; with this,
there is still only one build test per release.
with this, and the previous revisions dealing with
submodules, the source archives should now be complete.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
in release archives, .git is excluded but the version
and versiondate files are included. from these, the
git history is re-created with the exact date (but not
taking into account timezone, at present).
in this way, lbmk will have git history in a release
archive. some build systems, like coreboot, prefer that
there be git history available, so this is a nice
workaround on those build systems.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
do it using find -exec
this is more robust, and it will never need to be
maintained over time (famous last words).
this is done because now we download submodules
for all git projects, so it's hard to predict.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
when [] is used right at the end of a function, or
certain loops/subshells, some sh implementations will
just return a non-zero exit
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
this fixes a regression caused by a previous revision
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it couldn't hurt
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
config/git has been re-arranged in a prior revision,
ensuring that each file only refers to a main source
tree defined within those files.
the erstwhile "./build clean all" functionality is now
once again possible in lbmk
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
don't ever name it rpi-pico-serprog
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
in some cases, use of x_ or xx_ can be error-prone,
due to the way $@ is handled; commands requiring
quotes, or with funny file names as arguments such
as spaces in the file name, or other special
characters, can make the x/xx functions break.
in those cases, where x/xx must not be used, the
commands use || err instead
in other cases, use of x/xx is superfluous, and has
been removed in some commands.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
as opposed to the current 3-level structure.
recent build system simplifications have enabled
this change, thus:
./build fw coreboot -> ./build roms
./build fw grub -> ./build grub
./build fw serprog -> ./build serprog
./update project release -> ./update release
./update project trees -> ./update trees
./update vendor download -> ./vendor download
./update vendor inject -> ./vendor inject
alper criticised that the commands were too long,
so i made them shorter!
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
i forgot to include option.sh in this script,
during previous re-factoring. the cbfstoos variable
is now defined exclusively in option.sh, but other
scripts can set it to something else.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
move it all to other files where items are used, and not
used anywhere else. this reduces the size of vendor.sh.
also remove a few redundant variables, or variables that
are not meaningfully used.
a few items have been moved to include/option.sh
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
they are the functions only used by the download
script, so they don't belong in vendor.sh
an include file should only contain variables and
functions used by multiple main scripts
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
We don't really need a custom coreboot tree for Chromebooks. I had added
one, because at a cursory glance to the available config/coreboot/board
subdirectories I had the impression that I should. But upstreams have
one tree for every board and I think we should move towards that too.
Move the one important BL31 makefile patch into the default coreboot
patches, update the gru boards' configs by running savedefconfig in the
cros tree and then running olddefconfig in the default tree.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add an "-s" flag for "make savedefconfig", "-l" for "make olddefconfig"
and "-n" for "make nconfig" to the update script. The first two are
mainly useful for U-Boot, to compare our configs to the upstream
defconfigs and stay in sync with any upstream changes. The latter is
because the ncurses one has a nice "Symbol Search" that can point out
the menu entry for a config symbol we know.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The "u-boot.bin" file generated by U-Boot builds is a raw binary. When
adding payloads to a CBFS, we need to use ELF files with add-payload
or manually pass the entry point and load address of the payload binary
with add-flat-binary.
We primarily use the "u-boot.elf" which gets build with the REMAKE_ELF
option, as it also has the necessary device-tree binary that U-Boot
usually needs to work. When the option is not set (e.g. for QEMU), we
need to use the "u-boot" file which is an ELF.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
