gwj / at91sam9263 · Commits

Only very simple emulation of the LCD controller is included.

The controller features the standard HD44780 interface and supports character
output on four lines using a static 5x7 font and optional backlight controlled
by signal on a separate pin.

Capabilities such as custom characters, cursor and 5x10 fonts are not
implemented. Saving/loading of device state is not implemented either.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

The board scheme is available at
http://support.dce.felk.cvut.cz/e-kurzy/file.php/19/cviceni/Schema.pdf

Only the AT91SAM7X microcontroller, rotary encoder, matrix keyboard and
their connections are implemented.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

The Ethernet controller is implemented as a device on the system bus. It uses
DMA to read and write data from the main memory for packet queues.

Most of the controller features are implemented with the following exceptions:
- Statistics and related registers
- Support of VLAN tags
- Support for transmitting jumbo frames
- Recognizing of MAC addresses by a hash function

The emulation is based on the AT91SAM7X specification and also supports
registers present in the older AT91RM9200 controller - notably the TAR
register for sending a single frame by writing a physical memory
address into it.

EMAC also provides management interface for directly talking to the PHY chip.
The emulation of PHY chip is currently hard-coded in the EMAC emulation and
behaves as a DM9161 chip. Only few registers of the PHY chip are implemented.
Nevertheless it's enough to run the Atmel examples and even FreeRTOS demos.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

Only the timer part of the the Timer/Counter block is implemented since there
is no interface for connection of external clocks in QEMU, so there is nothing
to measure. The minimal implementation is done using host timers and an
internal counter.

This implementation is sufficient for running the Atmel examples,
but leaves a lot to be desired.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

The system controller in AT91 is composed of several devices and they are all
connected to single IRQ pin on the Advanced Interrupt Controller. This pseudo-
device allows multiplexing an IRQ pin by sending logic OR of all the inputs
to a single output pin.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

This patch introduces emulation of the AT91 reset controller. The behavior
and external interface to the reset controller is not emulated though and
only the features necessary to start the system are implemented.

Internal registers are maintained and partially emulated. The NRST status
bit is always asserted, even if a command to de-assert it is written
to the control register.

This emulation is sufficient to support running FreeRTOS and a sample code
from Atmel.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

This patch implements the RTT used on AT91 microcontrollers. All documented features are implemented.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

This patch implements the PIT used on AT91 microcontrollers. All documented features are implemented.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

This patch implements the GPIO controller used in the AT91 microcontrollers.

PIO controller is implemented as a device on the system bus with 3 sets of 32
input/output pins and one IRQ pin. The first set of the 32 I/O pins is used for
connections to external devices and the other two are used for pass-through
connections of external pins to internal peripherals.

Internal pull-up resistors are implemented by simulating the input value of 1
for every input pins where the value of the pin is unknown (a device is not
connected) or where explicit -1 constant was sent by the external device
emulation (a device is connected, but the wire is not) on the GPIO pin.

Unimplemented features are correct emulation of open-drain mode and
glitch-filter.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

The debug unit is implemented as serial character device hosted on the system
bus. Only the most basic features are emulated to allow capturing the output
and receiving external input. No actual timing is emulated based on the baud
rate register, although the information is passed to the backend driver using
the qemu_chr_ioctl API.

A two-byte FIFO transmission register, channel mode (normal, local feedback,
remote feedback) and in-circuit emulator (ICE) pins are not emulated. Emulating
the first two features would be straightforward. Emulating the ICE
communication is possible, but changes to CPU emulation are required to
accomplish it. The benefits for debugging would probably not be very high since
the built-in QEMU debugger is much more powerful.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

The isolated behavior of PMC is emulated completely, but the effects on other
parts of the system are not. Since QEMU lacks any API for proper modeling of
the system and peripheral clocks, the actual enabling and disabling of clocks
has no effect on the emulated system.

The master clock frequency is exposed using a global variable for use by other
system components, such as timers.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

Emulation of AIC has 32 input pins corresponding to the input interrupt sources
and two output pins corresponding to the IRQ and FIQ pins on the processor. All
features of the controller with the exception of external interrupt handling
are emulated according to the documentation. This includes emulation of the
debug register, edge and level triggered interrupts, software interrupts and
interrupt nesting.

External interrupt handling is not implemented because it differs between
various AT91 family microcontrollers in the number of externally exposed pins.
The only feature of the external interrupt processing that is not implemented
is inverting the level of input signal. Should the need arise, adding proper
implementation of external interrupt logic shouldn't be hard.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

This patch introduces an emulation of the standard 4x4 matrix keyboard that
could be connected to GPIO controller.

It doesn't emulate any pull-up resistors connected to the wires and depends on
the GPIO controller for their emulation. This requires the GPIO controller to
support the notion of special -1 value on the GPIO pins, which signals that
the wire is currently disconnected.

The emulation of keys is implemented through standard QEMU keyboard emulation
capabilities. An individual key mapping is specified using a device property
"keys", which should be set to array of 16 bytes where each byte corresponds
to scan code of the key.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

This patch introduces an emulation of the rotary encoder that could be connected
to GPIO controller.

An internal state is maintained with the values of the output pins. When a key is
pressed the state is modified accordingly and the information is signaled on the
output pins.

Key mappings are specified by the "key-left" and "key-left-alt" properties for a
counter-clockwise direction and "key-right" and "key-right-alt" for a clockwise
direction.

Signed-off-by: Filip Navara <filip.navara@gmail.com>

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>

Read of interrupt register should clear it and also sequence step and status.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>

Once again, the emulation of the EERD and ICS registers in e1000.c is
incorrect. Nobody has noticed this before because none of the Intel-written
e1000 drivers use these registers, and all of the independently written open
source drivers copy Intel's example, so they don't use them either.
Regardless, these registers are documented in the programmer's manuals, and
their emulated behavior doesn't match the verified behavior of real hardware,
so any software that does use them doesn't function correctly.

-Bill

Signed-off-by: Bill Paul <wpaul@windriver.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

When a VM state change handler changes VM state, other VM state change
handlers can see the state transitions out of order.

bmdma_map(), scsi_disk_init() and virtio_blk_init() install VM state
change handlers to restart DMA.  These handlers can vm_stop() by
running into a write error on a drive with werror=stop.  This throws
the VM state change handler callback into disarray.  Here's an example
case I observed:

0. The virtual IDE drive goes south.  All future writes return errors.

1. Something encounters a write error, and duly stops the VM with
   vm_stop().

2. vm_stop() calls vm_state_notify(0).

3. vm_state_notify() runs the callbacks in list vm_change_state_head.
   It contains ide_dma_restart_cb() installed by bmdma_map().  It also
   contains audio_vm_change_state_handler() installed by audio_init().

4. audio_vm_change_state_handler() stops audio stuff.

5. User continues VM with monitor command "c".  This runs vm_start().

6. vm_start() calls vm_state_notify(1).

7. vm_state_notify() runs the callbacks in vm_change_state_head.

8. ide_dma_restart_cb() happens to come first.  It does its work, runs
   into a write error, and duly stops the VM with vm_stop().

9. vm_stop() runs vm_state_notify(0).

10. vm_state_notify() runs the callbacks in vm_change_state_head.

11. audio_vm_change_state_handler() stops audio stuff.  Which isn't
   running.

12. vm_stop() finishes, ide_dma_restart_cb() finishes, step 7's
   vm_state_notify() resumes running handlers.

13. audio_vm_change_state_handler() starts audio stuff.  Oopsie.

Fix this by moving the actual write from each VM state change handler
into a new bottom half (suggested by Gleb Natapov).

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

These are now unused.

However, perhaps the idea is that when we add -device, they will be
useful? In that case, we should add virtio-net-pci-0-10 too.

Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

We have the pc-0.10 machine type now which does exactly the same
thing.

Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

I don't think it's critical to do this, but it's
best to keep uninit and error recovery consistent.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Follow on patch will use it to determine the size of the MADT and
other BIOS tables.

Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

This patch addresses the problems found by Andriy Gapon:

- The code was incorrectly overwriting the high order 32
  bits of the timer and hpet config registers. This didn't show up
  in testing because linux and windows use hpet in legacy mode,
  where the high order 32 bits (advertising available interrupts)
  of the timer config register are ignored, and the high order 32
  bits of the hpet config register are reserved and unused.

- The mask for level-triggered interrupts was off by a bit. (hpet
  doesn't currently support level-triggered interrupts).

In addition, I removed some unused #defines, and corrected the ioapic
interrupt values advertised. I'd set this up early in hpet development
and never went back to correct it, and no bugs resulted since linux and
windows use hpet in legacy mode where available interrupts are ignored.

Signed-off-by: Beth Kon <eak@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Demo QemuOpts in action ;)

Implementing a alternative way to specify the filename should be
just a few lines of code now once we decided how the cmd line syntax
should look like.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

cleanup pretty simliar to the drives_table removal patch:
 - drop the table and make a linked list out of it.
 - pass around struct pointers instead of table indices.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

First step cleaning up the drives handling.  This one does nothing but
removing drives_table[], still it became seriously big.

drive_get_index() is gone and is replaced by drives_get() which hands
out DriveInfo pointers instead of a table index.  This needs adaption in
*tons* of places all over.

The drives are now maintained as linked list.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Hook i44fx pcihost into sysbus.
Convert Host bridge and ISA bridge pci devices to qdev.
Tag as no-user.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

This patch implements a parser and qdev tree walker for bus paths and
adds qdev_device_add on top of this.

A bus path can be:
  (1) full path, i.e. /i440FX-pcihost/pci.0/lsi/scsi.0
  (2) bus name, i.e. "scsi.0".  Best used together with id= to make
      sure this is unique.
  (3) relative path starting with a bus name, i.e. "pci.0/lsi/scsi.0"

For the (common) case of a single child bus being attached to a device
it is enougth to specify the device only, i.e. "pci.0/lsi" will be
accepted too.

qdev_device_add() adds devices and accepts bus= parameters to find the
bus the device should be attached to.  Without bus= being specified it
takes the first bus it finds where the device can be attached to (i.e.
first pci bus for pci devices, ...).

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Create a default bus name if none is passed to qbus_create().

If the parent device has DeviceState->id set it will be used to create
the bus name,. i.e. -device lsi,id=foo will give you a scsi bus named
"foo.0".

If there is no id BusInfo->name (lowercased) will be used instead, i.e.
-device lsi will give you a scsi bus named "scsi.0".

A scsi adapter with two scsi busses would have "scsi.0" and "scsi.1" or
"$id.0" and "$id.1" busses.  The numbers of the child busses are per
device, i.e. when adding two lsi adapters both will have a "*.0" child
bus.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Put the new property into use.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

So we can parse "$slot.$fn" strings into devfn numbers.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>