| Age | Commit message (Collapse) | Author |
|---|
|
printf has more universal behaviour, across various
implementations of sh, so it's better to use this.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
in some cases, messages that should be considered errors
or warnings, were being written to the standard output,
rather than written as error messages.
also: one or two printf statements should specifically
avoid printing errors (to any file); in these cases,
stdout has been redirected to /dev/null
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
sha-1 has known collision issues, which may not be readily
exploitable yet (in our context), but we should ideally use
a more secure method for checking file integrity.
therefore, use sha-2 (sha512sum) for checking files. this is
slower than sha-1, but checksum verification is only a minor
part of what lbmk does, so the overall effect on build times
is quite negligible.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
|
|
we must conserve memory usage, in the event that the
user's /tmp is a tmpfs. copying of ROM images into
tmpfs is ill advised; we must copy them, due to how
the release process works (e.g. stripping of blobs,
but this must be done in a way so as to not interfere
with regular builds, thus they are copied instead)
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
microcode_required wasn't being reset per target,
leading to unreliable results. this fixes that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
More than 90% of cats were thus terminated.
read (shell built-in) is better at reading, and dogs are better pets.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
|
|
The -T option specifies how many threads xz shall use.
The -T value of zero shall dictate that xz use so many
threads as there are CPUs, on the host system.
This will probably speed up the release process a bit.
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>
|
|
this means the unified /tmp handling is now provided for
in both the former "fetch" and "fetch_trees" script, which
are now (respectively):
./update project repo
./update project trees
if the fetch scripts weren't cleaning /tmp before, they
now are, because lbmk handles it
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
libreboot's build system, lbmk, *is* available to use
in releases aswell (use the _src tarball), but it is
mostly intended for development, in lbmk.git
well, there's not much point wasting time / disk space
generating no-microcode roms within lbmk
they should be generated only at release time, alongside
the default ones
this patch implements that, thus speeding up the build
process and saving disk usage during development
the other alternative was to add a new option in
build/boot/roms, -m, that would opt in to removing them,
but this is extra complexity for something that is ill
advised and only provided to appease certain people
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
