[LinuxBIOS] register dump - Can anybody see??

Peter Stuge stuge-linuxbios at cdy.org
Sat Mar 24 22:23:25 CET 2007

Hi Sanjay,

On Sat, Mar 24, 2007 at 11:49:48AM -0700, sanjay tiwary wrote:
> 2. Now i would like to ask couple of question. Since raminit does
> not complain any failure and ramcheck also passes ramtest.Next,
> code in crt0.S is able to copy the code from ROM to RAM. I am also
> able to read the code and print them in the serial output.So my
> question is, if i am able to read/write correct data to/from RAM,
> why is there doubt on incorrect DRAM initialisation?

As you may know, thoroughly testing RAM takes a long time. Much
longer than any BIOS should spend. (Many hours!) There is however a
separate program that does an excellent job at it, if you can, please
try booting memtest86 as a payload with LinuxBIOS.

Until that works and reports zero errors, RAM misconfiguration is
highly likely to cause the boot problems.

> If i am not able to jump to a designated place (0x4000) in RAM
> simply due incorrect DRAM initialisation, then what are those
> things which i am not taking care of during DRAM initialization?
> Can u pls hightlight those area in RAMINIT so that i can re-walk
> those area.

Someone else has to step up here I'm afraid, I don't know enough
details about SDRAM initialization. There was recent mention of an
Intel memory controller data sheet that outlined the steps needed
to bring up RAM on that hardware, it could be used as a guideline
also for your chipset, but ideally you should contact the hardware
vendor and ask them for instructions.

> 3. if really, the DRAM initialization is correct, then what are the
> factors that may stop/misdirect the control to jump to a correct
> location in RAM.
> I tried to print the contents from the RAM which is copied from the
> ROM to RAM in the start of crt0.S, they are byte by byte same as is
> for c_start.o

How much contents?

I would suggest printing in hex several kilobyte (start with 10kb)
and then using diff to compare that with a hexdump you make on
another system using hexdump or xxd.

> 4. Are there any role of the register like AX,BX, CX and DX & other
> index register while control is try to jump at ram location. For
> reference, i am also printed the contents of the register before
> jumping i.e jmp *%edi

They should not be used for anything.

> 5. In my config, i have set DCAHE_RAM =0

Hm? What's this? Is this cache as ram?

> 6. i have compared the register dump for linuxbios and legacy
> bios.They are not exactly same. Should i try to cpmpare the entire
> dump or the register dump of device 00.0 only? 

Start with 00.0 and investigate each bit that differs, look it up in
the data sheet and/or contact your hardware vendor to find out what
the bit means.

>   ---RAM CHECKING (from 0-640K & 1M-16M)-------------
>   Testing DRAM : 00000000-000a0000
>   DRAM fill: 00000000-000a0000
>   00000000 00010000 00020000 00030000  00040000 00050000 
>   00060000 00070000 00080000 00090000  000a0000
>   DRAM filled
>   DRAM verify: 00000000-000a0000
>   00000000 00010000 00020000 00030000  00040000 00050000 
>   00060000 00070000 00080000 00090000  000a0000
>   DRAM range verified.
>   Done.

Does this test only look at the printed addresses or also everything
between them? How long does the test take? Unless the code spends a
good amount of time in here (I doubt it) it cannot test RAM enough to
make sure it is reliable. Each address should be tested several times
with different types of data. Again, try running memtest86 on some
systems to get an idea of what is needed.

>   Memory dump (from RAM 0x4000 upto 7094byte)
>   [I have intentionaly put some ee at the start of c_start.s for
> conveniance of identification. I have also deleted some of the last
> byte for saving space]

Make the same kind of dump for the data on another, running, system
and compare them with software. One bit of error is enough.


More information about the coreboot mailing list