<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lbmk.git, branch m920qwip</title>
<subtitle>libreboot build system (LibreBoot MaKe)
</subtitle>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/'/>
<entry>
<title>BROKEN/WIP: NEW MAINBOARD: Lenovo ThinkCentre M920 Tiny</title>
<updated>2024-12-03T14:52:53+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T23:54:41+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=fb497cec3bf3ca5fada8900cae2917c2af7643d8'/>
<id>fb497cec3bf3ca5fada8900cae2917c2af7643d8</id>
<content type='text'>
WARNING!!!!! i915 driver crashes when loading (KMS driver).
Could not use GRUB or SeaBIOS; SeaBIOS hangs and USB input
fails in GRUB. U-Boot UEFI works, you can boot things.
If you want to set upp a headless service this machine is
totally fine, because you can just avoid loading i915 in
Linux, and just use the EFI framebuffer or the coreboot
framebuffer, or possibly boot xorg with nomodeset.

DO NOT MERGE! This machine needs a lot work work.

Initial notes:

This should cover both the M920q and M920x, though the
x variant is quite rare.

This is a mITX desktop system, documented here:
https://doc.coreboot.org/mainboard/lenovo/m920q.html

Thanks go to Maciej Pijanowski, who ported coreboot to
this board and submitted the code upstream. Libreboot is
using the version that was recently merged upstream in
the coreboot project.

It's not yet known how to auto-download the ME, because the
update images are incomplete. The only reliable way thus far
is to extract the factory dump. However, it's also uncertain
what modules to whitelist in me_cleaner, so for this board, we
only:

* Unlock all IFD regions, setting them read-write
* Set the HAP bit, which is functionally equivalent to
  a valid me_cleaner setup

The result will be a disabled ME, and read-write operation.
No binary images will be provided for now, in releases. You
must also create the directory:

dump/m920q/

Then just extract from the factory dump using:

./ifdtool --platform cnl -x libreboot.rom

Then just stick the files that it creates into there, and
the build should work. I've made lbmk automatically set the
HAP bit and unlock regions, when building with these.

Also, SeaBIOS hung so I restored the possibility of using
GRUB as primary, but GRUB USB input also didn't work! The
board's port author tested edk2 only, it seems. I don't really
want edk2 in lbmk just for this board.

So, I made U-Boot the only payload. It seems to work fine.
However, Debian Linux and OpenBSD both seemed to completely fail:
On OpenBSD it had errors pertaining to i915 video driver.

Debian Linux stalled at startup just when it's switching to
KMS, which would use the i915 driver.

Arch Linux installer, same thing: uses KMS, and failed.

The port author said edk2 was tested. edk2 provides a decent
GOP implementation, so maybe they were using an EFI framebuffer
when booting Linux.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
WARNING!!!!! i915 driver crashes when loading (KMS driver).
Could not use GRUB or SeaBIOS; SeaBIOS hangs and USB input
fails in GRUB. U-Boot UEFI works, you can boot things.
If you want to set upp a headless service this machine is
totally fine, because you can just avoid loading i915 in
Linux, and just use the EFI framebuffer or the coreboot
framebuffer, or possibly boot xorg with nomodeset.

DO NOT MERGE! This machine needs a lot work work.

Initial notes:

This should cover both the M920q and M920x, though the
x variant is quite rare.

This is a mITX desktop system, documented here:
https://doc.coreboot.org/mainboard/lenovo/m920q.html

Thanks go to Maciej Pijanowski, who ported coreboot to
this board and submitted the code upstream. Libreboot is
using the version that was recently merged upstream in
the coreboot project.

It's not yet known how to auto-download the ME, because the
update images are incomplete. The only reliable way thus far
is to extract the factory dump. However, it's also uncertain
what modules to whitelist in me_cleaner, so for this board, we
only:

* Unlock all IFD regions, setting them read-write
* Set the HAP bit, which is functionally equivalent to
  a valid me_cleaner setup

The result will be a disabled ME, and read-write operation.
No binary images will be provided for now, in releases. You
must also create the directory:

dump/m920q/

Then just extract from the factory dump using:

./ifdtool --platform cnl -x libreboot.rom

Then just stick the files that it creates into there, and
the build should work. I've made lbmk automatically set the
HAP bit and unlock regions, when building with these.

Also, SeaBIOS hung so I restored the possibility of using
GRUB as primary, but GRUB USB input also didn't work! The
board's port author tested edk2 only, it seems. I don't really
want edk2 in lbmk just for this board.

So, I made U-Boot the only payload. It seems to work fine.
However, Debian Linux and OpenBSD both seemed to completely fail:
On OpenBSD it had errors pertaining to i915 video driver.

Debian Linux stalled at startup just when it's switching to
KMS, which would use the i915 driver.

Arch Linux installer, same thing: uses KMS, and failed.

The port author said edk2 was tested. edk2 provides a decent
GOP implementation, so maybe they were using an EFI framebuffer
when booting Linux.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "trees: Allow using a custom clean command"</title>
<updated>2024-12-02T21:22:36+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T21:22:36+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=efebfa992b6f64d610115502d47468bc039b3a59'/>
<id>efebfa992b6f64d610115502d47468bc039b3a59</id>
<content type='text'>
This reverts commit 5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690.
</pre>
</div>
</content>
</entry>
<entry>
<title>trees: Allow using a custom clean command</title>
<updated>2024-12-02T20:41:05+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T20:37:26+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690'/>
<id>5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690</id>
<content type='text'>
On coreboot for example, as Mate has told me, if you're
making Kconfig changes and re-compiling, sometimes the
actual image that you build might still have the old one
in it, due to how coreboot's build system works.

To mitigate this, you can just always run distclean before
doing the build, but lbmk was doing just clean.

In practise, we did not find any issues, but this change should
be harmless, and might prevent such issues in the future. It's
even possible that we might have already encountered this before
and not realised, and we were just lucky that no noticeable issues
were caused.

It's *also* possible that the reverse is true: an issue that
was previously covered up, then that issue will now be exposed.
However, if that turns out to be true, then that is good because
we are exposing said bugs and then we will know to fix them!

Anyway, the variable in target.cfg is:

cleancmd="whatever_you_want"

e.g.

cleancmd="distclean"

You may also specify this in global mkhelper.cfg files, per
project; I've already done this for SeaBIOS, coreboot
and U-Boot, since all of these use Kconfig files.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On coreboot for example, as Mate has told me, if you're
making Kconfig changes and re-compiling, sometimes the
actual image that you build might still have the old one
in it, due to how coreboot's build system works.

To mitigate this, you can just always run distclean before
doing the build, but lbmk was doing just clean.

In practise, we did not find any issues, but this change should
be harmless, and might prevent such issues in the future. It's
even possible that we might have already encountered this before
and not realised, and we were just lucky that no noticeable issues
were caused.

It's *also* possible that the reverse is true: an issue that
was previously covered up, then that issue will now be exposed.
However, if that turns out to be true, then that is good because
we are exposing said bugs and then we will know to fix them!

Anyway, the variable in target.cfg is:

cleancmd="whatever_you_want"

e.g.

cleancmd="distclean"

You may also specify this in global mkhelper.cfg files, per
project; I've already done this for SeaBIOS, coreboot
and U-Boot, since all of these use Kconfig files.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add SPD support for onboard ThinkPad T480S RAM</title>
<updated>2024-12-02T16:32:15+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T16:32:15+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=b95a411a3645b72036101aaa8f8ad28758eefd15'/>
<id>b95a411a3645b72036101aaa8f8ad28758eefd15</id>
<content type='text'>
Patchset 20 from:

https://review.coreboot.org/c/coreboot/+/83274/18..20

Updated to that. A bunch of changes I made locally have been
copied here, thus removed from lbmk.

The previous setup in lbmk was to have only the DIMM slot work,
on the ThinkPad T480S, without setting up SPD for the onboard RAM&gt;

Mate Kukri reverse engineered the scheme by which the SPDs are
chosen at boot, based on the wiring of the board. This should
just about match the way Lenovo did it in their firmware.

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

https://review.coreboot.org/c/coreboot/+/83274/18..20

Updated to that. A bunch of changes I made locally have been
copied here, thus removed from lbmk.

The previous setup in lbmk was to have only the DIMM slot work,
on the ThinkPad T480S, without setting up SPD for the onboard RAM&gt;

Mate Kukri reverse engineered the scheme by which the SPDs are
chosen at boot, based on the wiring of the board. This should
just about match the way Lenovo did it in their firmware.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Disable m2 caddy hotplug on T480S</title>
<updated>2024-12-02T11:29:19+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T11:29:19+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=046529abd98d7a98b57cfe9113f8c61dc3353cfc'/>
<id>046529abd98d7a98b57cfe9113f8c61dc3353cfc</id>
<content type='text'>
This fixes an error where nvme disappears and gets renamed
on s3 resume. Mate Kukri told me to test that and it worked.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes an error where nvme disappears and gets renamed
on s3 resume. Mate Kukri told me to test that and it worked.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vendor.sh: Remove T480 VGA ROM download handling</title>
<updated>2024-12-02T06:12:59+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T06:12:59+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=9dc3c86ae37db781b6bc4e745a57217c3511074b'/>
<id>9dc3c86ae37db781b6bc4e745a57217c3511074b</id>
<content type='text'>
Libreboot's binary blob reduction policy is crystal clear:

If a blob can be avoided, it must be avoided.

The ThinkPad T480 was using Intel's VGA ROM for graphics
initialisation very briefly, before Mate fixed libgfxinit.

Since libgfxinit is fixed, the Intel VGA ROM is obsolete,
so we should not be handling this at all.

Similarly, the Nvidia ROM handling has been removed, because
Mate is hard-disabling that in the coreboot code anyway, since
the Nvidia dGPU didn't work when tested anyway.

Even if it did, Libreboot's blob policy makes it clear
that Intel graphics with native init from coreboot is to
be the preferred option.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Libreboot's binary blob reduction policy is crystal clear:

If a blob can be avoided, it must be avoided.

The ThinkPad T480 was using Intel's VGA ROM for graphics
initialisation very briefly, before Mate fixed libgfxinit.

Since libgfxinit is fixed, the Intel VGA ROM is obsolete,
so we should not be handling this at all.

Similarly, the Nvidia ROM handling has been removed, because
Mate is hard-disabling that in the coreboot code anyway, since
the Nvidia dGPU didn't work when tested anyway.

Even if it did, Libreboot's blob policy makes it clear
that Intel graphics with native init from coreboot is to
be the preferred option.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Enable legacy 8254 timer on ThinkPad T480</title>
<updated>2024-12-02T06:09:03+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T06:09:03+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=33efe45b149558853a292c4b67f2f392e6c6fd27'/>
<id>33efe45b149558853a292c4b67f2f392e6c6fd27</id>
<content type='text'>
I also enabled this on T480S, because otherwise SeaBIOS hung.

Enabling it shouldn't cause any harm on the T480, though Mate
did say that his machine seemed to work with my setup.

However, I believe that was when I gave him the ones that lbmk
built with the VGA ROM. Now it builds with libgfxinit, because
Mate was able to fix libgfxinit on this machine.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I also enabled this on T480S, because otherwise SeaBIOS hung.

Enabling it shouldn't cause any harm on the T480, though Mate
did say that his machine seemed to work with my setup.

However, I believe that was when I gave him the ones that lbmk
built with the VGA ROM. Now it builds with libgfxinit, because
Mate was able to fix libgfxinit on this machine.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libgfxinit on Thinkpad T480</title>
<updated>2024-12-02T06:05:41+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T06:04:20+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=cde9594aab52b8898e1b38495ac2f0a45ae51185'/>
<id>cde9594aab52b8898e1b38495ac2f0a45ae51185</id>
<content type='text'>
was previously using the VGA ROM.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
was previously using the VGA ROM.

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>
</feed>
