We tried to build openfirmware for the DB800 board but it did not work:
------------------------------------------------------------- cd cpu/x86/pc/lxdevel make
... ./build lxdevel.rom --- Rebuilding romreset.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../romreset.bth --- Rebuilding rmstart.img --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../rmstart.bth ROM loader: version# 8 , format# 2 --- Rebuilding paging.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../../paging.bth --- Rebuilding fw.dic --- Cmd: ${HOSTDIR}/x86forth ${BP}/cpu/x86/build/basefw.dic ../fw.bth
${BP}/ofw/fs/ext2fs/dir.fth:54: >unix-seconds ? ${BP}/ofw/fs/ext2fs/dir.fth:220: >unix-seconds ? ${BP}/ofw/fs/ext2fs/dir.fth:256: unix-seconds> ? ${BP}/ofw/fs/ext2fs/methods.fth:74: >unix-seconds ? ${BP}/ofw/fs/jffs2/jffs2.fth:1605: unix-seconds> ? assign-pci-addr isn't unique ${BP}/cpu/x86/pc/olpc/mfgdata.fth:51: flash-base ? ${BP}/cpu/x86/pc/olpc/mfgdata.fth:52: flash-base ? ${BP}/dev/geode/display/gxfb.fth:121: tft-mode? ? ${BP}/dev/geode/display/gxfb.fth:159: gx? ? ${BP}/dev/geode/display/gxfb.fth:183: gx? ? ${BP}/dev/geode/display/gxfb.fth:221: gx? ? ${BP}/dev/geode/display/gxfb.fth:403: gx? ? ${BP}/dev/geode/display/gxfb.fth:407: gx? ? ${BP}/cpu/x86/pc/olpc/linux.fth:263: unfreeze ? --- Saving fw.dic ... --- Saving fw.img ... --- Rebuilding nandflash.fc --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../nandflash.bth
${BP}/dev/olpc/cafenand/badblock.fth:21: partition-start ? make: *** [lxdevel.rom] Error 1 -------------------------------------------------------------
Attached is a patch that allows to build it. As you can see we basically removed some stuff to make it to build. Do you think this is safe? We are going to download the binary image to the board but we would like to know we are trying to run something that makes sense first (typical newbie concern) ...
Regards, llandre
DAVE Electronics System House - R&D Department web: http://www.dave.eu email: r&d2@dave-tech.it
diff --git a/cpu/x86/pc/lxdevel/fw.bth b/cpu/x86/pc/lxdevel/fw.bth index f9032e3..ac9162b 100644 --- a/cpu/x86/pc/lxdevel/fw.bth +++ b/cpu/x86/pc/lxdevel/fw.bth @@ -117,12 +117,14 @@ end-support-package [then]
[ifdef] linux-support +\needs unix-seconds> fload ${BP}/ofw/fs/unixtime.fth \ Unix time calculation support-package: ext2-file-system fload ${BP}/ofw/fs/ext2fs/ext2fs.fth \ Linux file system end-support-package [then]
[ifdef] jffs2-support +\needs unix-seconds> fload ${BP}/ofw/fs/unixtime.fth \ Unix time calculation support-package: jffs2-file-system fload ${BP}/ofw/fs/jffs2/jffs2.fth \ Journaling flash file system 2 end-support-package diff --git a/cpu/x86/pc/lxdevel/lxdevel.bth b/cpu/x86/pc/lxdevel/lxdevel.bth index ffb3467..2c68bd9 100644 --- a/cpu/x86/pc/lxdevel/lxdevel.bth +++ b/cpu/x86/pc/lxdevel/lxdevel.bth @@ -6,7 +6,7 @@ in: ${BP}/cpu/x86/pc/lxdevel/build/romreset.di in: ${BP}/cpu/x86/pc/lxdevel/build/rmstart.img in: ${BP}/cpu/x86/pc/lxdevel/build/paging.di in: ${BP}/cpu/x86/pc/lxdevel/build/fw.dic -in: ${BP}/dev/geode/nandflash/build/nandflash.fc +\ in: ${BP}/dev/geode/nandflash/build/nandflash.fc in: ${BP}/dev/mmc/sdhci/build/sdhci.fc in: ${BP}/dev/mmc/sdhci/build/sdmmc.fc in: ${BP}/dev/geode/ac97/build/ac97.fc @@ -18,10 +18,10 @@ in: ${BP}/dev/usb2/device/serial/build/usbserial.fc in: ${BP}/dev/usb2/device/storage/build/usbstorage.fc in: ${BP}/dev/usb2/device/keyboard/build/usbkbd.fc in: ${BP}/dev/usb2/device/wlan/build/usb8388.fc -in: ${BP}/dev/olpc/cafenand/build/cafenand.fc -in: ${BP}/dev/olpc/cafecamera/build/cafecamera.fc +\ in: ${BP}/dev/olpc/cafenand/build/cafenand.fc +\ in: ${BP}/dev/olpc/cafecamera/build/cafecamera.fc in: ${BP}/dev/pci/build/pcibridg.fc -in: usb8388.bin +\ in: usb8388.bin
build-now
@@ -48,7 +48,7 @@ writing lxdevel.rom " romreset.di" $add-file \ " resume.di" $add-file
- fload ${BP}/cpu/x86/pc/olpc/loaddropins.fth +\ fload ${BP}/cpu/x86/pc/olpc/loaddropins.fth " ${BP}/dev/pci/build/pcibridg.fc" " class060400" $add-deflated-dropin
/rom h# 400 - pad-file \ rmstart image must start 0x400 from end diff --git a/cpu/x86/pc/lxdevel/rmstart.bth b/cpu/x86/pc/lxdevel/rmstart.bth index 57cccd3..94f7673 100644 --- a/cpu/x86/pc/lxdevel/rmstart.bth +++ b/cpu/x86/pc/lxdevel/rmstart.bth @@ -5,7 +5,7 @@ command: &builder &this build-now
\ To do this on the geode, extra init may be necessary -\ create debug-reset +create debug-reset
fload ${BP}/cpu/x86/pc/lxdevel/config.fth fload ${BP}/cpu/x86/pc/olpc/rmstart.fth
I started to incorporate these patches but then realized that several other related things need to be cleaned up. I'll check in the changes soon and post and announcement.
llandre wrote:
We tried to build openfirmware for the DB800 board but it did not work:
cd cpu/x86/pc/lxdevel make
... ./build lxdevel.rom --- Rebuilding romreset.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../romreset.bth --- Rebuilding rmstart.img --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../rmstart.bth ROM loader: version# 8 , format# 2 --- Rebuilding paging.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../../paging.bth --- Rebuilding fw.dic --- Cmd: ${HOSTDIR}/x86forth ${BP}/cpu/x86/build/basefw.dic ../fw.bth
${BP}/ofw/fs/ext2fs/dir.fth:54: >unix-seconds ? ${BP}/ofw/fs/ext2fs/dir.fth:220: >unix-seconds ? ${BP}/ofw/fs/ext2fs/dir.fth:256: unix-seconds> ? ${BP}/ofw/fs/ext2fs/methods.fth:74: >unix-seconds ? ${BP}/ofw/fs/jffs2/jffs2.fth:1605: unix-seconds> ? assign-pci-addr isn't unique ${BP}/cpu/x86/pc/olpc/mfgdata.fth:51: flash-base ? ${BP}/cpu/x86/pc/olpc/mfgdata.fth:52: flash-base ? ${BP}/dev/geode/display/gxfb.fth:121: tft-mode? ? ${BP}/dev/geode/display/gxfb.fth:159: gx? ? ${BP}/dev/geode/display/gxfb.fth:183: gx? ? ${BP}/dev/geode/display/gxfb.fth:221: gx? ? ${BP}/dev/geode/display/gxfb.fth:403: gx? ? ${BP}/dev/geode/display/gxfb.fth:407: gx? ? ${BP}/cpu/x86/pc/olpc/linux.fth:263: unfreeze ? --- Saving fw.dic ... --- Saving fw.img ... --- Rebuilding nandflash.fc --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../nandflash.bth
${BP}/dev/olpc/cafenand/badblock.fth:21: partition-start ? make: *** [lxdevel.rom] Error 1
Attached is a patch that allows to build it. As you can see we basically removed some stuff to make it to build. Do you think this is safe? We are going to download the binary image to the board but we would like to know we are trying to run something that makes sense first (typical newbie concern) ...
Regards, llandre
DAVE Electronics System House - R&D Department web: http://www.dave.eu email: r&d2@dave-tech.it
openfirmware mailing list openfirmware@openfirmware.info https://openfirmware.info/mailman/listinfo/openfirmware
I checked in some openfirmware changes to fix the lxdevel build.
The lxdevel build is now independent of the files in cpu/x86/pc/olpc ; everything that it used to include from that directory has either been moved out (to cpu/x86/pc and dev/geode as appropriate), or copied into cpu/x86/pc/lxdevel and modified as necessary, or deleted from the load files.
I've tested the changes to the following extent:
a) Built the OLPC version and tested the result on an OLPC machine
b) Built the lxdevel version - it compiles cleanly - but did not try it on actual hardware
There is a residual OLPC dependency in the nand5536 driver, which includes a couple of files from dev/olpc/cafenand/ . I doubt that will be a problem in practice.
I checked in some openfirmware changes to fix the lxdevel build. ... b) Built the lxdevel version - it compiles cleanly - but did not try it on actual hardware
There is a residual OLPC dependency in the nand5536 driver, which includes a couple of files from dev/olpc/cafenand/ . I doubt that will be a problem in practice.
We built and run it on DB800 but we don't see anything on the serial port :( Unfortunately testing new code on DB800 takes a lot of time because we have to remove the PLCC32 boot flash and reprogram it with an external programmer. However we have a custom board that provides an easy connection to LCP Dongle by Artec. Here we can test new code quite quickly. In the meanwhile I'll try to make an adaptor cable to connect LPC dongle to DB800 (unfortunately hardware designers chose to use a 1.27mm pitch connector for LPC bus that is not very handy to manage).
Hi all,
we are currently porting OFW to a custom board (codename Neptune) with is much like OLPC, but without SuperIO and keyboard controller.
First of all: is there any documentation about how to add a new custom platform? As a beginner I just copied lxdevel directory to one called neptune, changed some definitions inside: * Makefile * neptune.bth (taken from lxdevel.bth) * config.fth
Is this correct?
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).
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)
Thanks in advance and Best Regards,
R&D4 wrote:
Hi all,
we are currently porting OFW to a custom board (codename Neptune) with is much like OLPC, but without SuperIO and keyboard controller.
First of all: is there any documentation about how to add a new custom platform? As a beginner I just copied lxdevel directory to one called neptune, changed some definitions inside:
- Makefile
- neptune.bth (taken from lxdevel.bth)
- config.fth
Is this correct?
That's a good start.
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.
The PLL init is in "rmstart.fth" - that is "real mode start", which is the first thing that executes after power on. Its job is to get the system into 32-bit mode as fast as possible. On the Geode, where you have to double-reset to program the PLL, the PLL init is also in that file. In principle, PLL init could be in the 32-bit mode code, but it is faster to do it in rmstart . Executing code prior to PLL setup is inherently very slow, so I minimized the number of instructions executed prior to PLL turn-on.
The next code that executes is in romreset.bth . It runs in 32-bit mode. Its job is to get the memory working, again as quickly as possible. What the means in practice is that any system setup that isn't necessary for memory controller setup is deferred until later.
The one exception is the serial port - I typically turn that on very early in romreset.fth, so debugging is possible.
There is a difference between OLPC and the lxdevel board in the area of serial port init. OLPC uses the serial port inside the 5536 chip, whereas the lx devel board has an external superio. If you look at cpu/x86/pc/olpc/romreset.bth, you will see some 5536 UART init code starting at line 76. (\ Init UART ... [ifndef] lxdevel). If you are using the 5536 UART, you'll want to include that code in your romreset.bth
After romreset.bth sets up the memory controller, it includes dev/geode/draminit.fth , which configures the SDRAM chips themselves.
At the bottom of draminit.fth, commented out with "0 [if] .. [then]", there is a very simple memory test that just writes a couple of data patterns to a RAM location. It's not a complete memory test, but is usually sufficient to tell if the memory is working at all. It won't detect misconfiguration of the bank layout registers. Change "0 [if]" to "1 [if]" to enable it.
Once the RAM is turned on, romreset.bth includes cpu/x86/pc/resetend.fth . resetend.fth is generic for all x86 PC platforms; independent of either the Geode CPU or to the platform's I/O setup. Its purpose is to do final setup of the memory management unit (GDT and possibly page tables), then load the Forth dictionary into RAM. That loading process involves either copying or inflating the Forth dictionary from ROM into RAM.
resetend.fth's final action is to jump to the RAM copy of the Forth dictionary. Forth then runs an initialization chain named "stand-init". Debugging that is easy because you can use the Forth debugger to step through it.
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 in advance and Best Regards,
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,
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,
Dear Mitch,
Mitch Bradley wrote:
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.
I agree too. I also add 'test /cpu' in my build and I've seen that sometimes it does not complete the test and the board reboot.
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? Can you give me some clue in what I'm missing? (I'm a Forth beginner too, of course.. ;-) )
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 ;-)
[snip] You can adapt this technique for whatever settings you need to tune.
Thanks for the clue Mitch, maybe I'll use this tecnique in the next few days.
BTW, I change some PLL and SDRAM setting and OFW is somehow stable now. I can boot Linux from and USB key:
ok probe-usb USB2 devices: /pci/usb@f,5/scsi@0,0 /pci/usb@f,5/scsi@0,0/disk USB1 devices: ok dir u: fat-file-system --A-rwxrwxrwx 72388 2008-05-27 16:10:30 MEMTEST --A-rwxrwxrwx 1474560 2008-05-27 10:35:24 ROOT.IMG --A-rwxrwxrwx 1715312 2008-05-26 18:54:00 BZIMAGE --A-rwxrwxrwx 599474 2008-05-27 16:49:06 INITRD.IMG ok boot u:\bzImage console=uart,io,0x3f8,115200 Boot device: /usb/disk:\bzImage Arguments: console=uart,io,0x3f8,115200Boot dev ice: /usb/disk:\bzImage Arguments: console=uart,io,0x3f8,115200 Linux version 2.6.26-rc3-00285-gf556f19-dirty (amon@linuxserver2) (gcc version 3 .4.6 20060404 (Red Hat 3.4.6-3)) #21 Mon May 26 18:53:59 CEST 2008 BIOS-provided physical RAM map: BIOS-e801: 0000000000000000 - 000000000009f000 (usable) BIOS-e801: 0000000000100000 - 000000000f5fd000 (usable) Early serial console at I/O port 0x3f8 (options '115200') console [uart0] enabled 245MB LOWMEM available. Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 62973 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 62973
I 'still dont have an ethernet device on this board so I tried to have root on: * USB key: no success (this has nothing to do with OFW, of course ;-) ) * ramdisk
For the latter I follow the instruction here:
http://wiki.laptop.org/go/Forth_Lesson_12#Linux_Ramdisk
but I have "some trouble":
ok probe-usb USB2 devices: /pci/usb@f,5/scsi@0,0 /pci/usb@f,5/scsi@0,0/disk USB1 devices: ok dir u: fat-file-system --A-rwxrwxrwx 72388 2008-05-27 16:10:30 MEMTEST --A-rwxrwxrwx 1474560 2008-05-27 10:35:24 ROOT.IMG --A-rwxrwxrwx 1715312 2008-05-26 18:54:00 BZIMAGE --A-rwxrwxrwx 599474 2008-05-27 16:49:06 INITRD.IMG ok setenv ramdisk u:\initrd.img ramdisk = u:\initrd.img ok boot u:\bzImage console=uart,io,0x3f8,115200 Boot device: /usb/disk:\bzImage Arguments: console=uart,io,0x3f8,115200Boot dev ice: /usb/disk:\bzImage Arguments: console=uart,io,0x3f8,115200 Loading ramdisk image from u:\initrd.img ...
and the system hang (no messages on UART, no reboot) I think this has something to do with ramdisk loading address (that maybe overwrite kernel itself) but I don't really know where to look.. any clue?
Thanks in advance and Best Regards,
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.
Mitch Bradley wrote:
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).
ok
On your system, you don't need a special command - just run memtest like this:
ok boot u:\memtest
mmmhhh... that memtest on usb key it's just the memtest elf that I found inside client/memtest86 but it gives:
ok boot u:\memtest Boot device: /usb/disk:\memtest Arguments: Page Fault ok
Can you give me some clue in what I'm missing? (I'm a Forth beginner too, of course.. ;-) )
[snip]
Thanks you very much for the clear explanation Mitch!
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.
Ok, thanks
Now I have a (nearly ;-) ) stable board, after playing a while with PLL and SDRAM timing.
Thanks for the support Mitch!
(I have some more question but I think it's better to open another thread on this mailing list. I think it's more useful as reference for others too ;-) )
Best Regards,
openfirmware@openfirmware.info
-
Andrea -
llandre -
Mitch Bradley -
R&D4