[openfirmware] Fwd: [ARM] [Qemu] Cannot build OpenFirmware for ARM using make

[Mitch Bradley]

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-Development-Board-Module/141975649873

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 at 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
>