Re: [coreboot] EHCI wakeup on Haswell+Lynxpoint motherboards

[Zoran Stojsavljevic]

Hello Konstantin,

I have few questions for you here. If you put back original AMI BIOS for
your board, does it wake up from S3? I do recall that you have kind of
proprietary platform which does switching/routing, and does have only
Coreboot ported. Am I correct?

AMI BIOS would be preferable starting point for debugging/testing of this
problem, but if it does not exist, we'll try something different, with help
of sticks and ropes down the road. Do NOT forget, as I also recall that you
are using very old version of Coreboot: *coreboot-4.0*-8341-g5e6dd5f-dirty *Thu
Mar 19 10:15:27 UTC 2015.*

I have another suggestion for you: to try to go to S4 (hibernation) sleep,
and then to try to wake up? Does this work?

I need from you Linux kernel (preferably Fedora 24/25) S3 and S4 logs. How
to achieve this? If the whole platform does not wake up, simply do the HW
hard reset, and then, after booting up capture previous log with the
command: journalctl -b -1 , and attach it to the email.

Zoran

On Thu, Feb 2, 2017 at 4:26 PM, Аладышев Константин 
wrote:

> I have Haswell+LynxpointLP motherboard and Linux doesn't wakeup from USB
> devices from S3. EHCI controller is listed in "/proc/acpi/wakeup" as
> "enabled" and GPE number is seemed to be configured correctly in ACPI to
> PME_B0, but it doesn't work.
>
>
>
> What is need to be done to enable USB wakeup?
>
>
>
> Does USB wakeup work on Haswell+Lynxpoint motherboards?
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] T420i compatibility

[ilker via coreboot]

Is thinkpad T420i (4178CWG) compatible with Coreboot?

Differences between the T420i and the T420
https://www.ifixit.com/Device/ThinkPad_T420-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Back to original BIOS

[enrico pallazzo]

Hi Michael,

If t400 stock bios structure is similar, you might try restoring it 
using this procedure:

http://thinkwiki.de/UEFI_BIOS_T420_BIOS_Structure
It worked for me to revert to stock bios from coreboot on a t420.
As you write only bios region, you don' t need the old backup of your 
chip. In fact, I flashed a version of the stock bios that was different 
from the one I had before coreboot.


Regards,
Florian

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

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

[Julius Werner]

>
> Hmm.  I must have messed up someting in my earlier tests (maybe they
> ran without BUILD_TIMELESS=1?).  You're right; the resulting firmware
> images do not depend on the build path, so the extra CFLAGS are not
> necessary.


CBFS binaries (SELFs) cannot contain debug symbols, so -fdebug-prefix-map
can't really affect them. If you want intermediate build artifacts (e.g.
bootblock.elf and friends) to be reproducible, you'd have to add some flags
like you suggested. If you're fine with just the final images it should
already work out of the box.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

[Trammell Hudson]

On Thu, Feb 02, 2017 at 09:10:09PM +0100, Patrick Georgi via coreboot wrote:
> coreboot is normally reproducible:
> https://tests.reproducible-builds.org/coreboot/coreboot.html

Hmm.  I must have messed up someting in my earlier tests (maybe they
ran without BUILD_TIMELESS=1?).  You're right; the resulting firmware
images do not depend on the build path, so the extra CFLAGS are not
necessary.

-- 
Trammell

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

[coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

I spent some time checking the available RAM options for the KGPE-D16. The 
current list in the wiki is not very comprehensive and the models listed there 
are not easy to find on the market. After some research, I identified two 
"promising" candidates:

1.) Samsung M393B1K70DH0-YK0

Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank, x4 • Modules: 1x 
8GB • JEDEC: PC3L-12800R • Voltage: 1.35V

2.) Samsung M393B1K70DH0-YH9

Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank • Modules: 1x 8GB • 
JEDEC: PC3L-10667R • Voltage: 1.35V

Does one of you have experience with any of these (especially on this board)?

Cheers, Daniel

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

Re: [coreboot] Back to original BIOS

[Arthur Heymans]

ron minnich  writes:
> We really need to start warning people when the flash a thinkpad that
> it is very important to save the old flash image.

It is somewhat thinkpad specific whether the bios extracted from the
update tool will work.
On X60 I have had no success with it.

On X200 it sort of works to flash the vendor bios extracted from update
.exe. You can even just flash bios region and leave ifd, gbe (and me)
alone. (Though I have had it not being able to boot and complain about
some pxe stuff)

Note: on x200 there exists a modified (whitelist removed) bios which
does not write protect its bootblock. With this it is possible to flash
the vendor bios without having to rely on an external programmer to
re-flash coreboot. 

Backup are essential!

-- 
Arthur Heymans

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

Re: [coreboot] Back to original BIOS

[ron minnich]

peter is not talking about CMOS. He's talking about saving  data in the
flash ROM that is tied to an individual motherboard. Those are very
different things.

Here's a simple example from older systems. They would save the ethernet
MAC in flash. When you did an upgrade, you had to use the existing flash as
input, else your MAC would be lost or appear as all zeros. You can imagine
how tricky this can be if the exist flash rom has, e.g., GPIO settings that
must be transferred to the new flash image before flashing.

Hence, just a raw factory image may not work.

We really need to start warning people when the flash a thinkpad that it is
very important to save the old flash image.

ron

On Thu, Feb 2, 2017 at 11:52 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > I think that will be a problem. Lenovo BIOSes save some machine-specific
> > information in the flash ROM across updates, and I've so far not seen
> > a single Lenovo mainboard which does not require this information for
> > the vendor BIOS to work.
>
> Let say, you are right/correct, Peter. Then I need explanation for this
> text:
>
> http://www.howtogeek.com/131623/how-to-clear-your-computers-cmos-to-reset-bios-settings/
>
> *Reseat the CMOS Battery*
>
> *If your motherboard does not have a CLEAR CMOS jumper, you can often
> clear its CMOS settings by removing the CMOS battery and replacing it. The
> CMOS battery provides power used to save the BIOS settings – this is how
> your computer knows how much time has passed even when it’s been
> powered-off for a while – so removing the battery will remove the source of
> power and clear the settings.*
>
> *Important Note: Not all motherboards have removable CMOS batteries. If
> the battery won’t come loose, don’t force it.*
>
> *First, ensure the computer is powered off and you’re grounded so you
> won’t damage the motherboard with static electricity. Locate the round,
> flat, silver battery on the motherboard and carefully remove it. Wait five
> minutes before reseating the battery.*
>
> Since I am kind of *naive*, and do not understand what these people are
> talking about (you are opposing them, am I correct, or maybe not)?
>
> > It's a kind offer, but not useful in my experience, for the above reasons.
> All Lenovo BIOS updates require a Lenovo BIOS.
>
> Two questions/conclusions: did you ever try what I proposed here? If NOT,
> it is worth trying. If YES, total valid observation. Then DEDIPROG flash
> programmer or similar of kind is a must, unfortunately?!
>
> Zoran
>
> On Thu, Feb 2, 2017 at 8:53 PM, Peter Stuge  wrote:
>
> Michal Widlok wrote:
> > Ron - I've lost original bios, my mistake.
>
> I think that will be a problem. Lenovo BIOSes save some machine-specific
> information in the flash ROM across updates, and I've so far not seen
> a single Lenovo mainboard which does not require this information for
> the vendor BIOS to work.
>
>
> > On Wed, Feb 1, 2017 at 9:20 PM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> > > I'll try to find the original BIOS for Michael
>
> It's a kind offer, but not useful in my experience, for the above
> reasons. All Lenovo BIOS updates I've seen so far require a Lenovo BIOS.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

[Patrick Georgi via coreboot]

Am 02.02.2017 8:39 nachm. schrieb "Trammell Hudson" :

Is there a right way to pass additional compiler flags to the coreboot
makefiles?

Please add them as a test to util/xcompile/xcompile.

We've been working on making the Heads firmware reproducible

coreboot is normally reproducible:
https://tests.reproducible-builds.org/coreboot/coreboot.html


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

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

[Trammell Hudson]

On Thu, Feb 02, 2017 at 08:55:56PM +0100, Zoran Stojsavljevic wrote:
> > Is there a right way to pass additional compiler flags to the coreboot
> > makefiles?  We've been working on making the Heads firmware reproducible
> > and found that the -fdebug-prefix-map option is necessary to deal with
> > different build directories.  To make this work with coreboot we ended
> > passing in environment variables CFLAGS_x86_32 and *CFLAGS_x86_64*:
> 
> In other words, Trammel, you would like to say that you can compile
> Coreboot to be x86_64 compliant (64 bits Coreboot build)?!

Or more likely I saw both of them in the Makefile and just passed in
both of them for good measure, but didn't go back to check which ones
were actually required for a qemu/x230/chell mainboard build...

-- 
Trammell

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

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

[Zoran Stojsavljevic]

> Is there a right way to pass additional compiler flags to the coreboot
> makefiles?  We've been working on making the Heads firmware reproducible
> and found that the -fdebug-prefix-map option is necessary to deal with
> different build directories.  To make this work with coreboot we ended
> passing in environment variables CFLAGS_x86_32 and *CFLAGS_x86_64*:

In other words, Trammel, you would like to say that you can compile
Coreboot to be x86_64 compliant (64 bits Coreboot build)?!

(forgive me for my ignorance?)

Thank you,
Zoran

On Thu, Feb 2, 2017 at 8:37 PM, Trammell Hudson  wrote:

> Is there a right way to pass additional compiler flags to the coreboot
> makefiles?  We've been working on making the Heads firmware reproducible
> and found that the -fdebug-prefix-map option is necessary to deal with
> different build directories.  To make this work with coreboot we ended
> passing in environment variables CFLAGS_x86_32 and CFLAGS_x86_64:
>
>   EXTRA_FLAGS="-fdebug-prefix-map=`pwd`=. -gno-record-gcc-switches"
>   make CFLAGS_x86_32="$EXTRA_FLAGS" CFLAGS_x86_64="$EXTRA_FLAGS"
>
> Ideally coreboot could use this in its Makefile to avoid having any
> build tree path dependencies included in the binary, although for now the
> Heads build script passes in these extra flags to all of our dependencies.
>
> With this (and several other commits this week), Heads is now 100%
> reproducible (tested on Ubuntu, Qubes' Fedora, and an ancient Debian):
>
> https://github.com/osresearch/heads/releases/tag/v0.1.0
>
> --
> Trammell
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Back to original BIOS

[Zoran Stojsavljevic]

> I think that will be a problem. Lenovo BIOSes save some machine-specific
> information in the flash ROM across updates, and I've so far not seen
> a single Lenovo mainboard which does not require this information for
> the vendor BIOS to work.

Let say, you are right/correct, Peter. Then I need explanation for this
text:
http://www.howtogeek.com/131623/how-to-clear-your-computers-cmos-to-reset-bios-settings/

*Reseat the CMOS Battery*

*If your motherboard does not have a CLEAR CMOS jumper, you can often clear
its CMOS settings by removing the CMOS battery and replacing it. The CMOS
battery provides power used to save the BIOS settings – this is how your
computer knows how much time has passed even when it’s been powered-off for
a while – so removing the battery will remove the source of power and clear
the settings.*

*Important Note: Not all motherboards have removable CMOS batteries. If the
battery won’t come loose, don’t force it.*

*First, ensure the computer is powered off and you’re grounded so you won’t
damage the motherboard with static electricity. Locate the round, flat,
silver battery on the motherboard and carefully remove it. Wait five
minutes before reseating the battery.*

Since I am kind of *naive*, and do not understand what these people are
talking about (you are opposing them, am I correct, or maybe not)?

> It's a kind offer, but not useful in my experience, for the above reasons.
All Lenovo BIOS updates require a Lenovo BIOS.

Two questions/conclusions: did you ever try what I proposed here? If NOT,
it is worth trying. If YES, total valid observation. Then DEDIPROG flash
programmer or similar of kind is a must, unfortunately?!

Zoran

On Thu, Feb 2, 2017 at 8:53 PM, Peter Stuge  wrote:

> Michal Widlok wrote:
> > Ron - I've lost original bios, my mistake.
>
> I think that will be a problem. Lenovo BIOSes save some machine-specific
> information in the flash ROM across updates, and I've so far not seen
> a single Lenovo mainboard which does not require this information for
> the vendor BIOS to work.
>
>
> > On Wed, Feb 1, 2017 at 9:20 PM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> > > I'll try to find the original BIOS for Michael
>
> It's a kind offer, but not useful in my experience, for the above
> reasons. All Lenovo BIOS updates I've seen so far require a Lenovo BIOS.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

[Trammell Hudson]

Is there a right way to pass additional compiler flags to the coreboot
makefiles?  We've been working on making the Heads firmware reproducible
and found that the -fdebug-prefix-map option is necessary to deal with
different build directories.  To make this work with coreboot we ended
passing in environment variables CFLAGS_x86_32 and CFLAGS_x86_64:

  EXTRA_FLAGS="-fdebug-prefix-map=`pwd`=. -gno-record-gcc-switches"
  make CFLAGS_x86_32="$EXTRA_FLAGS" CFLAGS_x86_64="$EXTRA_FLAGS"

Ideally coreboot could use this in its Makefile to avoid having any
build tree path dependencies included in the binary, although for now the
Heads build script passes in these extra flags to all of our dependencies.

With this (and several other commits this week), Heads is now 100%
reproducible (tested on Ubuntu, Qubes' Fedora, and an ancient Debian):

https://github.com/osresearch/heads/releases/tag/v0.1.0

-- 
Trammell

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

Re: [coreboot] Back to original BIOS

[Peter Stuge]

Michal Widlok wrote:
> Ron - I've lost original bios, my mistake.

I think that will be a problem. Lenovo BIOSes save some machine-specific
information in the flash ROM across updates, and I've so far not seen
a single Lenovo mainboard which does not require this information for
the vendor BIOS to work.


> On Wed, Feb 1, 2017 at 9:20 PM, Zoran Stojsavljevic 
>  wrote:
> > I'll try to find the original BIOS for Michael

It's a kind offer, but not useful in my experience, for the above
reasons. All Lenovo BIOS updates I've seen so far require a Lenovo BIOS.


//Peter

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

[coreboot] 2017 North American coreboot Conference

[Martin Roth]

We are happy to announce that the 2017 North American coreboot Conference
will be held in Denver, Colorado on June 5th & 6th, with an optional
hacking day on June 7th.


Register here:  https://goo.gl/o2j4gX


The cost will be $250 for corporate attendees, $100 for individuals, and
$25 for students.
All fees go up by $50 for registrations received after May 5.
Payment is NOT required at the time of registration.  We will contact you
later with payment information.


Hotel, travel, and other additional information is available on the
coreboot wiki: https://www.coreboot.org/Denver2017


If you have any questions, please email us at convent...@coreboot.org


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

[coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Raptor Engineering Automated Coreboot Test Stand]

The ASUS KGPE-D16 fails verification for branch master as of commit 
3236f7be093b3dfed606d6a6b4e81743ecfe0c5c

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
3236f7b ectool: Support OpenBSD

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS 
KGPE-D16 test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineering.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineering.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1486050117-3-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rangeley FSP reports "Err[24]: GetSet Value exceeds limits" during memory init

[Zoran Stojsavljevic]

> As for our prototype, we got it to boot with one memory channel while
‘hot’. We’re working with Intel to narrow it down,
> but it looks like a marginal trace length issue. The verbose FSP tells us
we are having issues during Command Clock Training.

As I recall, INTEL provides HW PCB evaluation support for custom platforms,
for VIP IOTG customers. There is also INTEL trace length calculation tool,
for each family of ATOM/CORE. Important things to note (area: board HW
design and verification), Andy. [image: Inline image 1]

Since I also recall that Rangeley has some Gen.3 SATA support (2 ports), I
also will advise you to check/pay attention to these, during Lane Clock
training/SATA 3 Protocol training... Just in case.

Good Luck,
Zoran

On Thu, Feb 2, 2017 at 2:28 PM, Andy Knowles  wrote:

> A follow-up, for posterity:
>
>
>
> I got the RCC-DFF from ADI to boot using the memory down option. To do
> this, I enabled Memory Down in the FSP (via BCT) and also changed all of
> the SPD SMBus Addresses to 0xff, to make sure the EEPROM wasn’t being
> used.  Booting with this FSP I get an expected “No DIMMs Present” error.
>
>
>
> I then modified src/mainboard/adi/rcc-dff/romstage.c as attached,
> specifying the SPD data from the Kingston datasheet and one populated DIMM
> on channel 0.
>
>
>
> The RCC-DFF then booted normally.
>
>
>
> As for our prototype, we got it to boot with one memory channel while
> ‘hot’. We’re working with Intel to narrow it down, but it looks like a
> marginal trace length issue. The verbose FSP tells us we are having issues
> during Command Clock Training.
>
>
>
> Thanks again for responses!
>
>
>
> Andy
>
>
>
>
>
> *From:* coreboot [mailto:coreboot-boun...@coreboot.org] *On Behalf Of *Andy
> Knowles
> *Sent:* Monday, 23 January 2017 11:55
> *To:* Agrain Patrick 
> *Cc:* coreboot@coreboot.org
> *Subject:* Re: [coreboot] Rangeley FSP reports "Err[24]: GetSet Value
> exceeds limits" during memory init
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> 
>
> Feedback 
>
> Hi Patrick,
>
>
>
> I have an RCC-DFF from ADI. The memory is soldered down, but from their
> BIOS source it seems they aren’t using the FSP memory down option, so I
> suspect they have an EEPROM on the board with SPD data pretending to be a
> DIMM. I’m going to try booting it with memory down set in FSP and SPD data
> in coreboot instead.
>
>
>
> Thanks,
>
> Andy
>
>
>
> *From:* Agrain Patrick [mailto:patrick.agr...@al-enterprise.com
> ]
>
> HI Andy,
>
>
>
> RCC-VE dev board from ADI has also memory down. It may help to compare.
> But unfortunately, schematics are not available.
>
> Regards,
>
> Patrick Agrain
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] EHCI wakeup on Haswell+Lynxpoint motherboards

[Аладышев Константин]

I have Haswell+LynxpointLP motherboard and Linux doesn't wakeup from USB
devices from S3. EHCI controller is listed in "/proc/acpi/wakeup" as
"enabled" and GPE number is seemed to be configured correctly in ACPI to
PME_B0, but it doesn't work.

 

What is need to be done to enable USB wakeup? 

 

Does USB wakeup work on Haswell+Lynxpoint motherboards?

 

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

[coreboot] USB problems in Haswell+Lynxpoint motherboards

[Аладышев Константин]

Does someone have moherboards with Haswell+Lynxpoint?
I have problems with USB.
In Linux USB devices work fine with "ehci-pci" driver and don't work
correctly with "ehci-hcd" driver (they freeze completely short time after
boot).
In Windows USB devices work fine in safe mode and don't work correctly with
normal mode (again they freeze completely short time after boot).

What is the difference between these two Linux drivers and what can be the
source of this problem?



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

Re: [coreboot] Rangeley FSP reports "Err[24]: GetSet Value exceeds limits" during memory init

[Andy Knowles]

A follow-up, for posterity:

I got the RCC-DFF from ADI to boot using the memory down option. To do this, I 
enabled Memory Down in the FSP (via BCT) and also changed all of the SPD SMBus 
Addresses to 0xff, to make sure the EEPROM wasn’t being used.  Booting with 
this FSP I get an expected “No DIMMs Present” error.

I then modified src/mainboard/adi/rcc-dff/romstage.c as attached, specifying 
the SPD data from the Kingston datasheet and one populated DIMM on channel 0.

The RCC-DFF then booted normally.

As for our prototype, we got it to boot with one memory channel while ‘hot’. 
We’re working with Intel to narrow it down, but it looks like a marginal trace 
length issue. The verbose FSP tells us we are having issues during Command 
Clock Training.

Thanks again for responses!

Andy


From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Andy Knowles
Sent: Monday, 23 January 2017 11:55
To: Agrain Patrick 
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Rangeley FSP reports "Err[24]: GetSet Value exceeds 
limits" during memory init


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing

Feedback

Hi Patrick,

I have an RCC-DFF from ADI. The memory is soldered down, but from their BIOS 
source it seems they aren’t using the FSP memory down option, so I suspect they 
have an EEPROM on the board with SPD data pretending to be a DIMM. I’m going to 
try booting it with memory down set in FSP and SPD data in coreboot instead.

Thanks,
Andy

From: Agrain Patrick [mailto:patrick.agr...@al-enterprise.com]
HI Andy,

RCC-VE dev board from ADI has also memory down. It may help to compare. But 
unfortunately, schematics are not available.
Regards,
Patrick Agrain

/*
 * This file is part of the coreboot project.
 *
 * Copyright (C) 2007-2010 coresystems GmbH
 * Copyright (C) 2011 The ChromiumOS Authors.  All rights reserved.
 * Copyright (C) 2013-2014 Sage Electronic Engineering, LLC.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; version 2 of the License.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include "gpio.h"

static void interrupt_routing_config(void)
{
u8 *ilb_base = (u8 *)(pci_read_config32(SOC_LPC_DEV, IBASE) & ~0xf);

/*
* Initialize Interrupt Routings for each device in ilb_base_address.
* IR01 map to PCIe device 0x01 ... IR31 to device 0x1F.
* PIRQ_A maps to IRQ 16 ... PIRQ_H maps tp IRQ 23.
* This should match devicetree and the ACPI IRQ routing/
*/
write32(ilb_base + ILB_ACTL, 0x);  /* ACTL bit 2:0 SCIS IRQ9 */
write16(ilb_base + ILB_IR01, 0x3210);  /* IR01h IR(ABCD) - PIRQ(ABCD) */
write16(ilb_base + ILB_IR02, 0x3210);  /* IR02h IR(ABCD) - PIRQ(ABCD) */
write16(ilb_base + ILB_IR03, 0x7654);  /* IR03h IR(ABCD) - PIRQ(EFGH) */
write16(ilb_base + ILB_IR04, 0x7654);  /* IR04h IR(ABCD) - PIRQ(EFGH) */
write16(ilb_base + ILB_IR20, 0x7654);  /* IR14h IR(ABCD) - PIRQ(EFGH) */
write16(ilb_base + ILB_IR22, 0x0007);  /* IR16h IR(A) - PIRQ(H) */
write16(ilb_base + ILB_IR23, 0x0003);  /* IR17h IR(A) - PIRQ(D) */
write16(ilb_base + ILB_IR24, 0x0003);  /* IR18h IR(A) - PIRQ(D) */
write16(ilb_base + ILB_IR31, 0x0020);  /* IR1Fh IR(B) - PIRQ(C) */
}

/**
 * /brief mainboard call for setup that needs to be done before fsp init
 *
 */
void early_mainboard_romstage_entry(void)
{
setup_soc_gpios(_map);
}

/**
 * /brief mainboard call for setup that needs to be done after fsp init
 *
 */
void late_mainboard_romstage_entry(void)
{
interrupt_routing_config();
}

/**
 * Get function disables - most of these will be done automatically
 * @param mask pointer to the function-disable bitfield
 */
void get_func_disables(uint32_t *mask)
{

}

/*
  * MEM_DOWN_DIMM_CONFIG
  *   MemoryDownDimmPopulation - 0: Empty 1: Populated.
  *   MemoryDownDimmSpdData - structure MEM_DOWN_DIMM_SPD_DATA for spd data.
 */
  /* 4x Kingston 4Gb PC3-12800 DDR3-1600MHz Unbuffered CL11 Single Rank Memory  
*/
static const MEM_DOWN_DIMM_CONFIG PopulatedDimm = {
0x01, // MemoryDownDimmPopulation
{  // MemoryDownDimmSpdData
  0x0B,   //Byte   2  Dram Device Type  
  DDR3
  0x02,   //Byte   3  Module type (3:0) 
  UDIMM (Unbuffered Long DIMM)
  0x04,   //Byte   4  Density and Banks 
  4Gb (8