Many ARM SoCs have memory as MMIO. However, I have seen other ARM processors that support (like x86, et. al.) the ability to program the memory controller and move this mapping.

Is this a SoC-dependent feature? Or is the ability linked with a particular ARM core IP? The the ability linked with a certain ARM core tier and above (for instance, all Cortex-A)? Or is it up to the SoC vendor to decide if remapping is supported in their Memory Controller?

Specifically, because I am working with A series:

  • Is memory remapping supported on Cortex-A and later?

I want to run some firmware that has memory mapped into a location that is not supported by the specific SoC I have, so I was curious to see if it can be moved.


Fundamentally, I think the question I am asking is whether or not the presence of an MMU/Memory Controller implies the ability to remap the physical addresses of DRAM like you can on x86 hardware.

  • 1
    \$\begingroup\$ MMU (if you are referring to it) is an integral part of any Cortex-A core. \$\endgroup\$ – Eugene Sh. Mar 5 at 18:29
  • \$\begingroup\$ I'd expect that in specific would be possible if the firmware were willing to run entirely in the context of virtual addresses, but you may face larger problems getting a "firmware" to run on the wrong hardware. It might make more sense to run it in a virtual machine (yes, you can run qemu on arm hardware) or to analyze and modify the binary to alter the occasional absolute addresses, along with figuring out whatever other issues there may be. \$\endgroup\$ – Chris Stratton Mar 5 at 18:30
  • \$\begingroup\$ yup, for example the second paragraph of the wikipedia article on the Cortex-A core says that and cites sources. \$\endgroup\$ – Marcus Müller Mar 5 at 18:31
  • \$\begingroup\$ @EugeneSh. Of course, but can it be reprogrammed is what I am wondering. That is to say, can the base address of physical memory be mapped to something other than the default on power up. You can do this on x86. \$\endgroup\$ – sherrellbc Mar 5 at 18:53
  • \$\begingroup\$ @ChrisStratton I was wondering if the use of an MMU implied the ability to relocate physical memory. I know this can be done with VM. And yes, of course. The intent is to develop an understanding of what does and does not work (via traps into the hypervisor) as the firmware runs. I do not expect it to just work out of the box. \$\endgroup\$ – sherrellbc Mar 5 at 18:54

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.