Configuration for Thinkpad T530
Hello, I'm trying to configure coreboot for a Lenovo Thinkpad T530 and I need help because for some parts I didn't find any information on the internet. The T530 (Machine Type Model: 24297ZG) has the the following specifications: Intel Core i5-3230M with Intel HD Graphics 4000 NVIDIA NVS 5400M AUO B156HW01 V.4 FullHD Display Samsung SSD 840 Pro 16 GB RAM I want to use a Docking Station. In the future I want to upgrade the following: Intel Core i7-3940XM more and faster RAM eGPU I'm going to install only some Linux distributions (no Windows). I think I will install OpenSuse which has a modified GRUB2 bootloader, where you can choose from which kernel or snapshot you would like to boot (maybe this information is important for configuring coreboot). Inside the Linux distribution, with graphical environment KDE, I would like to install some virtual machines with QEMU/kvm and there could be also a Windows virtual machine. I configured everything until now with 'make menuconfig' as listed bellow. Could you please give me some advise which settings I should change and why I should change them. I also wrote some questions behind a few configuration settings (marked with '#####') which I don`t understand. I would really appreciate your help. 1 General setup 1.1 () Local version string 1.2 (fallback) CBFS prefix to use 1.3 Compiler to use (GCC) 1.4 [ ] Allow building with any toolchain 1.5 [ ] Use ccache to speed up (re)compilation 1.6 [ ] Generate flashmap descriptor parser using flex and bison 1.7 [ ] Generate SCONFIG & BINCFG parser using flex and bison 1.8 [*] Use CMOS for configuration values 1.9 [ ] Load default configuration values into CMOS on each boot 1.10 [*] Compress ramstage with LZMA 1.11 [*] Include the coreboot .config file into the ROM image 1.12 [*] Create a table of timestamps collected during boot 1.13 [ ] Print the timestamp values on the console 1.14 [*] Allow use of binary-only repository 1.15 [ ] Code coverage support 1.16 [ ] Undefined behavior sanitizer support 1.17 [ ] Update existing coreboot.rom image 1.18 [ ] Add a bootsplash image 2 Mainboard 2.1 Mainboard Vendor 2.1.1 Lenovo 2.2 Mainboard model 2.2.1 TinkPad T530 2.3 ROM chip size 2.3.1 12 MB 2.4 (0x100000) Size of CBFS filesystem in ROM 2.5 () fmap description file in fmd format 3 Chipset 3.1 -*- Enable VMX for virtualization 3.2 [*] Set lock bit after configuring VMX 3.3 Include CPU microcode in CBFS (Generate from tree) 3.4 () Microcode binary path and filename 3.5 [*] Ignore vendor programmed fuses that limit max. DRAM frequency 3.6 [*] Ignore XMP profile max DIMMs per channel 3.7 Flash locking during chipset lockdown (Don't lock flash sections) 3.8 [*] Lock down chipset in coreboot 3.9 [*] Beep on fatal error 3.10 [*] Flash LEDs on fatal error 3.11 [*] Support bluetooth on wifi cards 3.13 [*] Add Intel descriptor.bin file 3.14 (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/descriptor.bin) Path and filename of the descriptor.bin file 3.15 [*] Add Intel ME/TXE firmware 3.16 (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/me.bin) Path to management engine firmware 3.17 [*] Verify the integrity of the supplied ME/TXE firmware 3.18 [*] Strip down the Intel ME/TXE firmware 3.19 [*] Add gigabit ethernet firmware ##### If I read correctly I need that for internet connection and this bianry has just some configuration in it and no excecutable? So this should be not a privacy concerning thing? 3.20 (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/gbe.bin) Path to gigabit ethernet firmware 3.21 [*] Add EC firmware 3.22 (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ec.bin) Path to EC firmware 3.23 [*] Lock ME/TXE section 3.24 Bootblock behaviour (Always load fallback) 4 Devices 4.1 Graphics initialization (Use native graphics init) ---> 4.2 Display ---> Framebuffer mode (Legacy VGA text mode) ##### I have no idea what to choose here 4.3 [*] Enable PCIe Clock Power Management ##### I read it should increase battery runtime 4.4 [*] Enable PCIe ASPM L1 SubState ##### I read it should increase battery runtime 4.5 [ ] Early PCI bridge 4.6 (0x0000) Override PCI Subsystem Vendor ID ##### What?! 4.7 (0x0000) Override PCI Subsystem Device ID ##### And again: What?! 4.8 [*] Add a VGA BIOS image ##### I'm not sure if I need a VGA Option ROM. In which cases I need it? What disadvantage do I have if I do not integrate a VGA Option ROM? Will I see GRUB when I boot Linux? How could you value that binary in case of privacy and security? 4.9 (pci8086,0106.rom) VGA BIOS path and filename 4.10 (8086,0106) VGA device PCI IDs 4.11 [*] Add a Video Bios Table (VBT) binary to CBFS ##### Same questions as for the VGA BIOS image 4.12 (src/mainboard/$(MAINBOARDDIR)/variants/$(VARIANT_DIR)/data.vbt) VBT binary path and filename 4.13 [ ] Enable I2C controller emulation in software 5 Generic Drivers 5.1 [ ] AS3722 RTC support 5.2 [ ] Enable protection on MRC settings 5.3 [ ] Disable Fast Read command 5.4 [ ] Serial port on SuperIO 5.5 [ ] Oxford OXPCIe952 5.6 (0x0) UART's PCI bus, device, function address ##### What is that? What I have to insert? 5.7 [ ] USB 2.0 EHCI debug dongle support 5.8 [ ] Support for Vital Product Data tables 5.9 [*] Support Intel PCI-e WiFi adapters ##### If enabled, will this include a binary in the coreboot image? 5.10 [*] PS/2 keyboard init 5.11 [ ] Silicon Image SIL3114 5.12 [ ] TI TPS65913 support 5.13 [ ] TI TPS65913 RTC support 6 Security 6.1 Verified Boot (vboot) ---> 6.2 Trusted Platform Module ---> [*] Deactivate TPM ##### I disabled it because of security/privacy reasons. Any disadvantages when I disable it? 6.2.2 [ ] Output verbose TPM debug messages 6.2.3 [ ] Enable Delay Workaround for TPM 7 Console 7.1 [*] Squelch AP CPUs from early console. 7.2 [ ] spkmodem (console on speaker) console output 7.3 [*] Use onboard VGA as primary video device ##### On coreboot mailinglist I read: make sure you enable ONBOARD_VGA_IS_PRIMARY in your config, otherwise your integrated graphics will be disabled and you'll lose eGPU hotplug. 7.4 [ ] Network console over NE2000 compatible Ethernet adapter 7.5 [*] Send console output to a CBMEM buffer 7.6 (0x20000) Room allocated for console output in CBMEM 7.7 [ ] SPI Flash console output 7.8 Default console log level (0: EMERG) ---> ##### I read that this should decrease boot time. What disadvantages do I have with this setting? 7.9 [ ] Don't show any POST codes ##### What? 7.10 [ ] Store post codes in CMOS for debugging ##### What? 7.11 [ ] Show POST codes on the debug console ##### What? 7.12 [*] Send POST codes to an external device ##### What? 7.13 Device to send POST codes to (None) ##### What? 7.14 [*] Send POST codes to an IO port ##### What? 7.15 (0x80) IO port for POST codes ##### What? 8 System tables 8.1 [*] Generate SMBIOS tables 9 Payload 9.1 Add a payload (SeaBIOS) ---> 9.2 SeaBIOS version (1.11.2) ---> ##### Or should I choose master? 9.3 (10) PS/2 keyboard controller initialization timeout (milliseconds) 9.4 [ ] Hardware init during option ROM execution 9.5 () SeaBIOS config file 9.6 () SeaBIOS bootorder file 9.7 [ ] Add SeaBIOS sercon-port file to CBFS 9.8 (-1) SeaBIOS debug level (verbosity) 9.9 [ ] Add a PXE ROM 9.10 Payload compression algorithm (Use LZMA compression for payloads) ---> 9.11 [ ] FIT support 9.12 [*] Use LZMA compression for secondary payloads 9.13 Secondary Payloads ---> 9.13.1 [*] Load coreinfo as a secondary payload 9.13.2 [ ] Load Memtest86+ as a secondary payload 9.13.3 [*] Load nvramcui as a secondary payload 9.13.4 [ ] Load tint as a secondary payload 10 Debugging 10.1 [ ] Halt when hitting a BUG() or assertion error 10.2 [ ] Output verbose CBFS debug messages 10.3 [ ] Output verbose RAM init debug messages 10.4 [ ] Output verbose SMBus debug messages 10.5 [ ] Output verbose SMI debug messages 10.6 [ ] Debug SMM relocation code 10.7 [ ] Output verbose SPI flash debug messages 10.8 [ ] Trace function calls 10.9 [ ] Debug boot state machine 10.10 [ ] Compile debug code in Ada sources 10.11 [ ] Configure image for EM100 usage Is there anything else I should take care of with a T530? Thanks for reading until here ;) Greetings
tldr :P ...just kidding friend ;) here are some replies
3.19 [*] Add gigabit ethernet firmware ##### If I read correctly I need that for internet connection and this bianry has just some configuration in it and no excecutable? That means your Ethernet controller needs a closed source proprietary firmware in order to function. So this should be not a privacy concerning thing? Being a closed source this firmware may contain the backdoors or help the backdoor-like functionality of intel me. So yes, this is a privacy concerning thing.
4.2 Display ---> Framebuffer mode (Legacy VGA text mode) ##### I have no idea what to choose here If you don't know about some setting, just leave it default - usually the defaults are correct, although may be not the best setting. Write down the questionable options somewhere, and if there'd be some problems with your coreboot then you'd know where to dig. In addition, you might check other people's config at coreboot board status reports for your motherboard.
4.6 (0x0000) Override PCI Subsystem Vendor ID ##### What?! 4.7 (0x0000) Override PCI Subsystem Device ID ##### And again: What?!
That probably means if those IDs are different at your specific board you could force them to something different. But better leave them default if you don't have a better idea for them.
##### I'm not sure if I need a VGA Option ROM. In which cases I need it? What disadvantage do I have if I do not integrate a VGA Option ROM? Will I see GRUB when I boot Linux? How could you value that binary in case of privacy and security?
Without a binary option rom you may experience some glitches, some people can't see GRUB although maybe this info is outdated and such problems have been fixed at the latest coreboot. So, like with any other binary blob, you need to check if you could live without it, and only add if you can't.
4.11 [*] Add a Video Bios Table (VBT) binary to CBFS ##### Same questions as for the VGA BIOS image same answer ;)
5.6 (0x0) UART's PCI bus, device, function address ##### What is that? What I have to insert? if you don't plan to debug your coreboot with UART (and your laptop probably doesn't have a physical UART) don't need to change anything there
5.9 [*] Support Intel PCI-e WiFi adapters ##### If enabled, will this include a binary in the coreboot image? no but it will include some workaround for buggy intel wifi controllers that will increase the size of your coreboot image by a few KB . if you don't use intel wifi, dont enable it
6.2 Trusted Platform Module ---> [*] Deactivate TPM ##### I disabled it because of security/privacy reasons. Any disadvantages when I disable it? if you don't plan to use TPM functionality (which maybe couldn't be trusted because it's closed source soft/hardware) then yes disable it
7.8 Default console log level (0: EMERG) ---> ##### I read that this should decrease boot time. What disadvantages do I have with this setting?
that after your coreboot boots its' log will be mostly empty and you can't see any useful messages at CBMEM console, e.g. which could have been useful if you're debugging some functionality or preparing a bug report
POST code questions ##### What?
like any other bios, coreboot prints some post codes at various booting stages, and you could even insert more prints to coreboot source code if you don't have any other debug methods. E.g. there are some MiniPCIe adapters like Compal MiniPCIe, which are used to display 0xYZ hexadecimal POST code at double 8-segment screen Hope that helps :)
On 14.01.19 23:30, Ivan Ivanov wrote:
tldr :P ...just kidding friend ;) here are some replies
3.19 [*] Add gigabit ethernet firmware ##### If I read correctly I need that for internet connection and this bianry has just some configuration in it and no excecutable? That means your Ethernet controller needs a closed source proprietary firmware in order to function.
Like any other modern ethernet controller it runs proprietary firmware. But in this case, what you would add here is indeed just a tiny con- figuration binary, no code. The firmware is embedded somewhere in the chipset. Also worth to mention, you don't have to add this file or any related file (ME, IFD) into coreboot. This option is only for people that want to put everything into a single file to flash at once. You can instead just write coreboot only, to the respective BIOS region in flash. And leave everything else intact.
So this should be not a privacy concerning thing?
Not in this particular case, no.
Being a closed source this firmware may contain the backdoors or help the backdoor-like functionality of intel me. So yes, this is a privacy concerning thing.
Well, don't use modern controllers (ethernet, USB, etc.) if you don't want proprietary firmware in them. But that's far from the original question... Nico
Hello Ivan and Nico, thanks for your answers. That clarified a lot. I still have some questions:
Being a closed source this firmware may contain the backdoors or help the backdoor-like functionality of intel me. So yes, this is a privacy concerning thing.
Well, don't use modern controllers (ethernet, USB, etc.) if you don't want proprietary firmware in them. But that's far from the original question...
To sum it up, I have 4 possibilities: 1. Live without ethernet firmware and without internet 2. Use the untrusted ethernet firmware with a small risk in terms of security/privacy 3. Don't use the ethernet firmware and only use a free miniPCIe Wifi card? Is this possible? 4. Don't use the ethernet firmware and only use a free USB Wifi stick
Also worth to mention, you don't have to add this file or any related file (ME, IFD) into coreboot. This option is only for people that want to put everything into a single file to flash at once. You can instead just write coreboot only, to the respective BIOS region in flash. And leave everything else intact.
But than I can't disable Intel ME and can't use me_cleaner? If I read correctly: when you disable Intel ME, you have to insert IFD and GbE into coreboot? Btw, do I also have to insert EC firmware than? Greetings
Hi Yannik, On 17.01.19 13:46, Yannik Catalinac wrote:
Being a closed source this firmware may contain the backdoors or help the backdoor-like functionality of intel me. So yes, this is a privacy concerning thing.
Well, don't use modern controllers (ethernet, USB, etc.) if you don't want proprietary firmware in them. But that's far from the original question...
To sum it up, I have 4 possibilities: 1. Live without ethernet firmware and without internet
the ethernet firmware, if any, is part of the chipset and can't be removed. You can only remove its configuration data.
2. Use the untrusted ethernet firmware with a small risk in terms of security/privacy
The bigger risk wrt. Intel's integrated ethernet is that the ME has a device driver for it. me_cleaner can remedy this, in theory (it still leaves unerasable ME firmware in a ROM where it's unknown if it contains an ethernet driver.
3. Don't use the ethernet firmware and only use a free miniPCIe Wifi card? Is this possible?
I'm not sure if such a card exists. There are WiFi cards with free OS drivers (e.g. ath9k), but I would expect them to run some sort of firm- ware, too. Though, I don't see how that matters. The hardware vendors can deceive you; while it makes it easier, they don't need firmware for that.
4. Don't use the ethernet firmware and only use a free USB Wifi stick
USB at least doesn't give the WiFi full memory access by default. But regarding firmware see 3.
Also worth to mention, you don't have to add this file or any related file (ME, IFD) into coreboot. This option is only for people that want to put everything into a single file to flash at once. You can instead just write coreboot only, to the respective BIOS region in flash. And leave everything else intact.
But than I can't disable Intel ME and can't use me_cleaner? If I read correctly: when you disable Intel ME, you have to insert IFD and GbE into coreboot?
If you want to do all of that in one go and let the coreboot `make` do the ME cleaning, yes.
Btw, do I also have to insert EC firmware than?
No, the T530 has its EC firmware in a separate flash. Nico
Hello Nico, thanks for your patience and your great answer! That helped a lot.
If you want to do all of that in one go and let the coreboot `make` do the ME cleaning, yes.
Just to be sure, is the following a good way for flashing coreboot? 1. Update the original BIOS with an update of the Embedded Controller 2. Make a backup of the original BIOS 3. I will do 'make' with disabled me_cleaner and without any blob, so no GbE, IFD and ME blob. I will flash it to the first BIOS chip and test if everything works. If everything works, I will do the next step 4. I will do 'make' with enabled me_cleaner and with the blobs GbE, IFD and ME. I will flash it to both chips 5. If necessary, I will add a VGA Option ROM and flash it again Regarding to number 4, on the coreboot documentation website I read: "The second flash ICs is behind the case frame, but can be flashed by using a simple trick. Connect every pin of the first flash IC, but tie /CS to Vcc. Connect /CS of the second flash IC to the programmer. As all lines except /CS are shared between the flash ICs you can access both with an external programmer." Could you please explain that to me in more detail? I'm not sure about it and I'm afraid of bricking the BIOS if I connect it the wrong way. Greetings Am Do. 17. Januar 2019 19:27 CET, Nico Huber <nico.h@gmx.de> schrieb: Hi Yannik, On 17.01.19 13:46, Yannik Catalinac wrote:
Being a closed source this firmware may contain the backdoors or help the backdoor-like functionality of intel me. So yes, this is a privacy concerning thing.
Well, don't use modern controllers (ethernet, USB, etc.) if you don't want proprietary firmware in them. But that's far from the original question...
To sum it up, I have 4 possibilities: 1. Live without ethernet firmware and without internet
the ethernet firmware, if any, is part of the chipset and can't be removed. You can only remove its configuration data.
2. Use the untrusted ethernet firmware with a small risk in terms of security/privacy
The bigger risk wrt. Intel's integrated ethernet is that the ME has a device driver for it. me_cleaner can remedy this, in theory (it still leaves unerasable ME firmware in a ROM where it's unknown if it contains an ethernet driver.
3. Don't use the ethernet firmware and only use a free miniPCIe Wifi card? Is this possible?
I'm not sure if such a card exists. There are WiFi cards with free OS drivers (e.g. ath9k), but I would expect them to run some sort of firm- ware, too. Though, I don't see how that matters. The hardware vendors can deceive you; while it makes it easier, they don't need firmware for that.
4. Don't use the ethernet firmware and only use a free USB Wifi stick
USB at least doesn't give the WiFi full memory access by default. But regarding firmware see 3.
Also worth to mention, you don't have to add this file or any related file (ME, IFD) into coreboot. This option is only for people that want to put everything into a single file to flash at once. You can instead just write coreboot only, to the respective BIOS region in flash. And leave everything else intact.
But than I can't disable Intel ME and can't use me_cleaner? If I read correctly: when you disable Intel ME, you have to insert IFD and GbE into coreboot?
If you want to do all of that in one go and let the coreboot `make` do the ME cleaning, yes.
Btw, do I also have to insert EC firmware than?
No, the T530 has its EC firmware in a separate flash. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I'm not sure if such a card exists. There are WiFi cards with free OS drivers (e.g. ath9k), but I would expect them to run some sort of firmware, too
according to wikipedia this ath9k family of WiFi controllers have both drivers and firmware as opensource. About USB controller, I didn't add xhci firmware image to my g505s coreboot and all the usb ports are working fine although at usb2 mode - so it seems to me that at least some controllers could function without a firmware, just that functionality could be degraded without one
Just to be sure, is the following a good way for flashing coreboot?
Maybe yes, although personally I'd have started with the largest amount of blobs and if it works then I did everything correctly and could try decreasing their quantity. This way you'd now if you're going the correct way right from the beginning, meanwhile your way is maybe more ethical but less confidence
Could you please explain that to me in more detail? although I've never flashed t530 to me it seems pretty obvious: usually you connect your 8 wires to SPI flash chip and doing the flashing, but this time you'll connect 7 wires like usual to your programmer, but 8th CS wire to programmers VCC instead of programmers CS, and that programmers CS will be connected to CS of another chip
Hello. On Sat, Jan 19, 2019, 22:03 Ivan Ivanov <qmastery16@gmail.com wrote:
I'm not sure if such a card exists. There are WiFi cards with free OS drivers (e.g. ath9k), but I would expect them to run some sort of firmware, too
according to wikipedia this ath9k family of WiFi controllers have both drivers and firmware as opensource. About USB controller, I didn't add xhci firmware image to my g505s coreboot and all the usb ports are working fine although at usb2 mode - so it seems to me that at least some controllers could function without a firmware, just that functionality could be degraded without one
The xHCI controller firmware and the Lenovo g505s you mention are AMD-specific stuff, which does not apply to the Intel chipset on the Thinkpad T530 (it should work out-of-the-box). Best regards, Angel Pons
The xHCI controller firmware and the Lenovo g505s you mention are AMD-specific stuff, which does not apply to the Intel chipset on the Thinkpad T530 (it should work out-of-the-box).
Hi Angel, I completely agree with you and of course understand that g505s info is not appropriate for t530 situation . By this + wifi ath9k example I just meant there are some controllers which don't need the non-free closed source firmware to do something Best regards, Ivan
participants (4)
-
Angel Pons -
Ivan Ivanov -
Nico Huber -
Yannik Catalinac