ASRock e350m1 problems

[Tadas Slotkus]

Hi,

just compiled coreboot for e350m1, flashed original flashchip and got
this (log attached) everytime I power on or reset my system. Any hints?

Thanks,
Tadas

[Vibrans, Frank]

Yep, you're running into heap issues.  The specific error is CPU_ERROR_HEAP_BUFFER_HANDLE_IS_NOT PRESENT.  That may be because the heap allocation is failing early on.  I'm currently working on a bunch of F14 code updates that I should be posting in a week or so.  A fix to that issue may be in that code.

FrankV

-----Original Message-----
From: Tadas Slotkus [mailto:[e-mail]] 
Sent: Tuesday, July 05, 2011 1:43 PM
To: [e-mail]
Cc: Vibrans, Frank; Scott Duplichan
Subject: ASRock e350m1 problems

Hi,

just compiled coreboot for e350m1, flashed original flashchip and got this (log attached) everytime I power on or reset my system. Any hints?

Thanks,
Tadas

[Scott Duplichan]

Tadas Slotkus wrote:

]Hi,
]
]just compiled coreboot for e350m1, flashed original flashchip and got
]this (log attached) everytime I power on or reset my system. Any hints?

Hello Tadas,

AMD.h shows "EventClass = 2" corresponds to AGESA_BOUNDS_CHK, a warning
that does not prevent booting. This is related to memory allocation, as
Frank pointed out.

Your log file stops with:
EventLog:  EventClass = 7, EventInfo = 4011c00.

"EventClass = 7" is an unrecoverable error, according to amd.h. Searching
the source code for 4011c00 finds:
#define MEM_ERROR_NO_DIMM_FOUND_ON_SYSTEM 0x04011C00 ///< No DIMMs have been
found

I assume you have DIMMs installed, and the production BIOS confirms they
are good. Though I believe the SPD addressing is correct for both slots,
testing both single DIMM configurations is worthwhile.

If the DIMMs work with the production BIOS but not with your BIOS, it is 
possible that you are using low cost modules that do not have a valid 
SPD checksum. The coreboot project is configured to validate the SPD
checksum, while the Asrock production BIOS is configured to ignore the
SPD checksum. To test your coreboot using the DIMM SPD checksum ignore
option, change BLDCFG_IGNORE_SPD_CHECKSUM in buildopts.c and try it that
way.

Thanks,
Scott

[Tadas Slotkus]

Hi,

thank you all for the quick reply.
> If the DIMMs work with the production BIOS but not with your BIOS, it is 
> possible that you are using low cost modules that do not have a valid 
> SPD checksum. The coreboot project is configured to validate the SPD
> checksum, while the Asrock production BIOS is configured to ignore the
> SPD checksum. To test your coreboot using the DIMM SPD checksum ignore
> option, change BLDCFG_IGNORE_SPD_CHECKSUM in buildopts.c and try it that
> way.

I just tried that with fresh new tree, but the output remains the same.
(except build timestamps...).

The RAM is one dimm:
PATRIOT PSD32G13332H Desktop Memory Device Signature Line (DDR3
SDRAM,2GB,1333MHz(PC3-10600),CL9,256 x 64,DIMM 240-pin,Unbuffered)

Thanks,
Tadas

[David Hendricks]

On Thu, Jul 7, 2011 at 4:02 PM, Tadas Slotkus  wrote:
> Hi,
>
> thank you all for the quick reply.
> > If the DIMMs work with the production BIOS but not with your BIOS, it is
> > possible that you are using low cost modules that do not have a valid
> > SPD checksum. The coreboot project is configured to validate the SPD
> > checksum, while the Asrock production BIOS is configured to ignore the
> > SPD checksum. To test your coreboot using the DIMM SPD checksum ignore
> > option, change BLDCFG_IGNORE_SPD_CHECKSUM in buildopts.c and try it that
> > way.
>
> I just tried that with fresh new tree, but the output remains the same.
> (except build timestamps...).
>
> The RAM is one dimm:
> PATRIOT PSD32G13332H Desktop Memory Device Signature Line (DDR3
> SDRAM,2GB,1333MHz(PC3-10600),CL9,256 x 64,DIMM 240-pin,Unbuffered)

Just to completely rule out the bad SPD idea, can you please dump the SPD
content when you boot with the production BIOS? i2cdump output (ASCII) or
raw output from sysfs would be great. Then we can plug it into bc and
confirm that the checksum is correct. This would also be a good way to
confirm that the SPD addresses are correct in Coreboot, and rule out the
possibility that ASRock changed SPD addressing between board revisions...