Hello Nico,
I'll add more to your answer, and ask community to review my thoughts since not sure if I am putting them correctly (what do I know?).
Naveed,
Usually, boot-loaders are linear. "Linear" term means that MMU (Memory Management Unit HW) is not used/even initialized with (any) boot-loaders.
This implies that there is no OS (no virtual space, no TLBs, no HW TLB xlation), no kernel scheduler in place. Boot-loaders are translated to single linear HW thread, mostly INT disabled. They are bringing CPU/PCH/minimum platform internals up.
In this respect Coreboot is NOT responsible for memory allocation. It can ONLY see 4GB linear, after all. while MRC should take care (in x86 FSP) for all platform on-board memory (forgive me if I am wrong here). ;-)
OS is the one, which will start using MMU HW, and virtual space/TLB tables initialized (by OS MMU drivers). So, I would not blame either INTEL FSP, either Coreboot for what you see as DDR3 allocation in WIN7 32.
Zoran _______
On Tue, Jun 7, 2016 at 11:36 AM, Nico Huber nico.huber@secunet.com wrote:
Hello Naveed,
On 07.06.2016 07:21, Naveed Ghori wrote:
But I should still see 4GB without any patch. Right?
no, I'm afraid not.
Windows only see 1.92GB as “Installed Memory (RAM)” in Control
Panel->System. This is correct as the 4GiB address space is not only used for RAM but shared with other resources on modern systems.
I am happy for the system to see up to 4GB only.
It might be possible to tune the configuration a little. But you'd never get the full 4GiB. About 3GiB is a common limit today if you really want to run a 32bit OS without PAE support.
Nico