[coreboot] Debugging undetected SATA disk?

2020-02-11 Thread Mogens Jensen via coreboot
I have installed coreboot on my CompuLab Intense PC (Ivy Bridge). Intel ME blob 
was extracted from firmware image dump. This ME version (8.1.20.1336) contains 
multiple security vulnerabilites, so I have downloaded latest firmware update 
from vendor website extracted the ME (8.1.72.3002) and used that to build 
coreboot. However, after flashing updated rom, the SATA disk is no longer 
detected.

The coreboot configuration is identical for both roms, only difference is the 
ME version. The SATA controller is detected in both cases by coreboot and Linux:

SATA: Initializing...
SATA: Controller in AHCI mode.

00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA 
Controller [AHCI mode] (rev 04)

With newer ME, there are no errors, it's just like the SATA disk is not plugged 
in.

I have compared output of cbmem, line by line in cronological order, from 
system booted by USB disk with working and non working SATA, cut out blocks 
with differences and marked them with a *. I don't know if this is a good way, 
please let me know if I should have done otherwise.

SATA disk working:
=
Update PCI-E configuration space:
PCI(0, 0, 0)[a0] = 0
PCI(0, 0, 0)[a4] = 2 *
PCI(0, 0, 0)[bc] = 82a0
PCI(0, 0, 0)[a8] = 7b60
PCI(0, 0, 0)[ac] = 2 *
PCI(0, 0, 0)[b8] = 8000
PCI(0, 0, 0)[b0] = 80a0
PCI(0, 0, 0)[b4] = 8080
PCI(0, 0, 0)[7c] = 7f
PCI(0, 0, 0)[70] = fe00
PCI(0, 0, 0)[74] = 1 *
PCI(0, 0, 0)[78] = fe000c00
=
SATA disk NOT working:
=
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] = 7b60
PCI(0, 0, 0)[ac] = 4 *
PCI(0, 0, 0)[b8] = 8000
PCI(0, 0, 0)[b0] = 80a0
PCI(0, 0, 0)[b4] = 8080
PCI(0, 0, 0)[7c] = 7f
PCI(0, 0, 0)[70] = fe00
PCI(0, 0, 0)[74] = 3 *
PCI(0, 0, 0)[78] = fe000c00
=

SATA disk working:
=
ME: FWS2: 0x161f012a *
ME:  Bist in progress: 0x0
ME:  ICC Status  : 0x1 *
ME:  Invoke MEBx : 0x1
ME:  CPU replaced: 0x0
=
SATA disk NOT working:
=
ME: FWS2: 0x161f012e *
ME:  Bist in progress: 0x0
ME:  ICC Status  : 0x3 *
ME:  Invoke MEBx : 0x1
ME:  CPU replaced: 0x0
=

SATA disk working:
=
PASSED! Tell ME that DRAM is ready
ME: FWS2: 0x1650012e *
ME:  Bist in progress: 0x0
ME:  ICC Status  : 0x3 *
ME:  Invoke MEBx : 0x1
ME:  CPU replaced: 0x0
=
SATA disk NOT working:
=
PASSED! Tell ME that DRAM is ready
ME: FWS2: 0x1650012a *
ME:  Bist in progress: 0x0
ME:  ICC Status  : 0x1 *
ME:  Invoke MEBx : 0x1
ME:  CPU replaced: 0x0
=

SATA disk working:
=
memcfg channel assignment: A: 1, B  0, C  2 *
memcfg channel[0] config (): *
   ECC inactive
   enhanced interleave mode off *
   rank interleave off *
   DIMMA 0 MB width x8 single rank, selected *
   DIMMB 0 MB width x8 single rank
=
SATA disk NOT working:
=
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 single rank
=

SATA disk working:
=
PCH: Remap PCIe function 4 to 3
PCI: 00:1c.4 [8086/1e18] enabled
PCI: 00:1c.5: Disabling device
PCI: 00:1c.6: Disabling device
PCI: 00:1c.6 [8086/1e1c] disabled *
PCI: 00:1c.7: Disabling device
=
SATA disk NOT working:
=
PCH: Remap PCIe function 4 to 3
PCI: 00:1c.4 [8086/1e18] enabled
PCI: 00:1c.5: Disabling device
PCI: 00:1c.6: Disabling device
*
PCI: 00:1c.7: Disabling device
=

SATA disk working:
=
PCI: Leftover static devices:
PCI: 00:16.1
PCI: 00:16.2
PCI: 00:16.3
PCI: 00:1c.4
PCI: 00:1c.5
*
PCI: 00:1c.7
PCI: Check your devicetree.cb.
=
SATA disk NOT working:
=
PCI: Leftover static devices:
PCI: 00:16.1
PCI: 00:16.2
PCI: 00:16.3
PCI: 00:1c.4
PCI: 00:1c.5
PCI: 00:1c.6 *
PCI: 00:1c.7
PCI: Check your devicetree.cb.
=

SATA disk working:
=
Available memory below 4GB: 2048M
Available memory above 4GB: 6070M *
=
SATA disk NOT working:
=
Available memory below 4GB: 2048M
Available memory above 4GB: 14262M *
=

SATA disk working:
=
CPU physical address size: 36 bits
MTRR: default type WB/UC MTRR counts: 4/4. *
MTRR: UC selected as default type. *
=

[coreboot] Re: Extended IvyBridge CPU configuration

2020-02-11 Thread Evgeny Zinoviev via coreboot
Sorry for a long reply too. About mrc.bin: no, it's actually possible 
to use mrc blob on Sandy/Ivy, but as I see it's not supported across 
all boards. X220 has support, other boards needs patching (or maybe 
patches are already on gerrit, I'm not sure). It shouldn't be hard to 
get it working, though. 
Can you elaborate on this one? Why does the X220 has support and other 
Sandy/IvyBridge based laptops are not supported? Wasn't one of the 
ideas for coreboot to have a more common code base or am I missing 
something obvious?
Basically, it's just not enabled in other boards' configs. I don't know 
why exactly it is enabled only in X220, but I can guess it's because the 
native raminit is preferable, works quite well and nobody needed mrc 
raminit on other models. You can try this patch 
https://review.coreboot.org/c/coreboot/+/37153 on your T430.

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


[coreboot] Re: Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)

2020-02-11 Thread Paul Menzel
Dear Kyösti,


On 2020-01-25 00:56, Kyösti Mälkki wrote:
>>
>> System *boots* with one of:
>>
>> 1.  maxcpus=0 (equivalent nosmp)
>> 2.  maxcpus=1
>> 3.  nolapic (with e1000 warning about missing MSI-X
>>
>> System does *not* boot with one of:
>>
>> 1.  maxcpus=2
>> 2.  noapic

Booting with `maxcpus=1` and then starting the second CPU also results
in a hang.

echo 1 | sudo tee /sys/devices/system/cpu/cpu0/online

> I thought SMP was generally not compatible with PIC IRQ routing (which
> noapic enforces?) and this would explain case 2.
> 
> As for case 1, maybe I missed some detail with my commit [1] when
> switching from LAPIC to TSC timers. Like leaving LAPIC timers running
> at different rate or generally having the timer counters too much
> out-of-sync across CPU #0 and #1. You could try if that one is the
> commit with regression.

Yes, you are spot on.

Building the parent commit c00e2fb996
(cpu/intel: Use CPU_INTEL_COMMON_TIMEBASE) the system boots with both
CPUs.


Kind regards,

Paul


> [1] https://review.coreboot.org/c/coreboot/+/34200[2]: 
> https://review.coreboot.org/c/coreboot/+/31342



smime.p7s
Description: S/MIME Cryptographic Signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Extended IvyBridge CPU configuration

2020-02-11 Thread Lars Hochstetter
I managed to find some time to run memtest86+ v5.01 as a SeaBIOS payload 
[1].


As it turns out the RAM went bad - I made sure to check with another 
pair of sticks. I'll replace the RAM and retry the HT patch when my free 
time allows for it.


Sorry for creating so much noise over something so simple.

Regards

lhochstetter


[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html

On 2/8/20 4:23 PM, Lars Hochstetter wrote:
Unfortunately I'll be rather busy until mid April this year - here is 
my plan for the time being:


I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot 
and run it. I'll report back if it's just bad RAM or something else.


Since my T430 was modified a couple times I'd also suggest we try to 
find someone with a more stock T430 to see if your HT patch works. The 
X230 somewhere in this thread worked and I'd argue that it does work 
properly on unmodified Thinkpads.


Sorry for a long reply too. About mrc.bin: no, it's actually possible 
to use mrc blob on Sandy/Ivy, but as I see it's not supported across 
all boards. X220 has support, other boards needs patching (or maybe 
patches are already on gerrit, I'm not sure). It shouldn't be hard to 
get it working, though. 
Can you elaborate on this one? Why does the X220 has support and other 
Sandy/IvyBridge based laptops are not supported? Wasn't one of the 
ideas for coreboot to have a more common code base or am I missing 
something obvious?


Regards

lhochstetter
___
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: thinkpad x250 support

2020-02-11 Thread Evgeny Zinoviev via coreboot

No, they have Intel Boot Guard, which prevents running custom firmware.

On 2/11/20 12:47 PM, Eero Volotinen wrote:

Hi,

is the thinkpad x250 .. x260 supported in coreboot?

___
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] thinkpad x250 support

2020-02-11 Thread Eero Volotinen
Hi,

is the thinkpad x250 .. x260 supported in coreboot?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org