<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lbmk.git/config/coreboot/t440pmrc_12mb, branch 20240504</title>
<subtitle>libreboot build system (LibreBoot MaKe)
</subtitle>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/'/>
<entry>
<title>remove x220edp/x230edp (keep regular x220/x230)</title>
<updated>2024-05-03T22:46:27+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-05-03T22:00:27+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=780e03fe1e6222d353f56d14b003efc70dc4e975'/>
<id>780e03fe1e6222d353f56d14b003efc70dc4e975</id>
<content type='text'>
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 &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>build/roms: report status when building images</title>
<updated>2024-04-26T19:36:42+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-04-26T18:41:00+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=ce7fd754a3d831c563a8589f1cc35e55ce027814'/>
<id>ce7fd754a3d831c563a8589f1cc35e55ce027814</id>
<content type='text'>
export LBMK_VERSION_TYPE=x
x can be: stable, unstable

in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, lbmk defaults to "unknown"

if LBMK_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 LBMK_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 LBMK_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 &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
export LBMK_VERSION_TYPE=x
x can be: stable, unstable

in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, lbmk defaults to "unknown"

if LBMK_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 LBMK_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 LBMK_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 &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>haswell: only provide NRI-based ROMs in releases</title>
<updated>2024-04-24T04:27:27+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-04-24T04:27:27+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=ed0678ae2e9b58b3eb9a7606816e21ad8798192e'/>
<id>ed0678ae2e9b58b3eb9a7606816e21ad8798192e</id>
<content type='text'>
release="n" is set in target.cfg on haswell build targets
that use mrc.bin

script/update/release exports LBMK_RELEASE="y"

script/build/roms skips building a given target if release="n"
in target.cfg *and* LBMK_RELEASE="y"

you could also do the export yourself before running ./build roms,
for example:

export LBMK_RELEASE="y"
./build roms all

This would skip these ROM images. The native haswell raminit is
now stable enough in my testing, that I wish to delete the MRC-based
targets. This is in line with Libreboot's Binary Blob Reduction Policy,
which states: if a blob can be avoided, it should be avoided.

The problem is that users often run the inject script in *lbmk* from
Git, instead of from the src release archive. I forsee some users
running this on modern lbmk with older release images. If the mrc-based
target isn't there, the user may use an NRI-based target name, and
think it works; they will insert without MRC. I foresaw this ages
ago, which is why Caleb and I ensured that the script checks hashes,
and hashes are included in releases.

Therefore: for the time being, keep the MRC-based configs in lbmk
but do not include images for them in releases. This can be done
indefinitely, but I'll probably remove those configs entirely at
some point.

On the following boards, Libreboot now will *only* provide NRI-based
ROM images for the following machines:

* Dell OptiPlex 9020 SFF
* Dell OptiPlex 9020 MT
* Lenovo ThinkPad T440p
* Lenovo ThinkPad W541/W540

I now recommend exclusive use of NRI-based images, on Haswell
hardware. It's stable enough in my testing, and now supports S3.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
release="n" is set in target.cfg on haswell build targets
that use mrc.bin

script/update/release exports LBMK_RELEASE="y"

script/build/roms skips building a given target if release="n"
in target.cfg *and* LBMK_RELEASE="y"

you could also do the export yourself before running ./build roms,
for example:

export LBMK_RELEASE="y"
./build roms all

This would skip these ROM images. The native haswell raminit is
now stable enough in my testing, that I wish to delete the MRC-based
targets. This is in line with Libreboot's Binary Blob Reduction Policy,
which states: if a blob can be avoided, it should be avoided.

The problem is that users often run the inject script in *lbmk* from
Git, instead of from the src release archive. I forsee some users
running this on modern lbmk with older release images. If the mrc-based
target isn't there, the user may use an NRI-based target name, and
think it works; they will insert without MRC. I foresaw this ages
ago, which is why Caleb and I ensured that the script checks hashes,
and hashes are included in releases.

Therefore: for the time being, keep the MRC-based configs in lbmk
but do not include images for them in releases. This can be done
indefinitely, but I'll probably remove those configs entirely at
some point.

On the following boards, Libreboot now will *only* provide NRI-based
ROM images for the following machines:

* Dell OptiPlex 9020 SFF
* Dell OptiPlex 9020 MT
* Lenovo ThinkPad T440p
* Lenovo ThinkPad W541/W540

I now recommend exclusive use of NRI-based images, on Haswell
hardware. It's stable enough in my testing, and now supports S3.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>add 9020 sff/mt targets that use broadwell mrc</title>
<updated>2024-04-06T00:28:10+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-04-05T22:53:03+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=4134a883d0d8dd4020f2ddca7416e0b9f82b8843'/>
<id>4134a883d0d8dd4020f2ddca7416e0b9f82b8843</id>
<content type='text'>
broadwell mrc has better peg handling and can support 16gb
modules on broadwell machines - the blob can be used on haswell
machines too, instead of haswell mrc, and it might support 16gb
modules on these machines (not yet tested, but using broadwell
mrc does at least boot as reliably as haswell mrc anyway)

one little quirk with haswell mrc is that it actually handles
vga decode, disabling the igpu entirely, when a dgpu is used.
the broadwell mrc enables both GPUs and does not handle vga
decoding, so we must handle this the usual way; my patch for
this was merged upstream and i'm also adding it to libreboot,
which currently uses an older coreboot revision. this is needed
for dgpu to work. see patch:

0040-nb-haswell-Disable-iGPU-when-dGPU-is-used.patch

broadwell mrc may also make dealing with nvidia optimus setups
more reliable, on laptops that have nvidia GPUs, but this patch
does not add bmrc configs for t440p/w541

NOTE: on t440p/w541 laptops with nvidia graphics, the video output
is wired to intel but rendering can be offloaded to nvidia. in this
setup, we want vga decode to be done on intel, so i've set these
configs to enable CONFIG_ONBOARD_VGA_IS_PRIMARY (set it to y)

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
broadwell mrc has better peg handling and can support 16gb
modules on broadwell machines - the blob can be used on haswell
machines too, instead of haswell mrc, and it might support 16gb
modules on these machines (not yet tested, but using broadwell
mrc does at least boot as reliably as haswell mrc anyway)

one little quirk with haswell mrc is that it actually handles
vga decode, disabling the igpu entirely, when a dgpu is used.
the broadwell mrc enables both GPUs and does not handle vga
decoding, so we must handle this the usual way; my patch for
this was merged upstream and i'm also adding it to libreboot,
which currently uses an older coreboot revision. this is needed
for dgpu to work. see patch:

0040-nb-haswell-Disable-iGPU-when-dGPU-is-used.patch

broadwell mrc may also make dealing with nvidia optimus setups
more reliable, on laptops that have nvidia GPUs, but this patch
does not add bmrc configs for t440p/w541

NOTE: on t440p/w541 laptops with nvidia graphics, the video output
is wired to intel but rendering can be offloaded to nvidia. in this
setup, we want vga decode to be done on intel, so i've set these
configs to enable CONFIG_ONBOARD_VGA_IS_PRIMARY (set it to y)

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>coreboot/default: update coreboot to January 2024</title>
<updated>2024-01-25T15:41:15+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-01-25T15:24:02+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=4a6dc5553f2a15542f730ca735fb8bf95fb8f49b'/>
<id>4a6dc5553f2a15542f730ca735fb8bf95fb8f49b</id>
<content type='text'>
Base revision changed to:

commit b6cbfa977f63d57d5d6b9e9f7c1cef30162f575a
Author: Morris Hsu &lt;morris-hsu@quanta.corp-partner.google.com&gt;
Date:   Fri Jan 5 16:48:17 2024 +0800

    mb/google/dedede/var/metaknight:Add fw_config probe for multi codec
    and amplifier

Of note:

Several out-of-tree ports have been adjusted to use the new SPD config
style, where it is defined in devicetree. I manually updated the E6530
patch myself, based on the update that Nicholas did on E6430 (Nicholas
will later update the E6530 patch himself, and I'll re-merge the patch).

Several upstream patches now exist in this revision, that we were able
to remove from lbmk.

The heap size patch was reverted upstream, as we did, but see:
https://review.coreboot.org/c/coreboot/+/80023
https://review.coreboot.org/c/coreboot/+/79525
Although we still disable the TSEG Stage Cache, ivy/sandy/haswell should
be reliable on S3 now (leaving TSEG Stage Cache disabled, for now, anyway).

Also included in upstream now:

commit 29030d0f3dad2ec6b86000dfe2c8e951ae80bf94
Author: Bill Xie &lt;persmule@hardenedlinux.org&gt;
Date:   Sat Oct 7 01:32:51 2023 +0800

    drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume

Further patches from upstream:

commit 432e92688eca0e85cbaebca3232f65936b305a98
Author: Bill Xie &lt;persmule@hardenedlinux.org&gt;
Date:   Fri Nov 3 12:34:01 2023 +0800

    drivers/pc80/rtc/option.c: Reset only CMOS range covered by checksum

This should fix S3 on GM45 thinkpads.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Base revision changed to:

commit b6cbfa977f63d57d5d6b9e9f7c1cef30162f575a
Author: Morris Hsu &lt;morris-hsu@quanta.corp-partner.google.com&gt;
Date:   Fri Jan 5 16:48:17 2024 +0800

    mb/google/dedede/var/metaknight:Add fw_config probe for multi codec
    and amplifier

Of note:

Several out-of-tree ports have been adjusted to use the new SPD config
style, where it is defined in devicetree. I manually updated the E6530
patch myself, based on the update that Nicholas did on E6430 (Nicholas
will later update the E6530 patch himself, and I'll re-merge the patch).

Several upstream patches now exist in this revision, that we were able
to remove from lbmk.

The heap size patch was reverted upstream, as we did, but see:
https://review.coreboot.org/c/coreboot/+/80023
https://review.coreboot.org/c/coreboot/+/79525
Although we still disable the TSEG Stage Cache, ivy/sandy/haswell should
be reliable on S3 now (leaving TSEG Stage Cache disabled, for now, anyway).

Also included in upstream now:

commit 29030d0f3dad2ec6b86000dfe2c8e951ae80bf94
Author: Bill Xie &lt;persmule@hardenedlinux.org&gt;
Date:   Sat Oct 7 01:32:51 2023 +0800

    drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume

Further patches from upstream:

commit 432e92688eca0e85cbaebca3232f65936b305a98
Author: Bill Xie &lt;persmule@hardenedlinux.org&gt;
Date:   Fri Nov 3 12:34:01 2023 +0800

    drivers/pc80/rtc/option.c: Reset only CMOS range covered by checksum

This should fix S3 on GM45 thinkpads.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>update/trees: further simplify crossgcc handling</title>
<updated>2023-12-27T16:07:32+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2023-12-27T15:18:21+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=eff9130b7ab9ce79338ae6b1ec5c2f18bad5b5ec'/>
<id>eff9130b7ab9ce79338ae6b1ec5c2f18bad5b5ec</id>
<content type='text'>
arch no longer needs to be set, on multi-tree projects,
and it has been renamed to xarch

the new behaviour is: if xarch is set, treat it as a
list of crossgcc targets and go through the list. set
the first one as the target, for what lbmk builds, but
build all of the defined crossgccc targets

crossgcc_ada is now xlang, and defines which languages
to build, rather than whether to build gcc-gnat

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
arch no longer needs to be set, on multi-tree projects,
and it has been renamed to xarch

the new behaviour is: if xarch is set, treat it as a
list of crossgcc targets and go through the list. set
the first one as the target, for what lbmk builds, but
build all of the defined crossgccc targets

crossgcc_ada is now xlang, and defines which languages
to build, rather than whether to build gcc-gnat

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>build/roms: remove modify_coreboot_rom()</title>
<updated>2023-12-21T19:26:22+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2023-12-21T19:03:49+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=92986f0c421447f74f18ee061a689950af599e86'/>
<id>92986f0c421447f74f18ee061a689950af599e86</id>
<content type='text'>
don't handle "romtype" at all, in board target.cfg files

add /dev/null as pike2008 rom on amd boards. this serves
the same purpose, adding them as empty vga roms, to add
an empty rom in cbfs. pike2008 cards cause seabios to hang,
when their oproms are executed, so we insert a fake rom

on i945 thinkpads, use the coreboot config option:
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK

when set, this enables the same bootblock copy, for use
with bucts. these two cases, namely pike2008 roms and
i945 bootblock copies, no longer need to be handled in code

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
don't handle "romtype" at all, in board target.cfg files

add /dev/null as pike2008 rom on amd boards. this serves
the same purpose, adding them as empty vga roms, to add
an empty rom in cbfs. pike2008 cards cause seabios to hang,
when their oproms are executed, so we insert a fake rom

on i945 thinkpads, use the coreboot config option:
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK

when set, this enables the same bootblock copy, for use
with bucts. these two cases, namely pike2008 roms and
i945 bootblock copies, no longer need to be handled in code

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>update coreboot configs</title>
<updated>2023-12-21T14:18:58+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2023-12-21T13:46:58+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=3ccf194169de153350f3c7294ded0e274ed95a42'/>
<id>3ccf194169de153350f3c7294ded0e274ed95a42</id>
<content type='text'>
the x220 edp patch invalidated lots of configs, so
i did: ./update trees -u coreboot

this is the resulting patch

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the x220 edp patch invalidated lots of configs, so
i did: ./update trees -u coreboot

this is the resulting patch

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>update/trees: simplified crossgcc handling</title>
<updated>2023-12-21T14:18:51+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2023-12-21T10:48:07+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=90ac30b163b47769695ba247b2d5cb7c43226815'/>
<id>90ac30b163b47769695ba247b2d5cb7c43226815</id>
<content type='text'>
only call crossgcc for coreboot and u-boot, but use
hostcc for everything else. simplify the checking of
which architecture to compile for. "arch" in target.cfg
files has been modified, to allow further simplification.

without this patch, the logic currently only *barely* avoids
using crossgcc on things like utils, and only works in practise
because, in practise, lbmk only works on x86_64 anyway.

the new logic, as per this patch, is simpler and more robust.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
only call crossgcc for coreboot and u-boot, but use
hostcc for everything else. simplify the checking of
which architecture to compile for. "arch" in target.cfg
files has been modified, to allow further simplification.

without this patch, the logic currently only *barely* avoids
using crossgcc on things like utils, and only works in practise
because, in practise, lbmk only works on x86_64 anyway.

the new logic, as per this patch, is simpler and more robust.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "coreboot/default: use alternative heap size fix"</title>
<updated>2023-10-31T20:08:03+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2023-10-31T20:04:40+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=1306c9d2e36d1760ebb79020aec305bf5b4bc7ad'/>
<id>1306c9d2e36d1760ebb79020aec305bf5b4bc7ad</id>
<content type='text'>
This reverts commit 29e9c32e32f8e947f51a3efe375dab3ef8e1987e.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 29e9c32e32f8e947f51a3efe375dab3ef8e1987e.
</pre>
</div>
</content>
</entry>
</feed>
