enough to use as a console on my DEC 3000/400 (connected to a VT-520
terminal).
XXX The MI SCC driver needs serious changes to handle platforms which
have muliple SCC attachments (e.g. the Alpha port, which has an ioasic
attachment for TurboChannel systems and a gbus attachment for TurboLaser
systems).
XXX The MI SCC driver also needs changes to deal with the wacky (to put
it mildly) way the chips are wired up on the ioasic (on both TC Alphas
and DECstations). These are going to come along later.
Major change is that page table page management has been completely
rewritten. Page tables are now accessed via K0SEG (no more KVA space
wasted on user page tables), and a much larger user address space is
supported.
Many thanks to Chris Demetriou and Ross Harvey for helpful insight and
debugging assistance.
- Make pv_table an array of struct pv_head's, which contain LIST_HEADs
for the pv_entry's, as well as page attributes (mod, ref, ptpage).
- Use <sys/queue.h> to manipulate pv_entry lists.
- Fix several obvious bugs in pmap_collect_pv().
- Use K0SEG to access pv_page's.
- Clean up pmap_bootstrap() some, and make a slight change to how the
PROM mappings are saved.
- Give each pmap its own level 1 page table, rather than sharing a global
level 1 page table. This will eventually allow for Very Large user
address spaces.
- Keep a list of all pmaps, so that when kernel level 2 page tables are
allocated, all level 1 tables may be updated.
- Add a couple of functions for allocating and freeing page table pages.
- Add a few comments about ASN allocation.
These changes also recover memory that is located before the kernel in
the first system software segment on systems which do not use the PROM
for console I/O. Written by Chris Demetriou and myself.
knowledge) earlier, and gather all information needed earlier. Mark the
init code carefully re: when it can print stuff out, when it can expect
the firmware to stop working, etc. Be more careful about using the PROM
console and other PROM facilities, and hint that in the future all use
of firmware/boot program callbacks by the kernel should go away (since
the world may not be mapped the way the firmware/boot program wants!).
- Attempt to find the model string in the HWRPB's DSR area. Failing that
(if the HWRPB version is too old)...
- Look up the system variation in a variation/string table. Failing that
(unknown variation)...
- Create a default model string using the variation number.
Also, factor out a bunch of common code.
number passed by the boot block into a register, change the kernel's
bootinfo handing so that it always uses bootinfo to get bootinfo-ish values
(filling them in if the boot blocks didn't pass them), and make versioning
a small bit more sane.
ross