Booting Imac G5

[J. Mayer]

On Sun, 2004-11-14 at 23:43, Benjamin Herrenschmidt wrote:
> On Sun, 2004-11-14 at 23:31 +0100, J. Mayer wrote:
> > On Sun, 2004-11-14 at 23:07, Benjamin Herrenschmidt wrote:
[...]
> > > > - No RTC
> > > 
> > > RTC is probably in the SMU...
> > 
> > Yes, it's an i2c RTC clock in the SMU. I'm working to get SMU I2C work,
> > looking to Apple's drivers.
> > With luck, the RTC will be quite a standard one ;-)
> 
> Well, the Apple SMU driver isn't open sourced, though you may find out
> how it works from the OF code...

Yes, I saw... Will see if I can do something...

> > > > - No SMU management
> > > > - Bad detection of frame-buffer virtual res in
> > > >   riva-fb:
> > > >    should use xres=1440 yres=900 &
> > > >    virtual_xres=1536
> > > 
> > > Ok, weird. Will check that when I get it. Does X "nv" driver work when
> > > booting with offb ?
> > 
> > xorg runs well when booting with ofb. The only issue is that it doesn't
> > restore the OF original mode when exiting. The only problem I had was to
> > find the right modeline to put in the monitor section to be able to use
> > the native resolution. Here it is, if it can be useful:
> >         HorizSync    28.0-110.0
> >         VertRefresh  43.0-90.0
> >         Modeline "1440x900"  100.00  1440 1456 1464 1536  900 916 924
> > 940
> > The xorg nvidia driver worker really well: it can use other resolutions
> > (even if it does not seem useful), turn of the backlight, ... 
> 
> Doesn't OF node for the display contain an EDID ? That can be parsed to
> generate a correct ModeLine..

Thanks for pointing this. So,  I now got a modeline for 1440x900-60

> > > > - Have to unplug/replug the USB keyboard
> > > >   after kernel boot to make it work with kernel
> > > >   2.6.10-rc1. No such problem with 2.6.9.
> > > 
> > > There have been various USB related issue in 2.6.10-rc*, have you tried
> > > the latest bk ?
> > 
> > Hum... I don't use bk. Can't compile it...
> 
> There are snapshots too, dayly or so

It's not such a great issue. And I know I use a rc, not a realease. As
it works with 2.6.9 kernel, I'm quite certain it is or will be fixed.

> > > > - Lot's of segfaults occuring when multiple
> > > >   concurent processes are running, especially
> > > >   during compilations. Maybe the RAM is bad
> > > >   (I'm trying to port memtest86 to check this)
> > > >   or the CPU state is not completely saved / 
> > > >   restored when rescheduling: it seems not
> > > >   to occur when compiling without doing
> > > >   anything else concurently.
> > > > 
> > > > Do you have any idea about the last point ? Could this be Altivec
> > > > context save / restore problems ?
> > > 
> > > I very much doubt it has anything to do with CPU context
> > > saving/restoring... Could be lots of different things, difficult to say
> > > at this point. Thermal problem ? Clock chip setup problem ? Bad
> > > RAMs ? ...
> > 
> > I don't think it could be a thermal problem as the fans are running full
> > speed when SMU is not managed. But it could be bad RAM. I have to check
> > this point. OS X seems to run well, but I didn't stressed it a lot as I
> > do with Linux !
> 
> OS X tend to run well in lots of crappy cases, strangely. I think Linux
> somewhat stresses the HW more.

I did port some parts of memtest86 to ppc64 as a userland program. It's
sure not the best way, but I'm now able to launch it as an init
replacement. I may add more tests, I just have a few ones, for now, but
I may see if my RAM is bad (I would hate Apple, if it's the case !).

In the meantime, I did implement the timings for UDMA133 but I can't
really test them, as Apple put a 40 pin cable for the superdrive. What's
good is it still work ! I noticed hdparm doesn't like it: the drive
reports buggy features.... I may replace the cable when I'm not too lazy
to reopen the box ;-)

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