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>
changes upstream, relative to the previous revision:
* e5f2e4c6 pciinit: don't misalign large BARs
* 731c88d5 stdvgaio: Only read/write one color palette entry at a time
* c5a361c0 stdvga: Add stdvga_set_vertical_size() helper function
* 22c91412 stdvga: Rename stdvga_get_vde() to stdvga_get_vertical_size()
* 549463db stdvga: Rename stdvga_set_scan_lines() to stdvga_set_character_height()
* c67914ac stdvga: Rename stdvga_set_text_block_specifier() to stdvga_set_font_location()
* aa94925d stdvga: Rework stdvga palette index paging interface functions
* 8de51a5a stdvga: Rename stdvga_toggle_intensity() to stdvga_set_palette_blinking()
* 96c7781f stdvga: Add comments to interface functions in stdvga.c
* 2996819f stdvga: Rename CGA palette functions
* 91368088 stdvgamodes: Improve naming of dac palette tables
* 70f43981 stdvgamodes: No need to store pelmask in vga_modes[]
* 1588fd14 vgasrc: Rename vgahw_get_linesize() to vgahw_minimum_linelength()
* d73e18bb vgasrc: Use curmode_g instead of vmode_g when mode is the current video mode
* 192e23b7 vbe: implement function 09h (get/set palette data)
* 3722c21d vgasrc: round up save/restore size
* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info
* 163fd9f0 fix smbios blob length overflow
* 82faf1d5 Add LBA 64bit support for reads beyond 2TB.
* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code
* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes
* a6ed6b70 limit address space used for pci devices.
Signed-off-by: Leah Rowe <info@minifree.org>
was reported broken on canoeboot 0.1, which uses 2021
coreboot. we use much newer coreboot now in libreboot, but
still, better be cautious. set to release=n.
i'll set status and remove release=n if it works on testing
Signed-off-by: Leah Rowe <leah@libreboot.org>
Same idea as my never-download-microcode patch. Even if a
coreboot config enables blobs, the blobs are not actually
downloaded or inserted or otherwise handled in any way.
This means I can re-use lbmk-based coreboot configs without
as much modification, thus reducing the maintenance burden
for Canoeboot releases.
Signed-off-by: Leah Rowe <info@minifree.org>
With other recent changes, and this patch, Canoeboot is now
in sync with Libreboot lbmk, commit:
cd9685d12d2b71a00cb6766bb85f392d4db92c83
This is with updated deblobbing, and Canoeboot's no-microcode
patches, that disable microcode updates universally.
Several patches from lbmk (for coreboot) aren't needed,
due to being for boards that Canoeboot does not use, so
those patches have been somewhat rebased, and configs
adapted, but this is otherwise identical.
As in previous Canoeboot updates, I've turned off this
option in all coreboot configs:
CONFIG_USE_BLOBS
Turning off that option prevents the coreboot build system
from ever attempting to use any blobs, but in practise it
would not have done so anyway, because Canoeboot disables
all handling of microcode in the build system.
Signed-off-by: Leah Rowe <info@minifree.org>
it should be marked unstable, though these machines
are basically reliable; they have certain missing features
and quirky behaviour so it's important not to over-sell it
mark it as unstable, on all of the dell latitudes
Signed-off-by: Leah Rowe <leah@libreboot.org>
raminit has never been fully reliable on this board, and so
this board has never been stable. so, now that lbmk specifies
such status per board, mark these boards as such.
Signed-off-by: Leah Rowe <leah@libreboot.org>
export CBMK_VERSION_TYPE=x
x can be: stable, unstable
in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, cbmk defaults to "unknown"
if CBMK_VERSION_TYPE is set, no confirmation is asked
if the given target matches what's set (but what's set
in that environmental variable can only be stable or
unstable)
if CBMK_RELEASE="y", no confirmation is asked, unless
the target is something other than stable/unstable
"unstable" means it works, but has a few non-breaking
bugs, e.g. broken s3 on dell e6400
whereas, if raminit regularly fails or it is so absolutely
unreliable as to be unusable, then the board should be
declared "broken"
untested means: it has not been tested
With this change, it should now be easier to track whether
a given board is tested, in preparation for releases. When
working on trees/boards, status can be set for targets.
Also: in the board directory, you can add a "warn.txt" file
which will display a message. For example, if a board has a
particular quirk to watch out for, write that there. The message
will be printed during the build process, to stdout.
If status is anything *other* than stable, or it is unstable
but CBMK_VERSION_TYPE is not set to "unstable", and not building
a release, a confirmation is passed.
If the board is not specified as stable or unstable, during
a release build, the build is skipped and the ROM is not
provided in that release; this is in *addition* to
release="n" or release="y" that can be set in target.cfg,
which will skip the release build for that target if "n"
Signed-off-by: Leah Rowe <info@minifree.org>
GRUB has not pushed many patches to master since the recent 2.12
release, but there are a number of interesting fixes.
canoeboot is doing a release soon. bump to latest grub revision.
Some of the new patches in GRUB are interesting:
XFS fixes:
"fs/xfs: Handle non-continuous data blocks in directory extents"
68dd65cfdaad08b1f8ec01b84949b0bf88bc0d8c
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370
Apparently, XFS could not boot in some reports, though this was
likely with BIOS or UEFI GRUB; no such reports were made to canoeboot
"gfxmenu/view: Resolve false grub_errno disrupting boot process"
39c927df66c7ca62d97905d1385054ac9ce67209
"util/grub-fstest: Add a new command zfs-bootfs"
28c4405208cfb6e2cea737f6cbaf17e631bac6cd
The gnulib revision does not need to be updated at this time.
Signed-off-by: Leah Rowe <info@minifree.org>
see:
https://github.com/9elements/grub/commits/xhci-module-upstreaming-squash_v4/
grub only supports xhci on bios/uefi targets, but not coreboot.
some newer machines don't have ps/2 controllers, and boot in a
way where ehci isn't available at startup; the controller can't
be used by ehci code, there must be xhci support.
the code is from Patrick Rudolph working on behalf of 9elements.
the code was also sent here for review:
https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html
however, upstream never merged these patches. canoeboot will have
to maintain these from now on. the patches have been rebased for
use with grub 2.12.
Signed-off-by: Leah Rowe <info@minifree.org>
this merges the fix from:
https://codeberg.org/libreboot/pico-serprog/pulls/1
however, PRs are not to be sent there. riku merged it in
his repository, and i pulled it in the mirror hosted
on libreboot codeberg
Signed-off-by: Leah Rowe <leah@libreboot.org>
Riku introduced three new patches:
* Add support for multiple chip selects. This allows you to
control multiple chips from the same clip, on systems with
dual flash setups, at least theoretically.
* Enable pull-up on unused chip selects - pull them high so
that chips you connect that to are deactivated while flashing
the target chip. This could be used on thinkpad W541 for
instance, where miso/mosi have 0ohm between them via the two
flash ICs. You could pull the other chip select high.
* Documentation for the above, in the pico-serprog readme.
This goes in tandem with a patch from Riku, present in the
recently integrated flashprog project, namely:
commit ddb6d926783d4f9cbee04c7392718ed8f89daa0e
Author: Riku Viitanen <riku.viitanen@protonmail.com>
Date: Mon Jan 15 19:15:49 2024 +0200
serprog: Add support for multiple SPI chip selects
This functionality will therefore be present in the next
release of Libreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Nico Huber is the rightful project lead. I do not support
the coup that occured within the flashrom project. Nico
has always been of great service to the Libreboot project,
by virtue of his work on both coreboot and flashrom.
Nico Huber was unfairly removed from the flashrom project
infrastructure, due to unfounded accusations hurled at him
by flashrom's new project lead. The accusations are unfounded
because no evidence was given.
Use Nico Huber's fork, named flashprog. We will work with
flashprog from now on.
Signed-off-by: Leah Rowe <leah@libreboot.org>
these should be using the rdimm tree for crossgcc,
so define it explicitly. the build system creates
a symlink too, but it's still best that we use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
a tree can specify:
tree_depend="treename"
this will make the other tree be downloaded. this is
used for coreboot trees, to ensure that dependency
trees are downloaded, because trees can now re-use
crossgcc from other trees.
Signed-off-by: Leah Rowe <leah@libreboot.org>
let them specific it, rather than falling back
to coreboot/default (can also be used for coreboot boards)
Signed-off-by: Leah Rowe <leah@libreboot.org>
livio