The MMU wouldnt be all that useful if the map was static at boot. Not for running an operating system for example. Has nothing to do with ARM Cortex-A or an X86 or other general purpose operating system capable processor.
The MMU operates on tables in ram, the point is you can re-map the MMU on the fly. How do you think every application you build for an operating system loads into and runs at the same address? While you are looking at this web page, and the clock in the corner is changing time that the web browser program is dumped out of memory to disk the clock program is brought in and then vise versa in a way we cant detect?
No depending on the design of the MMU the table can either be driven by a virtual id that is assigned to a program/task/thread and that id is used to determine which table the mmu uses to map the virtual to physical. more likely the id is used for protection, the mmu also might include a feature that allows for a table entry to be tied to a virtual id if the access for that transaction did not come from that virtual id (the application running) then a fault is generated and handled by the operating system.
With a single threaded processor a single core switches applications the operating system ideally has designed the mmu tables such that a single entry has to change or a single register points at the beginning of the table for that thread. This can be happening at fractions of a second. The tables and thus the overall virtual to physical map of the address space is in constant flux.
this is how each application can think it is starting at the same address as every other application, but really isnt on the physical side.
When you allocate memory it is not like the pre-mmu days you dont necessarily have to have that much linear physical memory available, depending on the mmu design and the design of the tables by the operating system authors, fragments of memory can be joined together to make a linear virtual address space. as you alloc or free memory the mmu tables are changing for your application.
so yes they not only can but do change the tables, very often.
DRAM is only one portion of the address space of a processor. When you are dealing with purchased IP like a cortex-a arm doesnt necessarily dictate too many rules about the address space (the cortex-ms have more rules) so one design dram could be here another cortex-a design dram could be mapped there. One design the usb controller here, another the usb controller there (the mmu for a useful system like these also needs to have cache controls, when talking to a peripheral you do not want the status registers cached, but for dram you might, so the system level design needs to deal with this likely part of the mapping of space by a kernel driver). So think more along the lines of the whole address space is mappable not just dram. The cortex-a and others may have internal registers in the processors address space and those in older arms are mapped based on strap pins on the core that you tell the arm where its own address space starts, other designs may dictate that a specific address space will never hit the axi bus, I dont remember if any of the cortex-a works like the latter.
the cortex-a is a core, not a system. Think of the english language being used to write a biology text book and a math text book. Same language completely incompatible chapters, cant pull one out and put it in the other. Unless abstracted for example a printf("Hello World"); program compiled for linux on arm. it is unlikely that firmware will translate from one cortex-a based chip to another, so if the target doesnt accept your firmwares address there exists the possibility that if it did the firmware wouldnt work anyway. If the firmware relies on an address space but is bare metal and doesnt run on an operating system and does not use the mmu in any way, then you can use the mmu to map the memory space the application is using to mimic the system it was written for. but dont expect it to work. It depends heavily on what this code is doing and talking to.
