Thanks for the coreboot community for providing a strong technology
foundation and continuous support, coreboot support for servers
powered by Intel Xeon-SP processors is becoming a reality:
We look forward to further collaboration with you!
"For my ally is the Force, and a powerful ally it is."
did anyone get the discrete GPU working on a T530 with coreboot?
All I got so far was a blank screen when trying to switch to "Discrete
Only" with nvramtool. With "Integrated Only" it doesn't even show up in
Interestingly, both showed up on the first reboot after the "Discrete
Only" change, but the blank screen happened after the first full
The main problem there:
Without dGPU support, the external display port on a T530 docking
station is not driven at all - it is hardwired to the GPU, if present.
So when buying one of those, it actually hurts to have a dGPU.
I'm trying to get OpenBSD to install on an x220 Thinkpad with
Coreboot/SeaBIOS but I'm running into two problems: the ethernet device
doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0 wouldn't
load because the EEPROM had an invalid signature. I have no idea why
OpenBSD doesn't see my HDD though. It's strange because everything works
fine under Linux. And I cannot seem to mount a usb drive under the
OpenBSD installer to attach dmesg errors.
I originally posted this as a bug report to bug report mailing list but
Theo said it would be better suited for Coreboot's and wasn't a bug in
I'm runinng coreboot 4.7 without any problems on OpenBSD. I have
compiled 4.9 and master and both have the same problem for the hci
devices. On GNU/Linux I have experience inestability and lock ups.
I'm running with full ME.
Something must have be broken between 4.7 and 4.9 (I haven't been
able to build 4.8.1, still trying).
Hope someone has any solution or knowns what is happening.
On Sun, Mar 15, 2020 at 8:46 AM Matt B <matthewwbradley6(a)gmail.com> wrote:
> Thanks for the info on DRI_PRIME. I'm looking at doing a motherboard+cooler swap.
> Have you run battery life tests with/without the dGPU hidden?
> Isn't NVRAM the "correct" way to do it?
> On Wed, Mar 11, 2020 at 11:24 AM Mike Banon <mikebdp2(a)gmail.com> wrote:
>> On Sun, Mar 8, 2020 at 6:56 PM Matt B <matthewwbradley6(a)gmail.com> wrote:
>> > To those who have a dual-GPU G505s and have enabled the recent support for the dGPU, does DRI_PRIME GPU offloading work?
>> Yes, DRI_PRIME GPU offloading works on G505S - and actually I think
>> it's the only possible way of using a discrete GPU on this coreboot'ed
>> laptop at the moment. However, it's usefulness really depends on your
>> software and how fast is the integrated GPU's RAM: you may have
>> 1600MHz CL9 RAM modules installed, while a discrete GPU's own soldered
>> chips are i.e. 1333MHz CL9 only. I recommend testing them side by side
>> in all the programs you care about and remember which one is better in
>> what cases.
>> > Could here be an option created to enable/disable the dGPU at boot time without recompiling?
>> If there could be a real benefit from doing so (does it consume less
>> power if you "hide it" from your system by disabling a PCI bus?), such
>> a way could be implemented - however, I don't know how to do it
>> without using NVRAM (which I would like to avoid for various reasons)
Ideally I prefer a laptop as stateless as possible at least regarding
the BIOS - and also, at least some G505S laptops seem to have a broken
NVRAM (strong freeze on a write attempt to NVRAM and laptop doesn't
turn on until a full motherboard discharge).
A10-5750M TDP is 35W, after looking at the similar CPUs from this
table - https://www.eteknix.com/amd-kaveri-a10-7850k-overclocking-analysis/7/
, it seems that:
Idle | GPU load | CPU+GPU load
15.6W | 23.66W | 35W
44.5% | 67.6% | 100%
And "where the ACPI VFCT Table is missing, Power States may not work
properly" - so a constant iGPU load, caused by the missing ACPI VFCT
for iGPU in our case, adds about 8W to power consumption ~ about 12%
less battery life. HD 8570M or R5 M230 might be 20W TDP at max load
(hard to find exact info), but its' ACPI VFCT table is loaded by
coreboot, so a power consumption difference shouldn't be as big.
Currently I'm trying to add the XMP profiles support ( see
https://review.coreboot.org/c/coreboot/+/40291 ) so it could take me a
while to return to this research.
On 09.04.20 02:04, Peter Stuge wrote:
> I found something that might be relevant in https://del.dog/raw/cbmemlog
> however, search it for Remap:
> --8<-- https://del.dog/raw/cbmemlog#149
> PCI: 00:1c.0: Disabling device
> PCI: 00:1c.0: check set enabled
> PCH: Remap PCIe function 1 to 0
That's a weird puzzle. I've looked into the code, it's not mapping _to_
a specific number but swapping _with_ what was there last. So if the
idx 0 1 2 3 4 5 6 7
fn 0 1 2 3 4 5 6 7
this swaps what is at 0 with what is at 1:
idx 0 1 2 3 4 5 6 7
fn 1 0 2 3 4 5 6 7
> PCI: 00:1c.1 [8086/1c12] enabled
> PCI: 00:1c.2: Disabling device
> PCH: Remap PCIe function 3 to 0
Swaps what is at 3 with what is at 0:
idx 0 1 2 3 4 5 6 7
fn 3 0 2 1 4 5 6 7
> PCI: 00:1c.3 [8086/1c16] enabled
> PCH: Remap PCIe function 4 to 0
Swaps what is at 4 with what is at 0:
idx 0 1 2 3 4 5 6 7
fn 4 0 2 1 3 5 6 7
idx 1, 3 and 4 are on in the devicetree. So final relevant state:
idx 0 1 2 3 4 5 6 7
fn 0 1 3
This is not wrong. But the algorithm is that complex because it's
supposed to leave no gaps. And it fails at that in this case :-/
> --8<-- https://del.dog/raw/cbmemlog#175
> PCI: Leftover static devices:
> PCI: 00:01.0
> PCI: 00:16.1
> PCI: 00:16.2
> PCI: 00:16.3
> PCI: 00:1c.4
> PCI: 00:1c.2
> PCI: 00:1c.5
> PCI: 00:1c.7
> PCI: Check your devicetree.cb.
Partially my fault, when we added these messages, we didn't consider
devices that were hidden on purpose. I guess we should not complain
about devices on bus 0 with !dev->enabled (i.e. `off` in the device-
But here seems also something fishy wrt. the remapping: What about
It looks like QEMU supports TPM emulation via swtpm. The KConfig menu for the QEMU "boards" doesn't allow us to toggle TPM support as it does for say, the Chell board. Are there any blockers that would prevent the use of emulated TPM for QEMU "boards"? My apologies if this is a silly question, I'm a little out of my depth here.
I own an Acer Aspire VN7-572G and have not been impressed with its OEM
firmware. After discovering that it does not utilise Intel's Boot Guard
technology, that several Skylake and Kabylake laptops (it has a Skylake
chip, but I read that the platforms are similar) have received successful
coreboot ports and reading the porting guide on the wiki, I figured that I
could give porting coreboot to my laptop a shot.
When I was done, I figured that I had an image that might boot so I flashed
it to my laptop with a Raspberry Pi and a SOIC clip. However, here's what
a) It powers on quietly, as expected;
b) The backlight and power LED light up;
c) The fans spin up to high and then it stays that way. It does nothing
else. The display is dark too.
After 15 minutes and a second attempt, I figured that I could no longer
blame anything on a long first boot-up and gave up and flashed back to
Now, in all honesty I should have tried first without cleaning Intel ME but
I find it so much more likely that I did something wrong than that cleaning
ME was the sole problem.
Can anyone advise me on how to continue? My code is here:
I am a complete newb, though I want nothing more than to be able to program
at a bare metal level and help develop for this platform. How do I get
I am sure there is likely many emails like this, and I have truly done my
best hunting for information. I have a small understanding of assembly, and
have tried reading TRMs to no avail. Is there any texts anyone could
recommend to get me started?
I would truly be ever so grateful for any advice.