<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lbmk.git/config/vendor/sources, branch 20241205</title>
<subtitle>libreboot build system (LibreBoot MaKe)
</subtitle>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/'/>
<entry>
<title>lib.sh: more unified config handling</title>
<updated>2024-06-22T12:44:27+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-06-22T01:35:25+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=fc7ae3e5903c176584cfefd6d3cf4c1549c4eaaa'/>
<id>fc7ae3e5903c176584cfefd6d3cf4c1549c4eaaa</id>
<content type='text'>
replace it with logic that simply uses "." to load
files directly. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources

config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash

this change results in a noticeable reduction in code
complexity within the build system.

unified reading of config files: new function setcfg()
added to lib.sh

setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.

there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
replace it with logic that simply uses "." to load
files directly. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources

config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash

this change results in a noticeable reduction in code
complexity within the build system.

unified reading of config files: new function setcfg()
added to lib.sh

setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.

there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>do not allow dashes in coreboot target names</title>
<updated>2024-05-29T02:15:25+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-05-29T02:15:25+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=e7cb10d68b46bd4efb9a87c36d337f8a4fe1e24c'/>
<id>e7cb10d68b46bd4efb9a87c36d337f8a4fe1e24c</id>
<content type='text'>
Command: ./vendor download kcma-d8-rdimm_16mb

Output was:

include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory

That will have to be audited later on, but the recent
more stringent error checking in vendor.sh triggered
this previously untriggered error message. The error
was in fact already occuring before, silently.

Anyway, mitigate by renaming all coreboot targets so
that they do not contain hyphens in the name. This
should avoid triggering errors in that eval command,
on line 115 in lib.sh

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Command: ./vendor download kcma-d8-rdimm_16mb

Output was:

include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory

That will have to be audited later on, but the recent
more stringent error checking in vendor.sh triggered
this previously untriggered error message. The error
was in fact already occuring before, silently.

Anyway, mitigate by renaming all coreboot targets so
that they do not contain hyphens in the name. This
should avoid triggering errors in that eval command,
on line 115 in lib.sh

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>remove haswell mrc blob (libre raminit stable now)</title>
<updated>2024-05-11T18:12:11+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-05-11T18:03:26+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=cc33974150d275140fced9cfa4b8e901b0552074'/>
<id>cc33974150d275140fced9cfa4b8e901b0552074</id>
<content type='text'>
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 &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<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>add 9020sff/mt configs using haswell NRI</title>
<updated>2024-04-20T21:54:34+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-04-20T21:22:22+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=ac7ce93005ca7d8eccec5052d2e459514af70f39'/>
<id>ac7ce93005ca7d8eccec5052d2e459514af70f39</id>
<content type='text'>
Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>add t440p/w541 configs using broadwell mrc</title>
<updated>2024-04-06T01:09:04+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-04-06T01:09:04+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=e9c591a5547f48b2fce3337a502e87da6833d6d5'/>
<id>e9c591a5547f48b2fce3337a502e87da6833d6d5</id>
<content type='text'>
broadwell mrc enables both igpu and dgpu to be enabled
at any given time. if the onboard (intel) gpu is set as
primary, the logic to disable it is not executed within
coreboot; instead, the igpu is used for vga decode.

on some t440p/w541 thinkpads, both an intel and nvidia
gpu are present. in this setup, the intel gpu must be
used for vga, and all output, but rendering can be
offloaded to the nvidia gpu (nvidia optimus).

optimus would never work on haswell mrc.bin, because it
always disables the igpu when a dgpu is present, so a hack
exists in coreboot that hides the dgpu from mrc, so that the
igpu remains enabled. broadwell mrc doesn't do this, so the
option to hide PEG devices has been disabled in these
configs.

the broadwell mrc has better peg device handling, and can
support 16gb modules on broadwell hardware; it may well
support these modules on haswell hardware too, though ddr3
sodimms are very hard to find (and expensive). (and currently
untested, with this patch)

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 enables both igpu and dgpu to be enabled
at any given time. if the onboard (intel) gpu is set as
primary, the logic to disable it is not executed within
coreboot; instead, the igpu is used for vga decode.

on some t440p/w541 thinkpads, both an intel and nvidia
gpu are present. in this setup, the intel gpu must be
used for vga, and all output, but rendering can be
offloaded to the nvidia gpu (nvidia optimus).

optimus would never work on haswell mrc.bin, because it
always disables the igpu when a dgpu is present, so a hack
exists in coreboot that hides the dgpu from mrc, so that the
igpu remains enabled. broadwell mrc doesn't do this, so the
option to hide PEG devices has been disabled in these
configs.

the broadwell mrc has better peg device handling, and can
support 16gb modules on broadwell hardware; it may well
support these modules on haswell hardware too, though ddr3
sodimms are very hard to find (and expensive). (and currently
untested, with this patch)

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>config: Add Dell Latitude E5420</title>
<updated>2024-03-05T01:28:58+00:00</updated>
<author>
<name>Nicholas Chin</name>
<email>nic.c3.14@gmail.com</email>
</author>
<published>2024-03-05T01:17:21+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=036bf2c69a64c7a3bfdcfde3139ae2285e790a5b'/>
<id>036bf2c69a64c7a3bfdcfde3139ae2285e790a5b</id>
<content type='text'>
Signed-off-by: Nicholas Chin &lt;nic.c3.14@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Nicholas Chin &lt;nic.c3.14@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>config/vendor: fix entry for 9020sff</title>
<updated>2024-02-23T12:30:41+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-02-23T12:30:41+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=35e5464a5dd74f1f5933087d33056684a93e1acc'/>
<id>35e5464a5dd74f1f5933087d33056684a93e1acc</id>
<content type='text'>
the current entry is fine, but it would then not support
other configs of different flash sizes, unless they are
explicitly defined.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the current entry is fine, but it would then not support
other configs of different flash sizes, unless they are
explicitly defined.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NEW BOARD: dell 9020 optiplex sff</title>
<updated>2024-02-18T13:59:23+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-02-18T13:59:23+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=0add5571c053737289bddb33f84a7e187d5bbca1'/>
<id>0add5571c053737289bddb33f84a7e187d5bbca1</id>
<content type='text'>
Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
