This allows us to convert aucom to just another com attachment, and cleanup
some code in the com_arbus.c.
Additionally, we use a common com_cleanup routine rather than having a
zillion copies of it in the attachment points.
This has been tested on a number architectures, and it has been shown to get
close to comparable performance when COM_REGMAP is defined, and comparable
when it is not defined.
Approved by core@. Fixes PR port-evbmips/32362.
and others to avoid providing PCI I/O space at address 0.
Iyonix, however, needs to provide PCI I/O space at 0.
The others require I/O space to be offset in part due to a bug
work-around in wm(4) which requires that I/O space access be used
to reset the controllers. If I/O space is mapped at zero, the card
claims, but ignores, the transactions, and the controller doesn't
get reset properly and can't then be used.
- don't use managed mappings/backing objects for wired memory allocations.
save some resources like pv_entry. also fix (most of) PR/27030.
- simplify kernel memory management API.
- simplify pmap bootstrap of some ports.
- some related cleanups.
with a more generic "devmap" structure that can also handle mappings
made with large and small pages. Add new pmap routines to enter these
mappings during bootstrap (and "remember" the devmap), and routines to
look up the static mappings once the kernel is running.
Also in the ARM32_PMAP_NEW case, reclaim the USPACE-bytes of wasted space
at the top of the user address that hasn't been needed for a very very
long time.
add rd, pc, #foo - . - 8 -> adr rd, foo
ldr rd, [pc, #foo - . - 8] -> ldr rd, foo
Also, when saving the return address for a function pointer call, use
"mov lr, pc" just before the call unless the return address is somewhere
other than just after the call site.
Finally, a few obvious little micro-optimisations like using LDR directly
rather than ADR followed by LDR, and loading directly into PC rather than
bouncing via R0.
attached to "obio") on the IQ80310 and IQ80321. It makes more sense
to do it this way for this type of system (the goal being to encapsulate
as much information about the board as possible into one file).
