-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
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
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
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?
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/B57u...
> 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
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.
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.
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
