[openfirmware] Porting OFW to custom hardware
Mitch Bradley
wmb at laptop.org
Fri May 23 20:00:34 CEST 2008
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,
>
More information about the openfirmware
mailing list