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>
Fixes this bug:
https://codeberg.org/libreboot/lbmk/issues/216
Well, fix is the wrong word. We want xHCI ideally.
Mate is working on it as I write this. I've also:
* Disabled CONFIG_FINALIZE_USB_ROUTE_XHCI on Haswell
boards (coreboot)
* Disabled the GRUB payload on HP 820 G2 for now
We will need to re-add the xHCI patches once fixed.
If Mate/we can't fix it, I'll contact Patrick
Rudolph who originally wrote the xHCI patches.
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>
See:
https://codeberg.org/libreboot/lbmk/issues/216
Almost all users will be OK running GRUB, but a
minority of users have experienced a fatal error
pertaining to grub_free() or grub_realloc() (as
my investigation of GRUB sources reveal when grepping
the error reported in the link above).
We don't yet know what the bug is, only that the
error occurs, leading to an effective brick if the
user has GRUB as their primary payload.
So far, it has only been reported on some Intel
SandyBridge-based Dell Latitudes in Libreboot, but
we can't be too sure.
The user reported that memtest86+ passes just fine,
and SeaBIOS works; BIOS GRUB also works, which means
that the bug is likely only in an area of GRUB that
runs specifically on the coreboot payload, so it's
probably a driver in GRUB when running on the metal
rather than BIOS/UEFI.
The build system supports a configuration whereby
SeaBIOS is the primary payload, but GRUB is available
in the SeaBIOS boot select menu, and an additional
configuration is available where GRUB is what SeaBIOS
executes first (while still providing boot select);
both of these are now the *only* configurations
available, on all x86 targets except QEMU.
The QEMU target is fine because if the bug occurs there,
you can just close QEMU and try a different image.
Even after this bug is later identified and fixed,
the GRUB source code is vastly over-engineered and there
are likely many more such bugs. SeaBIOS is a reliable
payload; the code is small and robust. Remember always:
Code
equals
bugs
Therefore, this configuration change is likely going
to be permanent. This will apply in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I've rebased the workaround-mx patch as follows. See:
commit 9a11cbf21a5078bcdb8db7584c44a9ee17020db4
Author: Nico Huber <nico.h@gmx.de>
Date: Fri Jan 13 01:19:07 2023 +0100
Let the flash context directly point to the used master
This change, now upstream in flashprog, made me have to do this in
the patch. I changed this:
flash->mst->spi.command(flash, sizeof(cmd), sizeof(buf), cmd, buf);
to this:
flash->mst.spi->command(flash, sizeof(cmd), sizeof(buf), cmd, buf);
It should work fine. This update imports the following upstream
patches from flashprog:
* 5b4fdd1 z60_flashprog.rules: Add udev rule for CH347
* 72c9e40 meson: Check for CPU families with known raw mem access
* 3458220 platform/meson: Port pciutils/pci.h workaround to Meson
* f279762 platform/meson: Check for libi386 on NetBSD
* 14da5f7 README: Convert to Markdown
* 8ddea57 README: Document branching and release policy
* 2522456 util/list_yet_unsupported_chips.sh: Fix path
* cbf9c11 spi: Don't cross 16MiB boundaries with long writes
* 823a704 dediprog: Skip warning on first attempt to read device string
* e8463c8 dediprog: Revise prefix check for given programmer id
* 38af1a1 dediprog: Revise id matching
* 4661e7c amd_spi100: Use flashprog_read_chunked() for progress reporting
* cdcfda2 read_memmapped: Use flashprog_read_chunked() for progress reporting
* 7679b5c spi25: Replace spi_read_chunked() with more abstract version
* ca1c7fd spi25: Normalize parameters of spi_nbyte_read()
* e36e3dc dediprog: Use default_spi_write_256
* 522a86d linux_spi: Use default_spi_read()/_write_256()
* 806509b cli_classic: Turn progress reporting into a progress bar
* 842d678 libflashrom: Return progress state to the library user
* aa714dd flashprog.c: Let select_erase_functions() return byte count
* 2eed4cf serprog: Add SPI Mode and CS Mode commands
* 821a085 dediprog: Implement id reading for SF600 and later
* 274e655 dediprog: Read device string early
* 0057822 dediprog: Add protocol detection for SF700 & SF600Plus-G2
* fb176d2 dediprog: Use more general 4BA write mode for newer protocols
* 0ab5c3d dediprog: Split device type and version parsing
* bdef5c2 dediprog: Use unsigned conversions to parse device string
* 5262e29 dediprog: Try to request 32B device string (instead of 16B)
* e76e21f dediprog: Get rid of some unnecessary hex constants
* 5a09d1e udelay: Lower the sleep vs delay threshold
* 03ad4a4 linux_mtd: Provide no-op delay implementation
* 211c6ec serprog: Refine flushing before synchronization
* 383b7fe serprog: Test synchronicity before trying to synchronize
* d7318ea serprog: Move synchronicity test into separate function
* 9a11cbf Let the flash context directly point to the used master
* aabb3e0 writeprotect: Hook wp functions into the chip driver
* 89569d6 memory_mapped: Reduce `decode_sizes` to a single `max_rom_decode`
* 929d2e1 internal: Pass programmer context down into chipset enables
* 7c717c3 internal: Pass programmer context down into board enables
* e3a2688 Pass programmer context to programmer->init()
* 2b66ad9 Start implementing struct flashprog_programmer
* 4517e92 memory_bus: Drop stale `size == 0` workaround and FIXME
* b197402 memory_bus: Split register mapping into own function
* 0e76d99 memory_bus: Move (un)map_flash_region into par master
* 9eec407 Perform default mapping only for respective chips
* 56b53dd wbsio_spi: Request memory mapping locally
* 5596190 it87spi: Request memory mapping locally
* 46449b4 spi25: Drop stale `bus == SPI` guards
* ab6b18f spi25: Move 4BA preparations into spi_prepare_4ba() hook
* 901fb95 Add prepare/finish_access() hooks for chip drivers
* a96aaa3 dediprog: Support long writes of 16MiB and more
* 1338936 Consider 4BA support when filtering erase functions
* 8d36db6 flashprog.8: Fix up serprog example
* d2ac303 flashprog.8: document new serprog cs parameter
* d1b9153 chipset_enable.c: Add Genoa to mendocino entry
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>
i was checking whether it's a directory, whereas i should
have been checking whether it's a file. this is a workaround
put in place in case someone downloaded a tarball from codeberg
which is pre-generated per commit. in this situation, the
version and versiondate files do not exist, but the design
of the build system requires that they do exist.
the existing check is correct except for this bug, so fix
the bug. check that they are files, not directories
Signed-off-by: Leah Rowe <leah@libreboot.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>
this is using the same functionality that was added a few
commits ago, to override the use of "git submodule update"
each coreboot submodule has two repositories defined, with
the second one kicking in if the mail one fails upon cloning.
Signed-off-by: Leah Rowe <leah@libreboot.org>
whitelist what modules are downloaded, by adding
module.list files in the corresponding directories
under config/submodule/, per each coreboot tree.
this is making use of functionality added in the
previous commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
following on from the previous commit, if you run
something like "./build roms list" when running for
the first time from a codeberg tarball, the output
of the git commands will be included in the output
hide this output
Signed-off-by: Leah Rowe <leah@libreboot.org>
a user was getting error "version unset" when using the
tarball generated from codeberg. it's recommended to use
the git repository properly, or a release archive.
mitigate this so that the build succeeds anyway.
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>
this is an oversight in the last few commits.
canoeboot must not use --checkout, because doing so
would download blob repositories from coreboot.org
by only including "--init" in the submodule command,
coreboot's build system skips almost all blobs.
(and then canoeboot deletes any remaining stragglers)
Signed-off-by: Leah Rowe <info@minifree.org>
again, the directory in question is simply used
in a for loop using asterisk (git_am_patches) and
the for loop simply won't iterate if either the
directory doesn't exist or it contains no items.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in the function that immediately follows, it
starts two for loops that check every item in
that directory, using the asterisk wildcard.
if the directory does not exist, then the for
loop will simply break on first pass.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we want ./update release to work in release archives.
under the current logic, CHANGELOG would be cloned into
release/, thus breaking ./update trees -f
fix it by adding the file to .gitignore
Signed-off-by: Leah Rowe <leah@libreboot.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>
"./update project trees" is a leftover from the
old build system design, prior to audits.
this particular call is for when xtree is defined,
which means that a given tree must rely on the given
coreboot tree defined by xtree. the "xtree" tree is
downloaded, so that its crossgcc builds can be re-used
to save time when building targets across many trees.
this is because trees often use identical crossgcc builds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe