there are only two scripts under script/ now, and there
probably won't be many more. lbmk'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>
stub it from the main build script
the commands remain identical:
./vendor download arguments_here
./vendor inject arguments_here
Signed-off-by: Leah Rowe <leah@libreboot.org>
the main script isn't that big, and since the main
purpose of lbmk 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 lbmk is used shall remain unchanged
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>
this is a follow-up to the previous commit
again, there's no posix way to check the path to the
file at argument 0, because readlink (utility) isn't
defined in posix (the C function is defined, but not
the utility included on many unices)
check whether "build" (file) exists, and whether it
is a symlink; if the latter, then we are definitely
not in the lbmk work directory!
Signed-off-by: Leah Rowe <leah@libreboot.org>
there's no portable(posix) way to check when running
from a symlink to lbmk in the current work directory
for example:
ln -s lbmk/build lbmktest
./lbmktest roms list
this would pass the new test, and first try to
include option.sh. in practise, the user probably doesn't
happen to have include/option.sh in their current path
i can use readlink here, but again not portable
the current check will suffice. it also works when
the symlink is called from $PATH
e.g. /usr/bin/lbmktest exists and you do:
lbmktest roms list
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>
i replaced 2022, 2023 with 2022, 2024 when updating
the years, as per modifications, but the 2023 copyright
doesn't become invalidated
change it to 2022-2024 instead, which is correct
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>
I'm on a schedule here and don't have time to do the
release changelog before actually compiling the release.
I'm pushing the release changelog / news announcement
*while the release is building*. Therefore, the actual
release archive will contain Libreboot documentation, but
from the lbwww revision just before the release announcement.
(a changelog file is still generated from Git, and included
in releases)
Signed-off-by: Leah Rowe <leah@libreboot.org>
Angel Pons told me I should do it. See comments here:
https://review.coreboot.org/c/coreboot/+/81016
I see no harm in complying with the request. I'll merge
this into the main patch at a later date and try to
get this upstreamed.
Just a reminder: on Optiplex 9020 variants, Xorg locks up
under Linux when tested with a graphics card; disabling
IOMMU works around the issue. Intel graphics work just fine
with IOMMU turned on. Libreboot disables IOMMU by default,
on the 9020, so that users can install graphics cards easily.
I'm pretty sure this is the correct way to do it. The machine
still seems to boot, in this configuration.
Signed-off-by: Leah Rowe <leah@libreboot.org>
NRI is libre raminit
MRC is binary blob raminit
the libre raminit is stable enough now that it's default
the MRC-based targets will be removed in a future release
Signed-off-by: Leah Rowe <leah@libreboot.org>
i initially decided to say unstable, but the default
configuration is reliable; the only caveat is that if
you enable IOMMU, you must only be using intel graphics.
this is already documented in warn.txt files, and on
the website, so it's more than ok to call this stable.
i use one of these myself as my daily driver and it's
rock solid. i haven't had any problems with it. i also
sell these to people with libreboot. no problems.
mark it as stable, ready for a full release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
nitrocaster boards are hard to find nowadays and i'm not
comfortable supporting the knockoff chinese gear; quality
varies greatly, and i can't know how reliable they are.
nitrocaster has been out of business so it's just not
viable to support this mod anymore. in fact, keeping the
eDP-based targets is a liability to libreboot.
regular x220/x230 (non-eDP-modded) are retained. the eDP
modkit from nitrocaster let you use eDP screens instead
of lvds, on thinkpad x220 and x230, letting you use
higher resolution screens.
older lbmk revs can still be used, if you happen to come
across one of these boards. i only recommend using the
official nitrocaster board, if youcan find one unused.
ymmv with the chinese gear. better just use an unmodded
x230 or get a different machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
angel pons said how to fix it. more info in the patch.
works perfectly. i still see that scancode in dmesg and i guess
i have to assign it to some function that sets software rfkill
hw rfkill is no longer set. it's unblocked, and i can use wifi.
just in time for the libreboot release.
Signed-off-by: Leah Rowe <leah@libreboot.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>
Use shell scripting in the recipe instead of GNU make's
conditional syntax. This allows the Makefile to work with
the default implementations of make on the BSDs.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Add FreeBSD to the README as it is now supported. Make a note about
using gmake instead of make as the makefile currently uses GNU
extensions to determine build flags based on the OS.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
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>
Leah Rowe