OMAP emulation

OMAP emulation

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 6788 bytes --]

Hi,
I started adding basic emulation for a OMAP 310 based system (the Palm
Tungsten E device in particular) to the QEMU project (www.qemu.org)
taking advantage of its already functional emulation of the ARM
processor. Now it's already at a point where it lets me boot the some
of same OMAP kernel builds on my PC using the emulator and on the real
device using the Garux bootloader (garux.sourceforge.net). If anyone
is interested, feel free to try it out although the emulator is still
missing various parts. I'm hoping that it will help me debugging the
drivers later. Also, QEMU runs linux at about double speed of the real
device on my desktop PC so it might speed up testing.
Here is what I have got working so far, and what the patch contains:

 - well, the processor: QEMU emulates an ARM 1026 but it turned out to
be similar  enough to the TI 925. I really only had to change the
identification numbers it returns to those of TI 925.

 - some of the basic "MPU subsystems", that is:
 - the IRQ and FIQ generation from both level 1 and 2 banks of
interrupts (with the right peripherals connected to the right
interrupt lines.)
 - timers: the three general purpose MPU timers.
 - most of the configuration registers (actually many of them are only
dummies because the emulator doesn't care about things like voltages,
clocking schemes, or all the different types of caching.)
 - the shared GPIO lines plus the 16 MPUIO GPIOs (with the rest of the
peripherals connected to the right gpio pins like on my Palm.)
 - a keyboard connected through the MPUI keypad interface (the keymap
I used is not the one from the real device, it contains all the PC
keys. You can change that easily.)

 - the OMAP DMA controller with 9 general channels and one dedicated
channel for the LCD -- seems to be working but as you can imagine,
it's difficult to emulate.

 - the OMAP LCD controller with the QEMU display connected to it as
the actual LCD -- only tested with 8 bit colour, the penguin looks
fine.

 - an SD card emulator according to the SD specification (for those
who don't know, SD cards have a whole little "computer" working in
each of them.) Implements some security features too.

 - the OMAP MMC/SD host controller making use of the SD card emulator.
Also emulates the card eject event and insertion of new cards, and can
be accessed using either DMA or the registers. Unfortunately there's
still something wrong with it -- linux panics after a few requests
(but always reads the partition table fine), strange thing is that it
panics in the generic block driver when it's trying to allocate memory
for a new block of data from the card, not anywhere in MMC or OMAP
drivers.

 - the microwire ports (only tested with registers access, no dma.)

 - a (part of the) TSC2301 chipset connected to the MPU using the
microwire port. Currently only has some of the internal logic plus the
touchscreen controller with the QEMU mouse input connected as the
actual touchscreen. TSC2301 can also control audio inputs and outputs,
a keypad (unused in Palm Tungsten E as the keypad is connected to the
MPUI interface), temperature (also unused) and battery state monitors
-- and these are not implemented.

 - the OMAP RTC with alarm and stuff. Through it the VM can access the
host's clock.

The patch is at http://www.zabor.org/balrog/qemu-omap.patch (160 kB).
The command line I use to launch QEMU is:
   $ qemu-system-arm -M omap310 -kernel ./zImage
You can add "-fda ./cardimage".
Note however that I implemented most parts according to the
documentation from ti.com (mostly OMAP 5910 docs) and not according to
what Linux needed to work. Therefore, where linux drivers accessed
non-existent (or undocumented) registers, or performed writes to
read-only registers, or wrote values prohibited by the docs, I
modified the kernel and not the emulator (and there was a number of
such places). So QEMU is likely to exit with something like "fatal
error: bad register access at ..." when you try booting Linux. In that
case it can be:
 - Linux drivers accessing non-existent registers, or
 - Linux accessing a peripheral that QEMU doesn't emulate yet (e.g. USB).
If that happens you can either fix the kernel or add dummy registers
in QEMU or make QEMU ignore bad register accesses whatsoever (that's
what the real device does). In the latter case, recompile kernel
without support for the given peripheral device.
I know that 310 is practically the simplest of OMAP boards because it
doesn't have a DSP core and lacks a couple of other things. Almost all
of the code can be reused for OMAP 1510 or 5910/5912 emulation though.
Emualting other boards would require more changes.
The patch is against QEMU 0.8.0 release. I have only tested it on a
Linux/PC as host -- I'm pretty sure it won't work on little-endian
machines (even though QEMU in general does work on PPC and other
archs). It contains a bootloader code for Linux/ARM copied from the
IntegratorCP board emulator by Paul Brook. It also contains pieces of
code from Anthony Liguori's patch for WACOM tablet emulation, that
enables QEMU reporting absolute coordinates (for the TSC2301
touchscreen).

The purpose of this emulator was to help me fix a bug in the kernel
that causes linux userspace to be extremely unstable -- unfortuntaly
it turned out that the bug is not reproduced in the emulator,
everything works perfectly fine in it. The bug was already mentioned
on this list by X-Stranger
(http://linux.omap.com/pipermail/linux-omap-open-source/2006-February/006399.html).
On the real device (Palm Tungsten E) kernel always boots fine but as
soon as userspace kicks in, programs will hang, segfault or fail
assertions (in case of glib based programs) to the point of being
unusable. A given program binary with a given kernel binary always
fails the same way and in the same moment of execution. However,
adding or removing a single instruction in either the kernel or the
program, changes the kind of error and the place where it happens
(sometimes fixes the problem or breaks new things) -- not depending on
the actual instruction that was added, more on the size of it and its
placement in the code.
Removing the accesses of non-existent registers from the kernel didn't
help as I hoped it would. Since owners of OMAP 1510 devices don't
report such problems and the emulator (based on 5910 docs) doesn't
exhibit the bug either, our conclusion is that the differences between
OMAP 310 and other boards are in the root of the bug. Alternatively,
it could be a bootloader problem (we use Garux on the PDA). If anybody
has an idea about what might be wrong, please tell.

Regards,
Andrzej Zaborowski
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: OMAP emulation

[Tony Lindgren]

Hi,

* andrzej zaborowski <balrog@zabor.org> [060317 09:35]:
> Hi,
> I started adding basic emulation for a OMAP 310 based system (the Palm
> Tungsten E device in particular) to the QEMU project (www.qemu.org)
> taking advantage of its already functional emulation of the ARM
> processor. Now it's already at a point where it lets me boot the some
> of same OMAP kernel builds on my PC using the emulator and on the real
> device using the Garux bootloader (garux.sourceforge.net). If anyone
> is interested, feel free to try it out although the emulator is still
> missing various parts. I'm hoping that it will help me debugging the
> drivers later. Also, QEMU runs linux at about double speed of the real
> device on my desktop PC so it might speed up testing.

Hey, that's cool!

> Here is what I have got working so far, and what the patch contains:
> 
>  - well, the processor: QEMU emulates an ARM 1026 but it turned out to
> be similar  enough to the TI 925. I really only had to change the
> identification numbers it returns to those of TI 925.
> 
>  - some of the basic "MPU subsystems", that is:
>  - the IRQ and FIQ generation from both level 1 and 2 banks of
> interrupts (with the right peripherals connected to the right
> interrupt lines.)
>  - timers: the three general purpose MPU timers.
>  - most of the configuration registers (actually many of them are only
> dummies because the emulator doesn't care about things like voltages,
> clocking schemes, or all the different types of caching.)
>  - the shared GPIO lines plus the 16 MPUIO GPIOs (with the rest of the
> peripherals connected to the right gpio pins like on my Palm.)
>  - a keyboard connected through the MPUI keypad interface (the keymap
> I used is not the one from the real device, it contains all the PC
> keys. You can change that easily.)
> 
>  - the OMAP DMA controller with 9 general channels and one dedicated
> channel for the LCD -- seems to be working but as you can imagine,
> it's difficult to emulate.

Hehe!
 
>  - the OMAP LCD controller with the QEMU display connected to it as
> the actual LCD -- only tested with 8 bit colour, the penguin looks
> fine.
> 
>  - an SD card emulator according to the SD specification (for those
> who don't know, SD cards have a whole little "computer" working in
> each of them.) Implements some security features too.
> 
>  - the OMAP MMC/SD host controller making use of the SD card emulator.
> Also emulates the card eject event and insertion of new cards, and can
> be accessed using either DMA or the registers. Unfortunately there's
> still something wrong with it -- linux panics after a few requests
> (but always reads the partition table fine), strange thing is that it
> panics in the generic block driver when it's trying to allocate memory
> for a new block of data from the card, not anywhere in MMC or OMAP
> drivers.
> 
>  - the microwire ports (only tested with registers access, no dma.)
> 
>  - a (part of the) TSC2301 chipset connected to the MPU using the
> microwire port. Currently only has some of the internal logic plus the
> touchscreen controller with the QEMU mouse input connected as the
> actual touchscreen. TSC2301 can also control audio inputs and outputs,
> a keypad (unused in Palm Tungsten E as the keypad is connected to the
> MPUI interface), temperature (also unused) and battery state monitors
> -- and these are not implemented.
> 
>  - the OMAP RTC with alarm and stuff. Through it the VM can access the
> host's clock.
> 
> The patch is at http://www.zabor.org/balrog/qemu-omap.patch (160 kB).
> The command line I use to launch QEMU is:
>    $ qemu-system-arm -M omap310 -kernel ./zImage
> You can add "-fda ./cardimage".
> Note however that I implemented most parts according to the
> documentation from ti.com (mostly OMAP 5910 docs) and not according to
> what Linux needed to work. Therefore, where linux drivers accessed
> non-existent (or undocumented) registers, or performed writes to
> read-only registers, or wrote values prohibited by the docs, I
> modified the kernel and not the emulator (and there was a number of
> such places). So QEMU is likely to exit with something like "fatal
> error: bad register access at ..." when you try booting Linux. In that
> case it can be:
>  - Linux drivers accessing non-existent registers, or
>  - Linux accessing a peripheral that QEMU doesn't emulate yet (e.g. USB).
> If that happens you can either fix the kernel or add dummy registers
> in QEMU or make QEMU ignore bad register accesses whatsoever (that's
> what the real device does). In the latter case, recompile kernel
> without support for the given peripheral device.
> I know that 310 is practically the simplest of OMAP boards because it
> doesn't have a DSP core and lacks a couple of other things. Almost all
> of the code can be reused for OMAP 1510 or 5910/5912 emulation though.
> Emualting other boards would require more changes.
> The patch is against QEMU 0.8.0 release. I have only tested it on a
> Linux/PC as host -- I'm pretty sure it won't work on little-endian
> machines (even though QEMU in general does work on PPC and other
> archs). It contains a bootloader code for Linux/ARM copied from the
> IntegratorCP board emulator by Paul Brook. It also contains pieces of
> code from Anthony Liguori's patch for WACOM tablet emulation, that
> enables QEMU reporting absolute coordinates (for the TSC2301
> touchscreen).
> 
> The purpose of this emulator was to help me fix a bug in the kernel
> that causes linux userspace to be extremely unstable -- unfortuntaly
> it turned out that the bug is not reproduced in the emulator,
> everything works perfectly fine in it. The bug was already mentioned
> on this list by X-Stranger
> (http://linux.omap.com/pipermail/linux-omap-open-source/2006-February/006399.html).

LOL, that's a lot of work to track down a bug :) Too bad it did not
help. But at least there's an omap emulator now.

> On the real device (Palm Tungsten E) kernel always boots fine but as
> soon as userspace kicks in, programs will hang, segfault or fail
> assertions (in case of glib based programs) to the point of being
> unusable. A given program binary with a given kernel binary always
> fails the same way and in the same moment of execution. However,
> adding or removing a single instruction in either the kernel or the
> program, changes the kind of error and the place where it happens
> (sometimes fixes the problem or breaks new things) -- not depending on
> the actual instruction that was added, more on the size of it and its
> placement in the code.
> Removing the accesses of non-existent registers from the kernel didn't
> help as I hoped it would. Since owners of OMAP 1510 devices don't
> report such problems and the emulator (based on 5910 docs) doesn't
> exhibit the bug either, our conclusion is that the differences between
> OMAP 310 and other boards are in the root of the bug. Alternatively,
> it could be a bootloader problem (we use Garux on the PDA). If anybody
> has an idea about what might be wrong, please tell.

Sounds like you have already verified the memory timings. Does it work
properly with caches disabled?

Regards,

Tony

Re: OMAP emulation

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 8750 bytes --]

On 20/03/06, Tony Lindgren <tony@atomide.com> wrote:
> Hi,
>
> * andrzej zaborowski <balrog@zabor.org> [060317 09:35]:
> > Hi,
> > I started adding basic emulation for a OMAP 310 based system (the Palm
> > Tungsten E device in particular) to the QEMU project (www.qemu.org)
> > taking advantage of its already functional emulation of the ARM
> > processor. Now it's already at a point where it lets me boot the some
> > of same OMAP kernel builds on my PC using the emulator and on the real
> > device using the Garux bootloader (garux.sourceforge.net). If anyone
> > is interested, feel free to try it out although the emulator is still
> > missing various parts. I'm hoping that it will help me debugging the
> > drivers later. Also, QEMU runs linux at about double speed of the real
> > device on my desktop PC so it might speed up testing.
>
> Hey, that's cool!
>
> > Here is what I have got working so far, and what the patch contains:
> >
> >  - well, the processor: QEMU emulates an ARM 1026 but it turned out to
> > be similar  enough to the TI 925. I really only had to change the
> > identification numbers it returns to those of TI 925.
> >
> >  - some of the basic "MPU subsystems", that is:
> >  - the IRQ and FIQ generation from both level 1 and 2 banks of
> > interrupts (with the right peripherals connected to the right
> > interrupt lines.)
> >  - timers: the three general purpose MPU timers.
> >  - most of the configuration registers (actually many of them are only
> > dummies because the emulator doesn't care about things like voltages,
> > clocking schemes, or all the different types of caching.)
> >  - the shared GPIO lines plus the 16 MPUIO GPIOs (with the rest of the
> > peripherals connected to the right gpio pins like on my Palm.)
> >  - a keyboard connected through the MPUI keypad interface (the keymap
> > I used is not the one from the real device, it contains all the PC
> > keys. You can change that easily.)
> >
> >  - the OMAP DMA controller with 9 general channels and one dedicated
> > channel for the LCD -- seems to be working but as you can imagine,
> > it's difficult to emulate.
>
> Hehe!
>
> >  - the OMAP LCD controller with the QEMU display connected to it as
> > the actual LCD -- only tested with 8 bit colour, the penguin looks
> > fine.
> >
> >  - an SD card emulator according to the SD specification (for those
> > who don't know, SD cards have a whole little "computer" working in
> > each of them.) Implements some security features too.
> >
> >  - the OMAP MMC/SD host controller making use of the SD card emulator.
> > Also emulates the card eject event and insertion of new cards, and can
> > be accessed using either DMA or the registers. Unfortunately there's
> > still something wrong with it -- linux panics after a few requests
> > (but always reads the partition table fine), strange thing is that it
> > panics in the generic block driver when it's trying to allocate memory
> > for a new block of data from the card, not anywhere in MMC or OMAP
> > drivers.
(fixed already)
> >
> >  - the microwire ports (only tested with registers access, no dma.)
> >
> >  - a (part of the) TSC2301 chipset connected to the MPU using the
> > microwire port. Currently only has some of the internal logic plus the
> > touchscreen controller with the QEMU mouse input connected as the
> > actual touchscreen. TSC2301 can also control audio inputs and outputs,
> > a keypad (unused in Palm Tungsten E as the keypad is connected to the
> > MPUI interface), temperature (also unused) and battery state monitors
> > -- and these are not implemented.
> >
> >  - the OMAP RTC with alarm and stuff. Through it the VM can access the
> > host's clock.
> >
> > The patch is at http://www.zabor.org/balrog/qemu-omap.patch (160 kB).
> > The command line I use to launch QEMU is:
> >    $ qemu-system-arm -M omap310 -kernel ./zImage
> > You can add "-fda ./cardimage".
> > Note however that I implemented most parts according to the
> > documentation from ti.com (mostly OMAP 5910 docs) and not according to
> > what Linux needed to work. Therefore, where linux drivers accessed
> > non-existent (or undocumented) registers, or performed writes to
> > read-only registers, or wrote values prohibited by the docs, I
> > modified the kernel and not the emulator (and there was a number of
> > such places). So QEMU is likely to exit with something like "fatal
> > error: bad register access at ..." when you try booting Linux. In that
> > case it can be:
> >  - Linux drivers accessing non-existent registers, or
> >  - Linux accessing a peripheral that QEMU doesn't emulate yet (e.g. USB).
> > If that happens you can either fix the kernel or add dummy registers
> > in QEMU or make QEMU ignore bad register accesses whatsoever (that's
> > what the real device does). In the latter case, recompile kernel
> > without support for the given peripheral device.
> > I know that 310 is practically the simplest of OMAP boards because it
> > doesn't have a DSP core and lacks a couple of other things. Almost all
> > of the code can be reused for OMAP 1510 or 5910/5912 emulation though.
> > Emualting other boards would require more changes.
> > The patch is against QEMU 0.8.0 release. I have only tested it on a
> > Linux/PC as host -- I'm pretty sure it won't work on little-endian
> > machines (even though QEMU in general does work on PPC and other
> > archs). It contains a bootloader code for Linux/ARM copied from the
> > IntegratorCP board emulator by Paul Brook. It also contains pieces of
> > code from Anthony Liguori's patch for WACOM tablet emulation, that
> > enables QEMU reporting absolute coordinates (for the TSC2301
> > touchscreen).
> >
> > The purpose of this emulator was to help me fix a bug in the kernel
> > that causes linux userspace to be extremely unstable -- unfortuntaly
> > it turned out that the bug is not reproduced in the emulator,
> > everything works perfectly fine in it. The bug was already mentioned
> > on this list by X-Stranger
> > (http://linux.omap.com/pipermail/linux-omap-open-source/2006-February/006399.html).
>
> LOL, that's a lot of work to track down a bug :) Too bad it did not
> help. But at least there's an omap emulator now.
>
> > On the real device (Palm Tungsten E) kernel always boots fine but as
> > soon as userspace kicks in, programs will hang, segfault or fail
> > assertions (in case of glib based programs) to the point of being
> > unusable. A given program binary with a given kernel binary always
> > fails the same way and in the same moment of execution. However,
> > adding or removing a single instruction in either the kernel or the
> > program, changes the kind of error and the place where it happens
> > (sometimes fixes the problem or breaks new things) -- not depending on
> > the actual instruction that was added, more on the size of it and its
> > placement in the code.
> > Removing the accesses of non-existent registers from the kernel didn't
> > help as I hoped it would. Since owners of OMAP 1510 devices don't
> > report such problems and the emulator (based on 5910 docs) doesn't
> > exhibit the bug either, our conclusion is that the differences between
> > OMAP 310 and other boards are in the root of the bug. Alternatively,
> > it could be a bootloader problem (we use Garux on the PDA). If anybody
> > has an idea about what might be wrong, please tell.
>
> Sounds like you have already verified the memory timings. Does it work
> properly with caches disabled?
Unfortunately nope, for me at least. Except the slowdown, it changes
the places where the bug appears (i.e. where the programs break) but
it is because when I disable the caches in the config, it enables two
new instructions in head.S. Now, if I replace these two instructions
with any random instructions the result is the same.

The QEMU effort is not wasted I think :)  My new idea is to simulate
the Linux booting from the reset of the device, when it loads PalmOS
(which is the OS that comes with the device in a ROM) through the
Linux bootloader which then gradually unloads PalmOS and only then
jumps to the kernel. This will maybe allow me to find out what
registers is PalmOS messing with and reset those in the bootloader to
their default values because there is plenty of registers that Linux
doesn't touch when it's booting ( -- for example yesterday we found
out that on Zire 71 (a different PDA based on OMAP 310) the mpu
watchdog timer is always enabled in PalmOS and that was (correctly)
triggering mysterious resets of the device everytime Linux took over
the control -- until yesterday).
Regards,
Andrew
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: OMAP emulation

[tony]

* andrzej zaborowski <balrog@zabor.org> [060322 01:57]:
> On 20/03/06, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Sounds like you have already verified the memory timings. Does it work
> > properly with caches disabled?
> Unfortunately nope, for me at least. Except the slowdown, it changes
> the places where the bug appears (i.e. where the programs break) but
> it is because when I disable the caches in the config, it enables two
> new instructions in head.S. Now, if I replace these two instructions
> with any random instructions the result is the same.

Hmmm. And your root file system obviously is not corrupted and works
fine on other omaps?
 
> The QEMU effort is not wasted I think :)  My new idea is to simulate
> the Linux booting from the reset of the device, when it loads PalmOS
> (which is the OS that comes with the device in a ROM) through the
> Linux bootloader which then gradually unloads PalmOS and only then
> jumps to the kernel. This will maybe allow me to find out what
> registers is PalmOS messing with and reset those in the bootloader to
> their default values because there is plenty of registers that Linux
> doesn't touch when it's booting ( -- for example yesterday we found
> out that on Zire 71 (a different PDA based on OMAP 310) the mpu
> watchdog timer is always enabled in PalmOS and that was (correctly)
> triggering mysterious resets of the device everytime Linux took over
> the control -- until yesterday).

Yeah, it's really nice to have an omap emulator :)

Tony