> Correct. This is a side-effect of using RedBoot to load the kernel on
> many of those boards; the 2MB offset puts the kernel above RedBoot's
> SDRAM footprint. Once the kernel is running, it is free to reuse SDRAM
> below 2MB which, as you point out, is currently the case. There's
> certainly some wastage with this situation, but not excessively so.
> Unless you have very little SDRAM to begin with I don't think it's
> worth adding the spare pages to UVM's freelist.

Thanks Steve, the TS-7200 has 32Mbytes of onboard SDRAM; we could have
designed the thing with more SDRAM, but in the current market a 64Mbyte
SDRAM chip still hasn't reached a competetive price per bit and to hit our
price point we only had room on the board for 1 chip.  Anyway, the TS-7200
does boot from RedBoot and with 32Mbytes of RAM, I'm thinking its probably
worth it to squeeze that extra 1868 Kbytes if there isn't any major
side-effects in doing so.  The EP93xx processor itself doesn't expose
SDRAM as a contiguous block in physical address space(4x 8Mbyte), so for
this port to work I'm going to have to have get UVM to use multiple
physical spaces anyway.

I do have the TS-7200 and EP93xx CPU mostly booting now and I can get to a
point where at least I can get into DDB.  However, the on-cpu peripherals
(serial, ethernet, USB) and on-board peripherals (CF IDE, watchdog, isa
[PC/104] bus) still need some work.  For the most part, working with the
common NetBSD ARM code has been very smooth and seems very well thought
out; kudos to the ARM NetBSD developers.  So far, the only change I've had
to make to common code is in cpufunc.c for arm9_setup(), where I added a
couple lines from sa11x0_setup() for high vectors support.

//Jesse Off