Booting Imac G5
l_indien at magic.fr
Mon Nov 15 17:03:48 EST 2004
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>
More information about the Linuxppc64-dev