Hi Sanjay,
On Sat, Mar 24, 2007 at 11:49:48AM -0700, sanjay tiwary wrote:
- 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.
- 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.
- 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.
- In my config, i have set DCAHE_RAM =0
Hm? What's this? Is this cache as ram?
- 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.
//Peter