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>
lbmk never needed a makefile, because the build system
is all shell scripting; the former makefile simply called
those scripts, in a way that was mostly superfluous
build/release/src was still trying to copy it, so let's
remove it from that file
Signed-off-by: Leah Rowe <leah@libreboot.org>
it was previously trying to "continue", despite not being
inside a loop. the correct instruction would have
been "return 0", but then I thought it'd be better to
err here
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>
most of these steps do not need to be repeated, per image.
move it into handle/make/config, so that the steps are
performed on files that go under elf/coreboot (this will
save on build time).
the logic for handling 4MB ROM images on sandy/ivy was unused,
and has been removed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
new behaviour:
* grub.cfg and grubtest.cfg no longer inserted to cbfs
* grub.cfg in memdisk instead
* grub.cfg in memdisk defers to cbfs/grub.cfg if added
(not added by default, anymore)
* does not defer to grubtest.cfg even if available
* only shows link to grubtest.cfg if available,
as a menuentry item
keymaps:
if /keymap.gkb exists in cbfs, it uses that by default,
but by default this isn't added. instead, it looks for
a file named keymap.cfg and sources that, which then
sets the keymap to one that is located under memdisk.
this file is inserted for each rom, per layout.
if keymap.gkb and keymap.cfg both absent, grub.cfg in
memdisk shall defer to usqwerty as the default keymap
grub_scan_disk: grub.cfg looks for cbfs file "scan.cfg"
and sources that if found, which will be inserted with
the string: set grub_scandisk=setting_goes_here (based
on target.cfg, generated by build/boot/roms automatically).
If no scan.cfg is found, it defaults to "both"
The "background.png" file remains unchanged, and present in
CBFS, used by grub.cfg if present (and it is, by default)
This change actually *saves* space in CBFS, due to compression,
and means that the grub.cfg is now compressed heavily. This
is also safer, because now the user overrides grub.cfg by
adding it, and they can still add grubtest.cfg for testing
first. If they accidentally delete both configs from cbfs,
Libreboot will fall back to the one in memdisk which would
presumably not be deleted.
This also means that lbmk can now more easily be used by
other build systems, that just want the GRUB part to re-use
in their own project. For example, people who want to build
custom coreboot images without using Libreboot's build system.
This change also *speeds* up the build process considerably,
on the parts where ROM images are copied. It's less than half
a second now, whereas previously it took about 30-45 seconds
for ROM images to copy, because of grub.elf being re-added in
each ROM via cbfstool, where compression is used; I believe
the compression part is what caused slowness.
Much, much faster, more versatile builds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was an oversight, in a previous commit.
there was a space, between variable name and
the equals sign, and then another space, so it
was trying to *execute* the rom
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk's new style is inspired by the bsd coding styles:
top-down logic, main simplified to a skeleton showing
overall program structure, variables well-defined,
rigorous (yet deceptively simple) error checking.
this was attempted before, but caused problems; coreboot
wasn't being cleaned properly, and rather than audit it,
i simply reverted this back to the old style.
this is actually attempt number 5, because i made 3 more
attempts between then and this one. i've build-tested this
using "./build boot roms all" (which is what b0rked on
the first attempt, months ago). it should be stable(tm).
the code is much nicer to read / work on now. this is the
beating heart of lbmk. get this script wrong, and you break
all of libreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
With this change, about 54KB of compressed space is saved
inside of CBFS, on setups that use the GRUB payload.
The uncompressed saving is about 720KB, but payloads are
compressed inside each coreboot image, so the compressed
saving is much smaller. That 54KB saving means a lot,
especially on small (1MB or smaller) flash sizes.
The following modules were removed:
adler32, afsplitter, aout, archelp, backtrace, blocklist,
bswap_test, cat, cmdline_cat_test, cmosdump, cmostest, cmp,
cmp_test, cpuid, cs5536, ctz_test, date, datehook, datetime,
disk, diskfilter, div, div_test, dm_nv, efiemu, eval,
exfctest, extcmd, file, fshelp, functional_test, gdb,
gettext, gptsync, hashsum, hdparm, hello, hfspluscomp, http,
json, json, ldm, loadenv, macbless, macho, mda_text, morse,
mpi, msdospart, mul_test, net, ntfscomp, offsetio,
part_acorn, part_amiga, part_apple, part_dvh, part_plan,
part_sun, part_sunpc, parttool, pbkdf2, pbkdf2_test, pci,
play, priority_queue, probe, progress, random, rdmsr, read,
relocator, setjmp, setjmp_test, shift_test, signature_test,
sleep, sleep_test, smbios, strtoull_test, terminal,
terminfo, test_blockarg, testload, testspeed, tftp, tga,
time, tr, trig, usbtest, video_bochs, video_cirrus,
videoinfo, videotest, videotest_checksum, wrmsr, xnu_uuid,
xnu_uuid_test
These were retained, but moved to modules instead of
install modules:
geli, udf, ufs1, ufs1_be, ufs2
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe