Memory initialisation error

[Andy Pont]

Hello,

I have some life out of my Comet Lake based board but the debug output 
ends with

FMAP: area RW_MRC_CACHE found @ 420000 (65536 bytes)
MRC: no data in 'RW_MRC_CACHE'
PRMRR disabled by config.
WEAK: 
src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params 
called
FspMemoryInit returned 0x80000007
FspMemoryInit returned an error!

The board has all of the memory soldered directly down.  The spd.bin 
file in the build directory is 0 bytes.  Is there a way to extract the 
correct SPD information from either the original UEFI firmware or from a 
running Linux system?

-Andy.

[Matt DeVillier]

>

src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
called

means your board isn't overriding mainboard_memory_init_params() -- so all
the defaults are being used, which I'm not sure will result in a bootable
device. You might want to look at the CML/CFL reference boards, or
system76/lemp9 to see how they are set up and then adapt for your board.
You'll definitely need to load the SPD somehow for a memory-down config,
though I'm not sure how to best obtain it from the stock firmware

On Mon, Nov 16, 2020 at 11:36 AM Andy Pont  wrote:
> Hello,
>
> I have some life out of my Comet Lake based board but the debug output
> ends with
>
> FMAP: area RW_MRC_CACHE found @ 420000 (65536 bytes)
> MRC: no data in 'RW_MRC_CACHE'
> PRMRR disabled by config.
> WEAK:
> src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
>
> called
> FspMemoryInit returned 0x80000007
> FspMemoryInit returned an error!
>
> The board has all of the memory soldered directly down.  The spd.bin
> file in the build directory is 0 bytes.  Is there a way to extract the
> correct SPD information from either the original UEFI firmware or from a
> running Linux system?
>
> -Andy.
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Naresh G. Solanki]

Don't know how to recover SPD from UEFI but Try to read memory part number
written on chip and provide that. Look for SPD file with that name if it's
already present in coreboot.

Regards,
Naresh solanki

On Mon, 16 Nov, 2020, 11:46 pm Matt DeVillier, 
wrote:
> >
>
> src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
> called
>
> means your board isn't overriding mainboard_memory_init_params() -- so all
> the defaults are being used, which I'm not sure will result in a bootable
> device. You might want to look at the CML/CFL reference boards, or
> system76/lemp9 to see how they are set up and then adapt for your board.
> You'll definitely need to load the SPD somehow for a memory-down config,
> though I'm not sure how to best obtain it from the stock firmware
>
> On Mon, Nov 16, 2020 at 11:36 AM Andy Pont 
> wrote:
> > Hello,
> >
> > I have some life out of my Comet Lake based board but the debug output
> > ends with
> >
> > FMAP: area RW_MRC_CACHE found @ 420000 (65536 bytes)
> > MRC: no data in 'RW_MRC_CACHE'
> > PRMRR disabled by config.
> > WEAK:
> > src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
> >
> > called
> > FspMemoryInit returned 0x80000007
> > FspMemoryInit returned an error!
> >
> > The board has all of the memory soldered directly down.  The spd.bin
> > file in the build directory is 0 bytes.  Is there a way to extract the
> > correct SPD information from either the original UEFI firmware or from a
> > running Linux system?
> >
> > -Andy.
> > _______________________________________________
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Andy Pont]

Naresh wrote…
> Don't know how to recover SPD from UEFI but Try to read memory part 
> number written on chip and provide that. Look for SPD file with that 
> name if it's already present in coreboot.

The schematics for the platform show Samsung K4A8G165WB-BCRC devices 
which are (8Gb, 2400Mbps, 512Mx16 DDR4).  The samples of hardware that I 
have are actually fitted with Micron parts.

I can’t match what is printed on the top of the Micron devices (two 
lines of text “0JE75” and “D9ZFW”) to any part numbers on Micron’s 
website.  Is it some kind of encoded version of the part number or is it 
just factory and build information?  Looking at the website I would 
assume that the MT40A512M16JY family would be the equivalent parts.

-Andy.

[Angel Pons]

Hi,

On Wed, Nov 18, 2020 at 10:00 AM Andy Pont  wrote:
> Naresh wrote…
>
> Don't know how to recover SPD from UEFI but Try to read memory part number written on chip and provide that. Look for SPD file with that name if it's already present in coreboot.
>
> The schematics for the platform show Samsung K4A8G165WB-BCRC devices which are (8Gb, 2400Mbps, 512Mx16 DDR4).  The samples of hardware that I have are actually fitted with Micron parts.
>
> I can’t match what is printed on the top of the Micron devices (two lines of text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website.  Is it some kind of encoded version of the part number or is it just factory and build information?  Looking at the website I would assume that the MT40A512M16JY family would be the equivalent parts.

https://www.micron.com/support/tools-and-utilities/fbga
> -Andy.
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Best regards,
Angel

[Andy Pont]

Angel wrote...
> > I can’t match what is printed on the top of the Micron devices (two lines of text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website.  Is it some kind of encoded version of the part number or is it just factory and build information?  Looking at the website I would assume that the MT40A512M16JY family would be the equivalent parts.
>
> https://www.micron.com/support/tools-and-utilities/fbga

That is a cool and useful tool, and not one that was obvious to stumble 
across! That identifies the memory as MT40A1G16KD-062E:E.  The existing 
Coreboot sources seem to reference SPD for this part in two forms 
(Google Zork and Drallion) so I have “borrowed” the SPD files.

The debug output on my board is different to before as the mainboard 
specific memory initialisation code is now being called but ends with:

SPD INDEX = 0
FMAP: area COREBOOT found @ 490200 (11992576 bytes)
CBFS: Locating 'spd.bin'
CBFS: Found @ offset 50bc0 size 200
SPD: module type is DDR4
SPD: module part number is M471A5244BB0-CRC
SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb
SPD: device width 16 bits, bus width 64 bits
SPD: module size is 4096 MB (per channel)
memory slot: 0 configuration done.
memory slot: 2 configuration done.
POST: 0x36
POST: 0x92
POST: 0x98
FspMemoryInit returned 0x80000007
POST: 0xe3
FspMemoryInit returned an error!

The values in the SPD look wrong but also FspMemoryInit is still 
failing.  Is there any way to understand what it making FspMemoryInit do 
so?

-Andy.

[Naresh G. Solanki]

To understand the exact failure cause in FSPM, you need to get post code
from FSP. What is printed in log is Coreboot post code only.
Did you get memory part number from dmidecode -t 17 ?
If you read top of dimm, that will avoid confusion & in my experience
typically part number is printed. In some cases you may have to clean it &
may use a microscope to read part number.

Did you try both K4A8G165WB & MT40A1G16KD ?
Is it possible for you to read post code of FSP.

Regards,
Naresh G Solanki

On Wed, Nov 18, 2020 at 6:53 PM Andy Pont  wrote:
> Angel wrote...
>
> I can’t match what is printed on the top of the Micron devices (two lines
> of text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it
> some kind of encoded version of the part number or is it just factory and
> build information? Looking at the website I would assume that the
> MT40A512M16JY family would be the equivalent parts.
>
> https://www.micron.com/support/tools-and-utilities/fbga
>
> That is a cool and useful tool, and not one that was obvious to stumble
> across! That identifies the memory as MT40A1G16KD-062E:E.  The existing
> Coreboot sources seem to reference SPD for this part in two forms (Google
> Zork and Drallion) so I have “borrowed” the SPD files.
>
> The debug output on my board is different to before as the mainboard
> specific memory initialisation code is now being called but ends with:
>
> SPD INDEX = 0
> FMAP: area COREBOOT found @ 490200 (11992576 bytes)
> CBFS: Locating 'spd.bin'
> CBFS: Found @ offset 50bc0 size 200
> SPD: module type is DDR4
> SPD: module part number is M471A5244BB0-CRC
> SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb
> SPD: device width 16 bits, bus width 64 bits
> SPD: module size is 4096 MB (per channel)
> memory slot: 0 configuration done.
> memory slot: 2 configuration done.
> POST: 0x36
> POST: 0x92
> POST: 0x98
> FspMemoryInit returned 0x80000007
> POST: 0xe3
> FspMemoryInit returned an error!
>
> The values in the SPD look wrong but also FspMemoryInit is still failing.
> Is there any way to understand what it making FspMemoryInit do so?
>
> -Andy.
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Andy Pont]

Naresh wrote...
> To understand the exact failure cause in FSPM, you need to get post 
> code from FSP. What is printed in log is Coreboot post code only.

Is it possible to get the post code from FSPM without a hardware POST 
code indicator?

The hardware I am using only has an M.2 slot (used for an SSD) and it is 
the only format that I don’t have a POST code indicator board for!

-Andy.

[Naresh G. Solanki]

Not sure about other ways for getting post code. May be EC can provide
that. Not sure to what extent DbC can help.
For now as  Angel pointed out, along with SPD, dq_map, dqs_map,
Rcomp_resistor, Rcomp_Target.

I guess you have a CNL platform. Then for LPDDR4  memory, you can use
dq_map from
https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...

rcomp_resistor(Please verify in schematic the resistor value for
DRAM_RCOMP[0..2]. I guess they should be 100 ohm resistor)
https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...

rcomp_target(for LPDDR4)
https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...

For DQS_map, you need to first find the connection between SDRAM DQS pin to
CPU DQS pin map. Can you check that in schematic ?

With this setting + correct SPD, FSPM should run successfully.

On Fri, Nov 20, 2020 at 4:01 PM Andy Pont  wrote:
> Naresh wrote...
>
> To understand the exact failure cause in FSPM, you need to get post code
> from FSP. What is printed in log is Coreboot post code only.
>
> Is it possible to get the post code from FSPM without a hardware POST code
> indicator?
>
> The hardware I am using only has an M.2 slot (used for an SSD) and it is
> the only format that I don’t have a POST code indicator board for!
>
> -Andy.

[Angel Pons]

Hi Andy

On Wed, Nov 18, 2020 at 1:22 PM Andy Pont  wrote:
> Angel wrote...
>
> I can’t match what is printed on the top of the Micron devices (two lines of text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it some kind of encoded version of the part number or is it just factory and build information? Looking at the website I would assume that the MT40A512M16JY family would be the equivalent parts.
>
> https://www.micron.com/support/tools-and-utilities/fbga
>
> That is a cool and useful tool, and not one that was obvious to stumble across! That identifies the memory as MT40A1G16KD-062E:E.  The existing Coreboot sources seem to reference SPD for this part in two forms (Google Zork and Drallion) so I have “borrowed” the SPD files.

Nice!
> The debug output on my board is different to before as the mainboard specific memory initialisation code is now being called but ends with:
>
> SPD INDEX = 0
> FMAP: area COREBOOT found @ 490200 (11992576 bytes)
> CBFS: Locating 'spd.bin'
> CBFS: Found @ offset 50bc0 size 200
> SPD: module type is DDR4
> SPD: module part number is M471A5244BB0-CRC
> SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb
> SPD: device width 16 bits, bus width 64 bits
> SPD: module size is 4096 MB (per channel)
> memory slot: 0 configuration done.
> memory slot: 2 configuration done.
> POST: 0x36
> POST: 0x92
> POST: 0x98
> FspMemoryInit returned 0x80000007
> POST: 0xe3
> FspMemoryInit returned an error!
>
> The values in the SPD look wrong but also FspMemoryInit is still failing.  Is there any way to understand what it making FspMemoryInit do so?

Well, I'd like to see your code: which memcfg parameters you're using,
among other things. Could you please put it somewhere (e.g.
review.coreboot.org) so that I can take a look?
> -Andy.

Thanks in advance,
Angel

[Andy Pont]

Angel wrote...
> Well, I'd like to see your code: which memcfg parameters you're using,
> among other things. Could you please put it somewhere (e.g.
> review.coreboot.org) so that I can take a look?

I have basically just taken the memcfg structure from the Intel Comet 
Lake reference platform and modified it to use READ_SPD_CBFS.  The 
structure is currently:

static const struct cnl_mb_cfg memcfg = {
         /* Parameters required to access SPD for 
CH0D0/CH0D1/CH1D0/CH1D1. */
         .spd[0] = {
                 .read_type = READ_SPD_CBFS,
                 .spd_spec = {.spd_index = 0},
         },
         .spd[1] = {
                 .read_type = READ_SPD_CBFS,
                 .spd_spec = {.spd_index = 0},
         },
         .spd[2] = {
                 .read_type = READ_SPD_CBFS,
                 .spd_spec = {.spd_index = 0},
         },
         .spd[] = {
                 .read_type = READ_SPD_CBFS,
                 .spd_spec = {.spd_index = 0},
         },

/*
          * The dqs_map arrays map the ddr4 pins to the SoC pins
          * for both channels.
          *
          * the index = pin number on ddr4 part
          * the value = pin number on SoC
          */
         .dqs_map[DDR_CH0] = {0, 1, 3, 2, 4, 5, 6, 7},
         .dqs_map[DDR_CH1] = {1, 0, 4, 5, 2, 3, 6, 7},

/* Baseboard uses 121, 81 and 100 rcomp resistors */
         .rcomp_resistor = {121, 81, 100},

/*
          * Baseboard Rcomp target values.
          */
         .rcomp_targets = {100, 40, 20, 20, 26},

/* Baseboard is an interleaved design */
         .dq_pins_interleaved = 1,

/* Baseboard is using config 2 for vref_ca */
         .vref_ca_config = 2,

/* Disable Early Command Training */
         .ect = 0,
};

I have a query about the .dqs_map values as I don’t think this hardware 
matches the Intel reference design in this area.  The hardware has four 
devices for CH0 and four for CH1.  For CH0 the DQS signals appear to be 
paired as 0 & 6, 1 & 3, 5 & 2 and 7 & 4.  For CH1 they are paired as 7 & 
5, 3 & 6, 2 & 4 and 0 & 1.

-Andy.

[Andy Pont]

I wrote...
> static const struct cnl_mb_cfg memcfg = {
>     …
> };

Having been back and verified against the schematics, I have found a 
couple of value that were incorrect.

spd[1] and spd[3] needed to the set to NOT_EXISTING and the designed is 
not interleaved so .dq_pins_interleaved needed to be set to 0 not 1.

The board is now booting to a point where the last debug messages are:

enter handle_19:
  Booting from Hard Disk...
Booting from 0000:7c00 NULL

Thanks both for your help in getting to this point!

Next challenge is to sort out the VGA initialisation so that I can get 
something onto the screen!

-Andy.