Hi,
On Sat, 13 Jul 2013 22:18:50 +0400 Nikita Karetnikov nikita@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.