Re: [Qemu-discuss] Starting troubles in running stm32f4 on an i386

[Jakob Bohm]

On 04/03/2015 15:36, Peter Maydell wrote:
> On 4 March 2015 at 23:32, Srinath M <address@hidden> wrote:
> > The binary is for a very custom board.
> > http://autoquad.org/
> > I have replaced the sensor reading tasks with an onboard simulation that
> > feeds 'virtual sensor values' to the STM32F4. This way the executable is now
> > entirely self contained and doesn't call any physical sensors etc
> >
> > I would rather alter qemu to add the functionality needed if there was some
> > documentation on how to go about it, if that's the way to go about it
> It can be done, but it's a big and complicated job (think of it
> as about as much effort as porting an OS like Linux to the board
> would be: each device needs a device model to be written, and
> that's about as much work as writing a device driver). There's
> no documentation, you have to look at the existing QEMU source
> code to see how to write new device models.
To Srinath M:

Maybe the easiest solution is to use an existing -M parameter
most closelyresembling the relevant parts of the hardware (a
Cortex M3 or similar CPU,and other on-chip components as
close as possible to what is on the chipyou use, if there is
more than one choice).

Somewhat confusingly, Linux on Arm people have a nasty habit
of conflatingthe SoC chip with the machine/board, resulting
in lots of absurd situationswhen compiling kernels for real
world arm machines, such as the millions(billions soon?) of
phones and tablets running Linux kernels on Arm coresinside
mass produced SoC chips soldered onto different boards whose
very existence cannot be known by the free software community
until thefinished product, complete with a running Linux
kernel and production OShas been mass produced and
distributed to warehouses around the globefor a surprise
commercial release.

You, as someone soldering an Arm-based microcontroller onto
a custom project board and trying to emulate it using qemu
are now in the same situation as a Samsung/LG/HTC/Motorola/
OPPO/Acer/etc. engineer designing a new Smartphone around
a commercially available higher end Arm SoC connected to
a new secret (until released) mix of peripherals and trying
to get Android firmware up and running without revealing your
new design to the competitors until it is already arriving
in the shops while being announced to the world in a multi-
million dollar advertising campaign.

========================
To the qemu maintainers:

Life would be so much easier if the Arm "machines" supported
by the Linux kernel, qemu etc. were more like the PC
architectures: A command line/config file specified arbitrary
combination of CPU cores and common peripherials.  During its
short stint as an open source OS, the Symbian project was
trying to create this under the code name "Syborg", maybe
someone could resurrect that as a general mechanism for
emulating different Arm (etc.) machines without explicit code
development for each board.

In other words, one should be able to do something like

qemu-system-arm --cpu M3 --vfp=no --ram 32M \
   --device=sdcard1,sdcard4wire,0xabcd0000,disk1 \
   --disk=... --device=watchdog1,wdfoo,0xabcd0010 \
   --device=gpio,iobar,0xabcd0020 \
   --device=tty1,serial8250,0xabcd0030 ... \
   --bootrom=0xf0000000,0xf0001000,myrom.rom

Causing qemu to emulate that CPU without a floating point
unit, with the specified peripherals (out of those
supported by qemu, many shared with other architectures
like the classic 8250-style UART) at the specified
bus addresses, mapping in a virtual ROM with the specified
file contents at the specified address (0xf0000000, size
is file size) then start executing at 0xf0001000 and leaving
it to the supplied ROM to find a bootloader and tell it
about where the I/O devices are, just like what happens
when someone builds a new board from existing chips or
assembles a new SoC design from ARM inc. licensed mask
blobs.

But for now, it seems we will all have to make do with the
ugly hack of choosing a "similar" machine from a short list
of what others have created, and then adapt our test software
configurations to that unrealistic model, until we are ready
to test on the real hardware with a differently compiled
system.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded