On 08/02/2011 04:28 PM, Peter Maydell wrote:
On 2 August 2011 21:56, Anthony Liguori<anth...@codemonkey.ws> 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.
Yes, that's a feature not a bug.
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
So you basically have a OMAP3 SOC bus. You can't connect devices
directly to it, you need some sort of bridge to bridge existing devices
to this bus.
It's no different than something like ISA on the classic PC.
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.
So I think the modelling disconnect here is that you're trying to model
the wire connections to hook up arbitrary devices to a OMAP SOC.
Unless you're modelling each pin (which I don't think you're doing), I
think it makes more sense to treat this as a bus and model accordingly.
Regards,
Anthony Liguori
-- PMM
