Re: [coreboot] [RFH] Status of the Lenovo X201

[qtux]

I wrote a patch [0] for the finalize code issue. With that my X201i is working 
fine on current master besides an regression introduced in commit 
7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD 
card is not working anymore and it raises the following errors:

[   17.986754] usb 1-1: device not accepting address 2, error -110
[   18.110095] usb 1-1: new high-speed USB device number 3 using ehci-pci
[   18.200089] usb 2-1: device not accepting address 2, error -110
[   18.323421] usb 2-1: new high-speed USB device number 3 using ehci-pci
[   34.200083] usb 1-1: device not accepting address 3, error -110
[   34.200169] usb usb1-port1: attempt power cycle
[   34.413364] usb 2-1: device not accepting address 3, error -110
[   34.413439] usb usb2-port1: attempt power cycle
[   34.636752] usb 1-1: new high-speed USB device number 4 using ehci-pci
[   34.850085] usb 2-1: new high-speed USB device number 4 using ehci-pci
[   45.293417] usb 1-1: device not accepting address 4, error -110
[   45.416732] usb 1-1: new high-speed USB device number 5 using ehci-pci
[   45.506783] usb 2-1: device not accepting address 4, error -110
[   45.630088] usb 2-1: new high-speed USB device number 5 using ehci-pci
[   56.173393] usb 1-1: device not accepting address 5, error -110
[   56.173445] usb usb1-port1: unable to enumerate USB device
[   56.386753] usb 2-1: device not accepting address 5, error -110
[   56.386845] usb usb2-port1: unable to enumerate USB device

Additionally there are some IRQ errors inside the kernel messages like

can't derive routing for PCI INT A
PCI INT A: no GSI

for different devices which seem related to the change in [1].

Cheers,
Matthias

[0] https://review.coreboot.org/#/c/coreboot/+/25914/
[1] https://review.coreboot.org/#/c/coreboot/+/22859/


On 29/04/18 14:14, Kyösti Mälkki wrote:
> On Sun, Apr 29, 2018 at 1:35 PM, Nicola Corna  wrote:
>> April 28, 2018 5:59 PM, "Nico Huber"  wrote:
>>
>>> Yes, that's very likely a problem. It looks like the whole finalize code
>>> path of the X201 was untested all the time (even on resume). I don't
>>> remember if EHCI debug works in SMM? If it does, you could enable log-
>>> ging for the SMI handler as well (if you want to debug it).
>>>
>>> Nico
>> Attached you can find the log with the SMM debug enabled, but it doesn't seem
>> to me much different from the non-debug log.
>>
>> Nicola
> DEBUG_SMI does not output to EHCI, I have considered it too unstable.
>
> You can try your luck with attached patch to have DEBUG_SMI=y output
> on EHCI debug. EHCI console code does not take precautions against
> someone else touching the same register set so it's likely to fail
> once payload and/or OS loads its EHCI driver, possibly making USB
> media and keyboard unusable as well.
>
> Kyösti


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

Re: [coreboot] Why do we have FSP-S

[Aaron Durbin via coreboot]

On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber  wrote:
> Hello coreboot folks, hello Intel and Google coreboot developers,
>
> back on Tuesday, some of us discovered a commit on gerrit [1] that
> implements (another) foreign interface inside coreboot. Discussing

It's more of a bridge into coreboot's infrastructure, imo.

> it didn't go well and I kind of bursted. I feel sorry about that now
> (especially because I got too personal).
>
> One of the causes for this clash definitely was that things apparently
> were discussed before but not with coreboot (i.e. this coreboot mailing
> list). So I'll try to take the general discussion here, but I've to
> start some years back, where you lost me.
>
> Some questions (that I believe have to be answered) right away. I'll
> argue about why later, so these won't get lost (in an already too long
> email):
>
>
> TLDR;
> For Google:
> You kind of introduced blobs in coreboot (with Sandy Bridge) which was
> a simple jump-in-jump-out thing and kind of accepted. The argument was
> that the things it does aren't documented by Intel anymore, AFAIR. But
> with Broadwell suddenly another blob emerged (in ramstage) some
> `refcode.elf` AIUI. It turned out, later, that this blob (also) does
> things that were open source for Haswell (and would work verbatim on
> Broadwell). It seems to play a role comparable to FSP-S.
>   o What's the story behind this blob?
>   o Why was it introduced?
>   o Was there more than IP concerns? Time to market pressure maybe?

Saying it's comparable to FSP-S is apt. The story is, like most
things, that it has specific things that are not architectural that
Intel thinks they need to be secret. Typical settings are related to
power management. When needing to be competitive in the laptop space
power is a big concern. Time to market may have been a thing too, but
I don't recall all the specifics. I'll get to it later in the
response, but there are temporal components to decisions and/or how
things change over time that are not within Google's control when
working on a particular platform.

>
> For Intel:
> It's hard for me to understand what parts of your silicon init you can
> open-source and what parts you can't. I know your BIOS Writer's Guides
> (BWG) / BIOS Spec, and many things therein are often published by you
> or Google. Please tell us.
>   o Are the things that you can *not* open-source documented at all?
>   o if so, in these BWG documents?
>   o Or is everything in these documents generally publishable (with
> some NDA clearance, ofc)?
>   o For a configuration of FSP-S that just runs the bare minimum to
> boot (e.g. skips questionable add-ons like TXT, SGX), is there
> anything not publishable?
>   o Can anything be done to get more documentation published? e.g.
> for things that are done in open source (or were done in the past)
> but are not publicly documented.

Based on my working history a lot of BWGs and/or specs are usually
wrong. They don't always contain the right information, but generally
contain quite a few things that are wrong where you second guess
everything in the docs. This should sound familiar: the 'reference
code' is the documentation. Most docs are not in sync with reality or
necessarily with how the silicon was actually designed. It's my belief
when there wasn't as much change from version to version, the
copy-pasting in docs just kinda worked. But as things have been
getting more complicated and incorporating more 'features' the
documentation has not been keeping up.

>
>
> So why ask? The original introduction of blobs in coreboot in general
> happened with the argument that the things it does (e.g. memory init)
> are not documented anymore by Intel. This is a valid argument because
> the lack of documentation makes it harder to write clean code. I also
> believe it's true (that no documentation exists) because I've seen a
> previous BWG that already referred a lot to the reference code.
>
> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never
> discussed. The blobs I've seen so far all did things that were already
> open source for earlier platforms. Plus they are twisting coreboot into
> something that isn't coreboot anymore. Architectural changes happen in
> chipset specific code instead of moving coreboot as a whole (after an
> open discussion). Also, most of the positive aspects about coreboot are
> lost.

Purely business commentary: In order to develop a competitive laptop
on recent hardware one needs to include the features that consumers
expect. Intel also ties those features inside of FSP, but FSP has a
responsibility problem. It has traditionally attempted to do things it
should not. FSP should be a library of sorts, but it has things in
there it shouldn't. I mentioned some of this on the CL itself about
our usage of SkipMpInit. It trying to take over resources that it
shouldn't (among other things).

What architectural changes are you referring to? 

[coreboot] Thinkpad X230, Intel ME and Wake on Lan

[Jan Malakhovski]

Hi.

An update for the future explorers of the thread.

I tried flashing X230 with the following ROMs:

- coreboot + vendor ME,
- coreboot + cleaned ME,
- coreboot + cleaned trimmed ME with relocated FPTR (ROMB + BUP).

I expected WoL power trick to stop working with the second ROM, but,
surprisingly, it still works. Makes me really wonder what function ME's
NFTP has, what code actually implements WoL, and where is the bit that
toggles it then?

By the way, with the last ROM IFB + GBE + cleaned relocated ME use less
than 100K of flash out of the available 12M (the rest is filled with
0xff and coreboot). 11.9M is a lot of space to play with. That's more
flash than my router has and I fit Linux + sbase + ubase + stripped-down
Emacs there, just saying :)

Also, coreboot with cleaned ME doesn't modify the flash from the second
boot on (it writes memory training results on the first boot), which,
finally, feels like a sane state of things (i.e. the machine can now do
an unlimited number of reboots without wearing-out the flash).

Cheers,
  Jan

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

Re: [coreboot] [RFH] Status of the Lenovo X201

[Kyösti Mälkki]

On Sun, Apr 29, 2018 at 1:35 PM, Nicola Corna  wrote:
> April 28, 2018 5:59 PM, "Nico Huber"  wrote:
>
>> Yes, that's very likely a problem. It looks like the whole finalize code
>> path of the X201 was untested all the time (even on resume). I don't
>> remember if EHCI debug works in SMM? If it does, you could enable log-
>> ging for the SMI handler as well (if you want to debug it).
>>
>> Nico
>
> Attached you can find the log with the SMM debug enabled, but it doesn't seem
> to me much different from the non-debug log.
>
> Nicola

DEBUG_SMI does not output to EHCI, I have considered it too unstable.

You can try your luck with attached patch to have DEBUG_SMI=y output
on EHCI debug. EHCI console code does not take precautions against
someone else touching the same register set so it's likely to fail
once payload and/or OS loads its EHCI driver, possibly making USB
media and keyboard unusable as well.

Kyösti


usbdebug-in-smi
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [URGENT] Full List of AMD-based boards that are going to be removed from coreboot unless people cough up a board status update

[Raphaël Jacquot]

On 28/04/2018 14:37, Mike Banon wrote:

There are a lot of nice AMD-based coreboot-supported boards which have
an outdated board_status and are at risk of removal. The majority of
these boards (with the exception of PC engines apu2//3//4//5) - do not
require a closed source AMD PSP binary to run, and ( also compared to
many Intel boards which require Intel ME proprietary binary ) these
AMD boards are highly user-controllable - some of them are even
supported by the libreboot project!


according to https://www.pcengines.ch:


PC Engines alix1c - AMD LX - 2017-09-17


replaced by Alix1e - eol


PC Engines alix2d - AMD LX - 2017-09-17


still produced but not recommended for new designs


PC Engines apu1 - AMD Family 14h (AGESA) - 2017-09-05


APU1D and APU1D4 in active prodution


PC Engines apu2 // apu3 // apu4 // apu5 - AMD 00730F01 (PI) - 2017-10-26


this is the most recent system and actively produced

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