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>
The E6400 uses a 100 MHz reference clock on DPLL_REF_SSCLK, whereas
libgfxinit assumed that the reference was always 96 MHz. The frequency
difference caused by a 100 MHz reference with PLL config values
calculated assuming a 96 MHz reference were not significant enough to
cause noticable issues with the more common 1280 x 800 panels, but are
enough to matter for the 1440 x 900 panels which use a higher pixel
clock. This only affected the pre-OS graphics environment provided by
libgfxinit, as Linux drivers would determine the reference clock
frequency based on data in the VBT.
Fix this by making the reference clock frequency in libgfxinit
configurable for GM45 based on a new coreboot Kconfig, which is set to
100 MHz for the E6400.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
for single-tree project (e.g. flashprog):
config/submodule/PROJECT/MODNAME/patches
for multi-tree project (e.g. coreboot):
config/submodule/PROJECT/TREE/MODNAME/patches
MODNAME is e.g.:
3rdparty/vboot directory in coreboot: would become vboot
(the submodule codepath is filtered to up to the final slash)
another example:
submodire src dir 3rdparty/foo/bar
MODNAME would be "bar"
Add whatever patches you like to a given submodule.
An example patch is included in this commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc is retained, because it's needed on 820 g2
it's no longer needed on haswell, because nri is stable. nri
is short for "native ram initialisation", and libreboot provides
this for: thinkpad t440p, thinkpad w541, dell optiplex 9020 mt,
and dell optiplex 9020 sff
remove, in line with libreboot's binary blob reduction policy
previous revisions, prior to the recent release, stated that
it would be retained for compatibility, but it's really not
right to retain it, because doing so violates libreboot's policy
the recent release excluded mrc-based rom images for haswell
machines, providing only those rom images that use the libre
raminit, while retaining support for mrc in the build system, so
that users could still run the lbmk inject script on older release
roms that use mrc
again: libreboot's binary blob reduction policy is very clear:
https://libreboot.org/news/policy.html
it is a policy that can be summarised, thus:
if a blob can be avoided, it must be avoided.
therefore, we will avoid the Haswell MRC raminit blob
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 lbmk 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>
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>
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>
set to release="n" for now until the eDP targets
are fixed.
the regular non-eDP targets are stable, and will be
released.
Signed-off-by: Leah Rowe <leah@libreboot.org>
some latitudes still used the old style for variables
in target.cfg, specifically arch="x86_64" - lbmk used to
then check that on a big if/else and translate it to the
correct target name for crossgcc, e.g. i386-elf, arm-eabi
now it just puts the arch directly, in a new variable:
xarch
change arch="x86_64" to xarch="i386-elf" in these files.
also remove a few obsolete variables. should build now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
github is unreliable. i host these files myself.
coreboot uses intel.com again now in the latest revisions, and
intel broke it before. i'm going to start backing up the acpica
releases onto my rsync server from now on, and keep patching
coreboot to use my files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe