Re: [Qemu-devel] [RFC v2] arm: Add NRF51 SOC non-volatile memory controller

[Steffen Görtz]

Hello Peter,

thank you for your very elaborate remarks!
>  [ CPU ] -+- [ NVM, either FICR, UICR or CODE ]
>           |      |
>           \- [ NVMC ]
> 
> where the CPU can talk to either the NVMC or the NVMs, and the
> NVMC also has a control connection to the NVM. (See the block
> diagram in the nRF51 manual.)
> 
> The behaviour this allows is:
> 
>  * the CPU can directly read and execute from the NVMs (which it
>    can see in its address space at 0x00000000, 0x10000000, 0x10001000)
>  * the NVMC controls whether the CPU can write to the NVMs. If the
>    NVMC CONFIG register permits writes then the CPU writes directly
>    to the mapped NVMs, and gets the usual flash-memory behaviour that
>    writes can turn 1s to 0s but not 0s to 1s.
>  * the NVMC also has support for performing erases of either pages
>    or entire NVMs (which writes them to all-1s)
> 
> My suggestion for the best way to model this is:
> 
>  * the NVMs are (sysbus) devices which expose a MemoryRegion which
>    they have created with memory_region_init_rom_device().
>    MRs of this sort can be directly read (from a ram block), but
>    writes always go via a MemoryRegionOps write function. This
>    will let us do fast execution and reading, but catch writes so
>    we can make them behave correctly (be forbidden, not allow
>    writing of 0->1, etc).

In the latest revision of my NVMC model i included the FICR/UICR as
sysbus devices which expose a memory region using
memory_region_init_device. I can change this using init_rom_device for
performance. Furthermore i will add the CODE device.

I would like to provide all four devices (NVMC, CODE, FICR, UICR) from
one module and rename nrf51_nvmc.[ch] to nrf51_nvm.[ch]. Is this
acceptable or would you rather prefer three modules?

>  * the NVMs should implement a QOM interface that defines
>    how we model the "control connection" from the NVMC --
>    basically this will have some methods for "erase all",
>    "erase this page", and "set the writes permitted flag".
>  * the NVMC should have QOM link properties for its NVMCs, and
>    the SoC code sets those link properties to pointers to the
>    NVMCs
>  * the NVMC implements an ordinary IO MemoryRegion for its
>    register interface; guest writes to the registers may cause
>    it to tell the NVMs what to do by calling methods on the
>    NVMs (which it has pointers to via the link properties)
>  * the SoC code maps the NVMs and the NVMC's registers into
>    the right places in its address space

Thank you for these remarks, i will follow them.

Steffen