Hi sir_richard and welcome back!
Just to make sure you know, it seems this commit introduces a regression, ros hangs while
loading ndis.sys, see testbot logs:
Date: Sun, 5 Jun 2011 20:48:34 +0000
To: ros-diffs(a)reactos.org
From: sir_richard(a)svn.reactos.org
Subject: [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not
necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at
0x80000000. The current FreeLDR algorithms wou...
Author: sir_richard
Date: Sun Jun 5 20:48:34 2011
New Revision: 52098
URL:
http://svn.reactos.org/svn/reactos?rev=52098&view=rev
Log:
[FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for
example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms
would build FreeLDR "page entries" for every page from 0 to 0x7FFF0000 and mark
it as unusable, then build the actual valid entries from 0x80000000 -> end of RAM, thus
resulting in large memory consumption (and in the bloat of the PFN database later once
NTOS loads) and boot time. Therefore, the algorithm is changed to start the PFN database
at the lowest valid RAM page described by the Firemware descriptors, and entries therefore
will be offset. This means a 128MB embedded system no longer appears to have 2048+128MB of
RAM worth of PFN entries.
NOTE: Windows does not do this, opting instead to force manufacturers/use pull-up
resistors/reconfigure the ARM Bus to map RAM at 0x00000000. For wider portability, I
believe it makes more sense to simply do this "trick" in the boot loader.
Modified:
trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
trunk/reactos/boot/freeldr/freeldr/mm/meminit.c