[openfirmware] Porting OFW to custom hardware

Mitch Bradley wmb at laptop.org
Tue May 27 20:41:21 CEST 2008


R&D4 wrote:
>
>
>>
>> You might try
>>
>> ok memtest
>
> I got:
>
> ok memtest
> memtest ?
>
> so I thinks that 'memtest' is not included in my configuration.
> I tried to include 'memtest86' (is it the same?) which is included in 
> OLPC (correct me if I'm wrong, of course)
>
> I add memtest86 in build/Makefile and add the changes that I can 
> identify between OLPC and Neptune (my platform started from lx-devel)
> When building I have the following output:
>
> ./build neptune.rom
> --- ${BP}/cpu/x86/pc/neptune/config.fth is newer than the target file 
> neptune.rom
> --- ${BP}/cpu/x86/pc/neptune/config.fth is newer than the target file 
> fw.img
> --- Rebuilding fw.img
> --- Cmd: 
> /home/shared/devel/neptune/sw/ofw/openfirmware.git/cpu/x86/Linux/x86forth 
> /home/shared/devel/neptune/sw/ofw/openfirmware.git/cpu/x86/build/basefw.dic 
> ../fw.bth
>
> ${BP}/cpu/x86/pc/memtest.fth:9: config-l@ ?
> ${BP}/cpu/x86/pc/memtest.fth:13: ?linux-elf-map-in ?
> ${BP}/cpu/x86/pc/memtest.fth:15: elf-map-in ?
> make: *** [neptune.rom] Error 1
>
> Does it means that "config-l@" and "elf-map-in" are undefined?

You probably included memtest.fth too early in the fw.bth load file , 
before config-l@ and elf-map-in were defined.

The OLPC build floads memtest.fth just after linux.fth .

However, it turns out that you don't need to include memtest.fth at 
all.  The "config-l@" stuff that memtest does is OLPC-specific.  The 
location of memtest.fth in the pc/ directory is a mistake.  I just moved 
it down into the pc/olpc/ directory (svn revision 827).

On your system, you don't need a special command - just run memtest like 
this:

ok boot u:\memtest

> Can you give me some clue in what I'm missing?
> (I'm a Forth beginner too, of course.. ;-) )

The thing to realize is that Forth doesn't have a "linker" to resolve 
forward references.  Functions must be defined before they are used.  
This means that the inclusion order is critical, so you sometimes have 
to work harder to discover the best place for something.  But there are 
compensating advantages - it makes the compiler much simpler (and thus 
smaller, more reliable, and easier to understand), and you can stop a 
build at any point and the result will be self-consistent.

>
>
> I also try with:
>
> ok test /memory
> Testing memory at: 0f697000 size 000f2000
> Testing memory at: 00100000 size 0f4fd000
> Testing memory at: 00002000 size 0009e000
> ok
>
> But it's a bit "too fast" to be a "real" memory test.. maybe I'm 
> missing something ;-)

That memory test is very simple - just basic "works or not" 
functionality to detect hard failures .  It is not a stress test.




More information about the openfirmware mailing list