On 15 September 2017 at 21:41, William Mahoney <wmaho...@unomaha.edu> wrote:
> 3) Can of worms. The 5282 allows you to move the base address > of the control registers, the start address of the SRAM, all > sorts of things. The control registers are all offset from a > default address when the chip is reset but in theory the code > can come along and say “well from now on the base address for > the control registers is so-and-so”. In the startup code, > there’s those calls such as “memory_region_allocate_system_memory” > and “…add_subregion” and so on. What happens if after a system > starts and is being emulated, we need to move the regions or > subregions? You can rearrange things at runtime if you need to. You basically need to keep hold of a pointer to the MemoryRegion (typically by having them owned by some device or other which is also the thing with the control registers), and then you can enable/disable/map/unmap etc as required. Depending on exactly what the level of control provided is, this task may be made easier by adding in suitable "container" memory regions, so you can just move or the entire container (which automatically moves all the regions inside it) rather than moving multiple individual regions. > So also, philosophically you might say, does a qemu for a new > target emulate everything that the chip can do, or only what’s > needed for, say, Linux? Our general principle is that it should start with enough to do something useful, but it doesn't have to have complete functionality. You may find create_unimplemented_device() useful as a way to stub out things you don't provide -- it allows the user to turn on logging of when the guest accesses them. thanks -- PMM