-----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:
- stack segment for AP cpus, very ugly define, hardwired to 1MB when
using _RAMBASE lower then 1MB
- 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