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

[Carl-Daniel Hailfinger]

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