Re: [Qemu-discuss] Coldfire 5282 Support

[Peter Maydell]

On 15 September 2017 at 21:41, William Mahoney <address@hidden> 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