Hi,
I just bought a new PowerBook G4 and installed Linux on it. Now the
tweaking begins! One of the first orders of business is getting power
management working, and I'm a bit stuck.
I'm running kernel version 2.4.22 with Ben Herrenschmidt's 2.4.23-pre5
patches.
On startup, arch/ppc/platform/pmac_backlight.c doesn't recognize the
backlight controller. It checks compatibility with a couple of specific
machines, and then checks compatibility with the backlight controller.
This appears to be the same check that is performed in the Darwin/xnu
kernel (at least the version that I found...).
I've got a bit of experience with kernel hacking so I'd be very happy to
help figure out what's going on and how to fix it, but I'm also new to
this platform and I don't know how one goes about finding hardware
documentation and other useful sorts of resources.
Any (non-null) pointers would be appreciated!
Cheers,
dstn.
Here are some details from /proc/device-tree that might be relevant (I've
used "/" as token separator):
in /:
model = PowerBook6,2
compatible = PowerBook6,2/MacRISC3/Power Macintosh
in /pci@f2000000/:
model = AAPL,UniNorth
compatible = uni-north
in /pci@f2000000/mac-io@17/:
model = AAPL,Keylargo
compatible = Keylargo
in /pci@f2000000/mac-io@17/backlight@f300/:
name = backlight
device_type = backlight
backlight-control = mnca <---- ack!
in /pci@f2000000/mac-io@17/via-pmu@16000/:
name = via-pmu
compatible = pmu
in /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt/:
compatible = via-pmu-99
On Mon, 2003-11-03 at 06:23, Dustin Lang wrote:
> Hi,
>
> I just bought a new PowerBook G4 and installed Linux on it. Now the
> tweaking begins! One of the first orders of business is getting power
> management working, and I'm a bit stuck.
You can't expect a machine just released a couple of weeks ago by
Apple to be fully supported by linux, do you ? :)
> I'm running kernel version 2.4.22 with Ben Herrenschmidt's 2.4.23-pre5
> patches.
>
> On startup, arch/ppc/platform/pmac_backlight.c doesn't recognize the
> backlight controller. It checks compatibility with a couple of specific
> machines, and then checks compatibility with the backlight controller.
> This appears to be the same check that is performed in the Darwin/xnu
> kernel (at least the version that I found...).
If it's a new Mobility 9600 machine, then I expect my 2.6 tree
(bk://ppc.bkbits.net/linuxppc-2.5-benh or rsync from source.mvista.com)
to work, though the actual backlight "scale" may not be fully correct
yet.
> Any (non-null) pointers would be appreciated!
Unfortunately, there's isn't much HW documentation available for these
babies, other than reading Apple darwin source, Open Firmware forth
code, etc...
Regarding overall power management (that is machine sleep), it is not
supported on these machines yet. The blocking factor is the new ATI chip,
which need to be rebooted from scratch. ATI told me they might be able to
send me tables to do that though, so there is hope.
Ben.
Hi Ben,
> You can't expect a machine just released a couple of weeks ago by
> Apple to be fully supported by linux, do you ? :)
I'm very impressed at how well things are supported. I had to buy a USB
wireless dongle, the Linksys WUSB12 (which works great), thanks to
Broadcom's proprietariness about the Airport Extreme, but other than that,
almost everything is automagic.
> If it's a new Mobility 9600 machine, then I expect my 2.6 tree
> (bk://ppc.bkbits.net/linuxppc-2.5-benh or rsync from source.mvista.com)
> to work, though the actual backlight "scale" may not be fully correct
> yet.
Actually, it's got a GeForce FX Go 5200.
I just grabbed your 2.6 tree and see the same things happening.
> Unfortunately, there's isn't much HW documentation available for these
> babies, other than reading Apple darwin source, Open Firmware forth
> code, etc...
Oh joy. I've heard great things about Forth :)
> Regarding overall power management (that is machine sleep), it is not
> supported on these machines yet. The blocking factor is the new ATI chip,
> which need to be rebooted from scratch. ATI told me they might be able to
> send me tables to do that though, so there is hope.
Cool. I think backlight control, drive spindown, and CPU frequency
scaling should go a fairly long way on the battery life front. Speaking
of CPU scaling, do you know if it should work on this machine? I selected
it in the kernel config, but /sys/devices/system/cpu/cpu0 is empty.
Just for reference, /proc/cpuinfo is:
cpu : 7457, altivec supported
clock : 999MHz
revision : 1.1 (pvr 8002 0101)
bogomips : 761.85
machine : PowerBook6,2
motherboard : PowerBook6,2 MacRISC3 Power Macintosh
board revision : 00000002
detected as : 287 (Unknown Intrepid-based)
pmac flags : 00000008
L2 cache : 512K unified
memory : 256MB
pmac-generation : NewWorld
Oh, I just noticed something else in dmesg:
PMU driver 2 initialized for Core99, firmware: 0c
*shrug*
I grabbed the newest Darwin/xnu source I could find from Apple, and I can
no longer find where they do the backlight control - it used to be in
iokit/Drivers/platform/drvApplePMU . I'll have to look more closely
tomorrow...
Again, many thanks for your work on this platform.
Cheers,
dstn.
> Actually, it's got a GeForce FX Go 5200.
Ouch !
Well... This will be a bigger problem then. For some reason, nVidia
can't (or don't want) to tell us how to do fine backlight control. We
know how to switch the backlight on/off though since recently and Mark
just pushed a patch doing that for DPMS in XFree CVS "nv" driver.
Another bad new with nVidia based laptops is that there is little chance
we ever support sleep mode on these as so far, it doesn't seem nVidia
would be willing to give us the necessary informations to reboot the
chip on wakeup.
> Cool. I think backlight control, drive spindown, and CPU frequency
> scaling should go a fairly long way on the battery life front. Speaking
> of CPU scaling, do you know if it should work on this machine? I selected
> it in the kernel config, but /sys/devices/system/cpu/cpu0 is empty.
For finer backlight control, it may be possible to figure it out by
either tapping registers, looking at the nVidia OF driver, or examining
register contents in MacOS X (or tracing through MacOS X drivers).
> cpu : 7457, altivec supported
> clock : 999MHz
> revision : 1.1 (pvr 8002 0101)
> bogomips : 761.85
> machine : PowerBook6,2
> motherboard : PowerBook6,2 MacRISC3 Power Macintosh
> board revision : 00000002
> detected as : 287 (Unknown Intrepid-based)
> pmac flags : 00000008
> L2 cache : 512K unified
> memory : 256MB
> pmac-generation : NewWorld
Hrm... Bogompips is a bit low for a G4... I suspect it may be running at
the lower speed. I don't know for sure how speed control work on these
new models based on the 7457...
> Oh, I just noticed something else in dmesg:
> PMU driver 2 initialized for Core99, firmware: 0c
>
> *shrug*
What's wrong ?
> I grabbed the newest Darwin/xnu source I could find from Apple, and I can
> no longer find where they do the backlight control - it used to be in
> iokit/Drivers/platform/drvApplePMU . I'll have to look more closely
> tomorrow...
>
> Again, many thanks for your work on this platform.
It's scattered. For recent machines, it's done by the video driver itself
(the video chip controls the backlight on the LVDS lines afaik)
Ben.
Am Mon, den 03.11.2003 schrieb Benjamin Herrenschmidt um 01:45:
> You can't expect a machine just released a couple of weeks ago by
> Apple to be fully supported by linux, do you ? :)
<duckmode>not?</duckmode> ;)
> If it's a new Mobility 9600 machine, then I expect my 2.6 tree
> (bk://ppc.bkbits.net/linuxppc-2.5-benh or rsync from source.mvista.com)
> to work, though the actual backlight "scale" may not be fully correct
> yet.
Interesting, will try. I've a whole bunch of more pressing problems with
my new baby, though. X is completely broken, no matter which X modelines
I configure I get nothing but sizzle on the screen, it seems that the
mode setup for the LVDS with the 9600 Mobility is bork.
The clock scaling of the CPU also doesn't work; interestingly at 867 MHz
it's not much faster the my old Ti PB 500 in dnetc RC-5 though the
overall system has a lot faster design.
Also I cannot boot it automatically from network because holding down N
at bootup will not pick up a DHCP address, so I have to type quite a bit
in OF. :(
If you need any info about the system I'd be glad to help you out.
--
Servus,
Daniel
> Interesting, will try. I've a whole bunch of more pressing problems with
> my new baby, though. X is completely broken, no matter which X modelines
> I configure I get nothing but sizzle on the screen, it seems that the
> mode setup for the LVDS with the 9600 Mobility is bork.
It works with up to date stuffs. That is my latest 2.6 tree with
radeonfb and XFree from CVS. Part of the problem is that the firmware
sets up a tiled display. I updated my radeonfb to "clear" the
various SURFACE_* translation registers (among other fixes).
> The clock scaling of the CPU also doesn't work; interestingly at 867 MHz
> it's not much faster the my old Ti PB 500 in dnetc RC-5 though the
> overall system has a lot faster design.
Yup. I need to figure that out. It's possible that it does like a G5,
that is boot full speed when you auto-boot and low speed when you boot
via OF user interface. There may be need for some thermal control as
well.
> Also I cannot boot it automatically from network because holding down N
> at bootup will not pick up a DHCP address, so I have to type quite a bit
> in OF. :(
The "N" thing is normal. Apple hacked so that only DHCP servers which
know about some special Apple extensions can be used when doing that.
The easy work around is to use the syntax:
enet:x.x.x.x,file
where x.x.x.x is the IP address of the TFTP server and file is the
filename. With that in boot-device (or typing boot enet: etc....),
the machine will obtain it's local IP from any DHCP or BOOTP server and
will then TFTP from the specified host.
Ben.
Am Mon, den 03.11.2003 schrieb Benjamin Herrenschmidt um 22:54:
> It works with up to date stuffs. That is my latest 2.6 tree with
> radeonfb and XFree from CVS. Part of the problem is that the firmware
> sets up a tiled display. I updated my radeonfb to "clear" the
> various SURFACE_* translation registers (among other fixes).
I've the most recent X but up to now I've tried your 2.4 branch where
radeonfb doesn't work, so I was using offb.
> Yup. I need to figure that out. It's possible that it does like a G5,
> that is boot full speed when you auto-boot and low speed when you boot
> via OF user interface. There may be need for some thermal control as
> well.
This would be so cool.
> The "N" thing is normal. Apple hacked so that only DHCP servers which
> know about some special Apple extensions can be used when doing that.
I believe for this there are patches floating aroung which teach the ISC
DHCPd new parameters. There are also config snipplets which let one
configure using decimal notation of the attributes; will try.
> The easy work around is to use the syntax:
> enet:x.x.x.x,file
Yupp, this is what I'm doing...
--
Servus,
Daniel
Am Mon, den 03.11.2003 schrieb Benjamin Herrenschmidt um 22:54:
> > Interesting, will try. I've a whole bunch of more pressing problems with
> > my new baby, though. X is completely broken, no matter which X modelines
> > I configure I get nothing but sizzle on the screen, it seems that the
> > mode setup for the LVDS with the 9600 Mobility is bork.
Just checked. It doesn't work with the latest (Linus) 2.6-test and
radeonfb. Do you have any special patches in your tree for radeonfb?
BTW: It took me quite a while to figure out that the only working image
with yaboot was the zImage.chrp. The normal vmlinux doesn't contain a
valid ELF signature (according to yaboot) and the seemingly obvious
vmlinux.elf-pmac goes boom while trying to decompress the kernel.
--
Servus,
Daniel
On Wed, 2003-11-05 at 07:05, Daniel Egger wrote:
> Am Mon, den 03.11.2003 schrieb Benjamin Herrenschmidt um 22:54:
>
> > > Interesting, will try. I've a whole bunch of more pressing problems with
> > > my new baby, though. X is completely broken, no matter which X modelines
> > > I configure I get nothing but sizzle on the screen, it seems that the
> > > mode setup for the LVDS with the 9600 Mobility is bork.
>
> Just checked. It doesn't work with the latest (Linus) 2.6-test and
> radeonfb. Do you have any special patches in your tree for radeonfb?
No, I told you to use _my_ 2.6 tree which contains a new radeonfb
that have not yet been merged upstream.
bk://ppc.bkbits.net/linuxppc-2.5-benh or rsync from
source.mvista.com::linuxppc-2.5-benh
> BTW: It took me quite a while to figure out that the only working image
> with yaboot was the zImage.chrp. The normal vmlinux doesn't contain a
> valid ELF signature (according to yaboot) and the seemingly obvious
> vmlinux.elf-pmac goes boom while trying to decompress the kernel.
Ugh ?
Yaboot normally loads a plain vmlinux, though if you are using tftp, you
need to modify yaboot to be able to d/l more than 4Mb (edit fs_of.c and
change the allocated size). The ELF image should work, at least the
one produced by my tree does, it's possible that there's a similar size
problem with the one in Linus tree, a few of those recent changes haven't
yet made it to Linus.
Ben.
On Thu, Nov 06, 2003 at 11:28:25AM +1100, Benjamin Herrenschmidt wrote:
> > Just checked. It doesn't work with the latest (Linus) 2.6-test and
> > radeonfb. Do you have any special patches in your tree for radeonfb?
> No, I told you to use _my_ 2.6 tree which contains a new radeonfb
> that have not yet been merged upstream.
I noticed that, however I do not have the bandwitdh to track several trees
simultaneously. Will do that on a high bandwidth machine and create a diff.
> bk://ppc.bkbits.net/linuxppc-2.5-benh or rsync from
> source.mvista.com::linuxppc-2.5-benh
> Yaboot normally loads a plain vmlinux, though if you are using tftp, you
> need to modify yaboot to be able to d/l more than 4Mb (edit fs_of.c and
> change the allocated size).
This is probably it. The raw image is just a bit over 4 megs. Is there a
chance that this will change upstream? Also a warning would be nice while
creating the kernel as I'm probably not the only one experiencing this.
> The ELF image should work, at least the
> one produced by my tree does, it's possible that there's a similar size
> problem with the one in Linus tree, a few of those recent changes haven't
> yet made it to Linus.
Size problem? At least it's not triggered by the yaboot limitation because
the image is similar in size to zImage.chrp which would be around 1.8 megs.
--
Servus,
Daniel
Hi,
This thread is now a bit off-topic, since the solution I'm talking about
is in XFree86 rather than the kernel, but I thought I'd just post it here
so that the next person who hits on this problem can find the answer in
the archives.
To reply to my own post: the patch contributed by Guido Guenther to the
XFree86 CVS tree, which was meant for GeForce4-in-PowerBooks, also works
for me on my GeForceFX Go 5200 as found in some PowerBooks (PCI ID
10de:0329). To get this to work you'll have to grab the CVS sources, find
the part that checks what chipset you have, and edit it so that your chip
passes the test. (Hint:
xc/programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c :
NVBacklightEnable). You'll also need to make sure DPMS is turned on
(hint: read "man XF86Config-4" carefully). The usual disclaimers apply:
this hack will probably destroy your video card, make you lose your hair,
and microwave your cat. It worked for me, and my hair and cat are fine,
but that's just because I'm lucky.
Laters,
dstn.
On Thu, 2003-11-06 at 19:01, Daniel Egger wrote:
> This is probably it. The raw image is just a bit over 4 megs. Is there a
> chance that this will change upstream? Also a warning would be nice while
> creating the kernel as I'm probably not the only one experiencing this.
Ethan doesn't want that change upstream for 1.x, at least not until
it has been mode widely tested. The 1.x yaboot code base isn't something
I'd call "solid", so... :)
> Size problem? At least it's not triggered by the yaboot limitation because
> the image is similar in size to zImage.chrp which would be around 1.8 megs.
No, different issues, but I expect a 1.8 Mb vmlinux.elf-pmac to work,
though it's possible that the wrapper in linus tree is bogus (I though
I sent him fixes... it's beeing difficult to merge anything in 2.6 at
this point).
For PowerMac in general, you'd rather use my tree, at least until maybe
around 2.6.1, and even then... Especially for such very new machine for
which the proper support is only getting in now.
Ben.
On Thu, Nov 06, 2003 at 07:26:19PM +1100, Benjamin Herrenschmidt wrote:
> For PowerMac in general, you'd rather use my tree, at least until maybe
> around 2.6.1, and even then... Especially for such very new machine for
> which the proper support is only getting in now.
While your tree is about a mac can get I had several troubles in the past
on other architectures and unfortunately I have to run them as well. Since
bandwidth is not as cheap as one might think I do *not* have the ressources
to keep several trees up-to-date.
However I'm diffing your tree against a recent Linus version right now and will
retry.
--
Servus,
Daniel
Am Don, den 06.11.2003 schrieb Benjamin Herrenschmidt um 01:28:
> No, I told you to use _my_ 2.6 tree which contains a new radeonfb
> that have not yet been merged upstream.
Still cannot try this because your kernel wouldn't even survive yaboot.
> > BTW: It took me quite a while to figure out that the only working image
> > with yaboot was the zImage.chrp. The normal vmlinux doesn't contain a
> > valid ELF signature (according to yaboot) and the seemingly obvious
> > vmlinux.elf-pmac goes boom while trying to decompress the kernel.
> Ugh ?
> Yaboot normally loads a plain vmlinux, though if you are using tftp, you
> need to modify yaboot to be able to d/l more than 4Mb (edit fs_of.c and
> change the allocated size). The ELF image should work, at least the
> one produced by my tree does, it's possible that there's a similar size
> problem with the one in Linus tree, a few of those recent changes haven't
> yet made it to Linus.
With your tree I now have the problem that it doesn't even boot anymore.
The CHRP kernel which worked before stopped after "CHRP kernel
loader...", the elf-pmac one still crashes with:
Elf32 kernel loaded...
chrpboot starting: loaded at 0x01000000
heap at 0x00003000
gunzipping (0x00010000 <- 0x01006cf8:0x01155486)...
Decrementer exception at %SRR0: 01005804 %SRR1: 00003030
ok
0 >
--
Servus,
Daniel
On Fri, 2003-11-07 at 20:50, Daniel Egger wrote:
> Am Don, den 06.11.2003 schrieb Benjamin Herrenschmidt um 01:28:
>
> > No, I told you to use _my_ 2.6 tree which contains a new radeonfb
> > that have not yet been merged upstream.
>
> Still cannot try this because your kernel wouldn't even survive yaboot.
Can you give details ? It should work just fine, except if I broke
something in the past few days when getting G5 support in, but I didn't
have any other report of this, so...
> With your tree I now have the problem that it doesn't even boot anymore.
> The CHRP kernel which worked before stopped after "CHRP kernel
> loader...", the elf-pmac one still crashes with:
> Elf32 kernel loaded...
> chrpboot starting: loaded at 0x01000000
> heap at 0x00003000
> gunzipping (0x00010000 <- 0x01006cf8:0x01155486)...
> Decrementer exception at %SRR0: 01005804 %SRR1: 00003030
> ok
> 0 >
Well, you are not supposed to use the zImage.chrp on a PowerMac,
and definitely not from yaboot.
It may have altered some open firmware settings in a bad way.
I suggest you reset your nvram first (hopefully, booting with
cmd-opt-P-R will do the trick).
Last I tried, then just netbooting vmlinux.elf-pmac worked fine
on all the "newworld" models I have here). For yaboot, you need
to load a plain vmlinux binary.
Ben.
Am Son, den 09.11.2003 schrieb Benjamin Herrenschmidt um 03:59:
> > Still cannot try this because your kernel wouldn't even survive yaboot.
> Can you give details ? It should work just fine, except if I broke
> something in the past few days when getting G5 support in, but I didn't
> have any other report of this, so...
The report on the chrp image is all I have right now because every other
image will result in a hang right after downloading the kernel via tftp.
Which of the two radeon drivers should I use anyway?
> Well, you are not supposed to use the zImage.chrp on a PowerMac,
> and definitely not from yaboot.
With the Linus kernel it's the only one that works.
> Last I tried, then just netbooting vmlinux.elf-pmac worked fine
> on all the "newworld" models I have here). For yaboot, you need
> to load a plain vmlinux binary.
Yes, but the image is too big for yaboot. I'll have to patch it first.
--
Servus,
Daniel
On Sun, 2003-11-09 at 20:55, Daniel Egger wrote:
> Am Son, den 09.11.2003 schrieb Benjamin Herrenschmidt um 03:59:
>
> > > Still cannot try this because your kernel wouldn't even survive yaboot.
>
> > Can you give details ? It should work just fine, except if I broke
> > something in the past few days when getting G5 support in, but I didn't
> > have any other report of this, so...
>
> The report on the chrp image is all I have right now because every other
> image will result in a hang right after downloading the kernel via tftp.
>
> Which of the two radeon drivers should I use anyway?
The new one.
> > Well, you are not supposed to use the zImage.chrp on a PowerMac,
> > and definitely not from yaboot.
>
> With the Linus kernel it's the only one that works.
>
> > Last I tried, then just netbooting vmlinux.elf-pmac worked fine
> > on all the "newworld" models I have here). For yaboot, you need
> > to load a plain vmlinux binary.
>
> Yes, but the image is too big for yaboot. I'll have to patch it first.
It's fairly simple to "fix" yaboot to handle >4Mb images actually,
just change the size in of_fs.c
Ben.