[ros-dev] FW: [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...

[Gabriel ilardi]

I haven't seen an aswer, is there any plan about this?

From: gabrielilardi(a)hotmail.it
To: ros-dev(a)reactos.org
Subject: RE: [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...
Date: Mon, 6 Jun 2011 11:07:39 +0200








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/s…
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(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
>