we know that _dest is always what's set in the coreboot config,
without the ../../../ in it, so just copy both files in a single
function, and call the function twice.
if both files are done on the first call, the second call will
be skipped. if only the first file was done on the first call,
running the download script again will skip the first one, and
grab the second one.
this also avoids having to run the decat function twice, in most
cases, so it's a tiny optimisation.
this optimisation only works if both fsp files (s and m) are to
be extracted into the same directory, which is the case anyway,
and this will always be the case.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Don't copy it until it has been padded properly.
Otherwise, erroneous padding would result in an error,
and who knows what would be left in vendorfiles/ ?
Signed-off-by: Leah Rowe <leah@libreboot.org>
If we're in a release work directory, TMPDIR is already
set, so the local ./tmp won't be created, which would
lead to an error.
Fix it by creating xbmklocal before checking TMPDIR.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this silences confusing error messages that the user
sees on the screen, that are actually benign, and it
will thus reduce the number of people who ask questions
on #libreboot irc
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's not a lot of code, and takes less than a second.
the previous change uses x instead of ?, but this would
cause an error if the nvmutil was already built, because
the makefile might cause a build to be skipped.
therefore, force a re-build to mitigate the error.
Signed-off-by: Leah Rowe <leah@libreboot.org>
A user reported that '?' causes an error on zsh. See:
https://codeberg.org/libreboot/lbmk/issues/261
For example:
./mk inject libreboot-XXXXXX.tar.xz setmac ??:??:??:??:??:??
The user got:
zsh: no matches found: ??:??:??:??:??:??
The mitigation here is to double-quote, e.g.:
./mk inject libreboot-XXXXXX.tar.xz setmac "??:??:??:??:??:??"
However, a lot of people won't do that. Therefore, I will
retain the current behaviour but support x/X for randomness.
Now lbmk uses x by default, instead. I will now update the
documentation, accordingly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
not to be confused with /tmp
we use ./tmp inside the lbmk work directory, for large files,
because /tmp might not be very big, or might be a tmpfs
Signed-off-by: Leah Rowe <leah@libreboot.org>
In the mk script, we need fx_ to not return errors on the
find command, since it's searching a bunch of directories
where some of them may not exist.
All other instances where fx_ is used, must return an error
if the directory being searched doesn't exist.
For this, fe_() is introduced, which does the same as fx_
but with this much stricter check.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We have a lot of places in lbmk where the output of find is
used, and then some function is executed on the result.
This is messy, and bloats several of these functions.
Now this is unified, into a new function: fx_
What fx_ does is execute a given function, for each result
found, with the arguments for a find command appended.
For example:
find -name ".git"
If you wanted to do: foo "$arg"
Where "arg" is a search result from find, and you wanted
to execute "foo" on each one, you would do:
fx_ foo -name ".git"
The find utility does have an -exec feature, but I've found
that it only works for executables, not functions.
fx_ does not return errors, so "foo" in this example
would have to do its own error handling.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is similar to the 9020SFF, but this board has ECC support.
However, the native raminit isn't used here, even though it is
otherwise compatible, because the native init doesn't do ECC yet.
The broadwell mrc.bin has ECC support, which is also used on the
HP EliteBook 820 G2. The MRC for broadwell can be used on haswell
boards such as the T1700.
Add both the SFF and MT variants. Since these are identical to the
9020 variants, except for slightly different PCH enabling ECC, we
can just re-use the 9020 port without issue.
We *could* add a variant to coreboot, for T1700, but there is not
really any pressing need. It is simply the 9020sff/mt with mrc.bin
Signed-off-by: Leah Rowe <leah@libreboot.org>
remove it from mkhelper files, because rom.sh doesn't
initialise any variables globally, except one that
never changes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Do it just after creating the src archive. This way,
everything is downloaded all at once.
Otherwise, a momentary lapse of internet uptime will
cause a release build to fail later on, and one of
lbmk's flaws is that this would then mean you must
re-build from scratch.
If we assume that the internet is working within a
short period of time, then this change would mitigate
that possibility. If something did happen during tar
archive creation, that's a much shorter amount of time
that is "wasted".
Signed-off-by: Leah Rowe <leah@libreboot.org>
these functions make more sense in lib.sh
i made mk link lib.sh first, so that the
functions on init.sh can still use them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I fixed the AHCI bug, with a patch that I wrote. It works by
restoring the old SeaBIOS AHCI initialisation behaviour, whereby
the AHCI controller is enabled from its current state; the patch
that broke AHCI in coreboot (tested on ThinkPad T420), changed
AHCI initialisation behaviour so that the controller's state is
first reset, prior to enablement.
However, my patch also retains the new AHCI initialisation
behaviour, when a CSM is in use. The AHCI reset patch was done,
by the author, specifically for SeaBIOS in CSM mode, so it makes
sense to only change the behaviour conditionally according to that.
This reverts commit 8245f0b321.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit a08b8d94fc.
From #libreboot IRC today:
07:02 <irys> ooh this is fun. seabios commit 8863cbbd15a73b03153553c562f5b1fb939ad4d7 (ahci: add controller reset) breaks ahci entirely on t420
07:05 <irys> cbmem console on that seabios commit has a timeout then "AHCI/0: device not ready"
07:07 <irys> AHCI works fine if i change config/seabios/default/target.cfg to use the immediate previous seabios commit (df9dd418b3b0e586cb208125094620fc7f90f23d)
07:07 <irys> works in grub payload either way though
07:31 <irys> here, `cbmem -c` after booting the broken rev: https://0x0.st/84oQ.log
07:31 <irys> compared to the working one https://0x0.st/84o1.log
07:33 <irys> i can't report to upstream myself *right now* but i figure you might want to know about this leah
I have downloaded those logs locally for reference, so that an upstream
report can be made to SeaBIOS. For the purposes of this Libreboot commit,
the diff of the logs is as follows (diff -u broken.log working.log):
Taking each diff line out of the log, the relevant entries
seem to be:
Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0
+AHCI/0: Set transfer mode to UDMA-6
+Searching bios-geometry for: /pci@i0cf8/*@1f,2/drive@0/disk@0
+AHCI/0: registering: "AHCI/0: Netac SSD 128GB ATA-11 Hard-Disk (119 GiBytes)"
-WARNING - Timeout at ahci_port_setup:477!
-AHCI/0: device not ready (tf 0x80)
-All threads complete.
-2. Payload [memtest]
+2. AHCI/0: Netac SSD 128GB ATA-11 Hard-Disk (119 GiBytes)
+3. Payload [memtest]
-Space available for UMB: c7000-eb800, f5880-f5ff0
-Returned 16777216 bytes of ZoneHigh
+drive 0x000f5fa0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=250069680
+Space available for UMB: c7000-eb800, f5880-f5fa0
+Returned 16773120 bytes of ZoneHigh
Therefore, the revision will be reverted back for now. It was
only about 8 additional patches imported in the update anyway.
src/rp2_common/boot_stage2/boot2_w25x10cl.S:142: Error: junk at end of line, first unrecognized character is `0'
src/rp2_common/boot_stage2/boot2_w25x10cl.S:145: Error: garbage following instruction -- `beq 00b'
This should also fix it on Debian sid Experimental, where I'm testing
with GCC 15 and other bleeding edge dependencies.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i forgot to in the last commit, but it didn't matter because
it just meant that coreboot.git's own download logic kicked
in as a fallback. however, it's better to rely on libreboot's
build system for this, since it has redundancy.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this fixed kgpe-d16 build errors on gcc 15 when tested
on debian sid (with gcc-15 installed from experimental)
Signed-off-by: Leah Rowe <leah@libreboot.org>
Many users report bugs, so I'm reverting lbmk back to only
supporting the rp2040 dongles for the time being. The
documentation will be updated to reflect this.
Pico2 support will be re-added at a later date, once more
testing has been done, and fixes made if necessary.
This brings in the following improvements from upstream:
* 9029a010 kconfig: fix the check-lxdialog.sh to work with gcc 14+
* 8863cbbd ahci: add controller reset
* df9dd418 update pci_pad_mem64 handling
* a4fc1845 add romfile_loadbool()
* a2725e28 drop acpi tables and hex includes
* 35aa9a72 drop obsolete acpi table code
* 1b598a1d usb-hid: Support multiple USB HID devices by storing them in a linked list
Signed-off-by: Leah Rowe <leah@libreboot.org>
the fix in the previous revision wasn't being applied
properly, because the build system of gmp generates
a conftest.c file, and the entry being made for it was
actually coming from this place in the configure file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
gcc 15 defaults to -std=c23, but the older gcc was
using -std=c17. The new c23 breaks GMP, so let's add
a patch from upstream (GMP project) to fix it.
this has been done to both coreboot trees.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Building the fam15h tree results in one of the same nonstring errors
we also had when building the default tree. Copy the relevant patch from
the default tree, while dropping a hunk that we don't need in this old
version.
Another build error is about bool being a reserved keyword now:
.../lbmk/src/coreboot/fam15h/util/romcc/romcc.c:7140:13: error: 'bool' cannot be used here
7140 | static void bool(struct compile_state *state, struct triple *def)
| ^~~~
.../lbmk/src/coreboot/fam15h/util/romcc/romcc.c:7140:13: note: 'bool' is a keyword with '-std=c23' onwards
.../lbmk/src/coreboot/fam15h/util/romcc/romcc.c:7140:18: error: expected identifier or '(' before 'struct'
7140 | static void bool(struct compile_state *state, struct triple *def)
| ^~~~~~
.../lbmk/src/coreboot/fam15h/util/romcc/romcc.c: In function 'mkcond_expr':
.../lbmk/src/coreboot/fam15h/util/romcc/romcc.c:7708:19: error: expected ')' before ',' token
7708 | bool(state, test);
| ^
| )
[...]
Fix that by adding a patch that renames the function to bool_().
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Building coreboot host tools with GCC 15 results in build errors:
In file included from .../lbmk/src/coreboot/default/util/cbfstool/console/console.h:7,
from .../lbmk/src/coreboot/default/src/commonlib/fsp_relocate.c:3:
.../lbmk/src/coreboot/default/src/commonlib/include/commonlib/loglevel.h:170:26: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (6 chars into 5 available) [-Werror=unterminated-string-initialization]
170 | [BIOS_EMERG] = "EMERG",
| ^~~~~~~
.../lbmk/src/coreboot/default/src/commonlib/include/commonlib/loglevel.h:171:26: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (6 chars into 5 available) [-Werror=unterminated-string-initialization]
171 | [BIOS_ALERT] = "ALERT",
| ^~~~~~~
[...]
../cbfstool/common.c: In function 'bintohex':
../cbfstool/common.c:195:43: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (17 chars into 16 available) [-Werror=unterminated-string-initialization]
195 | static const char translate[16] = "0123456789abcdef";
| ^~~~~~~~~~~~~~~~~~
Add a patch that marks the latter with the "nonstring" attribute, and
disable the warning for the former because I couldn't figure out how to
add that attribute there.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The Debian package for libusb is "libusb-1.0-0". Fix the typo in the
list which is missing the suffix. While we're here, also fix a line
continuation.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
One of our SeaBIOS patches causes build errors with GCC 15:
src/romfile.c: In function 'romfile_loadfile_g':
src/romfile.c:65:18: error: too many arguments to function 'malloc_fn'; expected 0, have 1
65 | char *data = malloc_fn(filesize+add_len);
| ^~~~~~~~~ ~~~~~~~~~~~~~~~~
src/romfile.c: In function 'romfile_loadfile':
src/romfile.c:88:50: error: passing argument 3 of 'romfile_loadfile_g' from incompatible pointer type [-Wincompatible-pointer-types]
88 | char *data = romfile_loadfile_g(name, psize, &malloc_tmphigh, 1);
| ^~~~~~~~~~~~~~~
| |
| void * (*)(u32) {aka void * (*)(unsigned int)}
src/romfile.c:55:28: note: expected 'void * (*)(void)' but argument is of type 'void * (*)(u32)' {aka 'void * (*)(unsigned int)'}
55 | void *(*malloc_fn)(), int add_len)
| ~~~~~~~~^~~~~~~~~~~~
In file included from src/romfile.c:8:
src/malloc.h:42:21: note: 'malloc_tmphigh' declared here
42 | static inline void *malloc_tmphigh(u32 size) {
| ^~~~~~~~~~~~~~
make: *** [Makefile:142: out/src/romfile.o] Error 1
make: *** Waiting for unfinished jobs....
src/optionroms.c: In function 'vgarom_setup':
src/optionroms.c:468:60: error: passing argument 3 of 'romfile_loadfile_g' from incompatible pointer type [-Wincompatible-pointer-types]
468 | void *mxm_sis = romfile_loadfile_g("mxm-30-sis", NULL, &malloc_low, 0);
| ^~~~~~~~~~~
| |
| void * (*)(u32) {aka void * (*)(unsigned int)}
In file included from src/optionroms.c:18:
src/romfile.h:17:34: note: expected 'void * (*)(void)' but argument is of type 'void * (*)(u32)' {aka 'void * (*)(unsigned int)'}
17 | void *(*malloc_fn)(), int add_len);
| ~~~~~~~~^~~~~~~~~~~~
In file included from src/optionroms.c:16:
src/malloc.h:30:21: note: 'malloc_low' declared here
30 | static inline void *malloc_low(u32 size) {
| ^~~~~~~~~~
make: *** [Makefile:141: out/src/optionroms.o] Error 1
make: Leaving directory '/tmp/lbmk/src/seabios/default'
This is because the function pointer defined as `void *(*malloc_fn)()`
refers to a function that takes no arguments, unlike `malloc_tmphigh`
which takes an unsigned int. Add the missing argument type.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Recently, gru boards were migrated to use common stack addresses with
U-Boot commit 5e7cd8a11995 ("rockchip: Use common bss and stack
addresses on RK3399") and commit 49f8131e5594 ("rockchip: rk3399-gru:
Use TPL with common bss and stack addresses"). This is done with the
ROCKCHIP_COMMON_STACK_ADDR config.
With POSITION_INDEPENDENT, INIT_SP_RELATIVE defaults to enabled as well.
However, ROCKCHIP_COMMON_STACK_ADDR selects HAS_CUSTOM_SYS_INIT_SP_ADDR,
which depends on INIT_SP_RELATIVE being disabled. So this results in a
configuration warning:
WARNING: unmet direct dependencies detected for HAS_CUSTOM_SYS_INIT_SP_ADDR
Depends on [n]: ARM [=y] && ARCH_KIRKWOOD [=n] || ARC [=n] || ARM [=y] && !INIT_SP_RELATIVE [=y] || MIPS [=n] || PPC [=n] || RISCV [=n]
Selected by [y]:
- ROCKCHIP_COMMON_STACK_ADDR [=y] && ARM [=y] && ARCH_ROCKCHIP [=y] && SPL_SHARES_INIT_SP_ADDR [=y]
I'm not sure if adhering to the Rockchip values means we can't be
position-independent. Disabling INIT_SP_RELATIVE still appears to keep
my kevin board working, so let's do that for now.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Leah Rowe
Leah Rowe
Alper Nebi Yasak