[coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

> Well, CAR has to be below 1 MB (processor limitation). We can make sure
> it will not clobber more than 64 kB in that area. Because of conflicts
> with legacy ROM decoded areas, CAR has to stay below 896 kB. Conflicts
> with areas decoded by devices are pretty likely in the 640 kB - 1024 kB
> range.

Hum OK, so lets use 0-64KB?

> 
>>> What is the reason that we can't put all coreboot
>>> variables below 1MB?
>> Yes we can, but some parts are very messy including but not limited to:
>>
>> 1) stack segment for AP cpus, very ugly define, hardwired to 1MB when
>> using
>> _RAMBASE lower then 1MB
>>
>> 2) Memory is cleared from zero to TOPK, which is bad.
> 
> But the two points above are pure code issues and can be fixed, right?

Yes it could of course. IMHO there is no much space left for everything bellow
1MB so I think there is a hack with the 1MB above usage for the stack.
> 
> An area with 64 kB size somewhere below 1 MB should cover variable
> storage. We might have to mess with the 0-4 kB area as well.

I think this is fine, why not, because the LB table is there written once
Coreboot is nearly done anyway. Lets put there secondary.S trampoline
and back to real mode switcher too.

> Well, during CAR our stack has to be below 1 MB. Moving the stack during
> execution is something we do now for K8, but I'd like to get rid of that
> completely so we never introduce such stuff to v3. Note: Geode LX in v3
> does not move the stack.

Ok when it is possible to remap the stack to same location (as opposed to what
the Opteron BKDG says)

Up to 0xe AMD family it says that cache must be invalidated with INVD and
writeback is not possible with  CLFLUSH or WBINVB. Maybe Manual writeback is then.

 0xf AMD family allows only 48KB, 256 tags must be reserved.
It says nothing about "unable to copy it on itself". Only that cache
invalidate must be done after DRAM works.

And new guide revision also says: Temporarily disable cache fill probes on the
BSP by programming DisFillP = 1 (Function 0, offset 68h). Then read 64K and
enable the DisFillP = 0. It does not tell if data can be written back with
WINVD, CLFLUSH just to avoid that before dram is ready.

the 0x10 fam BKDG says even more, also just 48KB, read all with rep MOV,
there are additional constrains like not to push more then a double word
with first push.

It also says that writeback to main memory is possible with  CLFLUSH or WBINVD
invd. It also recommends not to use exceptions, interrupts, no MMX, 3Dow etc
Except of: MOVD, MOVQ, MOVDQA, MOVQ2DQ, MOVDQ2Q.

Maybe manual writeback will work here too.

> Congratulations!

Thanks, yep, its cool ;)

Rudolf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHiUXY3J9wPJqZRNURAok9AJ93Gi7OywIVfAv1A2f+WI5C6BukCwCfc9Le
9ktjrwY4ZUYkoJZxnUepbvE=
=/CVa
-----END PGP SIGNATURE-----