How to determine RAM size for aarch64

[ababo]

I plan to write a simple OS which can run on both x86_64 and aarch64 CPU architectures. At the current phase I need to write a memory manager so I have to find a reliable way of memory detection. It's not a problem for x86_64 since I can use a memory map provided by GRUB. But I currently have no idea how to detect memory on aarch64.

At the moment I program for generic aarch64-device emulated by QEMU ('-machine virt'). In future I'll decide which concrete device I'll support (the decision will be based on its popularity, maybe it will be the DragonBoard 410c).

So how can I reliably detect memory for aarch64?

P.S. I've found a source code which describes the memory map for QEMU virt-device (http://git.qemu.org/?p=qemu.git;a=blob; ... =HEAD#l112). The only thing I need to find is a RAM size.

[Octocontrabass]

There is no generic way to detect memory for any particular CPU architecture. You must read the documentation for your target hardware to determine the appropriate detection method.

This also applies to x86: the BIOS and UEFI memory maps are only available on PCs, and won't work on other x86-based hardware.

[ababo]

There is a Linux port running on qemu-system-aarch64 (-machine virt). How does it check the size of available RAM?

[jnc100]

ARM32 uses ATAGs to convey information regarding memory ranges to Linux kernels. This has been superseded in ARM64 by the use of the 'flattened device tree', however alternatives also exist including UEFI and ACPI implementations for ARM64 and the fallback method of pre-programmed memory ranges in your bootloader which are defined per-board. I believe the qemu virt machine implementation uses these with the fdt address in R2. You can see it building the fdt in qemu/hw/arm/virt.c.

Regards,
John.

[ababo]

Unfortunately all the registers seem to be cleared after startup.

[Nable]

AFAIK, QEmu passes ATAGs via registers only when you boot the kernel via "-kernel" argument. On real hardware some bootloader (such as U-Boot) prepares this information and passes to kernel in the same way.

[ababo]

I use '-kernel' option, but all the registers are cleared during startup.

P.S. Here is my code: https://github.com/ababo/arwen

[jnc100]

AFAIK, QEmu passes ATAGs via registers only when you boot the kernel via "-kernel" argument. On real hardware some bootloader (such as U-Boot) prepares this information and passes to kernel in the same way.

Thanks, yes, the -kernel option is indeed required to pass the fdt information.

I use '-kernel' option, but all the registers are cleared during startup.

I've just tried a stub kernel (simply a continuous loop) on qemu-system-aarch64 2.4.50. If you use the monitor, I get R0=0, R1=ffffffff, R2=44000000, and if you examine 0x44000000 (xp /4bx 0x44000000) you indeed get the fdt magic number (0xd0 0x0d 0xfe 0xed).

P.S. Here is my code: https://github.com/ababo/arwen

I can't quite see in your arm64 code where you are preserving (or even testing) R2 prior to jumping to the Rust code (which presumably trashes it somewhere).

Regards,
John.

[ababo]

Very simple to verify: just add the following line after __start label:

Code: Select all

CBNZ x2, __halt

and you'll see that the x2 register is cleared before startup.

I believe that it works for ARM32, but my question is about ARM64.

[Nable]

I've tried searching for aarch64 registers and this is what I've found:
https://www.kernel.org/doc/Documentatio ... ooting.txt

Code: Select all

- Primary CPU general-purpose register settings
  x0 = physical address of device tree blob (dtb) in system RAM.
  x1 = 0 (reserved for future use)
  x2 = 0 (reserved for future use)
  x3 = 0 (reserved for future use)

It looks like ATAGs are deprecated on aarch64 and it's time to learn about DTB. I didn't use it before, sorry.

Note that bootloader does something with secondary CPUs (if they are present), you can find it in the end of booting.txt.

Code: Select all

- Secondary CPU general-purpose register settings
  x0 = 0 (reserved for future use)
  x1 = 0 (reserved for future use)
  x2 = 0 (reserved for future use)
  x3 = 0 (reserved for future use)

[jnc100]

and you'll see that the x2 register is cleared before startup

It only provides the information if it thinks your kernel is Linux. Using an ELF kernel in particular will cause it to omit setting the registers. The simplest way is probably to use a uboot format using their mkimage tool.

Regards,
John.