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

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/02/2011 04:28 PM, Peter Maydell wrote:
> On 2 August 2011 21:56, Anthony Liguori<anthony@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
>