With newer hostcc, trying to build IASL will raise an error:
- Intermediate obj/aslcompilerlex.c
- Link obj/iasl
/usr/bin/ld: obj/aslcompilerparse.o:(.bss+0x8): multiple
definition of `AslCompilerlval'; obj/aslcompilerlex.o:(.bss+0x0):
first defined here
/usr/bin/ld: obj/prparserlex.o:(.bss+0x0): multiple definition of
`LexBuffer'; obj/dtparserlex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
This commit adds a patch for GCC 8.3.0 that modifies the ASL engine:
- making LuxBuffer variable static to avoid multiple definitions
being treated as errors
- removing a redundant definition of AcpiGbl_DbOpt_NoRegionSupport
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: commit: cosmetics changes only
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
With newer hostcc, trying to build GCC 8.3.0 will raise an error from ld:
undefined reference to `__gnat_begin_handler_v1'
This commit adds a patch for GCC found on coreboot [1] correcting this
error by backporting the GNAT exception handler v1 to GCC 8.3.0 allowing
GNAT to be built with newer hostcc like GCC 10+.
[1]https://review.coreboot.org/c/coreboot/+/42158
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Without that fix, if we build for a fam15h target on PureOS byzantium,
we have a build failure:
$ ./build boot roms kgpe-d16-udimm_2mb
[...]
Building MPC v1.1.0 for host ... ok
Building BINUTILS v2.32 for target ... failed. Check 'build-i386-elf-BINUTILS/build.log
make[2]: *** [Makefile:26: build_gcc] Error 1
make[1]: *** [Makefile:51: build-i386] Error 2
make: *** [util/crossgcc/Makefile.inc:48: crossgcc-i386] Error 2
Error: build/roms: something went wrong
Then the build log (here) in available in
coreboot/fam15h_udimm/util/crossgcc/build-i386-elf-BINUTILS/build.log
has the following:
In file included from ../../binutils-2.32/gold/debug.h:29,
from ../../binutils-2.32/gold/descriptors.cc:31:
../../binutils-2.32/gold/errors.h:87:50: error:
'string' in namespace 'std' does not name a type
87 | undefined_symbol(const Symbol* sym, const std::string& location);
| ^~~~~~
../../binutils-2.32/gold/errors.h:29:1: note: 'std::string'
is defined in header '<string>'; did you forget to '#include <string>'?
28 | #include "gold-threads.h"
+++ |+#include <string>
29 |
Signed-off-by: Adrien Bourmault <neox@a-lec.org>
GNUtoo: commit message but not its title
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Crossgcc needs acpica-unix2-20210331.tar.gz and acpica-unix2-20190703.tar.gz,
but this file is gone from upstream[1], so with guix-time-machine and
guix build --source, we recovered these files and published it at the addresses
in the patches.
[1]https://github.com/acpica/acpica/issues/883
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Co-developed-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
neox: Added fam15h patches and adjusted the commit message accordingly
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
with this change, it's unlikely we'll hit errors again. previously,
some projects used were calling "python" which in context was
python3, but on some setups, the user only has python2 and python3
but no symlink for "python" (which if exists, we assumed linked to
python3)
now it's unambiguous. docs/build/ can probably be updated now, as
a result of this change, to remove the advice about that
I was running into a race condition when rebuilding seabios with a high cpu count,
resulting in failure with this error message:
cc1: fatal error: can't open 'out/src/asm-offsets.s' for writing: No such file or directory
Performing the silentoldconfig step before the full make step seems to resolve the failure.
When running ./download all, we have the following error:
resources/scripts/download/coreboot: Line 52: $1 is not set.
The ./download all command was broken by the following commit:
2bb805e2e0 (download: Add --help in the
individual download scripts).
Reported-by: madbehaviorus[m] on #libreboot on liberachat
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Without that fix we have the following warning during the download:
Cloning into 'u-boot/u-boot'...
warning: redirecting to https://source.denx.de/u-boot/u-boot.git/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
the generated script to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
that blob to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The tar options come from the tutorial to remove archives metadata at
reproducible-builds.org[1].
[1]https://reproducible-builds.org/docs/archives/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This doesn't change the existing usage of the scripts:
- For the Coreboot script, before this change, all arguments that were
passed were considered as board to download the Coreboot source code
for.
Here we added the '--help' and '--list-boards' arguments, so it
should not be an issue as it is extremely unlikely that a board
would be called '--help' or '--list-boards'.
- All the other scripts don't use any arguments so passing --help
should not conflict with the existing usage.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
If the script is named u-boot-stable-src-release and that users see an
u-boot-libre tarball they will not make the link between both unless
we rename the script.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Many people using FSDG compliant distributions or wanting to use one
are already familiar with linux-libre. This change renames the
resulting tarball to u-boot-libre to make it easier for people to
understand the goal of this tarball.
In addition we also rename the version from v2021.07 (which is the git
tag corresponding to the release) to 2021.07 as u-boot upstream
tarballs use that.
The revision wasn't bumped as we didn't have any releases of
u-boot-libre yet.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Once the tarball are released, it will enable distributions to use
these tarballs to produce deblobbed u-boot packages.
Note that the produced tarball is not reproducible yet. Because of
that it has to be trusted.
During a release, it's a good idea to sign the uncompressed tarball as
the various compression formats and associated tools make different
tradeoffs.
For instance with xz, xz -9e tends to compress really well with the
the most used xz[1] implementation, and most GNU/Linux users probably
already have it installed, but and the drawbacks is that the format is
very fragile[2].
The lzip format is more suited for long term archiving but its most
packaged implementation[3] is less likely to be already installed by
users than more well known formats like xz, bzip2 or gzip.
Being able to add more compression formats after the release is also
useful, for instance to accommodate different build systems or use
cases (like being able to build u-boot with less dependencies in
distributions like Guix, or building u-boot directly on devices which
don't have enough RAM for xz for instance).
[1]https://tukaani.org/xz/
[2]https://www.nongnu.org/lzip/xz_inadequate.html
[3]https://www.nongnu.org/lzip/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
hardcode everything. in practise, the new logic will work just the same in
almost all cases, for most people, but it works around performance issues in
grub. cleanup of grub.cfg will be done in the next commit
On many boards, grub takes a very long time to
search for a grub.cfg file on the disk.
The problem is the search_grub function which
takes a long time to complete.
I (vitali64) studied the grub.cfg from 2016 and
the grub.cfg from 2021 and optimized the
grub.cfg. It should be faster now.
Coreboot is enabling PECI on these CPUs which, according to Intel erratum, must
only be done after loading microcode updates, otherwise the CPUID feature set
becomes corrupted. That's my understanding, and I think this is why SpeedStep
is broken. To be specific, it could but but operating systems no longer detect
that the feature is supported. In any case, belgin on IRC found the commit in
coreboot, after a bisect, enabling PECI. This commit in Libreboot adds a patch,
reverting coreboot's PECI patch.
tianocore is a liability for the libreboot project. it's a bloated mess, and
unreliable, broken on many boards, and basically impossible to audit.
i don't trust tianocore, so i'm removing it.
4mb and 8mb users can just pad their roms to 16mb, using the instructions on
<https://libreboot.org/faq.html#how-do-i-pad-a-rom-before-flashing>
maintaining them in lbmk is a waste of time, and also a hazard because it's a
lot of duplicated labour when making any changes, which could result in awful
mistakes being made
There is already a separate menuentry for USB, and most people don't boot their
installed system from USB anyway. This will result in faster boot speeds.
mitigate missing characters in unifont for border/arrow characters. this saves
space because now it is no longer necessary to add a custom font
the background added has the libreboot logo on it, and it's 10kb in size unlike
the old gnulove background that was hundreds of KB
These option ROMs are known to cause a system hang. If you insert an empty
option ROM into CBFS, it disables any option ROM loading for those devices
when using SeaBIOS.
this is a compromise. i was going to do 30 for desktops, 1 for laptops.
however, some laptop users complain about the 1 second timeout being too fast.
10 seconds should just about please everyone.
This fixes issue 3:
https://notabug.org/libreboot/lbmk/issues/3
In this issue, GM45 laptops such as X200/T400 will hang on reboot (normal boot
works, and shutting down works too).
2MiB and 16MiB were the only flash sizes supported. 4 and 8MiB have been
added.
Now there are only libgfxinit_txtmode configs.
Use seabios_withgrub or seabios_grubfirst ROMs if you wish to use an add-on
GPU.
this is forked from the "libre" branch in osboot, which is itself a libre,
deblobbed fork of osboot, a blobbed up fork of libreboot
libreboot needed to be purged clean. this is the new libreboot development
repository. the old one has been abandoned