Re: [coreboot] APIC and lspci

[杜睿哲_Pegatron]

Hi Nico,

I think there is no MSI mode in my system.
In my case, device 00:14.0 is SATA controller and as you said, there is likely 
a 1 to 1 mapping, so I expect it should maps to one of IRQ16-23 for IOxAPIC. 
But from lspci, it is IRQ28 and I want to know if this is changed in Coreboot 
or in kernel and where to modify it. Another is my MAC (02:00.0) which connects 
to Denverton through PCI-e, the lspci's output is "pin A routed to IRQ 0". Why 
IRQ0 is being used? Anything I forgot to configure?  I'll check the BWG, but I 
have to admit I am too "fresh" to understand it :p. If you know something, 
please advise. Thanks.

-Hilbert

-Original Message-
From: Nico Huber [mailto:nic...@gmx.de]
Sent: Tuesday, September 04, 2018 1:46 AM
To: Hilbert Tu(杜睿哲_Pegatron); coreboot@coreboot.org
Subject: Re: [coreboot] APIC and lspci

Hi Hilbert,

On 03.09.2018 12:36, Hilbert Tu(杜睿哲_Pegatron) wrote:
> I have a customized Intel Denverton-NS platform similar like Harcuvar
> CRB. In dmesg, I can see following:
> [   10.973387] ACPI: PCI Interrupt Link [LNKA] (IRQs 6 7 10 *11 12 14 15)
> [   10.981587] ACPI: PCI Interrupt Link [LNKB] (IRQs 6 7 *10 11 12 14 15)
> [   10.989776] ACPI: PCI Interrupt Link [LNKC] (IRQs *6 7 10 11 12 14 15)
> [   10.997961] ACPI: PCI Interrupt Link [LNKD] (IRQs 6 *7 10 11 12 14 15)
> [   11.006147] ACPI: PCI Interrupt Link [LNKE] (IRQs 6 7 10 11 *12 14 15)
> [   11.014332] ACPI: PCI Interrupt Link [LNKF] (IRQs 6 7 10 11 12 *14 15)
> [   11.022518] ACPI: PCI Interrupt Link [LNKG] (IRQs 6 7 10 11 12 14 *15)
> [   11.030697] ACPI: PCI Interrupt Link [LNKH] (IRQs 6 7 10 11 12 14 *15)
> And by “lspci -s 00:14.0 -vv”, there is a message “Interrupt: pin A
> routed to IRQ 28”. Actually I know in the devicetree.cb, the device 14’s
> interrupt is configured by IR08 which routes INTA to PIRQE and LNKE is
> using IRQ12. This is the legacy interrupt mode as kernel message dumped.
> But in ACPI mode, why does lspci report IRQ28 and how to reconfigure it
> in Coreboot? Please help to clarify. Thanks.

there is actually a third case, MSI interrupts. It's hard to tell if
that is used without seeing the lspci output. MSIs are configured by
the OS, not coreboot.

In APIC mode, there is likely a 1:1 mapping of the PIRQ LNK* to APIC
IRQs; e.g. LNKA -> 16, LNKB -> 17, ..., LNKH -> 23 (this usually can't
be changed, but I don't know for sure if that is the case for Denver-
ton). It should be documented in the BIOS Writer's Guide for your SoC.

Nico
This e-mail and its attachment may contain information that is confidential or 
privileged, and are solely for the use of the individual to whom this e-mail is 
addressed. If you are not the intended recipient or have received it 
accidentally, please immediately notify the sender by reply e-mail and destroy 
all copies of this email and its attachment. Please be advised that any 
unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X230 + 32GB RAM ?

[David Potocnik]

Thanks very much sir!

I guess it makes most sense to just have two of these machines side by
side, and split the workload. ;-)


On 3 September 2018 at 19:30, Nico Huber  wrote:

> Hi David,
>
> On 03.09.2018 19:13, David Potocnik wrote:
> > Coreboot, or perhaps rule it out completely?
>
> it's impossible, unless you want to heavily mod the mainboard. Ivy
> Bridge supports 4 ranks per channel, max 4GiB per rank. SO-DIMMs have
> only 2 ranks. So with 2 SO-DIMM slots, there are physical connections
> missing to get to 32GiB.
>
> > Information on RAM frequencies is welcome as well:
> >
> > I've also heard reports of people running the RAM at 1866Mhz. A newer
> > version of the official BIOS reduced the original 1666Mhz, to 1333Mhz. I
> > believe there's a mod available that over-rides this:
> > http://x220.mcdonnelltech.com/resources/
> >
> >
> > How is this currently on Coreboot?
>
> coreboot limits the frequency to whatever the board manufacturer con-
> figured the chipset to (using one-time programmable fuses). It can be
> configured, however, to ignore the fuses. Then it would use whatever
> the RAM supports up to the CPU's limit. This is overclocking so there
> is no guarantee that it would work on one X230 sample just because it
> works on another. And there is probably no real-world application that
> would benefit (2 x DDR3-800 is already quite fast compared to what Ivy
> bridge can do with the data).
>
> Hard to tell why Lenovo lowered the frequency late. Maybe because there
> was no performance impact but it saves power?
>
> Nico
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] APIC and lspci

[Nico Huber]

Hi Hilbert,

On 03.09.2018 12:36, Hilbert Tu(杜睿哲_Pegatron) wrote:
> I have a customized Intel Denverton-NS platform similar like Harcuvar
> CRB. In dmesg, I can see following:
> [   10.973387] ACPI: PCI Interrupt Link [LNKA] (IRQs 6 7 10 *11 12 14 15)
> [   10.981587] ACPI: PCI Interrupt Link [LNKB] (IRQs 6 7 *10 11 12 14 15)
> [   10.989776] ACPI: PCI Interrupt Link [LNKC] (IRQs *6 7 10 11 12 14 15)
> [   10.997961] ACPI: PCI Interrupt Link [LNKD] (IRQs 6 *7 10 11 12 14 15)
> [   11.006147] ACPI: PCI Interrupt Link [LNKE] (IRQs 6 7 10 11 *12 14 15)
> [   11.014332] ACPI: PCI Interrupt Link [LNKF] (IRQs 6 7 10 11 12 *14 15)
> [   11.022518] ACPI: PCI Interrupt Link [LNKG] (IRQs 6 7 10 11 12 14 *15)
> [   11.030697] ACPI: PCI Interrupt Link [LNKH] (IRQs 6 7 10 11 12 14 *15)
> And by “lspci -s 00:14.0 -vv”, there is a message “Interrupt: pin A
> routed to IRQ 28”. Actually I know in the devicetree.cb, the device 14’s
> interrupt is configured by IR08 which routes INTA to PIRQE and LNKE is
> using IRQ12. This is the legacy interrupt mode as kernel message dumped.
> But in ACPI mode, why does lspci report IRQ28 and how to reconfigure it
> in Coreboot? Please help to clarify. Thanks.

there is actually a third case, MSI interrupts. It's hard to tell if
that is used without seeing the lspci output. MSIs are configured by
the OS, not coreboot.

In APIC mode, there is likely a 1:1 mapping of the PIRQ LNK* to APIC
IRQs; e.g. LNKA -> 16, LNKB -> 17, ..., LNKH -> 23 (this usually can't
be changed, but I don't know for sure if that is the case for Denver-
ton). It should be documented in the BIOS Writer's Guide for your SoC.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X230 + 32GB RAM ?

[Nico Huber]

Hi David,

On 03.09.2018 19:13, David Potocnik wrote:
> Coreboot, or perhaps rule it out completely?

it's impossible, unless you want to heavily mod the mainboard. Ivy
Bridge supports 4 ranks per channel, max 4GiB per rank. SO-DIMMs have
only 2 ranks. So with 2 SO-DIMM slots, there are physical connections
missing to get to 32GiB.

> Information on RAM frequencies is welcome as well:
> 
> I've also heard reports of people running the RAM at 1866Mhz. A newer
> version of the official BIOS reduced the original 1666Mhz, to 1333Mhz. I
> believe there's a mod available that over-rides this:
> http://x220.mcdonnelltech.com/resources/
> 
> 
> How is this currently on Coreboot?

coreboot limits the frequency to whatever the board manufacturer con-
figured the chipset to (using one-time programmable fuses). It can be
configured, however, to ignore the fuses. Then it would use whatever
the RAM supports up to the CPU's limit. This is overclocking so there
is no guarantee that it would work on one X230 sample just because it
works on another. And there is probably no real-world application that
would benefit (2 x DDR3-800 is already quite fast compared to what Ivy
bridge can do with the data).

Hard to tell why Lenovo lowered the frequency late. Maybe because there
was no performance impact but it saves power?

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Lenovo X230 + 32GB RAM ?

[David Potocnik]

Hi all,

Please excuse this absolutely green question.

But it crossed my mind a few times now, and I've seen mentions of it with
people, as unqualified as I am, speculating about it here and there.

So, the Lenovo X230 sports Ivy Bridge CPUs, which apparently support 32GB
RAM.
https://ark.intel.com/products/64893/Intel-Core-i7-3520M-Processor-4M-Cache-up-to-3_60-GHz

Even though the official Lenovo documentation says the max RAM supported is
16GB, the docs also claimed 8GB was max for X220. And many of us were happy
to realize that wasn't true, running 16GB.

I've heard (possibly uninformed) mentions that the 16GB limit in X230 is a
BIOS limit. Could anyone think it would be possible to make this work with
Coreboot, or perhaps rule it out completely?


Information on RAM frequencies is welcome as well:

I've also heard reports of people running the RAM at 1866Mhz. A newer
version of the official BIOS reduced the original 1666Mhz, to 1333Mhz. I
believe there's a mod available that over-rides this:
http://x220.mcdonnelltech.com/resources/


How is this currently on Coreboot?


Does anyone see any possible developments in these directions?

Kind regards to anyone that would shed light on this.

- David
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel ME what is it? And when did this dangerous thing get installed?

[John Keates]

> On 3 Sep 2018, at 11:54, Philipp Stanner  wrote:
> 
> Am Mittwoch, den 29.08.2018, 04:09 -0400 schrieb Youness Alaoui:
>> If there are more specific questions that you have, ask them and I
>> might be able to answer them!
> 
> I might have one: What does stop a motherboard-vendor from just buying
> a CPU and implementing it? Which chips, beside the CPU, do you need
> from Intel in any case to make the machine work?

As usual, it boils down to money. You also need data from Intel to make a CPU 
work (microcode, FSP).
Creating a chipset, making RAM work etc. can easily cost you hundreds of 
millions. On top of that, it’s hard to make money off of it, making it 
double-bad from a capitalistic-commercial perspective.
There is a reason you don’t get to choose a chipset anymore; Nvidia and VIA 
(and others) once were in the business of making chipsets, but not any more.


> I always thought of the CPU just as a machine executing code, and
> assumed it's possible to use it just as any microcontroller: You can
> add the ME-Chipset, but you don't have to.
> 

Well, yes and no. There are plenty of CPU models out there that require 
specific Intel code to work, some of them cryptographically locking anyone else 
out.
End-users don’t care, and technical users don’t have enough power to do 
anything about it on the Intel side of things.

> Philipp
> 
> 
> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

Regards,
John


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] APIC and lspci

[杜睿哲_Pegatron]

Hi,

I have a customized Intel Denverton-NS platform similar like Harcuvar CRB. In 
dmesg, I can see following:
[   10.973387] ACPI: PCI Interrupt Link [LNKA] (IRQs 6 7 10 *11 12 14 15)
[   10.981587] ACPI: PCI Interrupt Link [LNKB] (IRQs 6 7 *10 11 12 14 15)
[   10.989776] ACPI: PCI Interrupt Link [LNKC] (IRQs *6 7 10 11 12 14 15)
[   10.997961] ACPI: PCI Interrupt Link [LNKD] (IRQs 6 *7 10 11 12 14 15)
[   11.006147] ACPI: PCI Interrupt Link [LNKE] (IRQs 6 7 10 11 *12 14 15)
[   11.014332] ACPI: PCI Interrupt Link [LNKF] (IRQs 6 7 10 11 12 *14 15)
[   11.022518] ACPI: PCI Interrupt Link [LNKG] (IRQs 6 7 10 11 12 14 *15)
[   11.030697] ACPI: PCI Interrupt Link [LNKH] (IRQs 6 7 10 11 12 14 *15)
And by “lspci -s 00:14.0 -vv”, there is a message “Interrupt: pin A routed to 
IRQ 28”. Actually I know in the devicetree.cb, the device 14’s interrupt is 
configured by IR08 which routes INTA to PIRQE and LNKE is using IRQ12. This is 
the legacy interrupt mode as kernel message dumped. But in ACPI mode, why does 
lspci report IRQ28 and how to reconfigure it in Coreboot? Please help to 
clarify. Thanks.

-Hilbert
This e-mail and its attachment may contain information that is confidential or 
privileged, and are solely for the use of the individual to whom this e-mail is 
addressed. If you are not the intended recipient or have received it 
accidentally, please immediately notify the sender by reply e-mail and destroy 
all copies of this email and its attachment. Please be advised that any 
unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] how to change PCI device's PFA

[杜睿哲_Pegatron]

Hi Lance,

Got it. I’ll check that. Thanks.

-Hilbert

From: Lance Zhao [mailto:lance.z...@gmail.com]
Sent: Saturday, September 01, 2018 1:29 AM
To: Hilbert Tu(杜睿哲_Pegatron)
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] how to change PCI device's PFA

Those devices have been fixed from chipset, I don't think any software side can 
change that. I will prefer to have a quick scan of PCI spec 2.2 first, which 
mentioned that clearly.


On Thu, Aug 30, 2018 at 11:44 PM Hilbert Tu(杜睿哲_Pegatron) 
mailto:hilbert...@pegatroncorp.com>> wrote:
Hi,

In my devicetree.cb of Intel Harcuvar CRB, I see the following PCI 
configuration:
device pci 14.0 on end # SATA Controller 1
device pci 15.0 on end # XHCI USB Controller

Can I change the device number for each different PCI device? For example,
device pci 16.0 on end # SATA Controller 1
device pci 17.0 on end # XHCI USB Controller

Is this PCI enumeration same in Coreboot and kernel? Or can I change it 
dynamically?

Thanks.
-Hilbert
This e-mail and its attachment may contain information that is confidential or 
privileged, and are solely for the use of the individual to whom this e-mail is 
addressed. If you are not the intended recipient or have received it 
accidentally, please immediately notify the sender by reply e-mail and destroy 
all copies of this email and its attachment. Please be advised that any 
unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel ME what is it? And when did this dangerous thing get installed?

[Philipp Stanner]

Am Mittwoch, den 29.08.2018, 04:09 -0400 schrieb Youness Alaoui:
> If there are more specific questions that you have, ask them and I
> might be able to answer them!

I might have one: What does stop a motherboard-vendor from just buying
a CPU and implementing it? Which chips, beside the CPU, do you need
from Intel in any case to make the machine work?
I always thought of the CPU just as a machine executing code, and
assumed it's possible to use it just as any microcontroller: You can
add the ME-Chipset, but you don't have to.

Philipp


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)

[Peter Stuge]

John Keates wrote:
> unless I can by the U-series CPU’s myself from a shady vendor without
> any blown fuses, I do have a reball & SMT rework lab nearby

Consider buying a donor mainboard for whatever system with the CPU you need
(in the state you need) and asking the lab to replace the one on your board.

I think it will be difficult to source a single CPU in a specific mode.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)

[Lil Evil]

Hi John,

I am the original poster of the thread you have quoted. all, apologies for the 
html formatted mail from my webmailer...
Great to see that I am not alone with my endeavor. However, due to other 
projects and lack of time, I have put this project temporarily on hold.
I have flashed a couple of coreboot trials, but the machine just spins up the 
fan in various patterns. Debug via serial console didn't work in this early 
stage. Getting some output there would be a great step ahead since I don't see 
any other debug option on this non-dev board.

regarding BootGuard:
I dont think bootguard is enforced, but its a while since I looked into the 
guts how this is acutally working.
However, I have patched my BIOS to include updated microcode, disabled ME and 
enabled all configuration options in the AMI bios. 
As a side effect I got an menuentry to enable secure boot and tinker with the 
key management, which I have not touched so far.
But based on the modifications I have done, I am pretty sure this shouldnt be 
an issue.

regarding FSP:
the Qotom board is very close to the intel dev board mentioned in my initial 
post and there are outdated coreboot patches under intel NDA that I couldnt get 
my hands on.
There is actually support for thie board in coreboot and you can get the FSP 
from intel's website, but coreboot is missing the FSP integration for those.
For FSP support the most probable option is to extract those from the firmware 
updates of google images, which I haven't started as I am tight up in other 
projects at the moment.

Let me know how I can best support your efforts
cheers
lIl
 
 

Gesendet: Samstag, 01. September 2018 um 21:01 Uhr
Von: "John Keates" 
An: "Nico Huber" 
Cc: coreboot 
Betreff: Re: [coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)
> On 31 Aug 2018, at 12:07, Nico Huber  wrote:
>
> Hi John,
>
> Am 29.08.18 um 04:02 schrieb John Keates:
>> Thank you for your reply! Sadly, Boot Guard is enabled in Verified Boot
>> mode. I’ll ask if Qotom can spin up a batch without any public key
>> burned into the CPU, or perhaps share the private key. (which is
>> obviously unlikely — but one can try)
>
> there are other alternatives; BootGuard has not a single key but a
> key hierarchy (probably for more profitable licensing schemes). So
> you could try to get your own certificate signed by Qotom. But...
> I can only advice against using BootGuard at all. If you don't have
> one, you'd be looking forward to an NDA with Intel*. Also, you'd have
> to integrate Intel's BootGuard ACM (piece of software that runs be-
> fore host firmware) into your coreboot image and might also have to
> adapt the early boot process of coreboot itself.

I thought the ACM was part of the ME or part of the Microcode itself, but I can 
be wrong.
From what I’ve read, the CPU has the hash of a public key burned in using 
fuses, but that can only be done during manufacturing with the PCH attached.
This was because the fuses are blown using the ME, and the ME has control over 
the first address the CPU will start executing code from. So the CPU has some 
minimal code besides the microcode, both is signed by Intel. That code is also 
used to verify with the ME that the SPI flash has signed contents and because 
the check is done super early, only the result is taken, not the action that 
might follow from the result; so good signature/bad signature only stops the 
CPU if the ME is active and a (signed) Boot Guard policy exists to do anything 
about this.
That is why the exploit with the older Gigabyte motherboards worked where you 
remove the BootGuard DXE (or was it a PEI module?) and then the Boot Guard init 
still works and lets the CPU run, but the follow-up (halting/continuing) is 
never executed.
The same was with a TXE bug where you can drop the ME into debug mode and 
access it’s JTAG via USB3, which can also be replaced in existing firmwares. 
When using JTAG, you can store permanent changes in the ME firmware using the 
ME CPU itself to disable Boot Guard pre-flash and also-post flash.

Another thing is the manufacturing mode PCH hard strap which puts the ME in 
insecure/BUP only mode, but I haven’t found any reference to what that does to 
Boot Guard. It would be fine for me if that disables Boot Guard follow-up (it 
still runs the init checks), because I can permanently bridge the ME mode pads 
to keep it in manufacturing mode. (this board has in fact two options, one is 
ME1 which is a jumper, and puts it in Jumper Security Override mode, another is 
a GPOP33 pin strap which either does ‘more’ or something similar.

I suppose I could check this by flipping a few bits in the SPI flash and 
checking if it still boots, and then pull the jumper and check again.

> About the port itself. There is another pitfall: Intel FSP for Broad-
> well is not integrated into upstream coreboot. What is integrated are
> Google's blobs that do about the same as FSP but seem to be only licen-
> sable as part of