LGTM. thanks.
It is a bit questionable whether ctfconvert should generate an error in this case (I don't think so), but calling it is clearly unnecessary in this case.

I afraid that this approach have problem on FDT based systems. FDT typically uses reserved memory regions also for secure portion of base memory (memory used by secure monitor or PSCI). And reserved memory is handled by using EXFLAG_NOALLOC -> https://cgit.freebsd.org/src/tree/sys/arm64/arm64/machdep.c#n1193
And of course this kind of memory cannot be accessed by /dev/mem.

Unfortunately, side effect of this is large reduction of VA space available for mmap -> available range for (unfixed) mmap is only in the interval <start of data segment + MAXDSIZ, end of user VA space>.

Ohh right, my next mistake. Seems I have not lucky day today :(
Thanks for fixing my stupid bugs.

I just committed fix for arm.
Thanks for cooperation.

In D27886#623414, @rlibby wrote:

In D27886#623242, @mmel wrote:

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.

Are you saying 32-bit ARM is also broken? Those are a little weirder, I think it uses sys/sys/_atomic_subword.h.

Yes, it is also broken. ARM uses its own implementation, which does not do modulo for the bit position.
See https://cgit.freebsd.org/src/tree/sys/arm/include/atomic-v6.h#n862.
I will commit proper fix in next hour or so...

Hmm, right. It would be better to read the manual before coding. My bad.

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.
Tested on real HW, everything OK.

This is not entirely true, for every SoC we know where DRAM is located and its maximum size. Same is true for all MMIO peripherals.

Tested with LINUX_BOOT_ABI, everything works fine.
But why did you also change the behavior for SOCDEV_PA/VA? Removal of the option to choose a SOCDEV_PA looks a like step backward to me. This breaks existing code (but covered by #if 0) for example in uart_dev_snps.c. At least this change should be mentioned in commit message, but I think that old way is better.

Can you, please, rebase this to fresh tree?
Patch fails for me with:

git apply -p0  ../../git/D27765.diff
error: patch failed: sys/arm64/arm64/locore.S:497
error: sys/arm64/arm64/locore.S: patch does not app

Unfortunately, this fails on armv7 and on aarch64.

Works for me and it's much better than my initial proposal.

I want to be stronger :) - to the best of my knowledge, wmb ()) is not needed at all or bus_dmamap_sync() is broken for x86. Nothing in between.
In current revision, the memory barrier should be ensured by calling bus_dmamap_sync() - (it's an external function and the buffer is not local variable, so compiler must expect access to these data).
I think that x86 architecture ensures right store ordering also for external observers so I think usage of wmb() (or any other explicit synchronization) in any driver is nothing but bug.

Bah, Warner was much faster :)

This wmb() was exist in initial version of nvme drivers, which did not used standard FreeBSD busdma functions.
See https://svnweb.freebsd.org/base/head/sys/dev/nvme/nvme_qpair.c?view=markup&pathrev=240616#l415 .
I'm near sure it was used as barrier to ensure the visibility of memcpy() few line above to nvme dma before the real comand is fired (by nvme_mmio_write_4()).

ping.

Perfect. Many thanks for cooperation.

In any case, with these minor issues fixed, LGTM

Tested on real HW without issues.

Tested on ARM and ARM64

Tested on ARM and ARM64

In D23085#604314, @greg_unrelenting.technology wrote:

I think that having one single codebase, fully based on GPL code for fast porting, is a MUCH more important goal than having display output without GPL (/in base).

Why you think that “single codebase, fully based on GPL” has any relation to fast porting in this context?
My understanding is that because the graphics on the SBC SoCs are related to virtually every subsystem, porting (and maintenance) cost increase exponentially.

The main issue in SBC DRM implementation is that graphic driver doesn’t handle separate self-contained device but it handle device tightly integrated in system, where many part of SoC are shared between GPU and rest of system. Also, graphic subsystem is not monolithic, it consist from multiple subdevices spreaded over whole SoC. some of these subdevices must be implemented by native drivers (rasterizer, HDMI formatter) we cannot condition presence of (unaccelerated) graphic console by GPL code.
Because of this we cannot use linux_device approach (we must be able to pass same struct device (or device_t) between native and ‘emulated’ code in all possible ways, same is true also for files and threads.
Number 1 for SBC is to have a working (with hotplug monitor) graphic output with a BSD license that can be used for X11 (Wayland). Acceleration 2D / 3D acceleration is optional and, in the worst case, can be performed by a GPL-licensed module.
And about DRMKPI - many goals are very different from LINUXKPI. DRMKPI is an attempt to implement some of the mostly used Linux functions or primitives used in DRM in a direct native way.
Another problem with LINUXKPI is significant namespace pollution caused by #define in the headers. I plan to make significant changes in this area. Each individual function should have the prefix linux_ <foo> defined to its original name only if the header is included in the Linux code.
For these reasons, I prefer to have separate implementations for now. Once the situation stabilizes, we can reconsider.
The problem has many threads that I am not able to express in a clear form, the problem is simply too complex. We have (unlike others) a functional (and I think usable) prototype, it needs some work before it can be committed (first it is necessary to resolve the real conflict LINUXKPI). But first we need a certain level of conclusion - no one is motivated to spread unacceptable code.
Plus, as you can see, I'm not a technical writer, so please excuse my chaotic words and sentences.
And let me not forget, this is by no means an attempt to slander LINUXKPI. But we are, although it does not seem so, in a very different situation.

I’m looking at this from perspective of presence of multiple different implementations of IOMMUs in ARM(64) world. From this point of view, I still have some problems with code partitioning, mainly in meaning of smmu_if.m.
I think that smmu_if.m should be taken as interface between system and individual IOMMU implementation. That’s mean that it should be decontaminated from using smmu (in names and/or as argument) and renamed to iommu_if.m.
The system wide function in smmu_iommu.c (like iommu_get_ctx(), iommu_find(),iommu_registe() or so) should be moved to own independent file (say iommu.c) and all HW dependent functionality should be passed by using iommu_if.m to given implementation.

I think it's wrong. In this case, multi-page alignment is required, the old comment is correct. Please see https://reviews.freebsd.org/D26735. I plan to commit this in the next day or two.