Void was not migrated to PackageKit because there is no backend for
xbps in it.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This can simplify the overal structure of GNU Boot as we don't need to
compute some git tag everytime in the code.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
It is possible to install GNU Boot on I945 Thinkpads without opening
the computer even if the nonfree bios sets the bootblock region (the
last 64K of the flash chip) read-only.
The flash chip looks like that:
+----- -----+---------------------------+-------------------------+
| ... | Secondary bootblock (64k) | Primary bootblock (64k) |
+----- -----+---------------------------+-------------------------+
0 0x1e0000 2MiB
To bypass the read-only restriction we use an utility (bucts) that
tells the hardware to swap the primary bootblock with the secondary
one for the next boot. We then have to disable that swap and reflash
again.
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK generates the two bootblocks
directly in coreboot so we don't need to use special commands to do
that anymore.
In addition the MacBook 1.1 and 2.1 are known not to have such
read-only restrictions so they don't need to have
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK enabled.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The arch, debian and ubuntu2005 packages names were respectively
checked on Parabola, PureOS byzantium and Trisquel 11.
The fedora35 and void packages were checked using the Fedora and Void
Linux online package databases.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The various scripts present in GNU Boot are very fragile, so it's a
good idea to have a pristine GNU Boot source code for making releases.
The issue is that 'git clean -dfx' doesn't remove existing git
repositories like coreboot/ grub/ etc, so we need additional code to
take care of that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit corrects linelength (this should have no functional impact)
and adds exit codes (sysexit.sh)
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
neox: wrote the commit message
This should contain no functional modifications.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
neox: wrote the commit message
Having an {arch,debian,fedora35,ubuntu2004,void} GNU Boot package
looked strange. Having a dependencies package instead makes more
sense.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The various build scripts are scattered around in multiple
places. This make it hard for contributors to understand what they
need to modify.
Most GNU Boot users are interested in running GNU/Linux or BSD
operating systems. And the way to install software on these
operating systems is through a package manager. So most users and
contributors already know the package manager abstraction.
So using that abstraction makes it easier to find where things are.
The scripts to install dependencies don't really fit the new structure
but for now we move them in to make sure that everything works
fine. This could be fixed later on and migrated to a single
dependencies packages by auto-detecting the distribution with
/etc/os-release.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
While that microcode is licensed under a permissive free software
license we don't have any corresponding source code, so until someone
produces that source code we need to treat it as nonfree software.
This issue was introduced by the commit the
f7c0fec698 ("coreboot/fam15h: update
code base, deblob, unset CONFIG_STM (see bug #64535)") and is also
present in GNU Boot 0.1 RC1.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The files were sorted with the sort command.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The configuration is based on the one in resources/coreboot/x60/.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In coreboot this build option is used to download nonfree software so
they can be included later on in the builds.
It doesn't necessarily means that nonfree software ends up in the
images but it is way easier and safer to disable that than having to
audit precisely what happen for each computer and build configuration.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Full build tested on PureOS.
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The script isn't related to flashrom. The comment was already in the
first lbmk commit 89517ed6b9
("libreboot!") which was based on osboot and at the time it didn't
contain any flashrom related code either.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The "Load Operating System (incl. fully encrypted disks) [o]" GRUB
entry tries to load grub configuration files from the hard disk or SSD
partitions. It tries various files in /boot, /grub, /grub2,
/boot/grub, /boot/grub2.
For consistency we at least need to make it search for the
gnuboot_grub.cfg in these directories as well. Since this is GNU Boot,
the gnuboot_grub.cfg takes precedence over files made for other boot
software distributions.
For libreboot_grub.cfg, it was not replaced because it is still
mentioned in the documentation.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: reworked code and commit message.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without having python-is-python3 installed, on recent PureOS 10
(byzantium) with at least the d510mo target, we have the following
build failure:
$ ./build boot roms d510mo
[...]
Compiling (16bit) out/vgaentry.o
Compiling whole program out/vgaccode16.raw.s
Fixup VGA rom assembler
make: python: No such file or directory
make: *** [Makefile:228: out/vgaccode16.o] Error 127
Without python-is-python3, the build also fails on recent
versions of Trisquel and Debian.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: Part of the commit message
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
These folders (fam15h_rdimm and fam15h_udimm) are generic plateforms to gather
patches in common for multiple boards (e.g. kgpe-16 and kcma-d8), this is why we also
disable crossgcc_ada in the configuration, since it will be built by specific boards
if needed, avoiding double compilation.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: split commit
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit updates the coreboot code base from release 4.11 to 4.11_branch for kgpe-d16,
kcma-d8, kfsn4-dre and addresses one new blob related to this update.
The main reason to update the codebase is to prevent a bug with RAM initialization
that occured with coreboot 4.11 and raised the following critical error:
fam15_receiver_enable_training_seed: using seed: 0054
fam15_receiver_enable_training_seed: using seed: 0054
TrainRcvrEn: Status 2005
TrainRcvrEn: ErrStatus 4000
TrainRcvrEn: ErrCode 0
TrainRcvrEn: Done
TrainDQSReceiverEnCyc_D_Fam15: lane 0 failed to train! Training for receiver 2 on DCT 0 aborted
TrainDQSReceiverEnCyc: Status 2205
TrainDQSReceiverEnCyc: TrainErrors 44000
TrainDQSReceiverEnCyc: ErrStatus 44000
TrainDQSReceiverEnCyc: ErrCode 0
TrainDQSReceiverEnCyc: Done
TrainDQSReceiverEnCyc: Status 2005
TrainDQSReceiverEnCyc: TrainErrors 4000
TrainDQSReceiverEnCyc: ErrStatus 4000
TrainDQSReceiverEnCyc: ErrCode 0
TrainDQSReceiverEnCyc: Done
DIMM training FAILED! Restarting system...soft_reset() called!
This coreboot revision also correct some bugs with SMM, SMBIOS, IPMI and BMC.
Some new values in coreboot configuration make coreboot first build stop to prompt
users and forcing them to choose an option to continue:
- CONFIG_STM
- CONFIG_DEBUG_IPMI
- CONFIG_VENDOR_VIA
- CONFIG_SOUTHBRIDGE_AMD_CIMX_SB900
- CONFIG_IPMI_FRU_SINGLE_RW_SZ
- CONFIG_IPMI_KCS_TIMEOUT_MS
A bug has been opened about CONFIG_STM on our bug tracker [1], and we decided,
for now, to unset this option explicitely.
So in this commit we just regenerated configurations for each fam15h board via
coreboot build prompts and copied the resulting configurations in the configuration
folder and that results in the following:
- unset CONFIG_STM
- unset CONFIG_DEBUG_IPMI
- unset CONFIG_VENDOR_VIA
- unset CONFIG_SOUTHBRIDGE_AMD_CIMX_SB900
- set CONFIG_IPMI_FRU_SINGLE_RW_SZ=16
- set CONFIG_IPMI_KCS_TIMEOUT_MS=5000
[1]https://savannah.gnu.org/bugs/?64535
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: split commit into "don't build ada toolchain for generic platforms"
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
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>
Denis 'GNUtoo' Carikli
Leah Rowe