Hi
I am trying to port a Haswell laptop and I would want it to have IOMMU support. My chipset supports VT-d but CPU does not. The official info from Intel says the PC needs chipset, CPU and BIOS to support VT-d to use IOMMU. I think this is not true because I saw some boards in board status have working IOMMU with no VT-d support in chipset but with coreboot advertising DMAR table to OS and CPU with VT-d support. Sapphire H61 is a example of this. But other H61 coreboot boards such as P8H61-M LX that have CPU without VT-d advertise no IOMMU capability. So what is really required for full IOMMU ? Do I have chance for full, working IOMMU on this laptop?
Thanks,
Lud
Hi Coreboot Team,
There is an external Monitor which works on HDMI/DVI and also DP , In BIOS
the display is good whereas in OS (Ubuntu 18.04) until the kernel is
initialized and i915 Video driver
is loaded display is perfect, looks like the i915 OS driver switches off
the monitor and there is no signal
Does ACPI GFX method have to return any External display specific data to
the OS driver ?
Tried to make changes to VBIOS but did not help, thought ASL code is
missing under GFX0
From the OS following data can be read
1. External Monitor's EDID data can be read from I2C Bus
2. Even VBT data from ACPI NVS can be read
Tried to dig into some of these files
https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/i915/display
intel_dp.c, intel_acpi.c to understand what function is turning off DP link
when i have the OS debug driver logs, can send it across
Any clues will help, appreciate your time
PS:The platform has Intel BayTrail SoC, ValleyView chipset and VBIOS. The
bios do not use GOP driver which replaces VBIOS
Thanks
Rao
Hi folks,
I spent a long time trying to get coreboot 4.13 to work on a Lenovo T410, trying various configuration options etc. but it never worked (fan, keyboard LED and thinklight went on, screen stayed dark). I tried even the most basic config, but no luck.
I tried the same with coreboot 4.12 and this seems to work fine.
Unfortunately, this is not my laptop and the owner needs his laptop back asap, so I don't have the time to further debug this issue. Yet, I wanted to report this regression as I I am wondering if anyone else is running 4.13 on a T410 with success?
Cheers, Daniel
Hello,
Just wanted to say thank you for creating this firmware it is a great
project and I hope I can contribute to it one day.
I have an x230 preinstalled with Coreboot skulls, am I able to re-flash
Coreboot skulls internally just through the OS or is there a way to
verify that the firmware installed on the system hasn't been modified in
any way, thank you.
Kindest regards,
Louis
I've been running coreboot on my T440P and trying to fix it up.
I have already resolved some things here:
https://github.com/Ph0rk0z/coreboot/pulls
Will have to figure out how to contribute this back to coreboot after
testing so it can pass code review.
Other things remain, including:
- software changing of keyboard backlight doesn't work on windows (but I
fixed it on linux)
- lenovo hotkey / mic mute services crash windows (bad pool_caller)
- intel haswell -mini hd audio shows exclamation point, will not start.
I've read others don't have DP audio working either.
- there is an unknown ACPI\VEN_BOOT@DEV_0000 device
- card reader doesn't work in windows/linux and crashes windows on warm
boot
- plug/unplug ac under bios and windows causes screen to go dark for a
second
- occasionally power button light turns off (fixed by suspend)
- TLP stats for charge mAH are off by a factor of 10.
- tianocore picks up the windows loader as a boot option but doesn't
pick up arch linux, old bios enumerated both.
- tianocore menus/graphics are only what looks like 640x480 and don't
take up the screen
I'd like to solve the card reader issue but not sure where to start. It
appears correctly detected and matches everything on my x250.
Any hints to what I should look at?
Hi all,
that we had another case of a missing-device-below-chip in a devicetree
made me write a patch for `sconfig` [1]. Now that it's checking for the
issue, that uncovered a few (31) more cases [2] that need to be fixed
before upstream can benefit from the patch. Please help to fix the
devicetrees.
Note, `sconfig` currently doesn't print the file name of override trees,
e.g. when it says
SCONFIG mainboard/.../devicetree.cb
line 10: end: syntax error
that might as well refer to line 10 in an override tree.
Nico
[1] https://review.coreboot.org/c/coreboot/+/51119
[2] https://qa.coreboot.org/job/coreboot-gerrit/164572/
Failing boards:
board.AMD_BILBY
board.AMD_CEREME
board.AMD_MANDOLIN
board.GETAC_P470
board.GOOGLE_BRYA0
board.GOOGLE_FALCO
board.GOOGLE_PEPPY
board.GOOGLE_WOLF
board.KONTRON_BSL6
board.LENOVO_R500
board.LENOVO_T430S
board.LENOVO_T431S
board.LENOVO_T520
board.LENOVO_T530
board.LENOVO_W530
board.LENOVO_X1
board.LENOVO_X220
board.LENOVO_X220I
board.LENOVO_X220_MRC_BIN
board.LENOVO_X220_OPTION_TABLE_DEBUG_TPM_EXTENDED_CBFS
board.LENOVO_X230
board.LENOVO_X230S
board.LENOVO_X230T
board.LENOVO_X301
board.LENOVO_X60
board.RODA_RK886EX
board.SIEMENS_BOXER26
I have a couple of X200's, all running coreboot 4.10. The dock works
fine there. When I press the undock button (either on the side or with
Fn+F9), the system undocks, and when I put the laptop back in the dock,
the led goes red again, and the USB ports start working again. The same
happens when the system is suspended and resumed.
However, since coreboot 4.11, the re-docking part is completely broken.
I can press the undock button(s), which work fine, but when I re-dock
the laptop, the led remains green and USB does not work. Also, when I
suspend and resume the laptop, the system undocks immediately after
resuming from S3, even though no button was pressed and it's still
physically docked.
The only way to recover from this is by rebooting.
In coreboot 4.13, this bug is still present. So I decided to bisect the
issue, and I found the offending commit:
96ae7a3a2d38b96c1dfee57fda2c2eaab7e9e762 is the first bad commit
commit 96ae7a3a2d38b96c1dfee57fda2c2eaab7e9e762
Author: Bill XIE <persmule(a)hardenedlinux.org>
Date: Wed Oct 16 23:22:10 2019 +0800
mb/lenovo/x200: Add ThinkPad X301 as a variant
It is similar to X200s, with U-series CPU, slightly different gpio
setup, no docking support, and no superio chip.
https://review.coreboot.org/c/coreboot/+/36093
Looking at the changes, this seems pretty plausible. I would like to get
coreboot 4.14 running properly again with docked X200's, but I'm not
sure (yet) what the exact cause of the breakage is.
--
With kind regards,
Kevin Keijzer
Hi everybody,
In our leadership meetings we repeatedly had companies using coreboot look
for qualified staff. In response this created a job site at coreboot.org,
linked prominently from our landing page, accessible at
https://coreboot.org/jobs.html
So if you're looking for a coreboot related job, check out these job
postings and if you're with a company that is looking for new folks, feel
free to push a change to our homepage.git repository to add your company
there!
Best regards,
Patrick Georgi
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hi
To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some
tooling is required to generate both a Key Manifest (A signed binary,
that is checked
against a key fused into the ME, holding keys that OEM can use to sign the BPM)
and a Boot Policy Manifest (signed binary, has a digest of IBBs,
Initial Boot Blocks).
At the moment these are included as binaries by the build system.
Obviously this only works if the IBB hasn't changed. If it changed, you'd
need to regenerate the BPM. 9elements has written some open source tooling
(BSD-3 clause) to generate both KM and BPM. The code for this tool is not yet
public as it was written using NDA documentation. Intel is currently reviewing
this to allow us to make it public, but this takes time. It will be
part of the 3rdparty/intel-sec-tools
submodule.
My question to the community is if it would be ok to allow for the build system
integration code for KM and BPM generation to be integrated into the
master branch
before the code to the tooling is made public.
CBnT is an optional feature on Intel hardware and is implemented as an
optional feature in
coreboot. The tool is standalone and coreboot can still be built fine
without it.
At the moment coreboot has code for xeon_sp in the master
branch without a public FSP too, with the promise that it will be
publicly released later
on by Intel. Compared to that the situation would be a little better:
we propose to add a binary tool (it's written in go so it's
automatically build as a static binary) to the blobs repo under a
licence similar to the one used for Intel FSP and MCU (allows
redistribution). We hope to remove it ASAP from there and build it
from source from 3rdparty/intel-sec-tools.
We'd like to develop as close as possible to the coreboot master
branch, so we hope that this is an acceptable solution to the
community.
So TL;DR:
- Is (temporarily) adding a tool to the blobs repo ok?
- Is integrating an (optional) not yet open tool into the build system ok?
Let me know what you think.
Kind regards.
Arthur Heymans
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: arthur.heymans(a)9elements.com
Phone: +49 234 68 94 188
Mobile: +32 478499445
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar
Datenschutzhinweise nach Art. 13 DSGVO
