<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lbmk.git, branch 20241206rev3</title>
<subtitle>libreboot build system (LibreBoot MaKe)
</subtitle>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/'/>
<entry>
<title>disable 3050micro nvme hotplug</title>
<updated>2024-12-11T01:11:08+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-11T01:11:08+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=3b6b283eabe7a655c861d1543aeae49d27566f53'/>
<id>3b6b283eabe7a655c861d1543aeae49d27566f53</id>
<content type='text'>
see patch for rationale. this should prevent instability caused
when the nvme randomly replugs under linux. sometimes e.g. nvme0n1
becomes nvme0n2 while the system is running.

in my case, that caused my raid1 to become unsynced every few days.
this issue was fixed on t480 by disabling pcie hotplug for its nvme
device, so the same fix has been applied for dell optiplex 3050 micro.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
see patch for rationale. this should prevent instability caused
when the nvme randomly replugs under linux. sometimes e.g. nvme0n1
becomes nvme0n2 while the system is running.

in my case, that caused my raid1 to become unsynced every few days.
this issue was fixed on t480 by disabling pcie hotplug for its nvme
device, so the same fix has been applied for dell optiplex 3050 micro.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fix t480 spd size (512, not 256)</title>
<updated>2024-12-10T23:48:41+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-10T23:45:59+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=c2023921893f8ee11a9a611469bb8350ef1692be'/>
<id>c2023921893f8ee11a9a611469bb8350ef1692be</id>
<content type='text'>
this was done with the following command:

./mk -u coreboot t480s_fsp_16mb t480_fsp_16mb

it was set to 256 but should be 512. the SPD is what
contains configuration data for raminit, which training
code uses so that the timings will be correct. if the SPD
size is wrong, the machine won't boot

in practise, lbmk always runs "make oldconfig" on
a coreboot config, before building it, so this was
already being corrected automatically at build time.

however, if that fact ever changes in the future, this
wrong configuration would cause the machines not to boot.

therefore, this can be considered a preventative or perhaps
pre-emptive bug fix.

this fix does not need to be applied to the 20241206 release,
because of the behaviour described above. the final ROM images
do have the spd size set correctly to 512, because of this
design feature in lbmk.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this was done with the following command:

./mk -u coreboot t480s_fsp_16mb t480_fsp_16mb

it was set to 256 but should be 512. the SPD is what
contains configuration data for raminit, which training
code uses so that the timings will be correct. if the SPD
size is wrong, the machine won't boot

in practise, lbmk always runs "make oldconfig" on
a coreboot config, before building it, so this was
already being corrected automatically at build time.

however, if that fact ever changes in the future, this
wrong configuration would cause the machines not to boot.

therefore, this can be considered a preventative or perhaps
pre-emptive bug fix.

this fix does not need to be applied to the 20241206 release,
because of the behaviour described above. the final ROM images
do have the spd size set correctly to 512, because of this
design feature in lbmk.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>add tarballs and signatures to gitignore</title>
<updated>2024-12-08T21:31:06+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-08T21:31:06+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=da527459b68f2e7a1e6a902fdb5b7d89e8b69dd6'/>
<id>da527459b68f2e7a1e6a902fdb5b7d89e8b69dd6</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>fix another very stupid mistake</title>
<updated>2024-12-08T18:24:57+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-08T18:24:57+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=b910424b5df8ed7c931a7b8f5cc8e34eacf0ca3e'/>
<id>b910424b5df8ed7c931a7b8f5cc8e34eacf0ca3e</id>
<content type='text'>
the last revision disabled building arm64 images!

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the last revision disabled building arm64 images!

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fix the stupidest bug ever</title>
<updated>2024-12-08T18:04:51+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-08T18:04:51+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=e3b77b132e6b5981c09bc1ce282afaae64058ab3'/>
<id>e3b77b132e6b5981c09bc1ce282afaae64058ab3</id>
<content type='text'>
no context given, but every rom needs to be re-built.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
no context given, but every rom needs to be re-built.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "vendor.sh: avoid unnecessary directory copy"</title>
<updated>2024-12-06T10:34:36+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-06T10:34:36+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=e80261dd5451c7a0d16e34b11bb3b7ce07364b51'/>
<id>e80261dd5451c7a0d16e34b11bb3b7ce07364b51</id>
<content type='text'>
Nope. It was correct before. fml

This reverts commit 2d96fe2a1d13486d3ea6577beedcf3b2babf6cab.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Nope. It was correct before. fml

This reverts commit 2d96fe2a1d13486d3ea6577beedcf3b2babf6cab.
</pre>
</div>
</content>
</entry>
<entry>
<title>Libreboot 20241206 release</title>
<updated>2024-12-06T10:06:38+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-06T10:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=ec581bde4753365df7c5509bce600ad6134693fe'/>
<id>ec581bde4753365df7c5509bce600ad6134693fe</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>vendor.sh: avoid unnecessary directory copy</title>
<updated>2024-12-06T01:53:44+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-06T01:53:44+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=2d96fe2a1d13486d3ea6577beedcf3b2babf6cab'/>
<id>2d96fe2a1d13486d3ea6577beedcf3b2babf6cab</id>
<content type='text'>
the previous commit changed an mv to a cp. what it hacked
was actually a relic of the vgarom download patch that i
did for t480, before mate got native video init working.

this patch is the better fix. i double checked to be sure,
and nothing was using the files at the copied location.
the _extracted directory under cache gets deleted later on,
so it's perfectly acceptable to keep.

the other alternative would have been to simply change
the path in the sch5545 function to appdir, instead of
the cache dir, but who really cares?

this patch removes bloat from lbmk.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the previous commit changed an mv to a cp. what it hacked
was actually a relic of the vgarom download patch that i
did for t480, before mate got native video init working.

this patch is the better fix. i double checked to be sure,
and nothing was using the files at the copied location.
the _extracted directory under cache gets deleted later on,
so it's perfectly acceptable to keep.

the other alternative would have been to simply change
the path in the sch5545 function to appdir, instead of
the cache dir, but who really cares?

this patch removes bloat from lbmk.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vendor.sh: fix minor release bug</title>
<updated>2024-12-06T01:24:35+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-06T01:24:35+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=2dc7c5fa7203b20c9251f72d99c4e4c7e07c4b72'/>
<id>2dc7c5fa7203b20c9251f72d99c4e4c7e07c4b72</id>
<content type='text'>
I should have copied the extract directory, in cases
where it appears as filename_extracted/ under cache/,
but I was moving it instead.

Both locations (cache/file/*_extracted/
and vendorfiles/appdir/) get deleted, on every run of
the vendor script, per target, so this is OK.

The only sin is additional use of disk space, for
archives that are mostly very small and get immediately
deleted anyway.

This one lbmk bug, minor though it may be, prevented
the Libreboot 20241205 release, which (since it's now
the 6th of December) will become Libreboot 20241206
instead - and that gives me time to contemplate whether
I want to do one more change that I had planned for the 5th!

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I should have copied the extract directory, in cases
where it appears as filename_extracted/ under cache/,
but I was moving it instead.

Both locations (cache/file/*_extracted/
and vendorfiles/appdir/) get deleted, on every run of
the vendor script, per target, so this is OK.

The only sin is additional use of disk space, for
archives that are mostly very small and get immediately
deleted anyway.

This one lbmk bug, minor though it may be, prevented
the Libreboot 20241205 release, which (since it's now
the 6th of December) will become Libreboot 20241206
instead - and that gives me time to contemplate whether
I want to do one more change that I had planned for the 5th!

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Libreboot 20241205 release</title>
<updated>2024-12-05T23:45:01+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-05T23:45:01+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=56b35bd9d8d6189c6bf905716bf8f946a6c88a0f'/>
<id>56b35bd9d8d6189c6bf905716bf8f946a6c88a0f</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>
