[coreboot] patch: init gx cache earlier.
Marc Jones
marc.jones at amd.com
Tue Feb 5 18:23:51 CET 2008
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
More information about the coreboot
mailing list