Hello all,
I am currently facing an issue to build OpenFirmware for ARM. Let’s start with some explanations : My goal is to have a Forth interpreter running on a barebone ARM device. I’ve tried some, like ForthOS (which runs on x86 only) and another one designed for the Raspberry Pi which is far for being complete. So, I’ve been following two of your official tutorials :
- https://www.openfirmware.info/Building_OFW_for_QEMU - https://www.openfirmware.info/Building_OFW_for_ARM
Got to say the first one worked well, except it is not stated that “subversion” is required, but we can easily find it out by ourselves. At the end, I got OpenFirmware running and have been able to type some Forth commands on the interpreter.
Then, I tried to reproduce this with ARM Qemu. Fell on the second tutorial, which is somewhat less detailed than the first one, but optionnal configuration on the first one should also be viable for the ARM’s one. Well, my issue comes when executing the “make” command inside “openfirmware/cpu/x86/pc/emu/build”. Here is what I get :
*jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$ make*
*./build ofw.rom*
*--- Rebuilding sp.img*
*--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../sp.bth*
*--- Rebuilding fw.img*
*--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/basefw.dic ../fw.bth*
*sh: 1: /home/jacky/openfirmware/cpu/x86/Linux/armforth: not found*
*Makefile:22: recipe for target 'ofw.rom' failed*
*make: *** [ofw.rom] Error 1*
*jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$ *
At first I tought it was due to script’s or environment’s variable like ${HOSTDIR} as this was the line causing the error. It seemed those variables were correctly replaced in the script itself, as a previous line is well executed using this same variable. Next, I’ve been looking for openfirmware/cpu/x86/Linux/armforth file. As the error states, this file is not present in the cpu/x86/Linux folder. In fact, there is a file named like this, but it has an extension .qemu (the complete file name is armforth.qemu. So I tough about a simple mistake, and renamed it (in fact, I copied it to avoid other errors) into armforth.
Once renamed, I did “make clean”, and relaunched a “make”. The previous error disappeared, the script went farther, but still did not complete :
*jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$ make*
*./build ofw.rom*
*--- Rebuilding sp.img*
*--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../sp.bth*
*--- Rebuilding fw.img*
*--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/basefw.dic ../fw.bth*
*${BP}/cpu/arm/mmp2/rootnode.fth:32: io2-va ?*
*${BP}/cpu/arm/mmp2/rootnode.fth:36: io-va ?*
*${BP}/cpu/arm/mmp2/mmuon.fth:12: fw-mem-va ?*
*${BP}/cpu/arm/mmp2/mmuon.fth:12: page-table-offset ?*
*${BP}/cpu/arm/mmp2/mmuon.fth:13: page-table-va ?*
*Makefile:22: recipe for target 'ofw.rom' failed*
*make: *** [ofw.rom] Error 1*
*jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$*
These errors appears to be forth-related, as if some words were not defined. Maybe is it due to the *basefw.dic *dictionnary… To be honest, I can’t think about any other solutions. Maybe I will dig into these forth files but I am afraid it will be a loss of time as I am a real beginner to Forth.
Here’s what I tried :
- Executing make as root. Same issue.
- Executing it on another distro (Ubuntu 14.x). Same issue.
- Tried different Qemu versions (don’t ask me why… I tried the 4.7 one on the official website, and the maintained one on github’s Qemu repo.
Forgot to mention this has been has been tested on both a clean Ubuntu and a clean Debian VM using VMWare. Yes, I am emulating an emulator. ;)
Also, I'd be glad if you have any other solutions to run a Forth interpreter on a bare-metal ARM machine, either emulated or not. Thanks in advance, for your work, for your help, and for reading this.
Regards, - John
On Wed, 19 Oct 2016, John Fisherman wrote:
Hello all,
which is somewhat less detailed than the first one, but optionnal configuration on the first one should also be viable for the ARM’s one. Well, my issue comes when executing the “make” command inside “openfirmware/cpu/x86/pc/emu/build”.
Hi John,
I think I got it working once, are you building on the x86 machine?
Marcin
I can answer/fix your specific problem soon, like say after this weekend. I'm currently teaching an Open Firmware class, which has me fully occupied for the next couple of days.
WRT your final "other solutions for bare metal" question, I particularly recommend my CForth implementation at https://github.com/MitchBradley/cforth.git
As the author of both Open Firmware and that CForth, I suggest that CForth is usually better suited for "just using Forth". Open Firmware includes a good (I think great) Forth subsystem, but it also has a lot of stuff that you don't really need unless you want to use it to boot other operating systems. CForth is almost as full-featured as the Open Firmware Forth core, notably lacking a processor-specific assembler/disassembler. To make up for that, it is much easier to incorporate external C routines, such as might be found in various SDKs, into Forth.
I have used CForth on lots of different ARM chips. In fact, the ARM version of the One Laptop Per Child computer uses both CForth and Open Firmware. CForth runs on a stripped-down ARM core that only participates in the initial secured process of memory init and loading the final bootloader to run on fancier ARM cores. That final bootloader is Open Firmware. So CForth "boots" Open Firmware which boots Linux.
Whichever you choose, I'll help you when I come up for air after this class.
Mitch
On 10/19/2016 5:22 AM, John Fisherman wrote:
Hello all,
I am currently facing an issue to build OpenFirmware for ARM. Let’s start with some explanations : My goal is to have a Forth interpreter running on a barebone ARM device. I’ve tried some, like ForthOS (which runs on x86 only) and another one designed for the Raspberry Pi which is far for being complete. So, I’ve been following two of your official tutorials :
Got to say the first one worked well, except it is not stated that “subversion” is required, but we can easily find it out by ourselves. At the end, I got OpenFirmware running and have been able to type some Forth commands on the interpreter.
Then, I tried to reproduce this with ARM Qemu. Fell on the second tutorial, which is somewhat less detailed than the first one, but optionnal configuration on the first one should also be viable for the ARM’s one. Well, my issue comes when executing the “make” command inside “openfirmware/cpu/x86/pc/emu/build”. Here is what I get :
/jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$ make/
/./build ofw.rom/
/--- Rebuilding sp.img/
/--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../sp.bth/
/--- Rebuilding fw.img/
/--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/basefw.dic ../fw.bth/
/sh: 1: /home/jacky/openfirmware/cpu/x86/Linux/armforth: not found/
/Makefile:22: recipe for target 'ofw.rom' failed/
/make: *** [ofw.rom] Error 1/
/jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$ /
At first I tought it was due to script’s or environment’s variable like ${HOSTDIR} as this was the line causing the error. It seemed those variables were correctly replaced in the script itself, as a previous line is well executed using this same variable. Next, I’ve been looking for openfirmware/cpu/x86/Linux/armforth file. As the error states, this file is not present in the cpu/x86/Linux folder. In fact, there is a file named like this, but it has an extension .qemu (the complete file name is armforth.qemu. So I tough about a simple mistake, and renamed it (in fact, I copied it to avoid other errors) into armforth.
Once renamed, I did “make clean”, and relaunched a “make”. The previous error disappeared, the script went farther, but still did not complete :
/jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$ make/
/./build ofw.rom/
/--- Rebuilding sp.img/
/--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../sp.bth/
/--- Rebuilding fw.img/
/--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/basefw.dic ../fw.bth/
/${BP}/cpu/arm/mmp2/rootnode.fth:32: io2-va ?/
/${BP}/cpu/arm/mmp2/rootnode.fth:36: io-va ?/
/${BP}/cpu/arm/mmp2/mmuon.fth:12: fw-mem-va ?/
/${BP}/cpu/arm/mmp2/mmuon.fth:12: page-table-offset ?/
/${BP}/cpu/arm/mmp2/mmuon.fth:13: page-table-va ?/
/Makefile:22: recipe for target 'ofw.rom' failed/
/make: *** [ofw.rom] Error 1/
/jacky@debiannos:~/openfirmware/cpu/arm/mmp2/build$/
These errors appears to be forth-related, as if some words were not defined. Maybe is it due to the /basefw.dic /dictionnary… To be honest, I can’t think about any other solutions. Maybe I will dig into these forth files but I am afraid it will be a loss of time as I am a real beginner to Forth.
Here’s what I tried :
Executing make as root. Same issue.Executing it on another distro (Ubuntu 14.x). Same issue.Tried different Qemu versions (don’t ask me why… I tried the4.7 one on the official website, and the maintained one on github’s Qemu repo.
Forgot to mention this has been has been tested on both a clean Ubuntu and a clean Debian VM using VMWare. Yes, I am emulating an emulator. ;)
Also, I'd be glad if you have any other solutions to run a Forth interpreter on a bare-metal ARM machine, either emulated or not. Thanks in advance, for your work, for your help, and for reading this.
Regards,
- John
openfirmware mailing list openfirmware@openbios.org https://www.coreboot.org/mailman/listinfo/openfirmware
Hello Mitch, Thanks for your answer, I successfully built the OpenFirmware's ROM by trying older subversion's revisions (thanks to Marcin). Now that I have the ROM, I am stuck on loading the ROM using Qemu.
Forgot to respond to the whole mailing list, here is the latest update of my issue :
|| || V
Hello Marcin,
Thanks again for your help, it solved the issue in a way. Tried several older revisions: r3500, r3000, r2500, and finally r2000. Only the revision 2000 successfully built the ARM rom called ofw.rom. This revision is from 2010-10-08 02:39:55, when the documentation is from 2010-08-11, 18:45.
Here’s the output :
* jacky@debiannos:~/openfirmware-r2000/cpu/arm/mmp2/build$ make*
*make[1]: Entering directory '/home/jacky/openfirmware-r2000/cpu/x86/Linux'*
*cc -c -O -g -m32 -DTARGET_X86 ../../../forth/wrapper/wrapper.c -o wrapper.o*
*cc -c -O -g -m32 -DTARGET_X86 ../../../forth/wrapper/logger.c -o logger.o*
*cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/zipmem.c -o zipmem.o*
*cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/deflate.c -o deflate.o*
*cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/trees.c -o trees.o*
*cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/bits.c -o bits.o*
*cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/util.c -o util.o*
*cc -c -m32 -Wall -fno-stack-protector -ffreestanding -D_FORTIFY_SOURCE=0 -DNEED_BCOPY -O3 -fpic ../../../forth/wrapper/zip/inflate.c -o inflate.lo*
*ld -T inflate.ld inflate.lo -o inflate.o*
*cc -m32 -o forth wrapper.o logger.o zipmem.o deflate.o trees.o bits.o util.o inflate.o *
*/usr/bin/ld: error in inflate.o(.eh_frame); no .eh_frame_hdr table will be created.*
*make[1]: Leaving directory '/home/jacky/openfirmware-r2000/cpu/x86/Linux'*
*./build ofw.rom*
*--- Rebuilding sp.img*
*--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../sp.bth*
*--- Rebuilding kernel.dic*
*--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../kernel.bth*
*context: forth forth re-heads root current: forth *
*--- Saving kernel.dic ---*
*--- Rebuilding tools.dic*
*--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/kernel.dic ../tools.bth*
*--- Saving tools.dic --- *
*--- Rebuilding basefw.dic*
*--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/tools.dic ../basefw.bth*
*--- Saving basefw.dic --- *
*--- Rebuilding fw.img*
*--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/basefw.dic ../fw.bth*
*(end-extra) isn't unique *
*${BP}/ofw/gui/iconmenu.fth:183: expand-rect ?*
*--- Saving fw.dic ...*
*--- Saving fw.img --- *
*--- Rebuilding ofw.rom*
*--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../ofw.bth*
*jacky@debiannos:~/openfirmware-r2000/cpu/arm/mmp2/build$ *
Only the following line still warns us of a potential issue : *${BP}/ofw/gui/iconmenu.fth:183: expand-rect ?* It seems to concern an icon, so it should not be a problem; the ROM is built, and this is what I wanted.
As it is explained in the documentation, the last step should be to launch qemu : *qemu -L . -bios ofw.rom -hda fat:. *Here’s the output :
*jacky@debiannos:~$ qemu-system-arm -L . -bios ofw.rom -hda fat:.*
*No machine specified, and there is no default.*
*Use -machine help to list supported machines!*
*jacky@debiannos:~$*
Let’s specify the machine :
*jacky@debiannos:~$ qemu-system-arm -L . -bios ofw.rom -hda fat:. –machine none*
This time, a Qemu window pops, with the following text:
*compat_monitor0 console*
*QEMU 2.1.2 monitor – type ‘help’ for more information*
*(qemu) $*
That’s just the Qemu console, correct me if i’m wrong, the bios is not executed.
So I tried some other machines:
*jacky@debiannos:~$ qemu-system-arm -L . -bios ~/openfirmware-r2000/cpu/arm/mmp2/build/ofw.rom –cpu cortex-m3 -machine lm3s811evb -hda fat:.*
*vvfat . chs 1024,16,63*
*Guest image must be specified (using -kernel)*
And:
*jacky@debiannos:~$ qemu-system-arm -L . -bios ~/openfirmware-r2000/cpu/arm/mmp2/build/ofw.rom -machine connex -hda fat:.*
*vvfat . chs 1024,16,63*
*A flash image must be given with the 'pflash' parameter*
*jacky@debiannos:~$*
Also tried with almost all the ones listed thanks to the command *qemu-system-arm –machine help.* Why would a flash or a kernel be required when it was not, using Qemu for x86 ?
Which kernel and flash should I use in order to run OpenFirmware? I suppose this question is partly getting off topic, as the base issue has been solved, maybe you want me to open another topic ?
Again, thanks a lot.
Regards, - John
a) Unless you happen to have an MMP2 development board from Marvell, you should not use the mmp2/ build directory. The best build directory for ARM QEMU is cpu/arm/versatilepb/build . The mmp2/, mmp3/, and olpc/ directories are full of Marvell-specific stuff which is very unlikely to work on any other platform, and which is unsupported by QEMU.
b) cpu/arm/versatilepb/qemubase.bth has instructions at the top for how to invoke qemu.
c) Please switch from the subversion repository to this one: https://github.com/MitchBradley/openfirmware.git My future development for non-OLPC platforms will be done there. It already has a bug fix for the QEMU build above. The svn repo is already in "archival" status; no new work is going there.
d) I strongly suggest that, unless you really need Open Firmware features and understand Open Firmware well, you should build qemuforth.rom instead of qemubase.rom . The latest cpu/arm/versatilepb/build/Makefile has instructions at the top for how to build qemuforth.rom . The Open Firmware features take up a lot of space and add complexity that most embedded apps do not use.
On 10/24/2016 12:44 AM, John Fisherman wrote:
Hello Mitch, Thanks for your answer, I successfully built the OpenFirmware's ROM by trying older subversion's revisions (thanks to Marcin). Now that I have the ROM, I am stuck on loading the ROM using Qemu.
Forgot to respond to the whole mailing list, here is the latest update of my issue :
|| || VHello Marcin,
Thanks again for your help, it solved the issue in a way. Tried several older revisions: r3500, r3000, r2500, and finally r2000. Only the revision 2000 successfully built the ARM rom called ofw.rom. This revision is from 2010-10-08 02:39:55, when the documentation is from 2010-08-11, 18:45.
Here’s the output : / jacky@debiannos:~/openfirmware-r2000/cpu/arm/mmp2/build$ make/
/make[1]: Entering directory '/home/jacky/openfirmware-r2000/cpu/x86/Linux'/
/cc -c -O -g -m32 -DTARGET_X86 ../../../forth/wrapper/wrapper.c -o wrapper.o/
/cc -c -O -g -m32 -DTARGET_X86 ../../../forth/wrapper/logger.c -o logger.o/
/cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/zipmem.c -o zipmem.o/
/cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/deflate.c -o deflate.o/
/cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/trees.c -o trees.o/
/cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/bits.c -o bits.o/
/cc -c -O -g -m32 -DTARGET_X86 -I../../../forth/wrapper/zip ../../../forth/wrapper/zip/util.c -o util.o/
/cc -c -m32 -Wall -fno-stack-protector -ffreestanding -D_FORTIFY_SOURCE=0 -DNEED_BCOPY -O3 -fpic ../../../forth/wrapper/zip/inflate.c -o inflate.lo/
/ld -T inflate.ld inflate.lo -o inflate.o/
/cc -m32 -o forth wrapper.o logger.o zipmem.o deflate.o trees.o bits.o util.o inflate.o /
//usr/bin/ld: error in inflate.o(.eh_frame); no .eh_frame_hdr table will be created./
/make[1]: Leaving directory '/home/jacky/openfirmware-r2000/cpu/x86/Linux'/
/./build ofw.rom/
/--- Rebuilding sp.img/
/--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../sp.bth/
/--- Rebuilding kernel.dic/
/--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../kernel.bth/
/context: forth forth re-heads root current: forth /
/--- Saving kernel.dic ---/
/ /
/--- Rebuilding tools.dic/
/--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/kernel.dic ../tools.bth/
/--- Saving tools.dic --- /
/--- Rebuilding basefw.dic/
/--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/tools.dic ../basefw.bth/
/--- Saving basefw.dic --- /
/--- Rebuilding fw.img/
/--- Cmd: ${HOSTDIR}/armforth ${BP}/cpu/arm/build/basefw.dic ../fw.bth/
/(end-extra) isn't unique /
/${BP}/ofw/gui/iconmenu.fth:183: expand-rect ?/
/--- Saving fw.dic .../
/--- Saving fw.img --- /
/--- Rebuilding ofw.rom/
/--- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../ofw.bth/
/jacky@debiannos:~/openfirmware-r2000/cpu/arm/mmp2/build$ /
Only the following line still warns us of a potential issue : /${BP}/ofw/gui/iconmenu.fth:183: expand-rect ?/ It seems to concern an icon, so it should not be a problem; the ROM is built, and this is what I wanted.
As it is explained in the documentation, the last step should be to launch qemu : /qemu -L . -bios ofw.rom -hda fat:. /Here’s the output :
/jacky@debiannos:~$ qemu-system-arm -L . -bios ofw.rom -hda fat:./
/No machine specified, and there is no default./
/Use -machine help to list supported machines!/
/jacky@debiannos:~$/
//
Let’s specify the machine :
/jacky@debiannos:~$ qemu-system-arm -L . -bios ofw.rom -hda fat:. –machine none/
This time, a Qemu window pops, with the following text:
/compat_monitor0 console/
/QEMU 2.1.2 monitor – type ‘help’ for more information/
/(qemu) $/
That’s just the Qemu console, correct me if i’m wrong, the bios is not executed.
So I tried some other machines:
/jacky@debiannos:~$ qemu-system-arm -L . -bios ~/openfirmware-r2000/cpu/arm/mmp2/build/ofw.rom –cpu cortex-m3 -machine lm3s811evb -hda fat:./
/vvfat . chs 1024,16,63/
/Guest image must be specified (using -kernel)/
And:
/jacky@debiannos:~$ qemu-system-arm -L . -bios ~/openfirmware-r2000/cpu/arm/mmp2/build/ofw.rom -machine connex -hda fat:./
/vvfat . chs 1024,16,63/
/A flash image must be given with the 'pflash' parameter/
/jacky@debiannos:~$/
Also tried with almost all the ones listed thanks to the command /qemu-system-arm –machine help./ Why would a flash or a kernel be required when it was not, using Qemu for x86 ?
Which kernel and flash should I use in order to run OpenFirmware? I suppose this question is partly getting off topic, as the base issue has been solved, maybe you want me to open another topic ?
Again, thanks a lot.
Regards,
- John
Hello Mitch and thanks for these advices.
a) I currently do not really know on which kind of machine I will perform further development, but there a high chances it will use a Cortex-M3 processor. Until then, I will follow your advices and use *versatilepb*, I will see later for the processor.
b) Good job. It works :) The QEMU window's there with the Forth interpreter. I'm somewhat afraid of some warnings tho, here's the output :
*johnny@ubuntu:~/openfirmware-mitchbradley/cpu/arm/versatilepb/build$ qemu-system-arm -M versatilepb -m 32 -kernel qemuforth.rom -serial vcFailed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-iscsi.soNote: only modules from the same build can be loaded.Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.soNote: only modules from the same build can be loaded.Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-rbd.soNote: only modules from the same build can be loaded.Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-dmg.soNote: only modules from the same build can be loaded.pulseaudio: set_sink_input_volume() failedpulseaudio: Reason: Invalid argumentpulseaudio: set_sink_input_mute() failedpulseaudio: Reason: Invalid argument*
The ones about audio are probably caused by the lack of audio emulation options, but what about other ones ? Aren't they dangerous ? Once again, good work, this is all I needed !
c) Thanks for redirecting me to your GitHub version.
d) You are right, I will use qemuforth.rom until I understand some more how OpenFirmware works. I successfully built the rom by replacing the* cpu/arm/versatilepb/build/**Makefile *first line by *ROMNAME=qemuforth*. A small error I faced with the subversion's version is still present on your GitHub version when building ARM ROMs: " I’ve been looking for openfirmware/cpu/x86/Linux/armforth file. As the error states, this file is not present in the cpu/x86/Linux folder. In fact, there is a file named like this, but it has an extension .qemu (the complete file name is armforth.qemu. So I tough about a simple mistake, and renamed it (in fact, I copied it to avoid other errors) into armforth." Renamed it, and successfully built the ROM.
Thanks for your help Mitch, you've put me in the good direction. I hope not to have to bother you again, it should be fine from now :)
Regards, - John
On 10/25/2016 4:02 AM, John Fisherman wrote:
Hello Mitch and thanks for these advices.
a) I currently do not really know on which kind of machine I will perform further development, but there a high chances it will use a Cortex-M3 processor. Until then, I will follow your advices and use /versatilepb/, I will see later for the processor.
My real advice is to use CForth. Cortex-M3 does not implement the old-school "ARM classic" instruction set encoding, but rather uses the more densely encoded Thumb variant. Open Firmware supports only the classic encoding. Making it support Thumb would require a new kernel port.
CForth, on the other hand, supports pretty much anything, because it lets the C compiler do the grunt work. Back in the day, C compilers were of mixed quality, so there was a good reason to do the Forth kernel in assembler, but modern C compilers are really really good so that reason has largely evaporated.
Lately I have used CForth with Cortex M0, M3, and M4, xtensa, x86 32 and 64 bit, and ARM classic. I have just stopped caring about the instruction set.
Furthermore, CForth is much easier to cross-compile. With OFW Forth, in order to extend the dictionary, you need to run the Forth kernel on the same CPU instruction set as the target machine, either natively or under emulation. The "armforth" program for x86 is actually an ARM (classic) instruction set simulator. CForth avoids this problem by using a processor-independent memory representation for the Forth dictionary . That lets you extend a dictionary on the host (e.g. x86) and then use that dictionary image on the target.
There was a time when the Forth in Open Firmware had important features that CForth lacked, but that too is a thing of the past. The current CForth is capable of compiling the Open Firmware source. I used a CForth-hosted Open Firmware to teach an Open Firmware class last week.
CForth even has an ARM-Thumb disassembler - although it is rarely needed.
The final argument in favor of CForth is that it works smoothly with the existing SDKs for micros. For OFW Forth, you must figure out the load image format for the target system and duplicate it. CForth avoids that problem because you just add the compiler-generated object files to the SDK's build and let the SDK handle the details.
Lately I have been doing a lot of work with ESP8266 modules. It is a WiFi radio with enough spare memory to run CForth alongside the WiFi stack. Cost-wise they are very hard to beat. The bare modules can be had for less than $2, and a breadboard-friendly versions in two different form factors with voltage regulator and USB-serial chip can be had for less than $4, from many suppliers.
http://www.ebay.com/itm/like/122186262293 http://www.ebay.com/itm/1PCS-NodeMcu-Lua-ESP8266-CH340G-WIFI-Internet-Develo...
The processor is xtensa, which CForth supports just fine - you just need to get the xtensa gcc, which is readily available.
They come with Lua preinstalled, but it is easy to replace that with Forth.
b) Good job. It works :) The QEMU window's there with the Forth interpreter. I'm somewhat afraid of some warnings tho, here's the output : / johnny@ubuntu:~/openfirmware-mitchbradley/cpu/arm/versatilepb/build$ qemu-system-arm -M versatilepb -m 32 -kernel qemuforth.rom -serial vc Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-iscsi.so Note: only modules from the same build can be loaded. Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.so Note: only modules from the same build can be loaded. Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-rbd.so Note: only modules from the same build can be loaded. Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-dmg.so Note: only modules from the same build can be loaded. pulseaudio: set_sink_input_volume() failed pulseaudio: Reason: Invalid argument pulseaudio: set_sink_input_mute() failed pulseaudio: Reason: Invalid argument/
The ones about audio are probably caused by the lack of audio emulation options, but what about other ones ? Aren't they dangerous ? Once again, good work, this is all I needed !
Most likely, those warnings are unimportant, because they are only used if you try to invoke emulated hardware features like iSCSI. The only emulated peripheral device that the versatilepb supports is the UART. Trying to hook it up to the other emulated peripherals would be pointless, as the programming models for that emulated hardware are largely obsolete.
I find qemu to be very frustrating. Every time I use it I have to spend an inordinate amount of time trying to get the options right and figuring out what it is really doing. It's an impressive body of work, but it can be a huge time sink.
c) Thanks for redirecting me to your GitHub version.
d) You are right, I will use qemuforth.rom until I understand some more how OpenFirmware works. I successfully built the rom by replacing the/cpu/arm/versatilepb/build///Makefile /first line by /ROMNAME=qemuforth/. A small error I faced with the subversion's version is still present on your GitHub version when building ARM ROMs: "I’ve been looking for openfirmware/cpu/x86/Linux/armforth file. As the error states, this file is not present in the cpu/x86/Linux folder. In fact, there is a file named like this, but it has an extension .qemu (the complete file name is armforth.qemu. So I tough about a simple mistake, and renamed it (in fact, I copied it to avoid other errors) into armforth." Renamed it, and successfully built the ROM.
armforth.qemu is a shell script that invokes qemu to emulate the ARM instruction set so you can use cpu/arm/Linux/armforth.static as the host system wrapper. In that mode, qemu-arm is emulating both the ARM instruction set and also the Linux user-level system interface. That certainly works, but there is another way that is a bit more direct:
cd cpu/x86/Linux make armforth
That creates an armforth that includes a simple ARM instruction set simulator from the source file cpu/arm/armsim.c . That approach does not require qemu at all. Of course, if you want to use QEMU to "run" the target code, you will still need QEMU, but in most of my work, I use target hardware directly, instead of running an emulator that is unlikely to match my hardware.
But anyway, this is all moot because you really should be using CForth.
Thanks for your help Mitch, you've put me in the good direction. I hope not to have to bother you again, it should be fine from now :)
Regards,
- John
openfirmware@openfirmware.info
-
James Cameron -
John Fisherman -
Marcin Cieslak -
Mitch Bradley