[coreboot] Supported laptops (again), treacherous computing

Denis 'GNUtoo' Carikli GNUtoo at no-log.org
Sun Jul 14 13:58:27 CEST 2013


Hi,

On Sat, 13 Jul 2013 22:18:50 +0400
Nikita Karetnikov <nikita at karetnikov.org> wrote:
> I mentioned Thinkpads for two reasons: I thought they don't need
> proprietary components, and they are quite popular among Coreboot
> people.
> 
> [1]
> http://www.coreboot.org/Thinkpad_X60s#proprietary_components_status

Looking at what I wrote on the wiki:
>CPU Microcode (optional?)
Basicaly the issue is that I found that the microcode was included,
trough #include and headers containig its code in coreboot,
What that means is that even if you select to use no microcode in make
menuconfig, it will still be included and run.

What is unclear and must be tested is if the computer would boot or
have some issues without the microcode. It really has to be tested...
It might also work only on a subset of the X60/T60.

>VGA option rom (optional): without it you will get no graphics during
>early boot,
I spent a lot of time trying to get graphics initialized by coreboot,
but I had graphics corruptions...At the end the problem was solved
during a coreboot meeting in Germany by making Ron Minnich, Peter Stuge
and me(trough the internet) work on it during at least two days.

At the end Peter Stuge found the reason of the issue and made some
modifications on top of his and Ron Minnich's code, which was on top of
my code(which has been merged nowadays).

So the issue is that Peter Stuge didn't push that code for review yet
and told me to wait for that...

In the meantime I've cleaned the diff I got from Peter stuge and pushed
it here along with some other patches:
http://gitorious.org/gnutoo-for-coreboot/coreboot/commits/production-x60+v2

The two issues are that he didn't push for review yet and seem to be
working on something else right now(making the thinkpad_acpi linux
kernel driver load by doing some coreboot modifications which
makes the thinkpad_acpi module detect the X60 as an X60, and
some other modifications)... which delays even more the push,
The second issue is that the version that he has on his computer, which
probably needs cleanup, is even better than the one I have on
gitorious: the one I have on gitorious doesn't contain the full set of
changes he has, it does work but the framebuffer is at 0xd0020000 which
is at the same address than the address the linux kernel puts the
framebuffer of the i915 driver...That seem to cause an issue: often(not
always), the kernel panics at boot when loading the i915 driver...

I remember trying to move the framebuffer to 0xd0000000 without
success(althouhg I didn't try very hard, I removed the offset for the
framebuffer and ajusted the I/O accordingly).

If you have a not that recent linux kernel, you can even not use the
option rom or the native graphics initializations that replace it:
The i915 driver was able to initialize the GPU alone, without the
presence of the option rom.

However that has huge drawbacks:
-> no graphics until the i915 driver loads, so even if you add that
module to your initramfs(which is really advised, so you will get
something on the screen way earlier) you won't have graphics before
that, like in grub or in your payload like SeaBIOS
-> there are various small issues like cbmem -c not working anymore, or
nvramtool requiring a supplementary option to work etc...wihch are
probably due to some memory corruption, which is spoted by recent
kernel and makes Xorg unusable(though the real console like CTRL+ALT+F1
is usable). I didn't try again on more recent kernels so it might work
with the lastest kernel, but I wound't count on that.

Using native graphics initialization also has drawbacks:
-> I didn't implement yet the possibility to ajust the backlight
luminosity, so right now it's at full power(it can only be turned on or
off), although if I run a trace of the option rom it does work, which
means that work is needed to identify the part making it work in the
trace...
-> It's only usefull with a limited subset of payloads: Very few
payloads are able to use it.
Basically coreboot itself initialize the i915, and pass the address of
the framebuffer to the payload trough the coreboot tables.

Grub2 as a payload is able to use that and it works fine.
Some libpayload based payloads seem also able to use that, although I
only tried them by running them trough grub.

SeaBIOS and Tianocore for instance won't work.
So for instance when you launch SeaBIOS trough grub, you get some
graphics in grub but SeaBIOS is unable to use the framebuffer, which
result on having nothing new drawn on the screen and the loading
message remaining there.

Note that grub is very flexible and has a lot of features, for instance
it's able to load grub.cfg files from disk.

Though it's not able to run all cdrom or usb keys out of the box(a
grub.cfg probably must be writen to find the Syslinux of your cdrom,
parse it to extract the kernel arguments etc... and use that).

It also doesn't implement BIOS runtime, which means that software using
that won't work, like for instance ipxe.

Once grub loads the linux kernel, the linux kernel can an early
framebuffer trough efifb or something like that, then the i915
loads(that sometimes crash for me though), if it didn't crash then you
get the normal "user experience", with 3d acceleration, Xorg working
etc...

> EC(Embedded Controller) => you do not have to touch it(just leave it
> where it is
The embedded controller is a microcontroller like chip connected to the
keyboard, and to some switches(like wifi switch for instance), leds and
similar things.
It's unable to transmit data to the outside.

Its code is proprietary and you don't have to load a firmware in it to
be able to use it because the firmware is in the chip already.

So in the worst case sceanrio it could implement a keylogger in its
ring buffer but wound't be able to transmit that data.

I also found recently that the Ethernet network card of the X60 and T60
had a firmware:
# ethtool -i eth0
driver: e1000e
version: 2.2.14-k
firmware-version: 0.5-1
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

You don't need to load that firmware to use the card because it's
already in the card.

I didn't find how to dump that firmware.
There is a --flash option in ethtool though, but since I don't know how
to dump the firmware first, I didn't try it.

The issue is that that card is on the PCI bus...
Beeing on the PCI bus open the possibility to do nasty tricks,
for more details there is http://stewin.org/papers/dimvap15-stewin.pdf

I wonder if the NIC has its own DMA engine.

Though the firmware on that card is probably small, and probably have
very few RAM at disposal...which makes it harder to use that kind of
tricks.

It seems that when AMT is implemented on such old chipsets, trough
the Network card, the BIOS flash is partitioned and some space is
reserved for the network card and/or AMT firmware.
It's clearly not the case here.

Denis.



More information about the coreboot mailing list