On 12.01.2008 23:57, Rudolf Marek wrote:
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?
That could work for processors which are guaranteed to have more than 64 kB of L2 cache. Basically, you can place the CAR area with 64 kB size granularity and alignment between 0 kB and 512 kB, with 16 kB granularity+alignment between 512 kB and 768 kB, and with 4 kB granularity+alignment between 768 kB and 1024 kB. That is a processor limitation. Now if a processor has 64 kB L2 cache or less, placing CAR between 0 kB and 512 kB is naturally impossible. /"You are in a maze of twisty little passages, all alike." /Of course, CAR is rather fragile and there is no guarantee my rewrites will ever allow us to use the full theoretical potential.
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.
Yes.
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.
Interesting. I must have overlooked that part.
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.
Yes, fragility abounds.
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.
Let's try it.
Regards, Carl-Daniel