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:
http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1342/steps/test/logs/stdio
I've filed http://www.reactos.org/bugzilla/show_bug.cgi?id=6292
Could you please take a look?

Thanks.

> Date: Sun, 5 Jun 2011 20:48:34 +0000
> To: ros-diffs@reactos.org
> From: sir_richard@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
>