[coreboot] Re: Memory Down approach Error on intel Denverton board

[Szafranski, MariuszX]

Hi,

Did you adjusted mMemoryDownConfig structure in mainboard`s romstage.c file to 
much your memory down configuration?
Refer to commented out example just above structure definition.
Also double check if .SpdDataPtr structure member for memory down slot has 
correct pointer to spd.bin content.

Mariusz
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)

[Szafranski, MariuszX]

... and a little note:
This is only for DNV/HCV  (as we are team dedicated to them). No change for 
other Intel  hw. They are handled by other Intel teams.
Mariusz

-Original Message-
From: Szafranski, MariuszX  
Sent: Wednesday, January 19, 2022 10:49 AM
To: Peter Stuge ; coreboot@coreboot.org; Daly, Jeff 

Subject: [coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS 
refactoring)

Hi,

To clarify situation (Jeff - looks like you got wrong my last email  )

DNV will still be supported by Intel. Vanessa will continue to be primary 
support contact from Intel side.
One thing that will change in next few months is that I and Suresh will move to 
another project and will have limited time to maintain DNV/HCV code. But we 
still be around .
So that’s main reason to propose Jeff as main maintainer for DNV/HCV.

Mariusz


-Original Message-
From: Peter Stuge 
Sent: Tuesday, January 18, 2022 2:17 PM
To: coreboot@coreboot.org
Subject: [coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS 
refactoring)

Thank you for your updates, Jeff.

Jeff Daly wrote:
> the feedback I got from Intel is that they will be moving away from 
> internal support for DNV coreboot.

It's sad and telling to see one of the most ambitious technology companies in 
the world, one that routinely pushed technology limits, choose to not continue 
to accept responsibility and be active in our firmware community.

Value is never inherent, it's what we choose to create.


Kind regards

//Peter
___
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to 
coreboot-le...@coreboot.org
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to 
coreboot-le...@coreboot.org
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)

[Szafranski, MariuszX]

Hi,

To clarify situation (Jeff - looks like you got wrong my last email  )

DNV will still be supported by Intel. Vanessa will continue to be primary 
support contact from Intel side.
One thing that will change in next few months is that I and Suresh will move to 
another project and will have limited time to maintain DNV/HCV code. But we 
still be around .
So that’s main reason to propose Jeff as main maintainer for DNV/HCV.

Mariusz


-Original Message-
From: Peter Stuge  
Sent: Tuesday, January 18, 2022 2:17 PM
To: coreboot@coreboot.org
Subject: [coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS 
refactoring)

Thank you for your updates, Jeff.

Jeff Daly wrote:
> the feedback I got from Intel is that they will be moving away from 
> internal support for DNV coreboot.

It's sad and telling to see one of the most ambitious technology companies in 
the world, one that routinely pushed technology limits, choose to not continue 
to accept responsibility and be active in our firmware community.

Value is never inherent, it's what we choose to create.


Kind regards

//Peter
___
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to 
coreboot-le...@coreboot.org
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).

[Szafranski, MariuszX]

Hi Furquan,

Thanks for pointing. I`ve missed this patch series.
Yeah omitting the `device lapic` line from the devicetree and adding this patch 
looks like correct (common) way to handle this issue.

BR,
Mariusz

> > have you tried omitting the `device lapic` line from the devicetree?
>
> I have tested this, in this case Linux shows only one processor core. 
> Therefore the 'device lapic' line is really needed...

Can you please try dropping `device lapic` from the devicetree along with this 
patch:

diff --git a/src/soc/intel/denverton_ns/cpu.c b/src/soc/intel/denverton_ns/cpu.c
index 1dc0830d86..ecefd3a987 100644
--- a/src/soc/intel/denverton_ns/cpu.c
+++ b/src/soc/intel/denverton_ns/cpu.c
@@ -287,6 +287,9 @@ static const struct mp_ops mp_ops = {

 void denverton_init_cpus(struct device *dev)  {
+   if (!dev->link_list)
+   add_more_links(dev, 1);
+
/* Clear for take-off */
if (mp_init_with_smm(dev->link_list, _ops) < 0)
printk(BIOS_ERR, "MP initialization failure.\n");

I think once you drop the device from device tree, dev->link_list would be NULL 
and so MP initialization failed for you. This problem is not really unique to 
denverton and was fixed just a few days back for other Intel SoCs using 
common/block/cpu/mp_init too:

https://review.coreboot.org/c/coreboot/+/56758
https://review.coreboot.org/c/coreboot/+/56852


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).

[Szafranski, MariuszX]

Hi Dimitry,

I can see it and my proposition isn`t “something new” (still updating lapicid 
with value detected while booting)
Logically little different (keeping 0 in devicetree.cb) without introducing 
“0xbeef magic” and avoiding future questions like below:
> I wish I could understand how this magic works :)! lapic 0xbeef .
As it is DNV specific it is just moved to DNV subdirectory without touching 
coreboot core.

BR,
Mariusz

From: Дмитрий Понаморев 
Sent: Friday, August 20, 2021 11:40 PM
To: Szafranski, MariuszX 
Cc: Sumo ; Jay Talbott ; 
Coreboot 
Subject: Re: [coreboot] Re: A different lapic number in devicetree.cb needed 
for CPU with the same SKU and steping (Intel Atom C3538).

Hi

I don't understand why to invent something new. Sumo's patch works great. Why 
can't you use it?
This Intel Atom Denverton C3000 processor has a maximum of 16 cores (4 clusters 
of 4 processors each).
The problem with the lapic ID is real for processors with less than 16 cores, 
especially for 2 and 4 cores - these processors are also 16 only with disabled 
cores in clusters.
Intel turns them off randomly and therefore the value lapic ID floats.
Changing this parameter as you suggest will suit you if you have one board - if 
there are many of them, it will not work.

Best regards,
Dmitry Ponamorev

пт, 20 авг. 2021 г. в 23:56, Szafranski, MariuszX 
mailto:mariuszx.szafran...@intel.com>>:
Hi,

Maybe keep 0 for apicid in devicetree.cb and add something like below to 
denverton soc_init (or define separate function for check and fixup)  in 
src/soc/intel/denverton_ns/chip.c.
Could anyone with apicid != 0 test and let us know?
BR,
Mariusz

static void soc_init(void *data)
{
  unsigned long bsp_lapicid = lapicid();
  struct device *dev;

  if (bsp_lapicid){
for (dev = _root, cnt = 0; dev; dev = dev->next){
  if ((dev->path.type == DEVICE_PATH_APIC){
if (bsp_lapicid != dev->path.apic.apic_id){
  printk(BIOS_SPEW,
"soc_init: BSP lapic ID = 0x%lx - updating in devicetree\n",
bsp_lapicid);
  dev->path.apic.apic_id = bsp_lapicid;
} else {
  break;
};
  };
};
  };
…..


From: Дмитрий Понаморев mailto:dponamo...@gmail.com>>
Sent: Monday, August 16, 2021 8:17 PM
To: Sumo mailto:kingsu...@gmail.com>>
Cc: Jay Talbott 
mailto:jaytalb...@sysproconsulting.com>>; 
Coreboot mailto:coreboot@coreboot.org>>
Subject: [coreboot] Re: A different lapic number in devicetree.cb needed for 
CPU with the same SKU and steping (Intel Atom C3538).

Hi Sumo,


>  ... It’s also possible (but not confirmed) that for a particular SKU (other 
> than 16-core SKUs), it might not be consistent between parts
I can confirm this, I have two C3558 SoC's with first core different APID 
ID's...

I can confirm it too for C3338, C3538.

Do you think I can submit my patch (see previous discussions) or do we have a 
better solution?

Your patch works great for me ( for C3338, C3538, C3758, C3958).
Thanks again! (from this thread: 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/MCRPRU7ETWDJFG7RQPFYPOTICCJLT4SL/#FTE6TVQU5VCZMJTBE2NFNC2AME5A7PBB
 )






пн, 16 авг. 2021 г. в 20:58, Sumo 
mailto:kingsu...@gmail.com>>:
Hi Jay,

>  ... It’s also possible (but not confirmed) that for a particular SKU (other 
> than 16-core SKUs), it might not be consistent between parts
I can confirm this, I have two C3558 SoC's with first core different APID 
ID's...

Do you think I can submit my patch (see previous discussions) or do we have a 
better solution?

Kind regards,
Sumo

On Mon, Aug 16, 2021 at 1:45 PM Jay Talbott 
mailto:jaytalb...@sysproconsulting.com>> wrote:
Unfortunately, for the Denverton SoC (C3000 series), the APIC ID of the first 
core is not always the same. For 16-core SKUs, it’s always 0, but for SKUs with 
a lower number of cores, it may be a different number. It’s also possible (but 
not confirmed) that for a particular SKU (other than 16-core SKUs), it might 
not be consistent between parts. The solution is to basically ignore the value 
in devicetree and use the actual APIC ID from the first core.

- Jay

From: Sumo [mailto:kingsu...@gmail.com<mailto:kingsu...@gmail.com>]
Sent: Monday, August 16, 2021 9:15 AM
To: Nico Huber
Cc: Дмитрий Понаморев; Coreboot
Subject: [coreboot] Re: A different lapic number in devicetree.cb needed for 
CPU with the same SKU and steping (Intel Atom C3538).

Hi,

> have you tried omitting the `device lapic` line from the devicetree?
I have tested this, in this case Linux shows only one processor core. Therefore 
the 'device lapic' line is really needed...

I can submit that Local APIC Fixup patch to gerrit but I'm not sure if this is 
really the best solution.

Kind regards,
Sumo


On Wed, Oct 7, 2020 at 6:35 PM Nico Huber mailto:nic...@gmx.de>> 
wrote:
Hi,

have you tried omitting the `device lapic` line from the devicetree?
It

[coreboot] [RFC] Intel split stack IIO design support in coreboot - new multidomain approach

[Szafranski, MariuszX]

Hi,

RFC/initial proposal how to implement split IIO in coreboot:
[RFC] Intel IIO split stack - multidomain approach (I38ac830e) * Gerrit Code 
Review (coreboot.org)
thx for all comments, suggestions

BR,
Mariusz
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).

[Szafranski, MariuszX]

Hi,

Maybe keep 0 for apicid in devicetree.cb and add something like below to 
denverton soc_init (or define separate function for check and fixup)  in 
src/soc/intel/denverton_ns/chip.c.
Could anyone with apicid != 0 test and let us know?
BR,
Mariusz

static void soc_init(void *data)
{
  unsigned long bsp_lapicid = lapicid();
  struct device *dev;

  if (bsp_lapicid){
for (dev = _root, cnt = 0; dev; dev = dev->next){
  if ((dev->path.type == DEVICE_PATH_APIC){
if (bsp_lapicid != dev->path.apic.apic_id){
  printk(BIOS_SPEW,
"soc_init: BSP lapic ID = 0x%lx - updating in devicetree\n",
bsp_lapicid);
  dev->path.apic.apic_id = bsp_lapicid;
} else {
  break;
};
  };
};
  };
…..


From: Дмитрий Понаморев 
Sent: Monday, August 16, 2021 8:17 PM
To: Sumo 
Cc: Jay Talbott ; Coreboot 

Subject: [coreboot] Re: A different lapic number in devicetree.cb needed for 
CPU with the same SKU and steping (Intel Atom C3538).

Hi Sumo,


>  ... It’s also possible (but not confirmed) that for a particular SKU (other 
> than 16-core SKUs), it might not be consistent between parts
I can confirm this, I have two C3558 SoC's with first core different APID 
ID's...

I can confirm it too for C3338, C3538.

Do you think I can submit my patch (see previous discussions) or do we have a 
better solution?

Your patch works great for me ( for C3338, C3538, C3758, C3958).
Thanks again! (from this thread: 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/MCRPRU7ETWDJFG7RQPFYPOTICCJLT4SL/#FTE6TVQU5VCZMJTBE2NFNC2AME5A7PBB
 )






пн, 16 авг. 2021 г. в 20:58, Sumo 
mailto:kingsu...@gmail.com>>:
Hi Jay,

>  ... It’s also possible (but not confirmed) that for a particular SKU (other 
> than 16-core SKUs), it might not be consistent between parts
I can confirm this, I have two C3558 SoC's with first core different APID 
ID's...

Do you think I can submit my patch (see previous discussions) or do we have a 
better solution?

Kind regards,
Sumo

On Mon, Aug 16, 2021 at 1:45 PM Jay Talbott 
mailto:jaytalb...@sysproconsulting.com>> wrote:
Unfortunately, for the Denverton SoC (C3000 series), the APIC ID of the first 
core is not always the same. For 16-core SKUs, it’s always 0, but for SKUs with 
a lower number of cores, it may be a different number. It’s also possible (but 
not confirmed) that for a particular SKU (other than 16-core SKUs), it might 
not be consistent between parts. The solution is to basically ignore the value 
in devicetree and use the actual APIC ID from the first core.

- Jay

From: Sumo [mailto:kingsu...@gmail.com]
Sent: Monday, August 16, 2021 9:15 AM
To: Nico Huber
Cc: Дмитрий Понаморев; Coreboot
Subject: [coreboot] Re: A different lapic number in devicetree.cb needed for 
CPU with the same SKU and steping (Intel Atom C3538).

Hi,

> have you tried omitting the `device lapic` line from the devicetree?
I have tested this, in this case Linux shows only one processor core. Therefore 
the 'device lapic' line is really needed...

I can submit that Local APIC Fixup patch to gerrit but I'm not sure if this is 
really the best solution.

Kind regards,
Sumo


On Wed, Oct 7, 2020 at 6:35 PM Nico Huber mailto:nic...@gmx.de>> 
wrote:
Hi,

have you tried omitting the `device lapic` line from the devicetree?
It would only matter if there is configuration associated with it, but
I can't see anything like that for `intel/harcuvar`.

What happens is that this `device lapic` line in the devicetree becomes
an entry in a list at runtime. This list is later filled with the actual
cores present. If any of the actual cores has the same APIC id as given
in the devicetree, no additional entry is added for this core. However
if none of the actual cores has that id, the original entry is left
blindly in the list, causing coreboot to report the spurious, fifth
core.

On 07.10.20 21:27, dponamo...@gmail.com wrote:
> Thank you so much Javier Galindo!
>
> Sorry for not finding this case myself ...
> I checked it on the motherboard with lapic #4 - everything works as it should.
> Tomorrow I'll check it on the motherboard with lapic #0.
> I wish I could understand how this magic works :)! lapic 0xbeef .

It's kind of a wildcard that gets replaced with the number found in the
hardware. Nothing too special but probably unnecessary.

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to 
coreboot-le...@coreboot.org
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended 

[coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE

[Szafranski, MariuszX]

Hi Sumo,

Looks ok, approved.
Thx for submitting patch

Mariusz

From: Sumo 
Sent: Wednesday, August 18, 2021 2:27 PM
To: Coreboot 
Subject: [coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE

Hi Mariusz,

The proposal of calling fast_spi_early_init() in bootblock is working. Other 
Intel processors are already doing the same way, probably this was missing in 
Denverton. Also, it works better than using 
BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES as we don't have the other issue I have 
pointed out.
The patch was submitted for review:
https://review.coreboot.org/c/coreboot/+/57033

Thanks,
Sumo

On Fri, Jun 11, 2021 at 9:05 AM Szafranski, MariuszX 
mailto:mariuszx.szafran...@intel.com>> wrote:
Hi Sumo,

It should be simple as adding SPI early init to bootblock.
You could try to add call to
fast_spi_early_init(DEFAULT_SPI_BASE);
at the end of bootblock_soc_early_init function from 
src/soc/intel/denverton_ns/bootblock/bootblock.c
I suspect that after that MRC writing should also work in earlier stage if 
there will be no address conflict (can`t verify that myself for now☹ )
Please try and let us know.

Mariusz

From: Sumo mailto:kingsu...@gmail.com>>
Sent: Friday, June 11, 2021 12:11 AM
To: mariusz.szafran...@akumat.pl<mailto:mariusz.szafran...@akumat.pl>
Cc: Coreboot mailto:coreboot@coreboot.org>>
Subject: [coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE

Hi Mariusz,

Setting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES solved the problem, thanks!

The only drawback of saving MRC CACHE in later state are the additional resets 
which are requested by FSP_S (silicon init) - for each additional reset the 
DDR4 training data is lost and this delays the startup a little bit, but this 
was also occurring in old coreboot-4.8.1.
Basically those additional resets happens when the CMOS is cleared (when 
RTC-power-well settings are lost also) so FSP_S resets the system to 
reconfigure peripherals (ie. SATA, HSIO changes, etc) - and for each reset DDR4 
training must be performed again.

For coreboot-4.8.1 in the past I have successfully implemented a change to save 
MRC CACHE before calling FSP_S to fix this, it worked well but I never used 
that change in production to not take any risk since I was unsure about side 
effects. But this improvement can save some time during manufacturing as some 
resets can't be avoided (here at least 1 reset always happens). It would be 
good if this can be implemented somehow in coreboot latest...

Hopefully this info could be useful to someone ;)

Kind regards,
Sumo

On Thu, Jun 10, 2021 at 3:41 PM Mariusz Szafrański via coreboot 
mailto:coreboot@coreboot.org>> wrote:

Hi Sumo,

Please try to additionally select MRC_WRITE_NV_LATE or 
BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to push MRC writing to later state
W dniu 10.06.2021 o 16:58, Sumo pisze:
Hi,

I'm stuck in a problem where coreboot fails to write the MRC cache in the SPI 
Flash.
Below is the log output:

FMAP: area RW_MRC_CACHE found @ 81 (65536 bytes)
MRC: Checking cached data update for 'RW_MRC_CACHE'.
SF: Detected 00  with sector size 0x1000, total 0x100
MRC: no data in 'RW_MRC_CACHE'
MRC: cache data 'RW_MRC_CACHE' needs update.
SPI Transaction Error at Flash Offset 81 HSFSTS = 0x01046003
REGF metadata allocation failed: 1949 data blocks 4096 total blocks
MRC: failed to update 'RW_MRC_CACHE'.

Any clues?

Thanks,
Sumo


___

coreboot mailing list -- coreboot@coreboot.org<mailto:coreboot@coreboot.org>

To unsubscribe send an email to 
coreboot-le...@coreboot.org<mailto:coreboot-le...@coreboot.org>
___
coreboot mailing list -- coreboot@coreboot.org<mailto:coreboot@coreboot.org>
To unsubscribe send an email to 
coreboot-le...@coreboot.org<mailto:coreboot-le...@coreboot.org>

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE

[Szafranski, MariuszX]

Hi Sumo,

It should be simple as adding SPI early init to bootblock.
You could try to add call to
fast_spi_early_init(DEFAULT_SPI_BASE);
at the end of bootblock_soc_early_init function from 
src/soc/intel/denverton_ns/bootblock/bootblock.c
I suspect that after that MRC writing should also work in earlier stage if 
there will be no address conflict (can`t verify that myself for now☹ )
Please try and let us know.

Mariusz

From: Sumo 
Sent: Friday, June 11, 2021 12:11 AM
To: mariusz.szafran...@akumat.pl
Cc: Coreboot 
Subject: [coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE

Hi Mariusz,

Setting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES solved the problem, thanks!

The only drawback of saving MRC CACHE in later state are the additional resets 
which are requested by FSP_S (silicon init) - for each additional reset the 
DDR4 training data is lost and this delays the startup a little bit, but this 
was also occurring in old coreboot-4.8.1.
Basically those additional resets happens when the CMOS is cleared (when 
RTC-power-well settings are lost also) so FSP_S resets the system to 
reconfigure peripherals (ie. SATA, HSIO changes, etc) - and for each reset DDR4 
training must be performed again.

For coreboot-4.8.1 in the past I have successfully implemented a change to save 
MRC CACHE before calling FSP_S to fix this, it worked well but I never used 
that change in production to not take any risk since I was unsure about side 
effects. But this improvement can save some time during manufacturing as some 
resets can't be avoided (here at least 1 reset always happens). It would be 
good if this can be implemented somehow in coreboot latest...

Hopefully this info could be useful to someone ;)

Kind regards,
Sumo

On Thu, Jun 10, 2021 at 3:41 PM Mariusz Szafrański via coreboot 
mailto:coreboot@coreboot.org>> wrote:

Hi Sumo,

Please try to additionally select MRC_WRITE_NV_LATE or 
BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to push MRC writing to later state
W dniu 10.06.2021 o 16:58, Sumo pisze:
Hi,

I'm stuck in a problem where coreboot fails to write the MRC cache in the SPI 
Flash.
Below is the log output:

FMAP: area RW_MRC_CACHE found @ 81 (65536 bytes)
MRC: Checking cached data update for 'RW_MRC_CACHE'.
SF: Detected 00  with sector size 0x1000, total 0x100
MRC: no data in 'RW_MRC_CACHE'
MRC: cache data 'RW_MRC_CACHE' needs update.
SPI Transaction Error at Flash Offset 81 HSFSTS = 0x01046003
REGF metadata allocation failed: 1949 data blocks 4096 total blocks
MRC: failed to update 'RW_MRC_CACHE'.

Any clues?

Thanks,
Sumo


___

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
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot image forIntel Harcuvar CRB

[Szafranski, MariuszX]

Hi Tirumalesh,

Please verify if FSP is correctly integrated. Especially if FSP-T part is 
enabled and used for setting up CAR.
config mainboard section:
vendor->Intel,
model->Harcuvar,
romsize ->16M, (insert your actual SPI flash size)
cbfs size 8M (0x80) (or adjust for your needs)
config chipset:
check  Enable High-speed UART debug port selected by 
UART_FOR_CONSOLE (enable for non legacy UART mode, disable for legacy)
cache as ram implementation -> Use FSP CAR
UART mode – leave at default non legacy mode (or enable if 
needed – adjust other settings for legacy mode)
Verify if generate from tree is selected for microcode (Include 
CPU microcode in CBFS (Generate from tree))
config generic drivers:
UART's PCI bus, device, function address - 0x8000d000
Verify if “serial port” on superior is unchecked (need to be 
when using UART in legacy mode)
config console:
verify if two first options (bootblock console and postcar 
console) are enabled

As I remember there are two serial port connectors – check if you are using 
correct one (try both)

BR,
Mariusz

From: Tirumalesh 
Sent: Friday, February 5, 2021 8:54 AM
To: Javier Galindo ; coreboot@coreboot.org
Subject: [coreboot] Re: coreboot image forIntel Harcuvar CRB

It seems the FSP binaries are auto included, and the configs seems to be of no 
effect.
Is it not right?

If so I will try to add binaries and microcode header file.

Thanks,
Tirumalesh


On Fri, Feb 5, 2021 at 11:22 AM, Javier Galindo 
mailto:javiergali...@sysproconsulting.com>> 
wrote:
Did you set the following in your config file --> CONFIG_LEGACY_UART_MODE=y

Also have you setup all the proper fsp/ucode binaries that are commented out in 
the config file (just did a quick review):

#Sample settings for Denverton-NS FSP.
#CONFIG_ADD_FSP_BINARIES=y
#CONFIG_FSP_M_FILE="../intel/fsp/denverton_ns/DENVERTON-NS_FSP_M.fd"
#CONFIG_FSP_S_FILE="../intel/fsp/denverton_ns/DENVERTON-NS_FSP_S.fd"
#CONFIG_FSP_T_FILE="../intel/fsp/denverton_ns/DENVERTON-NS_FSP_T.fd"
#CONFIG_FSP_CAR=y

#Sample settings for microcode definitions.
#CONFIG_CPU_MICROCODE_HEADER_FILES="../intel/cpu/denverton_ns/microcode/microcode_blob.h"
#CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER=y

Unfortunately all my harcuvar work has also been on a fairly old tree of 
coreboot.

I'll give it a try on my Harcuvar if you don't make any progress, but it won't 
be until the weekend.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to 
coreboot-le...@coreboot.org


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding Intel CPU frequency.

[Szafranski, MariuszX]

Hi Nitin,

Look`s like SpeedStepping in action - correct behavior while on idle.
Please put more stress on CPU and recheck - It should jump back to 2200

BR,
Mariusz

-Original Message-
From: nitin.ramesh.si...@gmail.com  
Sent: czwartek, 23 kwietnia 2020 14:36
To: coreboot@coreboot.org
Subject: [coreboot] Regarding Intel CPU frequency.

Hi,

I am using coreboot to boot Denverton cpu (CPU C3558) based board.

I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" 
under the coreboot logs.
.
"
CPU #3 initialized
bsp_do_flight_plan done after 146 msecs.
cpu: frequency set to 2200
"

Later when I check the frequency reading under linux (kernel version 4.19) , It 
comes out as 800 Mz:

model name  : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
stepping: 1
microcode   : 0x24
cpu MHz : 800.000


When I reprogram the board with BIOS, the cpu frequency gets reflected 
correctly (i.e. 2200 MHz) with the same kernel image.

I have also tried out the different Grub command line options like disabling 
the pstate, and idle state e.t.c, but the end result remains same. 

Can anyone please provide me some suggestions. Is there is any cpu specific 
settings which needs to enabled under coreboot or with Intel-FSP ? 

Thanks,
Nitin.
___
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to 
coreboot-le...@coreboot.org
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Atom c3000 Harcuvar and Intel ME

[Szafranski, MariuszX]

Hi,

In case of Harcuvar CRB we have 16M SPI flash: first 8M for ME (which is 
outside of CBFS) and last 8M for coreboot.
We need to specify two things in coreboot config:

-  ROM chip size – 16M – physical size of SPI flash (needed for correct 
flash offset calculations inside coreboot code)

-  Size of CBFS filesystem in ROM – 8M (0x80) or less
16M coreboot.rom file should be built with above config.
You need to manually inject 8M ME blob at offset 0 into ‘coreboot.rom’ file.
Or just flash last 8M from coreboot.rom into last 8M of SPI flash if ME blob is 
already there.

Mariusz

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Sumo
Sent: Monday, February 26, 2018 9:15 PM
To: coreboot@coreboot.org
Subject: [coreboot] Atom c3000 Harcuvar and Intel ME

Hi,

In the coreboot build menu there is no option regarding the Intel ME 
integration.
The 'coreboot.rom' file is the full SPI flash image or this file is suitable to
replace the BIOS region of the SPI flash (0x0080--0x00ff)?
(i.e. in the SPI flash we already have a region for Intel ME firmware)

Thanks,
Sumo
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI payload works

[Szafranski, MariuszX]

Verified payload was built using code based on EDK2 code commit:

>commit c1b0828b3ba8fa203033ede0c3329c0d5573719e
>Author: Zhang, Chao B <chao.b.zh...@intel.com>
>Date:   Wed Jan 25 12:50:55 2017 +0800
>
>SecurityPkg: Tcg2Dxe: Update PCR[4] measure logic
..

from git repo at https://github.com/tianocore/edk2 (master branch)

From: Melissa Yi [mailto:hu...@celestica.com]
Sent: Friday, September 22, 2017 10:53 AM
To: Szafranski, MariuszX <mariuszx.szafran...@intel.com>
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 
UEFI payload works

Hi Mariusz,
 which revision of EDK2 do you use? I used SVN 35017

Thanks.

Regards,
Melissa Yi

BIOS Lead Engineer
Celestica(Shanghai) R Center, China

www.celestica.com<http://www.celestica.com/>
Solid Partners, Flexible Solutions

2017-09-22 15:16 GMT+08:00 Szafranski, MariuszX 
<mariuszx.szafran...@intel.com<mailto:mariuszx.szafran...@intel.com>>:
Hi,

It was tested on Denverton_NS platform using mainly 64bit UEFI payload. 32bit 
UEFI payload was tested also.
Both UEFI payload versions should behave similarly when built from same source 
code using same coreboot configs.
I didn`t noticed difference between 32 and 64 versions.

BR,
Mariusz

From: coreboot 
[mailto:coreboot-boun...@coreboot.org<mailto:coreboot-boun...@coreboot.org>] On 
Behalf Of Melissa Yi
Sent: Thursday, September 21, 2017 11:21 AM
To: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI 
payload works

Hi
   I want to know whether coreboot supports 64bit UEFI payload on denverton 
platform?
   Attached the fail log.

Thanks.

Regards,
Melissa Yi

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI payload works

[Szafranski, MariuszX]

Hi,

It was tested on Denverton_NS platform using mainly 64bit UEFI payload. 32bit 
UEFI payload was tested also.
Both UEFI payload versions should behave similarly when built from same source 
code using same coreboot configs.
I didn`t noticed difference between 32 and 64 versions.

BR,
Mariusz

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Melissa Yi
Sent: Thursday, September 21, 2017 11:21 AM
To: coreboot@coreboot.org
Subject: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI 
payload works

Hi
   I want to know whether coreboot supports 64bit UEFI payload on denverton 
platform?
   Attached the fail log.

Thanks.

Regards,
Melissa Yi
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot