IMB-A180 based design question regarding POST codes during boot failure

[Mark C. Mason]

We have a board that is failing to boot, and we think there is a memory
problem on the board.  I have a trace (od -t x4 dump) of the POST codes:

0000000 01 10 10 a0 a1 a1 30 31 34 37 c0 b1 c1 38 39 c4
0000020 71 72 75 76 77 78 79 7b 7a 7c 90 91 91 58 5a 01
0000040 10 10 a0 a1 a1 34 37 c0 c1 38 39 c4 7d 7e 58 5a
0000060 58 58 5b 5b 5c 5d 5e 92 94 95 c5 40 01 0a 46 42
0000100 c6 44 96 97 98 03 02 3e 3f 47 48 49 3d 08 00 00
0000120 40 41 10 50 43 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
0000140 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
0000160 d7 d6 d7 d6 d7 d6 d7 41

Using the Sage SmartProbe to perform source-level debugging,
we find that the process is stuck in an infinite loop in this code:

while (CurrNodeOffset != 0) {
         CurrNodePtr = (BIOS_BUFFER_NODE *) (BiosHeapBaseAddr + 
CurrNodeOffset);
         if (CurrNodePtr->BufferHandle == AllocParams->BufferHandle) {
             return AGESA_BOUNDS_CHK;
         }
         CurrNodeOffset = CurrNodePtr->NextNodeOffset;
         /* If BufferHandle has not been allocated on the heap, 
CurrNodePtr here points
            to the end of the allocated nodes list.
         */
     }

with CurrNodeOffset == -1 (0xffffffff).  The code is from around line 103 in

coreboot/src/northbridge/amd/agesa/family16kb/fam16kb_callouts.c

I plan to continue the source-level debugging to try and track this down,
but as I am new to Coreboot, any guidance you may have to offer would be
much appreciated.

Mark Mason
Engineering Design Team

IMB-A180 based design question regarding POST codes during boot failure

[Dave Frodin]

Mark,

Can you describe your memory SODIMM config?
Are you loading both SODIMMs?

An engineer here suggests you set BLDCFG_MEMORY_ALL_CLOCKS_ON TRUE
in the mainboard buildOpts.c file.

Thanks,
Dave

On Thu, Jun 19, 2014 at 12:37 PM, Mark C. Mason  wrote:
> We have a board that is failing to boot, and we think there is a memory
> problem on the board.  I have a trace (od -t x4 dump) of the POST codes:
>
> 0000000 01 10 10 a0 a1 a1 30 31 34 37 c0 b1 c1 38 39 c4
> 0000020 71 72 75 76 77 78 79 7b 7a 7c 90 91 91 58 5a 01
> 0000040 10 10 a0 a1 a1 34 37 c0 c1 38 39 c4 7d 7e 58 5a
> 0000060 58 58 5b 5b 5c 5d 5e 92 94 95 c5 40 01 0a 46 42
> 0000100 c6 44 96 97 98 03 02 3e 3f 47 48 49 3d 08 00 00
> 0000120 40 41 10 50 43 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
> 0000140 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
> 0000160 d7 d6 d7 d6 d7 d6 d7 41
>
> Using the Sage SmartProbe to perform source-level debugging,
> we find that the process is stuck in an infinite loop in this code:
> while (CurrNodeOffset != 0) {
>     CurrNodePtr = (BIOS_BUFFER_NODE *) (BiosHeapBaseAddr +
>
> CurrNodeOffset);
>         if (CurrNodePtr->BufferHandle == AllocParams->BufferHandle) {
>             return AGESA_BOUNDS_CHK;
>         }
>         CurrNodeOffset = CurrNodePtr->NextNodeOffset;
>         /* If BufferHandle has not been allocated on the heap, CurrNodePtr
> here points
>            to the end of the allocated nodes list.
>         */
>     }
>
> with CurrNodeOffset == -1 (0xffffffff).  The code is from around line 103
> in
> coreboot/src/northbridge/amd/agesa/family16kb/fam16kb_callouts.c
>
> I plan to continue the source-level debugging to try and track this down,
> but as I am new to Coreboot, any guidance you may have to offer would be
> much appreciated.
>
> Mark Mason
> Engineering Design Team