<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">Dave, I was ready to boot your
suggestion and the hardware guys said:<br>
"We know there's no clock", then soon after had it booting
normally.<br>
Good call. This was indeed a debugging session, not a coreboot
issue.<br>
<br>
A bit of history. Our design uses a single DIMM, and we got that
running <br>
from earlier posts on this list. Agesa requires that specific
DIMMs<br>
be populated when there are empty DIMM slots, and so the config<br>
files devicetree.cb and buildOpts.c require two changes to allow<br>
a single DIMM to boot.<br>
<br>
We also had to find the correct VGA device id from the Series G
SOC<br>
range of 9830-D, but that's done as well. Our 210 parts use 9835<br>
and our 420 parts use 9831. Coreboot comes with 9830, and our<br>
stock IMB-A180 use 9834. It would be nice if this value could be<br>
polled in Coreboot.<br>
<br>
Lastly, we found that our legacy DMA interrupts were not working
with<br>
Coreboot. We switched to MSI interrupts and now everyone is
happy.<br>
<br>
Thanks for your help!<br>
<br>
Mark Mason<br>
Engineering Design Team<br>
<br>
<br>
I was getting ready to try your suggestions<br>
</div>
<blockquote
cite="mid:CAP5w7p=jnvAh7Wg32WShWo5=nCPuEojyRdLu2hcFV72BzsD=Ew@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Mark,<br>
<br>
</div>
Can you describe your memory SODIMM config?<br>
</div>
Are you loading both SODIMMs?<br>
<br>
</div>
An engineer here suggests you set
BLDCFG_MEMORY_ALL_CLOCKS_ON TRUE<br>
</div>
in the mainboard buildOpts.c file.<br>
<br>
</div>
Thanks,<br>
Dave<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jun 19, 2014 at 12:37 PM, Mark
C. Mason <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mark@edt.com" target="_blank">mark@edt.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We have a board that is failing to boot, and we think there
is a memory<br>
problem on the board. I have a trace (od -t x4 dump) of the
POST codes:<br>
<br>
0000000 01 10 10 a0 a1 a1 30 31 34 37 c0 b1 c1 38 39 c4<br>
0000020 71 72 75 76 77 78 79 7b 7a 7c 90 91 91 58 5a 01<br>
0000040 10 10 a0 a1 a1 34 37 c0 c1 38 39 c4 7d 7e 58 5a<br>
0000060 58 58 5b 5b 5c 5d 5e 92 94 95 c5 40 01 0a 46 42<br>
0000100 c6 44 96 97 98 03 02 3e 3f 47 48 49 3d 08 00 00<br>
0000120 40 41 10 50 43 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6<br>
0000140 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6<br>
0000160 d7 d6 d7 d6 d7 d6 d7 41<br>
<br>
Using the Sage SmartProbe to perform source-level debugging,<br>
we find that the process is stuck in an infinite loop in
this code:<br>
<br>
while (CurrNodeOffset != 0) {<br>
CurrNodePtr = (BIOS_BUFFER_NODE *) (BiosHeapBaseAddr
+ CurrNodeOffset);<br>
if (CurrNodePtr->BufferHandle ==
AllocParams->BufferHandle) {<br>
return AGESA_BOUNDS_CHK;<br>
}<br>
CurrNodeOffset = CurrNodePtr->NextNodeOffset;<br>
/* If BufferHandle has not been allocated on the
heap, CurrNodePtr here points<br>
to the end of the allocated nodes list.<br>
*/<br>
}<br>
<br>
with CurrNodeOffset == -1 (0xffffffff). The code is from
around line 103 in<br>
<br>
coreboot/src/northbridge/amd/agesa/family16kb/fam16kb_callouts.c<br>
<br>
I plan to continue the source-level debugging to try and
track this down,<br>
but as I am new to Coreboot, any guidance you may have to
offer would be<br>
much appreciated.<br>
<br>
Mark Mason<br>
Engineering Design Team<span class="HOEnZb"><font
color="#888888"><br>
<br>
-- <br>
coreboot mailing list: <a moz-do-not-send="true"
href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a moz-do-not-send="true"
href="http://www.coreboot.org/mailman/listinfo/coreboot"
target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>