[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