coreboot September 2017

coreboot@coreboot.org

57 participants
132 discussions

by A. Veek

2 years, 6 months

Where is the serial number stored on the thinkpad ivy/sandy bridge laptops

by Taiidan＠gmx.com

see "# dmidecode" Under system information and base board information I am curious as to how it survives the coreboot flash re-write, maybe the EC?

3 years, 8 months

Re: [coreboot] how to implement variable read/write variable in coreboot

by Nico Huber

Hi Melissa, On 28.09.2017 07:59, Melissa Yi wrote: > Hi All, > Does anyone know how to implement variable read/write in coreboot? > like: how to create a block nvram to be accessed by uefipayload? I don't know any quick solution. Though, here are my thoughts on the matter: AFAIK, coreboot currently doesn't have any specified format for in-flash, mutable configuration variables. Tianocore (or UEFI in general) might already have a format for that, but I would rather introduce something more native to coreboot that can easily be used in coreboot and all its payloads. I'll try to describe my ideas for a complete solution (and where we already have parts implement and where not) in some layers from bot- tom up: Flash-chip access ================= You need read/write access to the firmware flash chip. It's save to assume that coreboot at least knows how to read from its flash. And I would argue that writing variables from coreboot itself can be considered optional (or should even be discouraged). Though, when it comes to payloads, flash support is scarce. One option, and my preferred, is to use libflashrom that can currently be compiled and linked with libpayload. I guess it's not feasible to link the latter together with Tianocore (which seems to have its own implementation of the C library), so porting libflashrom to Tianocore is probably the way to go. (One alternative would be to only integrate drivers for the specific chipsets / chips one needs. But I can only advice against it. We should focus on one sophisticated code base for the matter and that is flashrom.) Flash-chip partitioning ======================= coreboot uses its native FMAP to describe the layout of the flash chip. libpayload has some code for it. Should be easy to find a place and add a new entry for variables. In-flash variable format ======================== I like to keep things simple and assume that a key=value approach suffices (for this layer). Though, as we have certainly to deal with NOR flash chips (and their erase blocks), we can't just store things in a table that would require an erase cycle for every change of a variable. Here is a random proposal: VARIABLE MAGIC (4 bytes, for sanity checks) COMPLETE LENGTH (4 bytes, length in bytes of this entry) KEY LENGTH (4 bytes, length of the key name, if 0 or 0xffffffff, entry is invalidated) KEY NAME (KEY LENGTH bytes) VALUE (COMPLETE LENGTH - KEY_LENGTH - 12 bytes) Read strategy: Either cache and index the whole thing, or read until the first valid entry with matching key. Write strategy: Invalidate any entry with matching key, append after last entry if there is enough space in the current erase block. If not, finalize current erase block with an invalid entry spanning the free space of the block, write variable into next erase block. If we run out of erase blocks, defragment the whole thing (needs one com- plete erase block size to cache things, afaics)? Application layer ================= Up to the use case. Could be anything from simple flags over UEFI runtime variables to full programs (e.g. tint easter-egg), I sup- pose. Hope there is anything helpful in this mail, Nico

3 years, 8 months

KGPE-D16/KCMA-D8 TPM support?

by Taiidan＠gmx.com

Does anyone know what TPM's are compatible? I also want to know what coreboot's tpm support is like these days, such as how can you perform an erase/reset like one could with a standard OEM bios. - Thanks in advance

3 years, 8 months

Re: [coreboot] Coreboot on X230 and Dualboot / How to make it work

by Nico Huber

Hi 799, On 29.09.2017 13:34, One7two99 wrote: > Hello Nico, > >> I suspect some misconfiguration or that something confuses the libpay- >> load VGA driver (which these two secondary payload rely on). > > This might be true, but I don't understand why I can see the SeaBios > Menu (Press ESC) and can also use graphical boot (Windows and Qubes OS) > but the secondary payloads don't work. Can you check my .config > especially the setting for the VGA device? you might have to accept that adding VGA compatibility for Windows may break compatibility with the secondary payloads. That's not generally the case but about the last thing that gets tested. If you don't get this setup with SeaBIOS running, there are alterna- tives. One that comes to mind: Do native GFX init in coreboot, add the VGA blob (so far your config below) but use GRUB as primary payload and run SeaBIOS as secondary. You'd have to hand-craft your grub.cfg, some- thing like four choices: 1. Run your favorite open source OS 2. SeaBIOS for legacy compatibility 3. coreinfo 4. nvramcui > >>> If you thing I"ve missed out important steps, I am happy to hear your comments. >> Don"t think you missed anything [...] But you might do too much already. >> Especially flashing anything but the BIOS region when you want to track >> down coreboot issues makes things harder to reason about. > > I had the seconday payloads booting when lynxis did the coreboot > flashing. But we flashed without adding a vga-rom so that I couldn't > boot into windows. I've extracted the vga rom and then tried to rebuild > coreboot, but I seem to miss some configuration to get graphical boot > (vga rom) and secondary payload boot running. > > I've seen the following option in make nconfig for coreboot under > "General Setup": │ [*] Include the coreboot .config file into the ROM > image │ > > QUESTION: How can I extract this .config file? I could then extract this > from my first flashing together with lynxis to see which settings have > been applied there. You can do that with cbfstool, e.g. $ build/cbfstool build/coreboot.rom extract -n config -f config.txt where your replace `build/coreboot.rom` with the path of your image and `config.txt` with the path to the output file. Another question about your setup, do you configure anything in SeaBIOS that is not visible from your coreboot .config? Anything GFX related? splashscreen? VESA mode? Nico (Some comments on your config below.) > >> Please attach your .config file. Nobody can say anything for sure >> with-out knowing what you chose. > > I've attached the config file and will also list the activated options here: > (only enabled options are shown): > > [General Setup] > │ [*] Use CMOS for configuration values > │ [*] Compress ramstage with LZMA > │ [*] Include the coreboot .config file into the ROM image > │ [*] Create a table of timestamps collected during boot > │ -*- Build the ramstage to be relocatable in 32-bit address space > > [Mainboard] > │ Mainboard vendor (Lenovo) > │ Mainboard model (ThinkPad X230) > │ ROM chip size (12288 KB (12 MB)) > │ (0x400000) Size of CBFS filesystem in ROM > > [Chipset] > │ *** CPU *** > │ [*] Enable VMX for virtualization > │ [*] Set lock bit after configuring VMX > │ Include CPU microcode in CBFS (Generate from tree) > │ *** Northbridge *** > │ -*- Use native raminit > │ *** Southbridge *** > │ Flash locking during chipset lockdown (Don't lock flash sections) > │ [*] Lock down chipset in coreboot > │ *** Embedded Controllers *** > │ [*] Beep on fatal error > │ [*] Flash LEDs on fatal error > │ *** Intel Firmware *** > │ [*] Add Intel descriptor.bin file > │ (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/descriptor.bin) > │ [*] Add Intel ME/TXE firmware > │ (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/me.bin) > │ [*] Verify the integrity of the supplied ME/TXE firmware > │ [*] Add gigabit ethernet firmware > │ (3rdparty/blobs/mainboard/$(MAINBOARDDIR)/gbe.bin) > │ [*] Lock ME/TXE section > │ Verified Boot (vboot) > │ Bootblock behaviour (Always load fallback) > > [Devices] > │ Graphics initialization (Use native graphics init) With this option you let coreboot initialize GFX. But you also let Sea- BIOS run the VGA BIOS. The former will be completely overrun. I doubt that it causes your secondary payload trouble, though. > | --> Framebuffer mode (Legacy VGA text mode) > │ Display > │ -*- Enable PCIe Common Clock │ > │ -*- Enable PCIe ASPM > [*] Add a VGA BIOS image > │ (./3rdparty/blobs/mainboard/lenovo/x230/pci8086,0166.rom) VGA BIOS > │ (8086,0166) VGA device PCI IDs > > [Generic Drivers] > │ [*] Serial port on SuperIO WTF? > │ [*] Support Intel PCI-e WiFi adapters > │ [*] PS/2 keyboard init Is this required? It's odd to set it when using SeaBIOS. > │ [*] Enable TPM support > > [Console] > │ [*] Squelch AP CPUs from early console. > │ [*] Send console output to a CBMEM buffer > │ (0x20000) Room allocated for console output in CBMEM > │ [*] Send POST codes to an external device > │ Device to send POST codes to (None) > │ [*] Send POST codes to an IO port > │ (0x80) IO port for POST codes > > [System tables] > │ [*] Generate SMBIOS tables > > [Payload] > │ Add a payload (SeaBIOS) ---> │ > │ SeaBIOS version (1.10.2) ---> │ > │ (0) PS/2 keyboard controller initialization timeout (milliseconds) │ Why override the default? If it works that's just fine. I'm just wondering if we should have different defaults then. > │ [*] Hardware init during option ROM execution │ > │ () SeaBIOS config file │ > │ () SeaBIOS bootorder file │ > │ (-1) SeaBIOS debug level (verbosity) │ > │ *** Using default SeaBIOS log level *** │ > │ [*] Use LZMA compression for payloads │ > │ Secondary Payloads ---> > │ [*] Load coreinfo as a secondary payload > │ [*] Load nvramcui as a secondary payload > > [Debugging] > all deactivated > > kind regards > > [788] huh?

3 years, 8 months

[RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7

by Paul Menzel

Dear coreboot folks, I’d like to propose the following goal for the upcoming coreboot 4.7 release. All boards have to build with GCC 7.2 [1] and IASL 20170831 [2]. For the latter, several Intel boards fail to build [3]. It’d be great if the maintainers looked into it. Thanks, Paul [1] https://review.coreboot.org/20809/ [2] https://review.coreboot.org/21156/ [3] https://ticket.coreboot.org/issues/138

3 years, 8 months

Re: [coreboot] Owner-controlled POWER9 Talos II [was: Disabling Intel ME 11 via undocumented mode]

by Timothy Pearson

On 09/06/2017 01:05 PM, Rene Shuster wrote: > Thanks for sharing this info. > > So the 4x SATA ports are optional and powered by PM8069, and they will > only be present if you checkbox the "Integrated Microsemi SAS Controller > (Proprietary)" on the purchase page, correct? Or in other words: if you > don't checkbox "Integrated Microsemi SAS Controller (Proprietary)" you > will receive a board with no SATA ports? Correct. Given the advantages of NVMe especially for a high-power development system like the Talos™ II this was considered an acceptable tradeoff. > How is the Samsung NVMe drive physically connected (M.2/U.2 or PCIe > slot)? What model# is it? PCIe. We'll be selecting an active model closer to machine ship; Samsung part numbers can change over time so we don't necessarily want to commit to a given part # at this point. > So BCM it is. They have a pretty thorough Diagnostic for their NICs. I'm > using it on some of our servers when it's time to run diagnostics. It's > DOS based (but they have an UEFI version as well) and it does check > quite a few things ("Register Tests, Memory Tests, Miscellaneous Tests, > Data Tests, Cable Tests, APE Register Tests and APE Diagnostics > Tests"). For the BCM5719 the diag is located here: > https://docs.broadcom.com/docs-and-downloads/docs/eula_download/570x/B57udi… > It includes the B57Diag.pdf which might be of interest for anyone who > wants to reverse engineer the fw. Sounds good. This is the only device on the board that requires firmware, but it is behind the IOMMU and the FSF has indicated that we can still obtain RYF with this limitation. That being said, we'd love to see a libre firmware created for this controller as it would allow not only this system, but future systems, to be blob-free while using a modern non-Intel GbE NIC... -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com

3 years, 8 months

Re: [coreboot] Booting live OS from encrypted LUKS partition in GRUB2

by Klemens Nanni

On Sat, Sep 30, 2017 at 08:37:55AM +0000, Thomasheidler via coreboot wrote: > I have GRUB2 as a payload in coreboot and I am trying to have it load Trisquel 7.0 Live (Test Trisquel without installing) from an encrypted LUKS partition on a USB flash drive. I am able to decrypt the LUKS container and GRUB finds the Trisquel ISOLINUX menu, but fails to load the OS. When I try to manually boot it with commands (linux, initrd, boot) it starts loading the kernel, but then halts when it detects the USB flash drive and drops into BusyBox. Live setups do not support encrypted root file systems, that's why Trisquel fails here and you're dropping to the initramfs's rescue shell. > Does anybody know how to overcome this problem and properly boot Trisquel in live mode from an encrypted LUKS partition in GRUB? Encrypted disks are decrypted twice during boot: First GRUB2 needs to read the kernel image (and initramfs), second the kernel reads / (and all other required file systems). These stages are completely separate, there's no way of passing state between bootloader and kernel. Put your live system on a USB stick as usual or install it properly using disk encryption, that's all you got.

3 years, 8 months

Booting live OS from encrypted LUKS partition in GRUB2

by Thomasheidler

Hello, I have GRUB2 as a payload in coreboot and I am trying to have it load Trisquel 7.0 Live (Test Trisquel without installing) from an encrypted LUKS partition on a USB flash drive. I am able to decrypt the LUKS container and GRUB finds the Trisquel ISOLINUX menu, but fails to load the OS. When I try to manually boot it with commands (linux, initrd, boot) it starts loading the kernel, but then halts when it detects the USB flash drive and drops into BusyBox. Does anybody know how to overcome this problem and properly boot Trisquel in live mode from an encrypted LUKS partition in GRUB? Thanks.

3 years, 8 months

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

by Peter Stuge

Hi Cameron, Cameron Craig wrote: > I have managed to create a bootable image using an out of date copy > of coreboot and U-Boot, provided by Intel under NDA. coreboot code is always covered by the GPL, regardless of where it came from. If Intel tries to bind you in a contradictory agreement I don't think that holds. Check with a lawyer. I think U-Boot is GPL-licensed too. > The stitching process used to generate the image is a little ugly: > a set of Windows tools are provided (or pointed at) by Intel to > stitch the various blobs together to create an 8MB image. We would > like to move away from this process. Using the cbfs tool it looks > like we are getting a legacy image composed entirely of a single > CBFS. What does a current cbfstool print output for that image? > However, as far as I understand, the latest coreboot release (v4.6) > should be capable of producing a 16MB working image without the use > of external tools. I would suggest reducing variables. So start with the same size. And reuse as many bits and pieces (descriptors, blobs, etc.) as possible from the working image. > 4. Extract Flash Descriptor from an existing Leaf Hill UEFI image (./ifdtool --extract leaf_hill_ref_board_uefi.bin) What about the flash descriptor from the working forked coreboot build? > Other than that, I currently have no working theories as to what > the root cause is ☹ Firmware development is lots of fun! :) > Is there anything obviously wrong with this process? If the flash descriptors match and bar the added variables then no, not really. I would recommend to focus on increasing debug capability. If all else fails then even looking at the SPI flash clock and data signals with a scope or logic analyzer can be useful. If there's a speaker on the board then you can try spkmodem. It's noisy, but fun, and works early. //Peter

3 years, 8 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2017