On 2022-11-20 14:39, Shao Miller wrote:
[...]
3. I could be mistaken, but there appears to be an assumption
somewhere about device-memory being at > 2 GiB ("high"). What I found
was that if the framebuffer was identity-mapped to its < 2 GiB
address, it would work until some random point after interrupts and
the clock are enabled, then any attempt to touch that "low" memory
would hang the device. When I mapped its low PA to a high VA, all was
well. Perhaps this has something to do with the user-land and
kernel-land split.
[...]
On 2022-11-23 10:27, Nick Hudson wrote:
On 23/11/2022 11:15, Shao Miller wrote:[...]7. The "NEXUSTROUBLEXXX" lines are merely descriptive. The use of an 'if' to block out a "problematic" line warrants further pursuit of understanding before even deciding upon a correct strategy, whether #ifdef or something else.Do the Krait CPUs have non-architecture described caches? [...]
Well I just restored the "problematic" line and all continues to be well. I now believe the "problem" only existed because I was previously identity-mapping the "low" framebuffer, instead of mapping its "low" PA to a "high" VA. One less complication to worry about, then. I suppose it makes sense, if NetBSD "desires" that all "low" VA be for user-land.
I'm not sure how to pick an appropriate (non-arbitrary) "high" VA for the framebuffer. Perhaps it might involve using bus_space_map instead of the DEVMAP setup?
- Shao Miller