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