[coreboot] patch: init gx cache earlier.

[Carl-Daniel Hailfinger]

On 05.02.2008 18:23, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> On 05.02.2008 07:31, ron minnich wrote:
>>> I think this is fine but I'd like to fit it into the "stage"
>>> nomenclature, so the numbering fits.
>>>
>>> So which stage is this? I am not sure, I feel like the stage numbering
>>> never quite got finished :-)
>>>
>>> possibly stage 3 is load payload, stage 4 is prepare the machine for a
>>> payload, and stage5 is run the payload?  
>>
>> Remember that we load stage 2 like a payload, so we'd have execution
>> order stage 0,1,3,4,5,2,3,4,5,realpayload. Stage 2 is also special
>> because it lives completely in RAM, but it calls a lot of functions in
>> bootblock ROM. If we shadow the boot block, most problems should
>> disappear.
>
> Since I was working in Stage1.c I assumed it was stage1 and that every
> other stage is called from stage1.

Fully agreed.

>> One thing I didn't understand:
>> Marc Jones wrote:
>>> Due to some cache coherency snoop problems across pci we need the ROM
>>> cache properties to be write-serialize + cache disabled. 
>>
>> The data in ROM doesn't change nor do we write to it. So where exactly
>> do we need write snooping and/or write-serialize?
>
> The problem is a transaction depth issue and bottlenecks inside the GX
> and LX that go across PCI.  The conditions are very complicated but it
> comes down to we need write serialization for writes to PCI. If you
> look in the data book you can't have write serialization and the cache
> enabled on a given area. During coreboot we don't have to worry about
> a write or a PCI bus master so I think we can enable caching the ROM.
> After coreboot we can't be sure what will happen in the system so we
> need to set it up to be safe. For example flashrom just clears the
> write protect bit. If the cache were enabled (no write serialization)
> and flashrom was writing the ROM we would be in a precarious position.
> A PCI  bus master doing a read or a write that has a hit on a tag
> would cause enough bottleneck conditions that it might hit the bug. We
> could change flashrom but that doesn't help other tools. We need to
> leave the system in a safe state. Also, caching the ROM after it is no
> longer used doesn't make much sense. So, we need a call just before
> the payload runs to clean up the system.

Thanks for the explanation. So this final cleanup need not be applied
for stage2, only for the real payload because we don't know what the
payload may do.


Regards,
Carl-Daniel