<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lbmk.git/config/ifd, branch 25.04rev1</title>
<subtitle>libreboot build system (LibreBoot MaKe)
</subtitle>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/'/>
<entry>
<title>ifd/q45t_am: unlock regions by default</title>
<updated>2025-04-22T02:25:51+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2025-04-22T02:25:51+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=4b7ab403c6549f22e8436ecdee89c48effba2279'/>
<id>4b7ab403c6549f22e8436ecdee89c48effba2279</id>
<content type='text'>
i used ifdtool --unlock to do this

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
i used ifdtool --unlock to do this

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>coreboot/g43t_am3: use ifd-based setup</title>
<updated>2025-04-22T02:24:38+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2025-04-22T02:24:38+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=564155277ea9d4ffab7287702bdd4868c0df0bdc'/>
<id>564155277ea9d4ffab7287702bdd4868c0df0bdc</id>
<content type='text'>
no-ME setup. with a gbe file. we previously made this
a descriptorless setup.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
no-ME setup. with a gbe file. we previously made this
a descriptorless setup.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>coreboot/q45t_am3: use ifd-based setup</title>
<updated>2025-04-22T01:44:33+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2025-04-22T01:43:27+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=0ddd19637519d95ab02a29d2b3ec5d16de3cbdf3'/>
<id>0ddd19637519d95ab02a29d2b3ec5d16de3cbdf3</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>restore old x230 gbe file</title>
<updated>2025-01-29T04:17:07+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2025-01-29T04:17:07+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=6b9cf09ca21987363ad11b8396aa4a9ba19a6ee3'/>
<id>6b9cf09ca21987363ad11b8396aa4a9ba19a6ee3</id>
<content type='text'>
i accidentally committed one where i'd changed
the mac address, on a previous revision to nvmutil

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
i accidentally committed one where i'd changed
the mac address, on a previous revision to nvmutil

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>util/nvmutil: Only read up to 4KB on larger gbe</title>
<updated>2025-01-29T03:41:55+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2025-01-29T03:41:55+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=b1d8975959dc942bb8691253f3599e4ac99932eb'/>
<id>b1d8975959dc942bb8691253f3599e4ac99932eb</id>
<content type='text'>
On the 16KB and 128KB files, we still only need to
operate on 4KB at the start of each block, where the
block size is larger than 4KB.

The reason we deal with the entire 4KB block is because
the nvm words (in the 128 byte section) can define an
extended nvm area anywhere after 128 bytes, within the
128 byte block.

We could systematically read where that is being handled,
and handle it; we could then allocate less memory, and
read/write fewer bytes, but many block devices like SSDs
and flash drives have at least a 4KB erase block anyway,
so it's kinda pointless. saving memory would be nice, but
I don't really want to bloat the code.

This is a nice easy optimisation, to avoid wasting an
additional 8KB of memory when handling 16KB files, and
additional 120KB if handling 128KB files, since nf is
what determines how much memory will be allocated.

the alternative would be to use an mmap, and then we
could reasonably handle the idea above for only writing,
surgically, what we need: nvm words and extended nvm
words.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On the 16KB and 128KB files, we still only need to
operate on 4KB at the start of each block, where the
block size is larger than 4KB.

The reason we deal with the entire 4KB block is because
the nvm words (in the 128 byte section) can define an
extended nvm area anywhere after 128 bytes, within the
128 byte block.

We could systematically read where that is being handled,
and handle it; we could then allocate less memory, and
read/write fewer bytes, but many block devices like SSDs
and flash drives have at least a 4KB erase block anyway,
so it's kinda pointless. saving memory would be nice, but
I don't really want to bloat the code.

This is a nice easy optimisation, to avoid wasting an
additional 8KB of memory when handling 16KB files, and
additional 120KB if handling 128KB files, since nf is
what determines how much memory will be allocated.

the alternative would be to use an mmap, and then we
could reasonably handle the idea above for only writing,
surgically, what we need: nvm words and extended nvm
words.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NEW MAINBOARD: ThinkPad T480S</title>
<updated>2024-12-02T05:57:34+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T02:01:09+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=c1b73269726a00255aa31ec02b3e55d281b397e6'/>
<id>c1b73269726a00255aa31ec02b3e55d281b397e6</id>
<content type='text'>
Added t480s delta to deguard, for MFS config.

Updated coreboot/next to latest t480 patch set,
which includes t480s. This porting was done by
Mate Kukri.

also includes experimental t480s support

Also added a data.vbt file (not in the gerrit patch)
for the T480s.

I had to turn on 8254 legacy timer on t480s, otherwise
SeaBIOS would hang. Same issue I saw on OptiPlex 3050 Micro.

Minor issue:

On S3 resume, nvme0n1 for example got renamed to nvme0n2.
This caused a crash if running Linux from the nvme. I confirmed
this via live USB distro. So this port will need some tweaking
before it can be considered stable.

Also uses libgfxinit, which Mate recently fixed. I'm
going to enable libgfxinit on regular T480 next.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added t480s delta to deguard, for MFS config.

Updated coreboot/next to latest t480 patch set,
which includes t480s. This porting was done by
Mate Kukri.

also includes experimental t480s support

Also added a data.vbt file (not in the gerrit patch)
for the T480s.

I had to turn on 8254 legacy timer on t480s, otherwise
SeaBIOS would hang. Same issue I saw on OptiPlex 3050 Micro.

Minor issue:

On S3 resume, nvme0n1 for example got renamed to nvme0n2.
This caused a crash if running Linux from the nvme. I confirmed
this via live USB distro. So this port will need some tweaking
before it can be considered stable.

Also uses libgfxinit, which Mate recently fixed. I'm
going to enable libgfxinit on regular T480 next.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NEW MAINBOARD: ThinkPad T480</title>
<updated>2024-12-01T23:51:20+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-01T05:45:06+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=264928c6cdefb0b7a3c3ff01d4fe16fa4cc3cbd8'/>
<id>264928c6cdefb0b7a3c3ff01d4fe16fa4cc3cbd8</id>
<content type='text'>
This uses the excellent deguard utility, written by
the excellent Mate Kukri.

A few bugs but it mostly works. Documentation to come
shortly, in lbwww.git.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This uses the excellent deguard utility, written by
the excellent Mate Kukri.

A few bugs but it mostly works. Documentation to come
shortly, in lbwww.git.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rom.sh: Support SeaUBoot for 64-bit x86 U-Boot</title>
<updated>2024-11-21T12:29:05+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-11-21T12:29:05+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=7d1fd1cc6a176d15d8a938cd0df9868cbbb86d8f'/>
<id>7d1fd1cc6a176d15d8a938cd0df9868cbbb86d8f</id>
<content type='text'>
Same concept as SeaGRUB, but for U-Boot. SeaBIOS starts, but
has a bootorder file loading U-Boot first, from flash.

You can interrupt it with the ESC menu, to boot something else
in SeaBIOS, including GRUB.

With this, we can effectively provide extremely user-friendly
UEFI-first setups in Libreboot.

Take that, edk2!

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Same concept as SeaGRUB, but for U-Boot. SeaBIOS starts, but
has a bootorder file loading U-Boot first, from flash.

You can interrupt it with the ESC menu, to boot something else
in SeaBIOS, including GRUB.

With this, we can effectively provide extremely user-friendly
UEFI-first setups in Libreboot.

Take that, edk2!

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NEW MAINBOARD: Dell OptiPlex 780 MT</title>
<updated>2024-10-28T05:03:17+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-10-28T01:36:50+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=97054498e9460b1cbc5800817fc0c9d64458536a'/>
<id>97054498e9460b1cbc5800817fc0c9d64458536a</id>
<content type='text'>
Thanks go to Lorenzo Aloe and Nicholas Chin for working on
and testing this code.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Thanks go to Lorenzo Aloe and Nicholas Chin for working on
and testing this code.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add config for Dell OptiPlex 3050 Micro</title>
<updated>2024-10-05T02:32:06+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-09-24T20:42:43+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=c3ef0a863912af184c4a49e4876c7845ba3100aa'/>
<id>c3ef0a863912af184c4a49e4876c7845ba3100aa</id>
<content type='text'>
This is using Mate Kukri's port, which was added in
previous lbmk revisions. I've added an IFD that sets
the HAP bit, and unlocks regions as standard.

vcfg is set to 3050micro, which defines downloading
of the MEv11 image and it will run deguard automatically.

I made a small adjustment to vendor.sh, because the hotpatch
logic for deguard uses -C in git, and when doing that, the
specified directory path is relative to that Git repository;
the .patch path has been adjusted accordingly.

Also add 3rdparty/fsp to coreboot/default modules.

This board requires the ifdtool option: -p sklkbl

The -p option tells flashrom what quirks are present in a
given IFD. We don't normally need this on other Libreboot
targets that we currently support. The -p option was needed
for creating this modified IFD, and it is therefore needed in
the inject script. Therefore, an "IFD_platform" option is
specified in a given board's target.cfg file. If this is set,
another variable is set that makes -p be used.

In this case, 3050's target.cfg says:

IFD_platform="sklkbl"

This option enables quirks for skylake/kabylake descriptors,
as required when using ifdtool.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is using Mate Kukri's port, which was added in
previous lbmk revisions. I've added an IFD that sets
the HAP bit, and unlocks regions as standard.

vcfg is set to 3050micro, which defines downloading
of the MEv11 image and it will run deguard automatically.

I made a small adjustment to vendor.sh, because the hotpatch
logic for deguard uses -C in git, and when doing that, the
specified directory path is relative to that Git repository;
the .patch path has been adjusted accordingly.

Also add 3rdparty/fsp to coreboot/default modules.

This board requires the ifdtool option: -p sklkbl

The -p option tells flashrom what quirks are present in a
given IFD. We don't normally need this on other Libreboot
targets that we currently support. The -p option was needed
for creating this modified IFD, and it is therefore needed in
the inject script. Therefore, an "IFD_platform" option is
specified in a given board's target.cfg file. If this is set,
another variable is set that makes -p be used.

In this case, 3050's target.cfg says:

IFD_platform="sklkbl"

This option enables quirks for skylake/kabylake descriptors,
as required when using ifdtool.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
