ARM memory mapping: INT15 equivalent? Standard way to query memory map?

Question

On PC-architectures (where the presence of the BIOS and the usage of it is pretty much standardized), you can discover the size of the RAM memory, as well as its reserved/free for use regions by using the INT15 BIOS interrupt, function 0xE820.

Since I'm passionate about low-level programming and after programming Intel architectures for approximately 6 months, I decided I should try and learn how other architectures work. So I've started digging into ARM development. I've got 2 boards I'm currently working on: Olimex A20 OlinuXino-MICRO and Samsung Arndale's Exynos 5250. What I'm trying to do is to port a hypervisor I've developed for Intel architectures to these two boards. I am now in the stage of trying to programmatically detect the memory map of the system in a reliable and acceptably standardized way (I would prefer not to write entirely different code for different ARM boards). But so far, I find the relevant documentation to be a little bit confusing.

On the Olimex A20 I've got a Cortex-A7 ARM CPU. The PDF found here: http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf , which applies to Cortex-A7 and other CPUs, states at page 14 that the memory addressing space from 1GB-to-2GB is reserved for Memory-Mapped I/O devices, whereas the Olimex-A20 documentation found at this link https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A20-PDFs/A20%20User%20Manual%202013-03-22.pdf?raw=true states at page 21 that the memory addressing space from 1GB-to-3GB is DDR-II/DDR-III memory.

Am I simply confused or is there an inconsistency between these two documents?

score 1 · Accepted Answer · answered Oct 23 '13 at 11:21

1

The memory maps on ARM chips are highly chip-specific. There is also usually nothing like a BIOS, so your bootloader or hypervisor will have to figure out the memory layout on its own.

Generally you'd need to work with the SDRAM controller to query and initialize the installed SDRAM chips. This is a non-trivial and, once again, very chip-specific process. You should check the code of bootloaders (e.g. U-Boot) you have available for your chips and look for the memory init code.

However, in many of cases, the memory "map" (start of RAM and its size) is simply hardcoded for each board the bootloader is ported to, since it's unlikely to change at every boot.

answered Oct 23 '13 at 11:21

Igor Skochinsky

24,629
2
72
109

that sounds very discouraging..isn't there at least a standard way to programmatically discover the board-type? – Zuzu Corneliu Oct 23 '13 at 11:27
Yes and no. There is a standard where the bootloader passes a [machine number](http://www.arm.linux.org.uk/developer/machines/) into the kernel in a specific register, which is used on Linux to build somewhat generic kernels; the kernel still needs to have a list of supported board types and their characteristics. – Simon Richter Oct 23 '13 at 11:47
so instead of relying on hardware for standardization, I'll have to rely on software. Question: one talks of "standards" when referring to an **interface** implemented by a **typically BROAD** set of targets. Is there a software-standard that is implemented by an acceptably broad set of ARM devices/boards and that fits my needs? I'm now using U-Boot for both boards. Is this boot-loader worth-using if I want to implement a hyper-visor that can easily be ported on a broad range of ARM boards? I need an interface to detect the **memory map** AND **the specifics of the hardware configuration**. – Zuzu Corneliu Oct 23 '13 at 12:48
I'm afraid there's nothing like that, except maybe UEFI/ACPI (which is very heavy). I'd say don't worry about it at this point. First make it work on your hardware, then think about porting. – Igor Skochinsky Oct 23 '13 at 13:39
You're right, it's too early to think about it. I hoped to find a satisfactory answer regarding this before I really start to write the code, since it would have made development much easier. Thank you both for helping! – Zuzu Corneliu Oct 23 '13 at 14:05

score 0 · Answer 2 · answered Nov 27 '13 at 15:18

Historically ARM boot-loaders pass information to the Linux kernel using ATAG structures as desribed in Booting ARM Linux. At a minimum the boot-loader is expected initialize the RAM in the system and pass ATAG_MEM structures to describe where the RAM lives in the address space. Interpreting these structures would give you some of the information you need but it doesn't tell you anything about any peripheral devices. In this booting method the machine type is used to trigger platform specific code to initialize the rest of the hardware.

The new way of doing this is through the Flattened Device Tree. The device tree originated with OpenFirmware and besides describing the RAM mapping can also describe the rest of the hardware and peripherals.

ARM memory mapping: INT15 equivalent? Standard way to query memory map?

2 Answers2