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.