Booting Imac G5

[J. Mayer]

On Mon, 2004-11-22 at 12:16, Benjamin Herrenschmidt wrote:
> > I tried to do mb() at the start of do_cmd() and after the cmd_done call.
> > Then, when reading the RTC, I read all zeroes but the first byte which
> > is 0x81. The cmd byte isn't modified, when I should read the command ack
> > which is the complement of the requested command (even if I don't check
> > it, for now).
> > I tried to add a call to flush_dcache_phys_range, then I got the same
> > result.
> > But using flush_inval_dcache_phys_range (yes the name is quite
> > strange....), with or without mb(), then it works.
> 
> Ok, that seem to indicate that indeed, that crap isn't cache
> coherent ... I wonder how they actually access the memory from the
> SMU... maybe i2c commands to U3...

They may use the SPU interface to access the RAM.  But, in fact, looking
at the OF SMU driver, I should have been warned about the cache issue:
this routine is quite clear:
: clr-cache-lines
   cmd-buf ^dcbf ^sync  ;
It's called just before ringing the doorbell...

> > I'm not sure it'll eat all PMU commands, but it sure can treat some...
> 
> Probably not all, I'm not even sure Apple themselves still knows what
> all PMU commands do :) The PMU is a mess that evolved from the original
> one that was in the very first Mac Portable !

;-)

> > All right !
> > But I think I reached my first goal: I got a usable and stable machine
> > with all basic features available.
> 
> Yes, that's really nice. Is rivafb working too ? I've seen somebody
> submitting a patch that recently got into Linus bk fixing some issues
> with the 5200

rivafb works well, the only problem is to make it use the right video
mode: it does not use the right virtual xres. I didn't spent time to try
to fix this issue, but I guess it can be easily fixed.

-- 
J. Mayer <l_indien at magic.fr>
Never organized