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
