instead, check for the presence of target.cfg files
not in config/project/ but config/project/tree/
the way this check is done, it merely returns 1 if
config/project/*/target.cfg is detected, and returns
0 in all other cases, even if config/project/target.cfg
exists
that way, if the maintainer accidentally adds a
target.cfg in the main directory, the given multi-tree
project will not break
Signed-off-by: Leah Rowe <leah@libreboot.org>
adding help again is a bad idea. code should never
document itself; that's what documentation is for.
so, make the code do a better job telling the user
where to find documentation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The xHCI patches were removed because they caused issues
on Sandybridge-based Dell Latitude laptops. See:
https://codeberg.org/libreboot/lbmk/issues/216
The issue was not reported elsewhere, but we still don't
need xHCI support in Canoeboot's GRUB because none of the
available coreboot targets have xHCI support. However, we
may want it in the future and it helps to keep Canoeboot
in sync with Libreboot (this patch is adapted from lbmk).
Each given coreboot target can say which GRUB tree to use
by setting this in target.cfg:
grubtree="xhci"
In the above example, the "xhci" tree would be used. Some
generic GRUB config has been moved to config/data/grub/
and config/grub/ now looks like config/coreboot/ - also,
the grub.cfg file (named "payload" in each tree) is copied
to the GRUB source tree as ".config", then added to GRUB's
memdisk in the same way, as grub.cfg.
Several other design changes had to be made because of this:
* grub.cfg in memdisk no longer automatically jumps to one
in CBFS, but now shows a menuentry for it if available
* Certain commands in script/trees are disabled for GRUB,
such as *config make commands.
* gnulib is now defined in config/submodule/grub/, instead
of config/git/grub - and this mitigates an existing bug
where downloading gnulib first would make grub no longer
possible to download in lbmk.
There is another reason for merging this design change from
lbmk, and that reasoning also applies to lbmk. Specifically:
This change will enable per-board GRUB optimisation in the
future. For example, we hardcode what partitions and LVMs
GRUB scans because * is slow on ICH7-based machines, due
to GRUB's design. On other machines, * is reasonably fast,
for automatically enumerating the list of devices for boot.
Use of * (and other wildcards) could enable our GRUB payload
to automatically boot more distros, with minimal fuss. This
can be done at a later date, in subsequent revisions.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this effectively lets you change the boot order. example:
./build roms -s "nvme ata" t1650_12mb
the above example would set:
grub_scan_disk="nvme ata"
another example:
./build roms -s nvme t1650_12mb
this would set:
grub_scan_disk="nvme"
this overrides what's set in target.cfg for the given
target. useful for quick reconfiguration if building
from source
Signed-off-by: Leah Rowe <leah@libreboot.org>
i already do this on crossgcc, but overlooked it on regular
builds where i just use -j, but coreboot's build system
makes use of the CPUS= option in make
use XBMK_THREADS for this
Signed-off-by: Leah Rowe <leah@libreboot.org>
Previously, grub_scan_disk could set ata, ahci or "both",
which would make both be tried (ahci first). This worked
when we only dealt with ata and ahci devices, but now we
support nvme devices so the logic is inherently flawed.
Instead, use grub_scan_disk to store the boot order, e.g.:
grub_scan_disk="ahci nvme ata"
grub_scan_disk="nvme ata"
In the first example, it would make GRUB scan ahci first,
then nvme and then ata.
In the secontd example, it would make GRUB scan nvme first,
and then ata.
If "both" is set, or anything other than ahci/ata/nvme,
grub_scan_disk is now changed to "nvme ahci ata".
Actual grub_scan_disk entries in target.cfg files will now
be modified, to match each machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
rather than if seabios_grubonly=y
if grubonly=y, still make the grubonly rom
this complements the previous commit
Signed-off-by: Leah Rowe <leah@libreboot.org>
as stated in the previous commit, i'm adding this function
to lbmk because there are files i want to systematically
delete in libreboot releases, not just canoeboot releases,
but libreboot releases delete things such as unlicensed
readme files, or poorly licensed other files.
i initially moved the nuke function to its own file so as
to reduce the number of merge conflicts when merging
changes to git.sh between cbmk and lbmk, but if they're
going to both contain this file, then it makes sense
to have this in git.sh once again.
Signed-off-by: Leah Rowe <info@minifree.org>
blobs.list is now nuke.list
this is because i'm going to import this functionality
into lbmk (libreboot build system).
libreboot will not do full deblobbing like canoeboot does,
but there are still certain files that i like to delete
in releases, such as u-boot's strlcat.c file under tests
calling it "nukeblobs" in libreboot makes no sense, but
i like to avoid merge conflicts when cherry-picking
patches between cbmk and lbmk, so i like to make sure
that functions and variables common to both are named
the name.
simply calling it "nuke" or calling the files "nuke.list"
is probably inoffensive while conveying the same meaning.
Signed-off-by: Leah Rowe <info@minifree.org>
the inject script is from lbmk and referenced here, but
cbmk does not have this script.
remove the reference.
Signed-off-by: Leah Rowe <info@minifree.org>
it wasn't being reset before. when coreboot is being
built, i add to makeargs every time. if multiple targets
are being built, the make command would end up looking
something like:
make -C src/coreboot/default UPDATED_SUBMODULES=1 \
UPDATED_SUBMODULES=1
(the parameter would be printed twice)
of course, this doesn't check whether that parameter is
added already in target.cfg for a given target, but that's
ok because i won't add that one in target.cfg
i baked it into the code, only when handling coreboot,
because that was easier than either putting it in makeargs
for every coreboot target.cfg, or again modifying the code to
handle that; the current solution is the cleanest.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we do not want submodules to be downloaded after the fact.
we only handle this on ./update trees -f coreboot
Signed-off-by: Leah Rowe <leah@libreboot.org>
i'm importing some changes from lbmk and they go at the
end of git.sh, in the diffs. moving the deblob function
to its own file will allow me to cherry-pick with fewer
merge conflicts.
Signed-off-by: Leah Rowe <info@minifree.org>
firstly, memtest86+ is currently not cross compiled and
relies on 64-bit headers (x86_64 only). a 32-bit distro
is unlikely to be able to build 64-bit binaries.
secondly: vboot throws a build error due to -Werror when
building on 32-bit hosts. we rely on vboot code to build
cbfstool, so turn off -Werror on vboot
that's all. 32-bit hosts are not recommended; it is assumed
that you are building on an x86_64 host. work will go into
the build system at a later date to make it more portable,
by cross compiling everything, but this should fix 32-bit
for now.
there are some x60/t60 users who still want to build roms,
so let's allow them that possibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
an equivalent change has been made in lbmk.
certain cbmk-specific variable names have been made
generic, with certain functions and other variables
moved around.
i maintain sync between libreboot and canoeboot, where
both projects can have the same behaviours, and most of
the merge conflicts have to do with variable names
containing "LBMK", "lbmk", "cbmk" or "CBMK", or
indeed "canoeboot" and "libreboot"
LBMK/lbmk/CBMK/cbmk variables between canoeboot and
libreboot now contain the string XBMK/xbmk
it should now be *much* easier to merge build system
changes between lbmk and cbmk.
Signed-off-by: Leah Rowe <info@minifree.org>
i always say, code should never document itself.
that's what documentation is for. the releases
contain documentation under docs/ but the git
repository does not; for that, use the website.
(in practise, cbmk usually needs internet anyway)
Signed-off-by: Leah Rowe <leah@libreboot.org>
in cbmk, we call check_project() to set variables
such as projectname, version, version date
this is unnecessary, because all main scripts use
this functionality anyway
do it by default
Signed-off-by: Leah Rowe <leah@libreboot.org>
export CBMK_RELEASE="y"
if this is done, the tarball is created instead
of a directory, and the rom images are nuked using
./vendor inject with the nuke option, inserting the
correct version files; the rom directory is deleted
now the release script logic simple renames existing
tarballs. the benefit of this change is fewer lines of
code, and now cbmk doesn't use an insane amount of disk
space when building a *lot* of release images (the
uncompressed directories are deleted after each build)
Signed-off-by: Leah Rowe <leah@libreboot.org>
the release variable is all we need, turning a target on
or off for a given release.
the status checks were prone to bugs, and unnecessary; it
also broke certain benchmark scripts.
it's better to keep the cbmk logic simpler. board status
will be moved to the documentation instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
there are only two scripts under script/ now, and there
probably won't be many more. cbmk's design has simplified
to such a degree that the two-level directory structure is
no longer necessary.
the existing command structure has not changed. for example:
./build roms list
./update trees -f coreboot default
these will still work, but the symlinks to "build" are now
strictly for backwards compatibility; they may be removed
at a later date, but i'll keep the current design for now.
this also leads to a quirk, for example:
./build roms all
./update roms all
these now do the exact same thing, whereas "./update roms all"
would have previously been an invalid command.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the main script isn't that big, and since the main
purpose of cbmk is geared toward the releases, it
makes sense to reduce the number of scripts by
merging into the main one
the way this works, "./update release" still works
afterward
so, the way cbmk is used shall remain unchanged
Signed-off-by: Leah Rowe <leah@libreboot.org>
previous command:
./build serprog
now it is:
./build roms serprog
after that, it's the same arguments e.g.
./build roms serprog stm32
./build roms serprog rp2040
further cleanup to commence
Signed-off-by: Leah Rowe <leah@libreboot.org>
x is part of the for loop in main() and may or not
still be available from handle_target, depending on
your implementation of sh, but this should not be assumed
do it properly
Signed-off-by: Leah Rowe <leah@libreboot.org>
for example:
./build roms list stable
this lists all images that are marked "stable"
now:
./build roms list _stable
this lists all images that are *not* marked stable
this will help me keep track during development
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe