Re: Raspberry Pi 3B: /dev/mem mmap GPIO works on earmv7hf but not onaarch64

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

Thanks for the clear answer.

> > - Is /dev/mem + mmap expected to work for BCM283x/2711 peripheral MMIO
> >    on evbarm/aarch64?
> 
> No. It's lucky it works on evbarmv7.
> 
> > - If yes, where should I look for the correct mapping attributes
> >    (device vs normal cacheable) for /dev/mem mappings on aarch64?
> 
> They don't exist.
> 
> 
> > - Does the described behavior sound like a cache attribute / pmap issue,
> >    or could it be an address translation issue?
> 
> There is no support for device type memory mappings via /dev/mem

To make sure I understand the intended direction for evbarm/aarch64:

 - Is it by design that /dev/mem + mmap cannot provide device-type
   mappings for peripheral MMIO (e.g. nGnRnE/nGnRE)?

 - If so, should we document this explicitly (e.g. mem(4) and/or
   evbarm/aarch64 notes), and possibly make evbarmv7 consistent
   so users do not rely on behavior that is not guaranteed?

I am asking because other ports (at least m68k, sh3, and also arm32
except vector region) often treat unmanaged physical addresses
(PHYS_TO_VM_PAGE(pa) == NULL) as device/bus space and map them
uncached/ordered.

On the other hand, pmap_mmap_flags() (which is undocumented in pmap(9)) 
exists, at least on aarch64 and x86, and looks like a place where
mapping attributes for mmap(2) could be decided.

> What's wrong with gpioctl(8)?

In my use case I am not only toggling a single GPIO bit but need to
update 8-bit bus data / 2-bit control signals atomically for the
PSG accesses (unlike FreeBSD we don't provide GPIOACCESS32 ioctl).

I also need to program BCM283x GPCLK0 (clock manager registers)
as the PSG master 2MHz clock, and I have not found a stable API
for that on NetBSD/evbarm (please correct me if I missed one).

That tends to push userland implementations toward MMIO register access.

So the main question is: is the intended answer
 (A) "/dev/mem is RAM-only for aarch64; peripheral MMIO via /dev/mem
      is unsupported", or
 (B) "peripheral MMIO via /dev/mem is acceptable if correct device
      attributes are implemented"?

Thanks,
---
Izumi Tsutsui