arch/arm64: implement up_addrenv_va_to_pa()

[royzah]

Why

https://github.com/apache/nuttx/blob/master/include/nuttx/arch.h declares up_addrenv_va_to_pa(), but only armv7-a implements it. A driver whose device addresses memory physically has nothing to call on arm64.

How

AT S1E1R, so the answer comes from the MMU rather than a software walk: any granule, block or page, at any level, and it cannot drift from the tables in use.

Point
PAR_EL1 is one register per CPU	nothing may run between the translation and the read, so interrupts are masked across five instructions. They are banked with it, so SMP needs nothing more
unmapped returns zero	per the declaration. https://github.com/apache/nuttx/blob/master/arch/arm/src/armv7-a/arm_physpgaddr.c returns the address unchanged instead, worth settling
built only when CONFIG_DEV_SIMPLE_ADDRENV is off	https://github.com/apache/nuttx/blob/master/drivers/misc/addrenv.c defines the same entry point, and ten qemu-armv8a configs select it

up_addrenv_pa_to_va() is untouched: there is no reverse of AT.

Tested

Booted qemu-armv8a:knsh, the config closest to this: BUILD_KERNEL, ARCH_ADDRENV, ARCH_USE_MMU.

VATOPA kernel data va=0x402bc080 pa=402bc080
VATOPA kernel text va=0x4028645c pa=4028645c
VATOPA unmapped pa=0 (want 0)
VATOPA offset preserved: yes

That board maps flat, so the first two would also pass for a stub returning its argument. The third is what separates them.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[royzah]

Ran it, rather than only building it.

qemu-armv8a:knsh is the closest config in tree to what this is for: CONFIG_BUILD_KERNEL, CONFIG_ARCH_ADDRENV and CONFIG_ARCH_USE_MMU, and it does not select CONFIG_DEV_SIMPLE_ADDRENV, so this file is the one built. A probe in board_late_initialize(), on QEMU 11.1.0 with -cpu cortex-a53 -smp 4:

VATOPA kernel data va=0x402bc080 pa=402bc080
VATOPA kernel text va=0x4028645c pa=4028645c
VATOPA unmapped pa=0 (want 0)
VATOPA offset preserved: yes

The kernel mapping on this board is flat, so the first two lines on their own would also pass for an implementation that just returned its argument. The third is what separates them: 0xdead0000dead0000 comes back as zero, so PAR_EL1.F is being read and the translation really is asked of the MMU. The fourth covers the offset composition, va + 5 giving pa + 5.

Not covered: a mapping where the virtual and physical addresses differ. That needs a user address environment, which needs a root filesystem this boot does not have.

[royzah]

@acassis @xiaoxiang781216 thanks both. Green and mergeable, ready when one of you has a moment.