[coreboot] patch: init gx cache earlier.

[Marc Jones]

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.



> 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.

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors