| Age | Commit message (Collapse) | Author |
|---|
|
just to ensure that nothing goes wrong. we don't rely on
the status variable for releases, because there is another
variable, release, that target.cfg files declare, e.g.
release="n"
release="y"
you can just omit the variable, because it defaults to y, so
you only need declare it when it needs to be "n"
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
release="n" is set in target.cfg on haswell build targets
that use mrc.bin
script/update/release exports LBMK_RELEASE="y"
script/build/roms skips building a given target if release="n"
in target.cfg *and* LBMK_RELEASE="y"
you could also do the export yourself before running ./build roms,
for example:
export LBMK_RELEASE="y"
./build roms all
This would skip these ROM images. The native haswell raminit is
now stable enough in my testing, that I wish to delete the MRC-based
targets. This is in line with Libreboot's Binary Blob Reduction Policy,
which states: if a blob can be avoided, it should be avoided.
The problem is that users often run the inject script in *lbmk* from
Git, instead of from the src release archive. I forsee some users
running this on modern lbmk with older release images. If the mrc-based
target isn't there, the user may use an NRI-based target name, and
think it works; they will insert without MRC. I foresaw this ages
ago, which is why Caleb and I ensured that the script checks hashes,
and hashes are included in releases.
Therefore: for the time being, keep the MRC-based configs in lbmk
but do not include images for them in releases. This can be done
indefinitely, but I'll probably remove those configs entirely at
some point.
On the following boards, Libreboot now will *only* provide NRI-based
ROM images for the following machines:
* Dell OptiPlex 9020 SFF
* Dell OptiPlex 9020 MT
* Lenovo ThinkPad T440p
* Lenovo ThinkPad W541/W540
I now recommend exclusive use of NRI-based images, on Haswell
hardware. It's stable enough in my testing, and now supports S3.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
lbmk otherwise uses nproc to set the number of build threads,
in these places:
* generic make commands in script/update/trees
* crossgcc make command in script/update/trees
the -T0 option is also used in script/update/release, when running
tar.
with this change, you can do:
export LBMK_THREADS=x
where x is the number of threads. when you then run
lbmk, your chosen number of threads will override
the default. this may be useful on a host that does
not have a lot of memory.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in lbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
lbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from lbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
./update release -m u-boot
if someone just wants to make u-boot, they can
use this and it tars up all the trees.
Signed-off-by: Leah Rowe <info@minifree.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
use the git log, as follows:
git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit
this creates a nice, uniform list of changes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
with neutered ME, fan control fails. while there are
ways to mitigate it, many users will not, and will
likely see their system overheat, which is very
dangerous.
this bug (failed fan control on neutered ME) only
affects arrandale machines such as lenovo x201.
the newer machines are not affected by this.
other arrandale machines will probably not be added
to libreboot because of this, or they will be subject
to further testing.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
while seemingly pedantic, this does actually make code
easier to read. mostly just switching to shorthand for
variable names, where no expansions or patterns are used
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
lbmk used to set version/versiondate directly in
err.sh, but now it's handled there by a function,
which is called by the main script.
script/update/release hadn't yet been adapted. the
only change necessary is to call check_project()
script/update/trees also makes use of it
script/build/roms is using "projectname"
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>
|
|
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>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The logic has been re-written, where source archives are
concerned. This clones the current repository, and starts
a new build from scratch. A custom release directory is
possible, by passing -d
This eliminates a step during build-testing, saving hours
of time, because it builds the release archive *inside* the
release archive, with git files removed, thus replicating
the same setup that the user would have.
This also makes everything a bit more consistent, because
it's guaranteed that a release archive will always have
the same files; previously, the release build script would
only copy what was already built, without building anything.
Now, this script builds everything itself.
The script also builds serprog images, not just coreboot.
Usage:
./update project release
If -d is not passed, release/ is used inside lbmk.
Otherwise, you could do:
./update project release -d /path/to/directory
If the directory exists, this script will exit (error).
Other minor fixes: build/fw/coreboot: make version in
coreboot-version (file) not contain hyphens, to work
around a quirk in coreboot's build system when not building
on regular libreboot releases. this quirk only appears
when lbmk is not being compiled under git.
The other main benefit of this change is that the new
script will probably require a lot less maintenance.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Just one script.
Just one!
Well, two, but the 2nd one already existed:
logic in update/project/trees and
update/project/repo was merged into
include/git.sh and update/project/build
was renamed to update/project/trees; an -f
option was added, which calls the functions
under git.sh
so git clones are now handled by the main build
script (for handling makefiles and defconfigs)
but the logic there is a stub, where git.sh
does all the actual heavy lifting
this cuts the file count down by two, and reduces
sloccount a reasonable amount because much of
the logic already exists in the build script, when
it comes to handling targets. git.sh was adjusted
to integrate with this, rather than act standalone
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
this is far less error-prone
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The benefit now is that it can be cleaned. E.g.
./update project build -b coreboot utils
./update project build -b coreboot utils default
./update project build -c coreboot utils
./update project build -c coreboot utils default
the update/project/build script checks when arguments
are provided after the project name. if the first one
is "utils", then it acts in the same way as the old
build/coreboot/util script
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
in the future, we may start downloading files that aren't
blobs, such as mxm port configs (on mainboards that use
MXM graphics)
this directory will contain all of those files
generally change the language used, across lbmk, to make
use of "vendorfile" instead of "blob"
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
build/release/src was partly re-written to accomodate this
memtest86plus was patched to have a central Makefile, and
lbmk modified to use that, rather than mess with build32
and build64. the central Makefile just builds both targets
or cleans both targets
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
