Hi,
I am very glad that the PPC patches are now merged so I can use a
mainstream kernel again on my iBook. Thanks to all the people who did
this. It works quite fine so far but there are two minor problems:
- The kernel ignores the boot parameter hdb=ide-scsi, it probes hdb anyway
and loads the ATAPI CD-ROM driver. The problem may be (I am really not
familiar with the kernel internals) the function pmac_ide_probe() in
drivers/ide/ide-pmac.c which does not check for any kernel boot
parameters at all.
- The generic RTC driver in drivers/char/rtc.c does not work for this
iBook. The driver in drivers/macintosh/rtc.c does work, but it only
implements the two ioctls RTC_RD_TIME and RTC_SET_TIME. (Is this due to
hardware limitations?) Anyway, it is confusing to have both drivers
configurable for PPC, maybe the corresponding Config.in files should be
adjusted. (In addition, this is complicated by the fact that both
configuration options appear in different submenus and if you select
both as modules, then the generic driver will "shadow" the macintosh
one.)
Lukas
> Hi,
>
> I am very glad that the PPC patches are now merged so I can use a
> mainstream kernel again on my iBook. Thanks to all the people who did
> this. It works quite fine so far but there are two minor problems:
>
> - The kernel ignores the boot parameter hdb=ide-scsi, it probes hdb anyway
> and loads the ATAPI CD-ROM driver. The problem may be (I am really not
> familiar with the kernel internals) the function pmac_ide_probe() in
> drivers/ide/ide-pmac.c which does not check for any kernel boot
> parameters at all.
This has beed changed for some time now. You need to pass some ignore
argument to the ide-cdrom driver and load it first then load the ide-scsi
which will detect any remaining atapi devices. I could give you the exact
line if my system wasn't dead at the moment.
>- The generic RTC driver in drivers/char/rtc.c does not work for this
> iBook. The driver in drivers/macintosh/rtc.c does work, but it only
> implements the two ioctls RTC_RD_TIME and RTC_SET_TIME. (Is this due to
> hardware limitations?) Anyway, it is confusing to have both drivers
> configurable for PPC, maybe the corresponding Config.in files should be
> adjusted. (In addition, this is complicated by the fact that both
> configuration options appear in different submenus and if you select
> both as modules, then the generic driver will "shadow" the macintosh
> one.)
That's a weirdness we haven't solved yet. Part of the problem is
that a common kernel can boot pmac, chrp and prep, and the later
ones can use the drivers/char/rtc.c driver. Actually, the
drivers/macintosh/rtc.c one may work on these too as it's just
a wrapper on some platform code selected at runtime depending on
the machine class.
Now, regarding the support of only GET/SET ioctls, it's normal.
Some of these machines don't have the legacy PC hardware RTC with
alarm support etc... That's the case of macs where the RTC hardware
is purely a real time clock. (It has other features, like scheduled
power up, but these aren't implemented yet and could be done entirely
in userland using /dev/adb anyway).
So the driver in drivers/macintosh/rtc.c is just a wrapper on the
get/set time functions provided by each type of machine.
Ben.
> is purely a real time clock. (It has other features, like scheduled
> power up, but these aren't implemented yet and could be done entirely
> in userland using /dev/adb anyway).
btw, i've heard there was a trick to enable automatic reboot of apple
powermac after a power failure (broken link on http://www.penguinppc.org, I've even
asked webmasters whithout having any response)
My main server/gateway/firewall _is_ a PPC running linux, and I would damn
like to know this trick !
thanx for any pointer/answer/whatever..
Thomas
On Wed, Jan 16, 2002 at 05:37:37PM +0100, [email protected] wrote:
> >- The generic RTC driver in drivers/char/rtc.c does not work for this
> > iBook. The driver in drivers/macintosh/rtc.c does work, but it only
> > implements the two ioctls RTC_RD_TIME and RTC_SET_TIME. (Is this due to
> > hardware limitations?) Anyway, it is confusing to have both drivers
> > configurable for PPC, maybe the corresponding Config.in files should be
> > adjusted. (In addition, this is complicated by the fact that both
> > configuration options appear in different submenus and if you select
> > both as modules, then the generic driver will "shadow" the macintosh
> > one.)
>
> That's a weirdness we haven't solved yet. Part of the problem is
> that a common kernel can boot pmac, chrp and prep, and the later
> ones can use the drivers/char/rtc.c driver. Actually, the
> drivers/macintosh/rtc.c one may work on these too as it's just
> a wrapper on some platform code selected at runtime depending on
> the machine class.
drivers/macintosh/rtc.c works on every PPC system, except for APUS (they
have their own generic rtc driver from m68k they use). This is a know
'issue' with 2.4, that's not really solvable for the reason Ben
mentioned. In 2.5 hopefully we'll replace drivers/char/rtc.c with a
generic rtc driver (and remove the PPC, MIPS and m68k generic drivers at
the same time).
Eric, do you think you could modify the CONFIG_RTC help entry to mention
that on PPC you should use the CONFIG_PPC_RTC option and not CONFIG_RTC,
if in doubt? That's probably the best fix for 2.4.x
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Tom Rini <[email protected]>:
> Eric, do you think you could modify the CONFIG_RTC help entry to mention
> that on PPC you should use the CONFIG_PPC_RTC option and not CONFIG_RTC,
> if in doubt? That's probably the best fix for 2.4.x
Done.
However, the *right* fix is
derive PPC_RTC from RTC & ((S390==n and APUS==n) or (APUS!=n and CONFIG_4xx))
eliminating PPC_RTC as a separate question entirely and hiding a platform
detail.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
To make inexpensive guns impossible to get is to say that you're
putting a money test on getting a gun. It's racism in its worst form.
-- Roy Innis, president of the Congress of Racial Equality (CORE), 1988
On Wed, Jan 16, 2002 at 12:10:58PM -0500, Eric S. Raymond wrote:
> Tom Rini <[email protected]>:
> > Eric, do you think you could modify the CONFIG_RTC help entry to mention
> > that on PPC you should use the CONFIG_PPC_RTC option and not CONFIG_RTC,
> > if in doubt? That's probably the best fix for 2.4.x
>
> Done.
>
> However, the *right* fix is
>
> derive PPC_RTC from RTC & ((S390==n and APUS==n) or (APUS!=n and CONFIG_4xx))
Unless the user wants to use drivers/char/rtc.c because they're on a
chrp or prep box.
The right fix is to make everyone use the m68k tree's actually generic
rtc driver in 2.5 :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Tom Rini <[email protected]>:
> Unless the user wants to use drivers/char/rtc.c because they're on a
> chrp or prep box.
OK, so the derivation right side should change a little (I'll take a patch).
The actual point is one of design philosophy. Instead of presenting the
ser with unnecessarily platform-specific questions, we should be asking
platform-independent (wherever this is possible) questions about the
*capabilities* he/she wants and mixing that wuith information about the
platform.
I'll go further than that. PP_RTC should probably never have existed
as a user-visible symbol and question in the first place, as it
duplicates what PPC is asking. The derivation should actually take
place somewhere in the C code of the PPC port tree.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Rapists just *love* unarmed women. And the politicians who disarm them.
On Wed, Jan 16, 2002 at 12:25:25PM -0500, Eric S. Raymond wrote:
> Tom Rini <[email protected]>:
> > Unless the user wants to use drivers/char/rtc.c because they're on a
> > chrp or prep box.
>
> OK, so the derivation right side should change a little (I'll take a patch).
The problem is both drivers are viable options on PPC, and it's possible
to build a kernel (CONFIG_ALL_PPC) that works on both systems that can't
use d/c/rtc.c (pmac) and ones that can (chrp/prep). And there are users
of d/c/rtc.c on that config even.
> The actual point is one of design philosophy. Instead of presenting the
> ser with unnecessarily platform-specific questions, we should be asking
> platform-independent (wherever this is possible) questions about the
> *capabilities* he/she wants and mixing that wuith information about the
> platform.
I mostly agree. But there's the design problem of 'CONFIG_RTC' meaning
PC-style RTC chip. Just like 'CONFIG_SERIAL' currently means
ns1655x-style uarts. Both of these should (and hopefully will) be fixed
in 2.5.x. CONFIG_RTC should be mean, we have some sort of Real Time
Clock, now give it to me. The code driver should be able to be told
what kind of clock we have (which, it currently can't, which is why
there's 3 'generic' rtc drivers but only 1 of which is in kernel.org
now).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
> btw, i've heard there was a trick to enable automatic reboot of apple
>powermac after a power failure (broken link on http://www.penguinppc.org, I've even
>asked webmasters whithout having any response)
>
> My main server/gateway/firewall _is_ a PPC running linux, and I would damn
>like to know this trick !
>
>thanx for any pointer/answer/whatever..
The actual command to send to /dev/adb is different depending if
your machine has the Cuda or the PMU chip for controlling power.
Also, it sorta have to be reset in the kernel when doing a normal
shutdown or your machine will always come back up ;) So we need
some kind of userland script putting it back ON and the kernel
putting it back off.
I'll go dig around to find the exact commands, but you could well
post a message to the linuxppc-dev and get a reply before I find
that out ;)
Ben.
On Wed, 16 Jan 2002, Ed Sweetman wrote:
> > - The kernel ignores the boot parameter hdb=ide-scsi, it probes hdb anyway
> > and loads the ATAPI CD-ROM driver. The problem may be (I am really not
> > familiar with the kernel internals) the function pmac_ide_probe() in
> > drivers/ide/ide-pmac.c which does not check for any kernel boot
> > parameters at all.
> This has beed changed for some time now. You need to pass some ignore
> argument to the ide-cdrom driver and load it first then load the ide-scsi
> which will detect any remaining atapi devices. I could give you the exact
> line if my system wasn't dead at the moment.
O.K., thanks, please forget this one. It is solved now and it was not a
kernel problem, it was one of those PEBKAC ones... :)
Lukas
"Eric S. Raymond" <[email protected]> said:
[...]
> However, the *right* fix is
>
> derive PPC_RTC from RTC & ((S390==n and APUS==n) or (APUS!=n and CONFIG_4xx))
>
> eliminating PPC_RTC as a separate question entirely and hiding a platform
> detail.
PPC is for PowerPC chips, right? Then deducing it is a PPC from it not
being totally unrelated systems is... weird. And will break the moment the
next architecture is included, because nobody will know to update such
rules.
--
Horst von Brand http://counter.li.org # 22616