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?).
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.
On Tue, Jun 7, 2016 at 11:36 AM, Nico Huber <nico.huber(a)secunet.com> wrote:
On 07.06.2016 07:21, Naveed Ghori wrote:
But I should still see 4GB without any patch.
no, I'm afraid not.
Windows only see 1.92GB as “Installed Memory
(RAM)” in Control
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.