[Qemu-devel] PL353 Device model

[Qemu-devel] PL353 Device model

[Peter Crosthwaite]

Hi Everyone,

We currently have a somewhat hacky PL353 device model in our tree that
we wish to refactor and ultimately push to mainline. Before I go about
reworking it, I wish to discuss the architecture of this device model
because its non-trivial. The pl353 is sysbus slave that is a combined
NAND flash + parallel flash interface. The two interfaces are
independent of each other. Currently, we pretty much ignore the pflash
interface completely (and its just a bunch of stubs that effectively
nop) and leave the instantiation of the backing device up to the
machine model using pflash_cfi_02_register():  (from xilinx_zynq.c)

    pflash_cfi02_register(0xe2000000, NULL, "zynq.pflash", FLASH_SIZE,
                          dinfo ? dinfo->bdrv : NULL, FLASH_SECTOR_SIZE,
                          FLASH_SIZE/FLASH_SECTOR_SIZE, 1,
                          1, 0x0066, 0x0022, 0x0000, 0x0000, 0x0555, 0x2aa,
                              0);

With the straight SRAM style pflash interface, for 95% functionality
there is no need to model the pl353 controller that sits in-between
the bus and the device. Effectively the pflash behind the 353 is
attached straight to the top level sysbus by the machine model. Is
this flawed or should there be some sort of straight pass-through in
the 353 device model? The 353 also has an interface for indirectly
issueing commands to the device, which is not supported, as due to the
architecture the pflash is actually invisible to the device model. To
resolve this should the SRAM pflash interface be a qemu bus-standard
in its own right? Alternatively should the PL353 create a memory
subregion for its sram interface using the memory API?

Onto the NAND flash, we currently have the 353 directly instantiating
a NAND flash chip but im thinking this is the responsibility of the
machine model, not the device model. I.E. the machine should
qdev_create both the controller and nand flash chip and connect the
two. This would perhaps be best achieved by making the standard nand
flash interconnect (ONFi) a bus standard as well?

Please let us know what you think.

Regards,
Peter

Re: [Qemu-devel] PL353 Device model

[John Williams]

On Fri, Mar 30, 2012 at 5:13 PM, Peter Crosthwaite
<peter.crosthwaite@petalogix.com> wrote:

> We currently have a somewhat hacky PL353 device model in our tree that
> we wish to refactor and ultimately push to mainline. Before I go about
> reworking it, I wish to discuss the architecture of this device model
> because its non-trivial.

Ping..

We'd really appreciate some feedback on this to avoid the duplicated
effort we are seeing in other areas such as SPI.

Thanks,

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [Qemu-devel] PL353 Device model

[Andreas Färber]

Hello John,

Am 05.04.2012 01:35, schrieb John Williams:
> On Fri, Mar 30, 2012 at 5:13 PM, Peter Crosthwaite
> <peter.crosthwaite@petalogix.com> wrote:
> 
>> We currently have a somewhat hacky PL353 device model in our tree that
>> we wish to refactor and ultimately push to mainline. Before I go about
>> reworking it, I wish to discuss the architecture of this device model
>> because its non-trivial.
> 
> Ping..
> 
> We'd really appreciate some feedback on this to avoid the duplicated
> effort we are seeing in other areas such as SPI.

Generally speaking, the qdev busses (i.e., tree-style) are scheduled to
die out in favor of DAG-style QOM. However that's not going to happen
for 1.1 yet, so if there's a need for a new SPI bus it needs to be qdev.

As for the desired cascading here, my idea would be to make both flash
interfaces child<>s of the controller, arranging their MemoryRegions so
that (if applicable) they become subregions and can be toggled by the
controller.

My .02 AUD,

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] PL353 Device model

[Peter Crosthwaite]

Thanks for you thoughts Andreas,

On Thu, Apr 5, 2012 at 9:56 AM, Andreas Färber <afaerber@suse.de> wrote:
> Hello John,
>
> Am 05.04.2012 01:35, schrieb John Williams:
>> On Fri, Mar 30, 2012 at 5:13 PM, Peter Crosthwaite
>> <peter.crosthwaite@petalogix.com> wrote:
>>
>>> We currently have a somewhat hacky PL353 device model in our tree that
>>> we wish to refactor and ultimately push to mainline. Before I go about
>>> reworking it, I wish to discuss the architecture of this device model
>>> because its non-trivial.
>>
>> Ping..
>>
>> We'd really appreciate some feedback on this to avoid the duplicated
>> effort we are seeing in other areas such as SPI.
>
> Generally speaking, the qdev busses (i.e., tree-style) are scheduled to
> die out in favor of DAG-style QOM. However that's not going to happen
> for 1.1 yet, so if there's a need for a new SPI bus it needs to be qdev.
>
> As for the desired cascading here, my idea would be to make both flash
> interfaces child<>s of the controller,

Ok, i think step one is getting that pflash interface off the main
memory region then and having it in the device model. Two approach to
machine setup here tho, should the machine model hand off the flash
device to the pl353 is some way, or should the pl353 expose that
subregion to the machine model? Im personally thinking the former?

 arranging their MemoryRegions so
> that (if applicable) they become subregions and can be toggled by the
> controller.

One thing to consider tho, that there currently is no SRAM style NAND
implementation like there is for pflash, so the nand flash memory
region would be implemented from withing the pl353 itself. Basically
the pl353 would be talking to itself using mem api if you wanted to
get that kind of symmetry between the two interfaces.

Regards,
Peter

>
> My .02 AUD,
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg