I agree, your random crashes sound like memory timing problems.
After a page fault, you can find out what what happening by typing:
ok .registers ok ftrace
That is especially helpful for tracking down repeatable problems, but might not be useful for your current random problem.
You might try
ok memtest
Also, look at the cpu/x86/pc/olpc/rmstart.fth starting at line 187 and cpu/x86/pc/olpc/romreset.bth lines 151 .... (guarded by "cmos-startup-control"). That lets you experiment with different PLL and memory controller settings without recompiling. The idea is that you put new values for certain MSRs in CMOS RAM, along with an expiration counter. The new value is used on reboot, and the counter is decremented. When the counter becomes 0, on the next reboot the default value is used. Code for setting the CMOS values is in cpu/x86/pc/olpc/fw.bth line 478 (set-mc).
The specific details for the OLPC version are:
+ If CMOS location 60 is nonzero, the PLL value is set for 333 MHz MB clock, 333 MHz CPU clock. Otherwise the PLL is set to its default value for 333 MB + 433 CPU
+ If CMOS location 61 is nonzero, MSRs 2000.0019 and 2000.001a (memory controller configuration) are set to values from CMOS RAM locations 62..64 and 66..69, otherwise they are set to default values.
We used this, in conjunction with "memtest", to dial in the OLPC memory controller settings during early production.
You can adapt this technique for whatever settings you need to tune.
R&D4 wrote:
Dear Mitch,
Mitch Bradley wrote:
R&D4 wrote:
Is this correct?
That's a good start.
Thanks! ;-)
Of couse, it's a bit hard for me to figure out, for example, where to look for some basic initialization (e.g. PLL, SDRAM, memory mapping).
I assume you are using the version that I checked in yesterday, that removes the olpc dependencies from the lxdevel build. If not, switch to that version. It will be much easier to work with.
Yes, I checkout the latest release (from the dwmw2's git repository here: http://git.infradead.org/?p=openfirmware.git;a=summary). This is easier then svn for us because we already use git internally.
The PLL init is in "rmstart.fth" - that is "real mode start", which is [snip]
Thank you very much for this precious informations! Now I'm able to:
- enable serial port
- boot OFW on our custom board
I was also able to remove keyboard initialization from startup and also able to start debugging some simple Forth programs.
There are still some problems (IMHO in my PLL or SDRAM inits) because I have some weird and random problem like:
+cs Type 'i' to interrupt stand-init sequence ff04cfc0 Page Fault ok
or
Type 'i' to interrupt stand-init sequence
Welcome to Dave Neptune Interactive boot Evaluating: master-probe Inflate size error ok
When everything goes "well" I got
รพ+cs Type 'i' to interrupt stand-init sequence
Welcome to Dave Neptune Interactive boot USB probe USB2 devices: USB1 devices: Failed to set device address: 1 Type any key to interrupt automatic startup Type 'help' for more information.
ok
and a fully functional shell (but also some random reboots ;-) )
I'll keep you informed about the porting status.
AFAIK the "official" documentation is here:
http://www.firmworks.com/open_firmware/literature/
among these documents is there also a guide for porting OFW or about OFW "internals"? ("Open Firmware Command Reference" seems the closest to my needs)
We did a porting guide for an ARM platform, but we haven't done one for x86. The command reference has a lot of useful information that is machine independent. There is also a manual for how to write FCode drivers. It explains how the device interface works.
Thanks, we will buy them soon!
Best Regards,