[coreboot] Boot loop on Thinkpad X200/GM45 with master.

[Denis 'GNUtoo' Carikli]

Hi,

I've a reboot loop on master on the Thinkpad X200.

It's configured to run without the Management Engine firmware (which
is not present on the flash chip).

Here's the boot log:
> coreboot-4.10-678-gdd12d53494b-dirty Mon Sep 16 13:42:10 UTC 2019
> romstage starting (log level: 8)... WARNING: Ignoring
> S4-assertion-width violation. Stepping B3
> 2 CPU cores
> AMT enabled
> capable of DDR2 of 800 MHz or lower
> VT-d enabled
> GMCH: GM45
> TXT enabled
> Render frequency: 533 MHz
> IGD enabled
> PCIe-to-GMCH enabled
> GMCH supports DDR3 with 1067 MT or less
> GMCH supports FSB with up to 1067 MHz
> SMBus controller enabled.
> 0:50:b
> 2:51:b
> DDR mask 5, DDR 3
> Bank 0 populated:
>  Raw card type:F
>  Row addr bits:   14
>  Col addr bits:   10
>  byte width:   1
>  page size: 1024
>  banks:8
>  ranks:2
>  tAAmin:105
>  tCKmin: 15
>   Max clock: 533 MHz
>  CAS:   0x01c0
> Bank 1 populated:
>  Raw card type:F
>  Row addr bits:   14
>  Col addr bits:   10
>  byte width:   1
>  page size: 1024
>  banks:8
>  ranks:2
>  tAAmin:105
>  tCKmin: 15
>   Max clock: 533 MHz
>  CAS:   0x01e0
> Trying CAS 7, tCK 15.
> Found compatible clock / CAS pair: 533 / 7.
> Timing values:
>  tCLK:   15
>  tRAS:   20
>  tRP: 7
>  tRCD:7
>  tRFC:   68
>  tWR: 8
>  tRD:11
>  tRRD:4
>  tFAW:   20
>  tWL: 6
> Changing memory frequency: old 3, new 6.
> Setting IGD memory frequencies for VCO #1.
> Memory configured in dual-channel assymetric mode.
> Memory map:
> TOM   =   512MB
> TOLUD =   512MB
> TOUUD =   512MB
> REMAP: base  = 65535MB
>limit = 0MB
> usedMEsize: 0MB
> JEDEC init @0x
> JEDEC init @0x0800
> JEDEC init @0x1000
> JEDEC init @0x1800
> Final timings for 
> group 0, ch 0: 6.1.0.5.6
> Final timings for 
> group 1, ch 0: 6.0.2.8.4
> Final timings for 
> group 2, ch 0: 6.1.2.3.4
> Final timings for 
> group 3, ch 0: 6.1.0.8.6
> Final timings for 
> group 0, ch 1: 6.1.0.3.5
> Final timings for 
> group 1, ch 1: 6.0.2.6.1
> Final timings for 
> group 2, ch 1: 6.1.2.1.6
> Final timings for 
> group 3, ch 1: 6.1.0.8.1
> Lower bound for byte lane 0, ch 0: 0.0
> Upper bound for byte lane 0, ch 0: 10.6
> Final timings for 
> byte lane 0, ch 0: 5.3
> Lower bound for byte lane 1, ch 0: 0.0
> Upper bound for byte lane 1, ch 0: 9.7
> Final timings for 
> byte lane 1, ch 0: 4.7
> Lower bound for byte lane 2, ch 0: 0.0
> Upper bound for byte lane 2, ch 0: 9.4
> Final timings for 
> byte lane 2, ch 0: 4.6
> Lower bound for byte lane 3, ch 0: 0.0
> Upper bound for byte lane 3, ch 0: 10.2
> Final timings for 
> byte lane 3, ch 0: 5.1
> Lower bound for byte lane 4, ch 0: 0.0
> Upper bound for byte lane 4, ch 0: 9.2
> Final timings for 
> byte lane 4, ch 0: 4.5
> Lower bound for byte lane 5, ch 0: 0.0
> Upper bound for byte lane 5, ch 0: 7.7
> Final timings for 
> byte lane 5, ch 0: 3.7
> Lower bound for byte lane 6, ch 0: 0.0
> Upper bound for byte lane 6, ch 0: 8.5
> Final timings for 
> byte lane 6, ch 0: 4.2
> Lower bound for byte lane 7, ch 0: 0.0
> Upper bound for byte lane 7, ch 0: 10.5
> Final timings for 
> byte lane 7, ch 0: 5.2
> Lower bound for byte lane 0, ch 1: 0.0
> Upper bound for byte lane 0, ch 1: 10.1
> Final timings for 
> byte lane 0, ch 1: 5.0
> Lower bound for byte lane 1, ch 1: 0.0
> Upper bound for byte lane 1, ch 1: 11.6
> Final timings for 
> byte lane 1, ch 1: 5.7
> Lower bound for byte lane 2, ch 1: 0.0
> Upper bound for byte lane 2, ch 1: 11.6
> Final timings for 
> byte lane 2, ch 1: 5.7
> Lower bound for byte lane 3, ch 1: 0.0
> Upper bound for byte lane 3, ch 1: 9.6
> Final timings for 
> byte lane 3, ch 1: 4.7
> Lower bound for byte lane 4, ch 1: 0.0
> Upper bound for byte lane 4, ch 1: 10.6
> Final timings for 
> byte lane 4, ch 1: 5.3
> Lower bound for byte lane 5, ch 1: 0.0
> Upper bound for byte lane 5, ch 1: 9.3
> Final timings for 
> byte lane 5, ch 1: 4.5
> Lower bound for byte lane 6, ch 1: 0.0
> Upper bound for byte lane 6, ch 1: 8.5
> Final timings for 
> byte lane 6, ch 1: 4.2
> Lower bound for byte lane 7, ch 1: 0.0
> Upper bound for byte lane 7, ch 1: 10.7
> Final timings for 
> byte lane 7, ch 1: 5.3
> Lower bound for group 0, ch 0: 1.6.3
> Upper bound for group 0, ch 0: 2.3.1
> Final timings for 
> group 0, ch 0: 1.10.6
> Lower bound for group 1, ch 0: 1.6.1
> Upper bound for group 1, ch 0: 2.2.3
> Final timings for 
> group 1, ch 0: 1.10.2
> Lower bound for group 2, ch 0: 2.0.0
> Upper bound for group 2, ch 0: 2.10.0
> Final timings for 
> group 2, ch 0: 2.5.0
> Lower bound for group 3, ch 0: 2.4.7
> Upper bound for group 3, ch 0: 3.1.0
> Final timings for 
> group 3, ch 0: 2.8.7
> FMAP: Found "FLASH" version 1.1 at 1.
> FMAP: base = ff80 size = 80 #areas = 3
> FMAP: area COREBOOT found @ 10200 (8322560 bytes)
> CBFS: Locating 'cmos_layout.bin'
> CBFS: Found @ offset 30200 size 680
> IGD decoded, subtracting 
> 32M UMA
>  

[coreboot] RAM init failing with some DIMMs on GM45 with "Timing overflow during read training."

[Denis 'GNUtoo' Carikli]

Hi,

I've bought two 4G DIMMs with the following characteristics:
- Vendor: Corsair
- Model: MACMEMORY
- Markings: CMSA4GX3M1A1066C7
DDR3

- Chips markings:
  Corsair 
  256MB8DCJG
  HYE0001924

On a Thinkpad X200 with coreboot master, it gives me the following log:
> coreboot-4.10-678-gdd12d53494b-dirty Mon Sep 16 13:42:10 UTC 2019 romstage 
> starting (log level: 8)...
> Stepping B3
> 2 CPU cores
> AMT enabled
> capable of DDR2 of 800 MHz or lower
> VT-d enabled
> GMCH: GM45
> TXT enabled
> Render frequency: 533 MHz
> IGD enabled
> PCIe-to-GMCH enabled
> GMCH supports DDR3 with 1067 MT or less
> GMCH supports FSB with up to 1067 MHz
> SMBus controller enabled.
> 0:50:b
> 2:51:b
> DDR mask 5, DDR 3
> Bank 0 populated:
>  Raw card type:D
>  Row addr bits:   15
>  Col addr bits:   10
>  byte width:   1
>  page size: 1024
>  banks:8
>  ranks:2
>  tAAmin:105
>  tCKmin: 15
>   Max clock: 533 MHz
>  CAS:   0x01c0
> Bank 1 populated:
>  Raw card type:D
>  Row addr bits:   15
>  Col addr bits:   10
>  byte width:   1
>  page size: 1024
>  banks:8
>  ranks:2
>  tAAmin:105
>  tCKmin: 15
>   Max clock: 533 MHz
>  CAS:   0x01c0
> Trying CAS 7, tCK 15.
> Found compatible clock / CAS pair: 533 / 7.
> Timing values:
>  tCLK:   15
>  tRAS:   20
>  tRP: 7
>  tRCD:7
>  tRFC:  104
>  tWR: 8
>  tRD:11
>  tRRD:4
>  tFAW:   20
>  tWL: 6
> Setting IGD memory frequencies for VCO #1.
> Memory configured in dual-channel assymetric mode.
> Memory map:
> TOM   =   512MB
> TOLUD =   512MB
> TOUUD =   512MB
> REMAP: base  = 65535MB
>limit = 0MB
> usedMEsize: 0MB
> JEDEC init @0x
> JEDEC init @0x0800
> JEDEC init @0x1000
> JEDEC init @0x1800
> Final timings for 
> group 0, ch 0: 7.0.0.3.7
> Final timings for 
> group 1, ch 0: 7.0.0.3.2
> Final timings for 
> group 2, ch 0: 7.0.2.3.1
> Final timings for 
> group 3, ch 0: 7.0.2.1.3
> Final timings for 
> group 0, ch 1: 7.0.0.1.1
> Final timings for 
> group 1, ch 1: 7.4.0.7.1
> Final timings for 
> group 2, ch 1: 7.0.2.0.6
> Final timings for 
> group 3, ch 1: 7.0.0.8.3
> Lower bound for byte lane 0, ch 0: 0.0
> Upper bound for byte lane 0, ch 0: 10.5
> Final timings for 
> byte lane 0, ch 0: 5.2
> Lower bound for byte lane 1, ch 0: 0.0
> Upper bound for byte lane 1, ch 0: 9.3
> Final timings for 
> byte lane 1, ch 0: 4.5
> Lower bound for byte lane 2, ch 0: 0.0
> Upper bound for byte lane 2, ch 0: 10.0
> Final timings for 
> byte lane 2, ch 0: 5.0
> Lower bound for byte lane 3, ch 0: 0.0
> Upper bound for byte lane 3, ch 0: 10.3
> Final timings for 
> byte lane 3, ch 0: 5.1
> Timing overflow during read training.
> Read training failure: lower bound.

On older Coreboot versions it failed as well.

With other known-working DIMMs I can manage to get pass this stage and
the laptop gets up to ramstage:
> usbdebug: ramstage starting...

However for some other reason it doesn't boot, but that's probably for
another mail.

Denis.


pgpYWjKqmMMnz.pgp
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What are splitted / several flash ROMs about?

[Stefan Reinauer]

Yes, this is often done as a cost reduction method. The habit started with
the arrival of the ME and the firmware descriptor allowing you to spread
your different firmware regions across one or both chips. The tool ifdtool
will help you analyze images for Intel firmware descriptors.
Sounds like in this case ME and the other regions live in the larger chip,
allowing the smaller chip to be fully used for system firmware. If that's
the case, erasing the larger chip will brick your system. Better do some
analysis first.

Stefan

On Mon, 16 Sep 2019, 04:50 Philipp Stanner,  wrote:

> Hi folks,
>
> Platforms like the x230 have two flash ROMs which are virtually treated
> as a single one.
>
> So:
>1. What the heck is the meaning of this? Why do vendors buy and solder
>   two small chips (even worse, on the x230, one with 8M and one with
>   4M) instead of a single big one? Is this cheaper? Sounds unlikely to
>   me, in technics one big thing is usually cheaper than several small
>   ones. Beyond that, I imagine you have some effort to concatenate the
>   two chips virtually.
>2. The manual for the x230 [1] (is there a version in the new
>   documentation btw?) states that you can just flash the smaller (4M)
>   chip and then you're done. So I assume:
>   1. the 4M chip is the one the CPU first executes code from
>   2. neither coreboot nor the payload will ever jump "into" the larger
>  chip, therefore code from it will not be executed.
>   3. Therefore, it does not matter if you overwrite the 8M chip or
>  not.
>
> But what lays on this larger ROM? What if there are parts of the IME on
> it I would like to annihilate?
>
> The whole thing is really awkward to me. Especially, because the
> predecessor x220 already has a place on the board ready to host the
> second chip, but it was left empty on this device.
>
> P.
>
>
> [1] https://www.coreboot.org/Board:lenovo/x230
> ___
> 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: supported hardware

[Michal Zygowski]

On 16.09.2019 14:20, Angel Pons wrote:
> Hello,
>
> On Mon, Sep 16, 2019 at 12:56 PM Michal Zygowski
>  wrote:
>> On 14.09.2019 17:16, Андрей Карелин wrote:
>>> Hello
>>>
>> Hi,
>>> First of all thank you for your great work, I mean coreboot, it's
>>> really cool
>>>
>>> I have mainboad Supermicro X11SSM-F rev 1.01, which almost the same as
>>> supported X11SSH-TF. Any chance that it will work fine with ROM for
>>> X11SSH-TF?
> Somebody is working on it: https://review.coreboot.org/c/coreboot/+/35427
> I would recommend messaging him about the port status. He is also active on
> IRC, if you prefer less formal and more spontaneous communication channels.
>
>> I do not see any reason it shouldn't. BMC, chipset and supported
>> processors are the same. There are small differences in PCI Express
>> topology which should be adjusted in devicetree and/or FSP config, but
>> it should still boot. IIRC flash descriptor handles the PCI Express lane
>> configuration, so small changes in devicetree and/or  FSP config eventually.
> Please do NOT suggest running coreboot ROMs for mainboard X on something
> that is not mainboard X. If GPIO settings for the southbridge and/or SuperIO
> differ between boards X and Y, running coreboot for board X on board Y can
> result in short-circuits, and cause permanent hardware damage. And replacing
> the SuperIO, southbridge, or even the whole SoC on some board, is a very
> laborious task which requires expensive, specialized equipment and skills,
> so it is impractical to do for most people.
Yep, you are right. I was a little bit too hasty.  I have just recently
tested a coreboot on mainboards like these with just different product
suffix and it occurred to have the same GPIO configuration. It is quite
unlikely that the GPIOs will change. Like you said, replacing the
components is expensive so I doubt board vendors do that for similar
mainboards. However still significant enough to not ignore it.

Thank you for correction Angel.

Regards,
Michał
>
>> Best regards,
>> Michał
>>> Best regards
>> --
>> Michał Żygowski
>> Firmware Engineer
>> http://3mdeb.com | @3mdeb_com
> Regards,
>
> Angel
> ___
> 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: supported hardware

[Angel Pons]

Hello,

On Mon, Sep 16, 2019 at 12:56 PM Michal Zygowski
 wrote:
>
> On 14.09.2019 17:16, Андрей Карелин wrote:
> > Hello
> >
> Hi,
> > First of all thank you for your great work, I mean coreboot, it's
> > really cool
> >
> > I have mainboad Supermicro X11SSM-F rev 1.01, which almost the same as
> > supported X11SSH-TF. Any chance that it will work fine with ROM for
> > X11SSH-TF?

Somebody is working on it: https://review.coreboot.org/c/coreboot/+/35427
I would recommend messaging him about the port status. He is also active on
IRC, if you prefer less formal and more spontaneous communication channels.

> I do not see any reason it shouldn't. BMC, chipset and supported
> processors are the same. There are small differences in PCI Express
> topology which should be adjusted in devicetree and/or FSP config, but
> it should still boot. IIRC flash descriptor handles the PCI Express lane
> configuration, so small changes in devicetree and/or  FSP config eventually.

Please do NOT suggest running coreboot ROMs for mainboard X on something
that is not mainboard X. If GPIO settings for the southbridge and/or SuperIO
differ between boards X and Y, running coreboot for board X on board Y can
result in short-circuits, and cause permanent hardware damage. And replacing
the SuperIO, southbridge, or even the whole SoC on some board, is a very
laborious task which requires expensive, specialized equipment and skills,
so it is impractical to do for most people.

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

Regards,

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

[coreboot] Re: Coreboot Payload.

[nisingh]

I am looking out to program GRUB2 as a separate payload image.
 
Thanks.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] What are splitted / several flash ROMs about?

[Philipp Stanner]

Hi folks,

Platforms like the x230 have two flash ROMs which are virtually treated
as a single one.

So:
   1. What the heck is the meaning of this? Why do vendors buy and solder
  two small chips (even worse, on the x230, one with 8M and one with
  4M) instead of a single big one? Is this cheaper? Sounds unlikely to
  me, in technics one big thing is usually cheaper than several small
  ones. Beyond that, I imagine you have some effort to concatenate the
  two chips virtually.
   2. The manual for the x230 [1] (is there a version in the new
  documentation btw?) states that you can just flash the smaller (4M)
  chip and then you're done. So I assume:
  1. the 4M chip is the one the CPU first executes code from
  2. neither coreboot nor the payload will ever jump "into" the larger
 chip, therefore code from it will not be executed.
  3. Therefore, it does not matter if you overwrite the 8M chip or
 not.

But what lays on this larger ROM? What if there are parts of the IME on
it I would like to annihilate?

The whole thing is really awkward to me. Especially, because the
predecessor x220 already has a place on the board ready to host the
second chip, but it was left empty on this device.

P.


[1] https://www.coreboot.org/Board:lenovo/x230

signature.asc
Description: This is a digitally signed message part
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Coreboot Payload.

[nisingh]

Hi,

I am using "GRUB-2" as a direct payload for a Denverton based implementation.
Is it possible to invoke a payload which is programmed as a separate Image (not 
as a part of cbfs coreboot image) within a BOOT flash ?
If not, then what are the areas do we need to modify in a state-machine to 
implement the same ?

Thanks in advance,
Nitin.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: supported hardware

[Michal Zygowski]

On 14.09.2019 17:16, Андрей Карелин wrote:
> Hello
>
Hi,
> First of all thank you for your great work, I mean coreboot, it's
> really cool
>
> I have mainboad Supermicro X11SSM-F rev 1.01, which almost the same as
> supported X11SSH-TF. Any chance that it will work fine with ROM for
> X11SSH-TF?
I do not see any reason it shouldn't. BMC, chipset and supported
processors are the same. There are small differences in PCI Express
topology which should be adjusted in devicetree and/or FSP config, but
it should still boot. IIRC flash descriptor handles the PCI Express lane
configuration, so small changes in devicetree and/or  FSP config eventually.

Best regards,
Michał
>
> Best regards
>
> ___
> 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] supported hardware

[Андрей Карелин]

Hello

First of all thank you for your great work, I mean coreboot, it's really 
cool


I have mainboad Supermicro X11SSM-F rev 1.01, which almost the same as 
supported X11SSH-TF. Any chance that it will work fine with ROM for 
X11SSH-TF?


Best regards

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

[coreboot] Re: TPM measurements with UefiPayloadPkg EDK2

[Michal Zygowski]

Hi Matt,

Unfortunately not. I just have studied Git log for changes in
SecurityPkg to determine whether white paper is valid or not. The only
thing that helped me achieve the goal was the OVMF package and its
modified modules taken from SecurityPkg on the master branch. So
basically nothing in a document format like white paper or similar.

Regards,
Michał

On 13.09.2019 23:08, Matt B wrote:
> Hello,
>
> Are there any up-to-date references you're aware of, for those interested?
>
> -Matt
>
> On Fri, Sep 13, 2019 at 8:44 AM Michal Zygowski
> mailto:michal.zygow...@3mdeb.com>> wrote:
>
> Thank you for response. I already got that working actually yesterdays
> evening :)
>
> If you mean the white paper A Tour Beyond BIOS with the UEFI TPM2
> Support in EDKII and the wiki on GitHub, I have also encountered these
> guides. They have removed TrEE protocol and rewritten whole TCG2
> stack.
> So most of the guidelines in this white paper are useless
> unfortunately.
>
> Some modifications to included libraries and components in DSC and few
> INFs in FDF. At last few PCD fixes and done.
>
> Regards,
>
> On 13.09.2019 02:33, benjamin.doro...@gmail.com
>  wrote:
> > I remember seeing a guide on Tianocore's wiki on GitHub that I
> was meaning to follow after porting coreboot to my laptop. From
> memory, it's a matter of adding some "includes" to the package you
> plan to build. Hopefully isn't much more than that.
> > ___
> > 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 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