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.
table is handled the podulebus mappings are now done at initarm, rather
than in the podulebus code. While I'm not happy with this it does work,
perhaps there's a better way to do it?
Not enableing by default I've not got enough cards to check the podulebus
change hasn't broken something (works with my rapide and with my network
podule)
major code cleanup esp. types used. Also cleanup up a major BUG that for
some odd reason worked :-/ makes me puzzled. It signifies that there might
be copies around in physical space of the DRAM ??? and thus its function
was motherboard dependent? It must have been old cruft from before the
cleanup of the relocation engine.
/*
* The size of the code/data to be moved is not `end - rmbase' but
* `__bss_start__ - rmbase' for the module is loaded into RISC OS
* based on the filesize where as NetBSD doesn't have to include all
* the bss space into the file itself. In some odd cases the
* relocatable module area can be smaller than the module + bss and
* thus bomb out.
*/
cd ${KERNSRCDIR}/${KERNARCHDIR}/compile && ${PRINTOBJDIR}
This is far simpler than the previous system, and more robust with
objdirs built via BSDOBJDIR.
The previous method of finding KERNOBJDIR when using BSDOBJDIR by
referencing _SRC_TOP_OBJ_ from another directory was extremely
fragile due to the depth first tree walk by <bsd.subdir.mk>, and
the caching of _SRC_TOP_OBJ_ (with MAKEOVERRIDES) which would be
empty on the *first* pass to create fresh objdirs.
This change requires adding sys/arch/*/compile/Makefile to create
the objdir in that directory, and descending into arch/*/compile
from arch/*/Makefile. Remove the now-unnecessary .keep_me files
whilst here.
Per lengthy discussion with Andrew Brown.
got wrong when no VRAM was there.
Placing the video DRAM in front of the kernel is OK when its 1Mb since the
kernel wants to be on a Mb boundary. Placing the video DRAM in the last
SIMM bank at the front is also OK unless there is just one SIMM and just one
bank; then it got in the way again!
Solution is to put the DRAM at the end of the SIMM instead of the beginning!
This however can result in the non 16 kb alignment of the top of physical
RAM where the temporary L1 page tables are situated. If its not 16 kb aligned
then move the L1 page table address down and down until it is 16 kb aligned.
This memory will be reused later on anyway.
What to do when we really support changing screensizes... see it as a max?
or use a different sceme alltogether? It might not even be a bootloader
problem then allthough its memory is not showing up in the DRAM/VRAM
block counts wich needs to be fixed one day.
martin