Booting Imac G5
benh at kernel.crashing.org
Mon Nov 22 19:41:04 EST 2004
> I need to invalidate the L1 cache because I need the memory to be read
> again after the SMU updated the buffer. If I don't, I will read back my
> request instead of the SMU answer.
No, the system should be fully cache coherent.
> This because the caches don't know that another chip will update this
> memory area.
They do normally
> In fact, I spent quite a long time before I understood why I didn't get
> valid SMU messages back....
That's strange... I suspect the SMU must bypass normal cache coherency
protocol in some way, but that is strange, since according to the base
address of the SMU area, it's in the middle of K2, which is on a fully
> As the SMU is a separate chip, I'm not so surprised that the northbridge
> does not know that it may "corrupt" some memory. The SMU may act as a
> fake CPU while doing this if it was located on the processor bus.
It can't be on the processor bus. Which is why I'm surprised. It seem to
be on K2, which is on a coherent bus. You may just be missing memory
barriers in fact. Can you show me your code ?
> If I understand things well, the CPU acts as an IIC slave for the SPU
> (which seems to be a part of the SMU) then can receive commands from
> this unit. But it seems that the CPU cannot talk directly to the SPU.
Hrm... the CPU is definitely an i2c slave of the SPU, but the command
processing goes through some MMIOs wirted to K2 no ?
> I implemented SMU communication the same way Apple does in the OF
> driver: we talk through a doorbell buffer and a GPIO all located in the
> MacIO space. The doorbell buffer only contains the physical address of
> the buffer used to exchange data with the SMU.
Right... well, it's possible that the SMU actually uses i2c accesses to
read the memory buffer, in which case it will indeed bypass coherency
protocols... scary !
More information about the Linuxppc64-dev