Two issues with 2.4.18pre3 on PPC

Two issues with 2.4.18pre3 on PPC

[Lukas Geyer]

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

Re: Two issues with 2.4.18pre3 on PPC

[Ed Sweetman]

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

Re: Two issues with 2.4.18pre3 on PPC

[Lukas Geyer]

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

Re: Two issues with 2.4.18pre3 on PPC

[benh]

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

Automatic reboot on PPC (was: Re: Two issues with 2.4.18pre3 on PPC)

[Thomas Capricelli]

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

Re: Automatic reboot on PPC (was: Re: Two issues with 2.4.18pre3 on PPC)

[Benjamin Herrenschmidt]

>	btw, i've heard there was a trick to enable automatic reboot of apple 
>powermac after a power failure (broken link on 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.

Re: Two issues with 2.4.18pre3 on PPC

[Tom Rini]

On Wed, Jan 16, 2002 at 05:37:37PM +0100, benh@kernel.crashing.org 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/

Re: Two issues with 2.4.18pre3 on PPC

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> 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

Re: Two issues with 2.4.18pre3 on PPC

[Tom Rini]

On Wed, Jan 16, 2002 at 12:10:58PM -0500, Eric S. Raymond wrote:
> Tom Rini <trini@kernel.crashing.org>:
> > 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/

Re: Two issues with 2.4.18pre3 on PPC

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> 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.

Re: Two issues with 2.4.18pre3 on PPC

[Tom Rini]

On Wed, Jan 16, 2002 at 12:25:25PM -0500, Eric S. Raymond wrote:
> Tom Rini <trini@kernel.crashing.org>:
> > 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/

Re: Two issues with 2.4.18pre3 on PPC

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> 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