[coreboot] Re: t420s USB 3.0 port

[Iru Cai]

Hi Jason,

On Fri, Mar 1, 2019 at 10:33 AM Jason Andryuk  wrote:

> Hi,
>
> I have a Lenovo Thinkpad t420s on which I've installed coreboot.
> However, the USB 3.0 port is not active and the controller is not
> listed under lspci.
>
> Under the original Lenovo bios, the xhci device was at pci address
> 0d:00.0 behind bridge 00:1c.4.
>
> It looks like the t420s devicetree.cb is set up for the xhci
> controller to be behind 00:1c.6.  I changed that to 00:1c.4 and that
> got the xhci pci device to show up as 03:00.0.  Strangely, booting
> into linux, it shows 001c.3 as the bridge to 03:00.0.  Additionally,
> plugged in USB devices were not detected.
>

Note that the mainboard has pcie_port_coalesce set in the devicetree, so it
can be wrong to just see the BDF address to know which port the XHCI device
is connected to.

However, lspci also shows the port, it'll show `PCI Express Root Port X`
where X is actually the port number (PCI function number + 1). The function
number in the device tree is based on this port number.


> Here's where it gets weird.  I had a mouse plugged in, and I was
> looking in sysfs.
> cat /sys/devices/pci\:00/\:00\:1c.3/\:03\:00.0/enable
> 0
> So the xhci pci device is disabled.  I ran `lspci -vvnn` a few times
> in quick sucession - I was looking to see if it showed disabled - and
> the mouse lit up!
>
> Plugging in a USB Flash drive, it was again not detected.  The lspci
> trigger worked.  Later, promptly switching USB devices resulted in the
> new USB device still being detected.
>
> Is "PCH: PCIe map 1c.4 -> 1c.3" the remapping from the device tree
> 1c.4 to the 1c.3 that I see?
>
> Below I've included the cbmem -c output and a snippet from an old
> lenovo BIOS dmesg w/ the pci address.
>
> Does anyone have an idea of what is going on, or what I should
> investigate next?  A total guess, but could poking the PCI device with
> lspci turn it on so that it may detect an attached device and then
> stay active?  Maybe something with power management?  Again, I'm just
> guessing.  Any suggestions are appreciated.
>
> Thanks,
> Jason
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] t420s USB 3.0 port

[Jason Andryuk]

Hi,

I have a Lenovo Thinkpad t420s on which I've installed coreboot.
However, the USB 3.0 port is not active and the controller is not
listed under lspci.

Under the original Lenovo bios, the xhci device was at pci address
0d:00.0 behind bridge 00:1c.4.

It looks like the t420s devicetree.cb is set up for the xhci
controller to be behind 00:1c.6.  I changed that to 00:1c.4 and that
got the xhci pci device to show up as 03:00.0.  Strangely, booting
into linux, it shows 001c.3 as the bridge to 03:00.0.  Additionally,
plugged in USB devices were not detected.

Here's where it gets weird.  I had a mouse plugged in, and I was
looking in sysfs.
cat /sys/devices/pci\:00/\:00\:1c.3/\:03\:00.0/enable
0
So the xhci pci device is disabled.  I ran `lspci -vvnn` a few times
in quick sucession - I was looking to see if it showed disabled - and
the mouse lit up!

Plugging in a USB Flash drive, it was again not detected.  The lspci
trigger worked.  Later, promptly switching USB devices resulted in the
new USB device still being detected.

Is "PCH: PCIe map 1c.4 -> 1c.3" the remapping from the device tree
1c.4 to the 1c.3 that I see?

Below I've included the cbmem -c output and a snippet from an old
lenovo BIOS dmesg w/ the pci address.

Does anyone have an idea of what is going on, or what I should
investigate next?  A total guess, but could poking the PCI device with
lspci turn it on so that it may detect an attached device and then
stay active?  Maybe something with power management?  Again, I'm just
guessing.  Any suggestions are appreciated.

Thanks,
Jason

Old linux dmesg from Lenovo BIOS:
Dec  6 01:55:52 ubuntu kernel: [   10.077337] pci :0d:00.0:
>[1033:0194] type 00 class 0x0c0330
Dec  6 01:55:52 ubuntu kernel: [   10.077382] pci :0d:00.0: >reg
10: [mem 0xf0c0-0xf0c01fff 64bit]
Dec  6 01:55:52 ubuntu kernel: [   10.077610] pci :0d:00.0: >PME#
supported from D0 D3hot D3cold
Dec  6 01:55:52 ubuntu kernel: [   10.077701] pci :00:1c.4: >PCI
bridge to [bus 0d-0d]
Dec  6 01:55:52 ubuntu kernel: [   10.077714] pci :00:1c.4: >
bridge window [mem 0xf0c0-0xf0cf]

cbmem -c dump:

*** Pre-CBMEM romstage console overflowed, log truncated! ***
666 MHz
Selected CAS latency   : 9T
PLL busy... done in 50 us
MCU frequency is set at : 666 MHz
Done dimm mapping
Update PCI-E configuration space:
PCI(0, 0, 0)[a0] = 0
PCI(0, 0, 0)[a4] = 4
PCI(0, 0, 0)[bc] = 82a0
PCI(0, 0, 0)[a8] = 7d60
PCI(0, 0, 0)[ac] = 4
PCI(0, 0, 0)[b8] = 8000
PCI(0, 0, 0)[b0] = 80a0
PCI(0, 0, 0)[b4] = 8080
Done memory map
Done io registers
t123: 1912, 9120, 500
ME: FW Partition Table  : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode  : YES
ME: Boot Options Present: NO
ME: Update In Progress  : NO
ME: Current Working State   : Initializing
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Debug or Disabled by AltDisableBit
ME: Error Code  : No Error
ME: Progress Phase  : BUP Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State: Check to see if straps say ME DISABLED
ME: Wrong mode : 2
ME: FWS2: 0x100a
ME:  Bist in progress: 0x0
ME:  ICC Status  : 0x0
ME:  Invoke MEBx : 0x0
ME:  CPU replaced: 0x0
ME:  MBP ready   : 0x0
ME:  MFS failure : 0x0
ME:  Warm reset req  : 0x0
ME:  CPU repl valid  : 0x0
ME:  (Reserved)  : 0x0
ME:  FW update req   : 0x0
ME:  (Reserved)  : 0x0
ME:  Current state   : 0xa
ME:  Current PM event: 0x0
ME:  Progress code   : 0x1
Waited long enough, or CPU was not replaced, continue...
PASSED! Tell ME that DRAM is ready
ME: ME is reporting as disabled, so not waiting for a response.
ME: FWS2: 0x100a
ME:  Bist in progress: 0x0
ME:  ICC Status  : 0x0
ME:  Invoke MEBx : 0x0
ME:  CPU replaced: 0x0
ME:  MBP ready   : 0x0
ME:  MFS failure : 0x0
ME:  Warm reset req  : 0x0
ME:  CPU repl valid  : 0x0
ME:  (Reserved)  : 0x0
ME:  FW update req   : 0x0
ME:  (Reserved)  : 0x0
ME:  Current state   : 0xa
ME:  Current PM event: 0x0
ME:  Progress code   : 0x1
ME: Requested BIOS Action: No DID Ack received
ME: FW Partition Table  : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode  : YES
ME: Boot Options Present: NO
ME: Update In Progress  : NO
ME: Current Working State   : Initializing
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Debug or Disabled by AltDisableBit
ME: Error Code  : No Error
ME: Progress Phase  : BUP Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State: Check to see if straps say ME DISABLED
memcfg DDR3 ref clock 133 MHz
memcfg DDR3 clock 1330 MHz
memcfg channel assignment: A: 0, B  1, C  2
memcfg channel[0] config (00620020):
   ECC inactive
   enhanced interleave mode on
   rank interleave on
   DIMMA 8192 MB width x8 dual rank, selected
   DIMMB 0 MB width x8 

[coreboot] Re: Intel Xeon D-1577 (16-core)

[Jay Talbott]

Since it is a race condition, there are many factors that come into play
that determine if it would cause the SoC to lock up or not, so my statement
that it's a problem with SKUs with more than 4 cores is just a
generalization. Other factors that could impact the timing of the execution
of the SMM relocation code on each core during MP init could result in
masking the problem. Frankly, it's just a fluke that it wasn't caught in the
original development of the Broadwell-DE solution, and only because it can't
be reproduced on the Camelback Mountain CRBs with the stock 4-core SKU that
was in all of them that were built back in the day.

Serialization of the SMM relocation code, which would otherwise run in
parallel on all cores with no serialization, is what masks the race
condition, be it from either turning up the console output such that printks
in the code path are executed, OR by a call to wbinvd() in function
smm_relocation_handler() in file
src/soc/intel/fsp_broadwell_de/smmrelocate.c. But again, this just masks the
underlying root cause.

My point is that the race condition itself exists in the code regardless of
what SKU you are using. The number of cores that execute the SMM relocation
code in parallel just increases the chance of causing a lockup. Our
experience with a 12-core SKU was that it would lock up 100% of the time if
the console level was dialed down and before we introduced the wbinvd()
workaround. And others on this list have reported similar results with other
SKUs with more than 4 cores. But again, when it comes to race conditions,
there are many factors that come into play that could impact whether or not
a lockup occurs.

Looking at the last post code dumped to the console in the original message
before it hung, I immediately recognized that from when we saw the same
hang. That's the last post code you get before the MP init code takes off
and ultimately runs the SMM relocation handler code.

Bottom line is that at some point somebody should investigate the underlying
root cause and fix it right. At the moment, we are busy with other things
and don't have the bandwidth to look into it deeper, but at least we have a
pretty good idea of where the problem lies.

- Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3057 E. Muirfield St.
Gilbert, AZ 85298
(480) 704-8045
(480) 445-9895 (FAX)
jaytalb...@sysproconsulting.com
http://www.sysproconsulting.com

> -Original Message-
> From: Frans Hendriks [mailto:fhendr...@eltan.com]
> Sent: Thursday, February 28, 2019 1:13 AM
> To: coreboot@coreboot.org
> Cc: 'Jay Talbott'; aure...@platinasystems.com
> Subject: [coreboot] Re: Intel Xeon D-1577 (16-core)
> 
> This relocation is performed in a later stage, so some output is expected.
> Is (correct) microcode included for D-1577?
> 
> I assume wbinvd() must be included in  smm_relocation() function.
> (We have implemented coreboot on several Broadwell-DE boards with >4
> cores
> without using wbinv() of 8:SPEW.)
> 
> Best regards,
> Frans Hendriks
> Eltan B.V.
> 
> 
> -Original Message-
> From: Jay Talbott [mailto:jaytalb...@sysproconsulting.com]
> Sent: woensdag 27 februari 2019 22:19
> To: aure...@platinasystems.com; coreboot@coreboot.org
> Subject: [coreboot] Re: Intel Xeon D-1577 (16-core)
> 
> There's a bug in the SMM relocation code for Broadwell-DE that causes a
race
> condition resulting in the SoC locking up during the MP init. With the
stock
> 4-core SKU that comes in most of the Camelback Mountain CRBs, it's not a
> problem, which is why Intel didn't find it when they developed the
original
> coreboot implementation for the CRB. But as has been reported previously
> on
> this list, it becomes a problem with more than 4 cores. We actually have
an
> open ticket with Intel to see if they are willing to diagnose the root
cause
> and fix it, but I have zero expectation that any action will ever be done
on
> their part at this point.
> 
> If you turn up your console output level to 8:SPEW, the problem will go
> away, as the extra printks that get enabled in that case result in
> serialization of the SMM relocation code on each core, thus masking the
race
> condition (try this first!).
> 
> Another workaround is to insert a call to wbinvd() in function
> smm_relocation_handler() in file
> src/soc/intel/fsp_broadwell_de/smmrelocate.c. This will also result in
> serialization that masks the race condition (fixed it for us on a 12-core
> SKU) without needing to have the console turned all the way up.
> 
> At some point somebody needs to dig into the actual code in smmrelocate.c
> and identify the root cause of the actual race condition. We just haven't
> had the time to do any further investigation into the root cause since we
> have a working workaround.
> 
> Hope that helps...
> 
> - Jay
> 
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> Gilbert, AZ 85298
> (480) 704-8045
> (480) 445-9895 (FAX)
> 

[coreboot] Re: New API to clear DRAM at boot

[ron minnich]

On Wed, Feb 27, 2019 at 8:27 AM  wrote:
> I noticed in your patch you are calling this host CPU based clearing after 
> the return from FSP memory initialization.  If you are calling this in a 
> system with ECC memory, this step is redundant.  Part of the initialization 
> of ECC enabled memory is to write a pattern to all of memory to setup the ECC 
> code.

This is a bad idea for many people for a simple reason: sometimes you
don't want memory cleared. We deliberately did not clear memory in
coreboot for many years, starting in 1999, following the practice of
unix: memory setup was the kernel's job and could even be done lazily
or on demand. This allows you, even after a power cycle, to do some
post mortem in the event of a failure, or even upload the contents to
a server for later analysis. This is useful in many places, from
supercomputer to data center to laptop, especially in development.
Hardwiring memory clearing behavior as part of ECC setup is a poor
decision IMHO. It's like doing a lobotomy every time you boot, and
after a failure, you REALLY want that memory data. We should at least
have a choice.

The preferred way to do this is to read the memory and write it back,
with ECC traps disabled, to get the ECC bits set up. Memory contents
are preserved and ECC is set up correctly. Especially in this case,
the speed tradeoff is not worth it.

The engine is interesting but it's another case of proprietary
firmware designers (as in FSP) implementing a neat idea without
thinking of user consequences. This is disappointing. Were FSP open
source, we could explore the option space, but as it is, we're just
twiddling the knobs on a black box. The fact that someone as
knowledgeable as Patrick might not have known this tells you how
obscure the information is. That's not good.

ron
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Nico Huber]

Hi Michal,

On 28.02.19 10:38, Michal Zygowski wrote:
> AFAIK gerrit now adds the reviewers to patches based on MAINTAINERS
> file. It would be great to be added automatically to Braswell patches.
> Is there a way to workaround that without being Braswell maintainer?

you can just push a patch that adds you to the MAINTAINERS file. I don't
think there is any requirement to be a maintainer, it's just your offer
to look into things. Please also consider removing stale entries and up-
dating the status (e.g. from Supported to Maintained, in case you prefer
that).

You can also set up "Notifications" in Gerrit based on a search pattern.

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Michal Zygowski]

On 28.02.2019 09:52, Matt DeVillier wrote:
> hi Frans,
>
> I'm happy to review these patches (and think I have for some already),
> but as my Braswell-based ChromeOS boards don't require them, a little
> more explanation in the commit msgs as to what issue they are
> resolving would be helpful in that regard.  Obviously I'd like to test
> them and ensure no regressions for my boards as well
Hi Matt,

I have added some comments to these patches. As ChromeOS may not require
them (and I am aware of that since I worked once with Chromebook), the
SeaBIOS payload have problems (especially with interrupts and keyboard
input) and other operating systems complain. We are awaiting for Your
review.

I have added short comments on few of these patches. Feel free to ask
questions under the patches, I will hopefully give satisfying answers.

>
> cheers,
> Matt
Best regards,
Michał
>
> On Thu, Feb 28, 2019 at 2:42 AM Frans Hendriks  > wrote:
>
> An additional question related to this SoC and new mainboards:
> Should maintainer of Braswell SoC also take care of review/merge
> new mainboards based on this chipset?
>
> Who should merge new boards?
> (I have uploaded code for two mainboards based on this SoC, where
> 1 is waiting 3 months to be merged?)
>
> Best regards,
> Frans Hendriks
> Eltan B.V.
>
> -Original Message-
> From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com
> ]
> Sent: donderdag 28 februari 2019 09:20
> To: Michal Zygowski  >; coreboot@coreboot.org
> 
> Subject: [coreboot] Re: Intel Braswell uploads
>
> On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
> > I would like to submit my candidacy for Braswell SoC maintainership
> > along with Piotr Król. Since we have 3 Braswell SoC platforms on
> hand,
> > we are willing to test any incoming patches to Braswell SoC code
> base.
> > We would be glad to become the maintainers. Would like to hear Your
> > opinions, dear coreboot developers/maintainers, what do You think
> > about the change?
>
> Hi Michal,
> I'm glad to see that you want to maintain an additional platform.
>
> I recommend to email all maintainers, that are not known to be
> active, as part of the half year release process. If you don't get
> a response or a bounce message the platform should be marked as
> unmaintained.
>
> What do you think about adding a "supporters section" to the start
> page of https://coreboot.org/ to ackknowledge companies that
> really maintain coreboot code.
>
> Regards,
> --
> Patrick Rudolph
>
> 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email:  patrick.rudo...@9elements.com
> 
> Phone:  +49 234 68 94 188
>
> Sitz der Gesellschaft: Bochum
> Handelsregister: Amtsgericht Bochum, HRB 17519
> Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
> ___
> coreboot mailing list -- coreboot@coreboot.org
>  To unsubscribe send an email to
> coreboot-le...@coreboot.org 
> ___
> coreboot mailing list -- coreboot@coreboot.org
> 
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Michal Zygowski]

On 28.02.2019 09:20, Patrick Rudolph wrote:
> On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
>> I would like to submit my candidacy for Braswell SoC maintainership
>> along with Piotr Król. Since we have 3 Braswell SoC platforms on
>> hand, we are willing to test any incoming patches to Braswell SoC
>> code base. We would be glad to become the maintainers. Would like to
>> hear Your opinions, dear coreboot developers/maintainers, what do You
>> think about the change?
> Hi Michal,
> I'm glad to see that you want to maintain an additional platform.
Hi Patrick,
> I recommend to email all maintainers, that are not known to be active,
> as part of the half year release process. If you don't get a response
> or a bounce message the platform should be marked as unmaintained.
>
> What do you think about adding a "supporters section" to the start page
> of https://coreboot.org/ to ackknowledge companies that really maintain
> coreboot code.
Sounds good. Fine for me as a temporary solution.
AFAIK gerrit now adds the reviewers to patches based on MAINTAINERS
file. It would be great to be added automatically to Braswell patches.
Is there a way to workaround that without being Braswell maintainer?
>
> Regards,
Best regards,
Michał

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Patrick Rudolph]

On Thu, 2019-02-28 at 08:41 +, Frans Hendriks wrote:
> An additional question related to this SoC and new mainboards:
> Should maintainer of Braswell SoC also take care of review/merge new
> mainboards based on this chipset?
> 
> Who should merge new boards? 
> (I have uploaded code for two mainboards based on this SoC, where 1
> is waiting 3 months to be merged?)
> 
> Best regards,
> Frans Hendriks
> Eltan B.V.

Everybody should review (new mainboards), not only the platform
maintainers.
As boards consists of multiple parts: EC, SuperIO, Audio, Ethernet,
DRAM, GPIOs, ... you can only review the part you are an expert in.

Of course everybody is short on time and as most boards do not have a
good documentation (from firmware developer perspective) or schematics
publicly available, it makes reviewing hard and time consuming.

I don't have a good solution for that, except request reviews in
regular intervals.

Regards,
> 
> -Original Message-
> From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com] 
> Sent: donderdag 28 februari 2019 09:20
> To: Michal Zygowski ; 
> coreboot@coreboot.org
> Subject: [coreboot] Re: Intel Braswell uploads
> 
> On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
> > I would like to submit my candidacy for Braswell SoC
> > maintainership 
> > along with Piotr Król. Since we have 3 Braswell SoC platforms on
> > hand, 
> > we are willing to test any incoming patches to Braswell SoC code
> > base. 
> > We would be glad to become the maintainers. Would like to hear
> > Your 
> > opinions, dear coreboot developers/maintainers, what do You think 
> > about the change?
> 
> Hi Michal,
> I'm glad to see that you want to maintain an additional platform.
> 
> I recommend to email all maintainers, that are not known to be
> active, as part of the half year release process. If you don't get a
> response or a bounce message the platform should be marked as
> unmaintained.
> 
> What do you think about adding a "supporters section" to the start
> page of https://coreboot.org/ to ackknowledge companies that really
> maintain coreboot code.
> 
> Regards,
> --
> Patrick Rudolph
> 
> 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email:  patrick.rudo...@9elements.com
> Phone:  +49 234 68 94 188
> 
> Sitz der Gesellschaft: Bochum
> Handelsregister: Amtsgericht Bochum, HRB 17519
> Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an
> email to coreboot-le...@coreboot.org
-- 
Patrick Rudolph

9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  patrick.rudo...@9elements.com
Phone:  +49 234 68 94 188

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Matt DeVillier]

hi Frans,

I'm happy to review these patches (and think I have for some already), but
as my Braswell-based ChromeOS boards don't require them, a little more
explanation in the commit msgs as to what issue they are resolving would be
helpful in that regard.  Obviously I'd like to test them and ensure no
regressions for my boards as well

cheers,
Matt

On Thu, Feb 28, 2019 at 2:42 AM Frans Hendriks  wrote:

> An additional question related to this SoC and new mainboards:
> Should maintainer of Braswell SoC also take care of review/merge new
> mainboards based on this chipset?
>
> Who should merge new boards?
> (I have uploaded code for two mainboards based on this SoC, where 1 is
> waiting 3 months to be merged?)
>
> Best regards,
> Frans Hendriks
> Eltan B.V.
>
> -Original Message-
> From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com]
> Sent: donderdag 28 februari 2019 09:20
> To: Michal Zygowski ; coreboot@coreboot.org
> Subject: [coreboot] Re: Intel Braswell uploads
>
> On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
> > I would like to submit my candidacy for Braswell SoC maintainership
> > along with Piotr Król. Since we have 3 Braswell SoC platforms on hand,
> > we are willing to test any incoming patches to Braswell SoC code base.
> > We would be glad to become the maintainers. Would like to hear Your
> > opinions, dear coreboot developers/maintainers, what do You think
> > about the change?
>
> Hi Michal,
> I'm glad to see that you want to maintain an additional platform.
>
> I recommend to email all maintainers, that are not known to be active, as
> part of the half year release process. If you don't get a response or a
> bounce message the platform should be marked as unmaintained.
>
> What do you think about adding a "supporters section" to the start page of
> https://coreboot.org/ to ackknowledge companies that really maintain
> coreboot code.
>
> Regards,
> --
> Patrick Rudolph
>
> 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email:  patrick.rudo...@9elements.com
> Phone:  +49 234 68 94 188
>
> Sitz der Gesellschaft: Bochum
> Handelsregister: Amtsgericht Bochum, HRB 17519
> Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an
> email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Frans Hendriks]

An additional question related to this SoC and new mainboards:
Should maintainer of Braswell SoC also take care of review/merge new mainboards 
based on this chipset?

Who should merge new boards? 
(I have uploaded code for two mainboards based on this SoC, where 1 is waiting 
3 months to be merged?)

Best regards,
Frans Hendriks
Eltan B.V.

-Original Message-
From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com] 
Sent: donderdag 28 februari 2019 09:20
To: Michal Zygowski ; coreboot@coreboot.org
Subject: [coreboot] Re: Intel Braswell uploads

On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
> I would like to submit my candidacy for Braswell SoC maintainership 
> along with Piotr Król. Since we have 3 Braswell SoC platforms on hand, 
> we are willing to test any incoming patches to Braswell SoC code base. 
> We would be glad to become the maintainers. Would like to hear Your 
> opinions, dear coreboot developers/maintainers, what do You think 
> about the change?

Hi Michal,
I'm glad to see that you want to maintain an additional platform.

I recommend to email all maintainers, that are not known to be active, as part 
of the half year release process. If you don't get a response or a bounce 
message the platform should be marked as unmaintained.

What do you think about adding a "supporters section" to the start page of 
https://coreboot.org/ to ackknowledge companies that really maintain coreboot 
code.

Regards,
--
Patrick Rudolph

9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  patrick.rudo...@9elements.com
Phone:  +49 234 68 94 188

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen 
___
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to 
coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Braswell uploads

[Patrick Rudolph]

On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote:
> I would like to submit my candidacy for Braswell SoC maintainership
> along with Piotr Król. Since we have 3 Braswell SoC platforms on
> hand, we are willing to test any incoming patches to Braswell SoC
> code base. We would be glad to become the maintainers. Would like to
> hear Your opinions, dear coreboot developers/maintainers, what do You
> think about the change?

Hi Michal,
I'm glad to see that you want to maintain an additional platform.

I recommend to email all maintainers, that are not known to be active,
as part of the half year release process. If you don't get a response
or a bounce message the platform should be marked as unmaintained.

What do you think about adding a "supporters section" to the start page
of https://coreboot.org/ to ackknowledge companies that really maintain
coreboot code.

Regards,
-- 
Patrick Rudolph

9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  patrick.rudo...@9elements.com
Phone:  +49 234 68 94 188

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Xeon D-1577 (16-core)

[Frans Hendriks]

This relocation is performed in a later stage, so some output is expected.
Is (correct) microcode included for D-1577?

I assume wbinvd() must be included in  smm_relocation() function.
(We have implemented coreboot on several Broadwell-DE boards with >4 cores 
without using wbinv() of 8:SPEW.)

Best regards,
Frans Hendriks
Eltan B.V.


-Original Message-
From: Jay Talbott [mailto:jaytalb...@sysproconsulting.com] 
Sent: woensdag 27 februari 2019 22:19
To: aure...@platinasystems.com; coreboot@coreboot.org
Subject: [coreboot] Re: Intel Xeon D-1577 (16-core)

There's a bug in the SMM relocation code for Broadwell-DE that causes a race
condition resulting in the SoC locking up during the MP init. With the stock
4-core SKU that comes in most of the Camelback Mountain CRBs, it's not a
problem, which is why Intel didn't find it when they developed the original
coreboot implementation for the CRB. But as has been reported previously on
this list, it becomes a problem with more than 4 cores. We actually have an
open ticket with Intel to see if they are willing to diagnose the root cause
and fix it, but I have zero expectation that any action will ever be done on
their part at this point.

If you turn up your console output level to 8:SPEW, the problem will go
away, as the extra printks that get enabled in that case result in
serialization of the SMM relocation code on each core, thus masking the race
condition (try this first!).

Another workaround is to insert a call to wbinvd() in function
smm_relocation_handler() in file
src/soc/intel/fsp_broadwell_de/smmrelocate.c. This will also result in
serialization that masks the race condition (fixed it for us on a 12-core
SKU) without needing to have the console turned all the way up.

At some point somebody needs to dig into the actual code in smmrelocate.c
and identify the root cause of the actual race condition. We just haven't
had the time to do any further investigation into the root cause since we
have a working workaround.

Hope that helps...

- Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3057 E. Muirfield St.
Gilbert, AZ 85298
(480) 704-8045
(480) 445-9895 (FAX)
jaytalb...@sysproconsulting.com
http://www.sysproconsulting.com


> -Original Message-
> From: aure...@platinasystems.com [mailto:aure...@platinasystems.com]
> Sent: Wednesday, February 27, 2019 12:46 PM
> To: coreboot@coreboot.org
> Subject: [coreboot] Intel Xeon D-1577 (16-core)
> 
> Hello,
> 
> I got a daughter-card (DC) based on the Intel's Camelback Mountain CRB.
> Coreboot won't boot when a DC is populated with a 16-core Xeon D-1577
> processor. Nothing is printed in the boot process, so it doesn't seem to
be
> getting very far. However, if i load/program the boot SPI with AMI BIOS
> instead of coreboot, then everything is hunky-dory. It boots up all the
way
> into linux (see below for the platform information when AMI is loaded). In
> addition, if DC is populated with a 4-core D-1527 or 2-core D-1508 then
> coreboot has no issues (see below for info).
> 
> Is there any configuration that i need to change in coreboot to support
the D-
> 1577?
> 
> thanks!
> 
> ## AMI BIOS
> ##
> @unassigned:~$ inxi -F
> System:Host: unassigned Kernel: 4.13-platina-mk1 x86_64 (64 bit)
>Console: tty 0 Distro: Debian GNU/Linux 8
> Machine:   Mobo: Default string model: Default string v: Default string
>Bios: American Megatrends v: 5.11 date: 05/31/2017
> CPU:   Octa core Intel Xeon D-1577 (-HT-MCP-) cache: 24576 KB
>Clock Speeds: 1: 1300 MHz 2: 1300 MHz 3: 1300 MHz 4: 1300 MHz
>5: 1300 MHz 6: 1300 MHz 7: 1300 MHz 8: 1300 MHz
> Graphics:  Card: Failed to Detect Video Card!
>Display Server: N/A driver: N/A
>tty size: 80x24 Advanced Data: N/A out of X
> Network:   Card-1: Broadcom Device b960
>IF: N/A state: N/A speed: N/A duplex: N/A mac: N/A
>Card-2: Broadcom Device b960
>IF: N/A state: N/A speed: N/A duplex: N/A mac: N/A
>Card-3: Intel Device 15ab driver: ixgbe
>IF: eth1 state: down mac: 00:a0:c9:00:00:00
>Card-4: Intel Device 15ab driver: ixgbe
>IF: eth2 state: down mac: 34:12:78:56:01:00
>Card-5: Intel I210 Gigabit Network Connection driver: igb
>IF: eth0 state: up speed: 1000 Mbps duplex: full
>mac: 50:18:4c:00:16:a1
> Drives:HDD Total Size: 520.1GB (4.0% used)
>ID-1: /dev/sda model: TS512ZBTDM1500T size: 512.1GB
>ID-2: USB /dev/sdb model: Echo size: 8.0GB
> Partition: ID-1: / size: 451G used: 942M (1%) fs: ext4 dev: /dev/sda1
>ID-2: swap-1 size: 20.75GB used: 0.00GB (0%) fs: swap dev:
/dev/sda5
> RAID:  No RAID devices: /proc/mdstat, md_mod kernel module present
> Sensors:   System Temperatures: cpu: 56.0C mobo: N/A
>Fan Speeds (in rpm): cpu: N/A
> Info:  Processes: 118 Uptime: 17:49 Memory: 110.9/32087.7MB
>