Booting Imac G5

[Benjamin Herrenschmidt]

On Sun, 2004-11-14 at 23:31 +0100, J. Mayer wrote:
> On Sun, 2004-11-14 at 23:07, Benjamin Herrenschmidt wrote:
> > > Here's a quick overview of current kernel status:
> > > - Pmac PCI IRQ fix: needed for IDE & SATA on
> > >    Imac G5 (should not break other targets).
> > > - Ethernet PHY failure if the cable is plugged
> > >   during boot
> > 
> > Ok, have to check out what's in darwin, there are some bits for the
> > Shasta chipset that I haven't adapted yet.
> 
> OK.
> 
> > 
> > > - 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...
> 
> > > - 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..

> > > - 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

> > > - 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.