Re: [Qemu-devel] modelling omap_gpmc with the hierarchical memory API

[Peter Maydell]

On 2 August 2011 21:56, Anthony Liguori <address@hidden> wrote:
> Hrm, this looks like badness to me.
>
> You're effectively using MemoryRegions to implement an ad-hoc interface.

As you'll see below, the hardware intreface is somewhat ad-hoc :-)

>  This is not what MemoryRegions are meant to do though.  You want something
> like:
>
> class WhateverDevice : public Device, implements SimpleDevice
> {
>   MemoryRegion *get_memory_region(void);
> };
>
> class OmapGmc : public Device
> {
>   SimpleDevice *slots[8];
> };
>
> In qdev of today, you should implement something other than SysBus as a base
> class and make OmapGmc a bus.

Doesn't this then preclude connecting the memory region of an
existing sysbus device model into the OmapGpmc bus? After all,
it wouldn't be implementing SimpleDevice.

> What's the relationship between the omap_gpmc and the devices in real
> hardware?  Are the devices designed to connect to the GPMC explicitly via a
> common set of pins?  Is there an intermediate bridge chip or something?

The external interface (ie the one to the outside of the OMAP3 SOC,
into which a board can wire devices) looks like this:

 gpmc_a[10:1]   output    Address (note no bit zero!)
 gpmc_d[15:0]   i/o       Data
 gpmc_ncs[7:0]  output    Chip selects
 gpmc_nadv_ale  output    Address valid (or address latch enable for NAND)
 gpmc_noe_nre   output    Output enable (or read enable for NAND)
 gpmc_nwe       output    Write enable
 gpmc_nbe0_cle  output    Lower byte enable (also command latch enable for NAND)
 gpmc_nbe1      output    Byte 1 enable
 gpmc_nwp       output    Write protect
 gpmc_io_dir    output    gpmc_d[15:0] direction control (input vs output)

...which you can then use in a number of different modes by programming
the GPMC appropriately:
 * multiplexed address-and-data NOR-like device:
   gpmc_d[15:0] are a 16 bit data bus and also used for addressing:
   gpmc_a[10:1] + gpmc_d[15:0] together give an address bus A26..A1
   (no A0, so you can't byte-address, only 16-bit-word address)
 * non-multiplexed NOR like device:
   gpmc_d[15:0] are a 16 bit data bus only
   gpmc_a[10:1] are A10..A1 address bus (again, no A0)
 * 16 bit NAND device wired up to gpmc_d[15:0], with the NAND
   control pins being gpmc_nadv_ale etc as above
 * 8 bit NAND device, as 16 bit NAND but only using gpmc_d[7:0]

Assuming we aren't going to actually try to model this at a pin
level, this disentangles into talking to one of two interfaces:
 * a NAND device (which at the moment nand.c implements via
   nand_setpins/nand_getpins/nand_setio/nand_getio)
 * a random addressable memory region

Typically in the latter case the device we're talking to will
also provide some gpio or irq signals, which will be routed in
a totally different direction having nothing to do with the GPMC.
So it's important that we should be able to take an existing
device model and route its registers through the GPMC and its
GPIO elsewhere.

-- PMM