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
