From: Sven Luther <hidden> Date: 2003-12-17 09:51:39
BTW, should this discussion not be moved to linuxppc mailing lists ?
On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
quoted
On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
quoted
CONFIG_RTC will definitely break a pmac
I think I heard something about clock/timer problems on PPC a long time ago,
but could never track down an issue. Wouldn't it be best to remove RTC on
PPC or document the problem with a (read help) or something?
Is the PPC RTC (as opposed to GENERIC_RTC) stuff automatically in there, or
something? Or is it this PPC_RTC that's broken?
Well... CONFIG_RTC enables the "PC style" RTC driver that taps IO ports
to look for an RTC chip of the kind found in x86 machines. Such a chip
doesn't exist on powermac and this random IO port tapping can actually
crash the machine.
And i guess that this PC style RTC is found on the southbridge, right ?
Let me check the VIA docs. Yep, it indeed is there, and i doubt that
there is another clock on the system. Not sure though.
CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
the /dev/rtc interface but relies on hooks provided by the platform
code for actually getting/setting the RTC content. The PowerMac platform
provides hooks for the different kind of RTC chips found on Macs (that
is basically access to the RTC via via-cuda or via-pmu). CHRP or
Mmm, these are external via chips on mac hardware used for clocks ?
PReP machines should provide their own hooks, it's possible that what
CHRP provides doesn't work properly on the Pegasos, in which case we'd
have to fix this.
Another solution would be to :
1) build a pegasos specific config with CONFIG_RTC, but not the other
two. <= Not good, since it would mean over one hour compil more, and
one more binary packages. Already like that the ftp-masters are not
happy.
2) build all RTC stuff as modules, and let userland choose the one it
needs.
3) have CONFIG_RTC check the subarch or something and not work if it
recognize hardware it doesn't know about or something.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
quoted
CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
the /dev/rtc interface but relies on hooks provided by the platform
code for actually getting/setting the RTC content. The PowerMac platform
provides hooks for the different kind of RTC chips found on Macs (that
is basically access to the RTC via via-cuda or via-pmu). CHRP or
Mmm, these are external via chips on mac hardware used for clocks ?
No, that's VIA as in Versatile Interface Adapter, not as in VIA Technologies.
It used to be a separate chip in the old 68000 days, but now it's integrated in
some Mac fabric (e.g. Mac I/O).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
No, that's VIA as in Versatile Interface Adapter, not as in VIA
Technologies.
It used to be a separate chip in the old 68000 days, but now it's
integrated in
some Mac fabric (e.g. Mac I/O).
Actually, there is no RTC chip _at all_ in NewWorld Macs. The PMU
itself keeps the time (from a 32768Hz clock).
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
No, that's VIA as in Versatile Interface Adapter, not as in VIA
Technologies.
It used to be a separate chip in the old 68000 days, but now it's
integrated in
some Mac fabric (e.g. Mac I/O).
Actually, there is no RTC chip _at all_ in NewWorld Macs. The PMU
itself keeps the time (from a 32768Hz clock).
So from a technical point of view, the PMU is the RTC chip, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Dec 17, 2003 at 10:51:39AM +0100, Sven Luther wrote:
BTW, should this discussion not be moved to linuxppc mailing lists ?
On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
quoted
On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
quoted
CONFIG_RTC will definitely break a pmac
I think I heard something about clock/timer problems on PPC a long time ago,
but could never track down an issue. Wouldn't it be best to remove RTC on
PPC or document the problem with a (read help) or something?
Is the PPC RTC (as opposed to GENERIC_RTC) stuff automatically in there, or
something? Or is it this PPC_RTC that's broken?
Well... CONFIG_RTC enables the "PC style" RTC driver that taps IO ports
to look for an RTC chip of the kind found in x86 machines. Such a chip
doesn't exist on powermac and this random IO port tapping can actually
crash the machine.
And i guess that this PC style RTC is found on the southbridge, right ?
Let me check the VIA docs. Yep, it indeed is there, and i doubt that
there is another clock on the system. Not sure though.
quoted
CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
the /dev/rtc interface but relies on hooks provided by the platform
code for actually getting/setting the RTC content. The PowerMac platform
provides hooks for the different kind of RTC chips found on Macs (that
is basically access to the RTC via via-cuda or via-pmu). CHRP or
Mmm, these are external via chips on mac hardware used for clocks ?
quoted
PReP machines should provide their own hooks, it's possible that what
CHRP provides doesn't work properly on the Pegasos, in which case we'd
have to fix this.
Another solution would be to :
1) build a pegasos specific config with CONFIG_RTC, but not the other
two. <= Not good, since it would mean over one hour compil more, and
one more binary packages. Already like that the ftp-masters are not
happy.
2) build all RTC stuff as modules, and let userland choose the one it
needs.
3) have CONFIG_RTC check the subarch or something and not work if it
recognize hardware it doesn't know about or something.
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2003-12-17 16:56:08
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2003-12-17 17:10:52
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
Ok, will do this tomorrow, thanks for your help.
BTW, in this case, would it make sense to hide the CONFIG_RTC on powerpc ?
Amicalement,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Actually, there is no RTC chip _at all_ in NewWorld Macs. The PMU
itself keeps the time (from a 32768Hz clock).
So from a technical point of view, the PMU is the RTC chip, right?
Not really, it's a very different mechanism. But you could say it
is yeah, if you don't mind being sloppy ;-)
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Dec 17, 2003 at 06:10:52PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
quoted
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
Ok, will do this tomorrow, thanks for your help.
BTW, in this case, would it make sense to hide the CONFIG_RTC on powerpc ?
From: Sven Luther <hidden> Date: 2003-12-19 11:40:50
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
set_rtc_time function.
BTW, what exactly should i do in 'chrp_get_rtc_time' and
'chrp_set_rtc_time' ? Just replace the existing code, or make a new
function, and set it depending on machine type who needs it in
chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
have to set ppc_md.set_rtc_time accordyingly.
This is still with the 2.4.x code base.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
quoted
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
set_rtc_time function.
Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)
BTW, what exactly should i do in 'chrp_get_rtc_time' and
'chrp_set_rtc_time' ? Just replace the existing code, or make a new
function, and set it depending on machine type who needs it in
chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
have to set ppc_md.set_rtc_time accordyingly.
My preferance would be to replace, and then see if it breaks some other
chrp machines (it really shouldn't).
Something that just dawned on me again (sorry) is that I've really really
intended to try and kill both prep_time.c and chrp_time.c (since both of
those machine subtypes have PC-style RTC chips) and make them use
todc_time.c (see arch/ppc/kernel/todc_time.c). I've got patches to do
half of this, against 2.6 (which was a trivial forward port of older
2.4-based patches I had, there is nothing 2.6-specific about these
patches). You would want to look at:
006-redo_inb_inw_inl_outb_outw_outl.patch
007-make_out_8_and_friends_synchronous.patch
008-todc_warning.patch
009-prep_time_death-GNU.patch
from http://stop.crashing.org:16080/~trini/
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2003-12-22 13:45:04
On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
quoted
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
set_rtc_time function.
Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)
Ok.
quoted
BTW, what exactly should i do in 'chrp_get_rtc_time' and
'chrp_set_rtc_time' ? Just replace the existing code, or make a new
function, and set it depending on machine type who needs it in
chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
have to set ppc_md.set_rtc_time accordyingly.
My preferance would be to replace, and then see if it breaks some other
chrp machines (it really shouldn't).
Ok, fine, altough i don't have an idea about the other chrp machine
types out there. From what i know from Geert, generic RTC is already not working
for its box anyway.
Something that just dawned on me again (sorry) is that I've really really
intended to try and kill both prep_time.c and chrp_time.c (since both of
those machine subtypes have PC-style RTC chips) and make them use
todc_time.c (see arch/ppc/kernel/todc_time.c). I've got patches to do
half of this, against 2.6 (which was a trivial forward port of older
2.4-based patches I had, there is nothing 2.6-specific about these
patches). You would want to look at:
006-redo_inb_inw_inl_outb_outw_outl.patch
007-make_out_8_and_friends_synchronous.patch
008-todc_warning.patch
009-prep_time_death-GNU.patch
from http://stop.crashing.org:16080/~trini/
Mmm, i am somewhat confused now on what to do.
If i understood things tight, you either want to :
1) replace ppc.md chrp time stuff with similar code than what
asm-generic/rtc.h is doing.
2) use todc.h for all of prep/chrp.
In the first case, i guess that is easy, and may break some chrp boxes
not using a compatible clock, which may or may not exist.
In the second case, well, the todc code makes use of nvram_write, which
unless i am wrong, is not defined on chrp. the RTC code uses CMOS_WRITE,
so maybe i should define a chrp_write wrapping this one.
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
So, what did you have in mind for this.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Dec 22, 2003 at 02:45:04PM +0100, Sven Luther wrote:
On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
quoted
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
quoted
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
quoted
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
quoted
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
Ok, thanks, i will look into it.
But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.
Yes. The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
set_rtc_time function.
Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)
Ok.
quoted
quoted
BTW, what exactly should i do in 'chrp_get_rtc_time' and
'chrp_set_rtc_time' ? Just replace the existing code, or make a new
function, and set it depending on machine type who needs it in
chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
have to set ppc_md.set_rtc_time accordyingly.
My preferance would be to replace, and then see if it breaks some other
chrp machines (it really shouldn't).
Ok, fine, altough i don't have an idea about the other chrp machine
types out there. From what i know from Geert, generic RTC is already not working
for its box anyway.
quoted
Something that just dawned on me again (sorry) is that I've really really
intended to try and kill both prep_time.c and chrp_time.c (since both of
those machine subtypes have PC-style RTC chips) and make them use
todc_time.c (see arch/ppc/kernel/todc_time.c). I've got patches to do
half of this, against 2.6 (which was a trivial forward port of older
2.4-based patches I had, there is nothing 2.6-specific about these
patches). You would want to look at:
006-redo_inb_inw_inl_outb_outw_outl.patch
007-make_out_8_and_friends_synchronous.patch
008-todc_warning.patch
009-prep_time_death-GNU.patch
from http://stop.crashing.org:16080/~trini/
Mmm, i am somewhat confused now on what to do.
If i understood things tight, you either want to :
1) replace ppc.md chrp time stuff with similar code than what
asm-generic/rtc.h is doing.
2) use todc.h for all of prep/chrp.
In the first case, i guess that is easy, and may break some chrp boxes
not using a compatible clock, which may or may not exist.
In the second case, well, the todc code makes use of nvram_write, which
unless i am wrong, is not defined on chrp. the RTC code uses CMOS_WRITE,
so maybe i should define a chrp_write wrapping this one.
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
I appologize since I ramble a bit too much. For 2.4, the best fix is
(1) above. For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param. Or something along
those lines.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2003-12-22 16:26:01
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
quoted
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
I appologize since I ramble a bit too much. For 2.4, the best fix is
(1) above. For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param. Or something along
those lines.
Ok, i have looked more, and the MC146818 is ok for my box. don't know
about other chrp boxes though.
There is also the todc code in the 2.4 tree though, so it should also be
possible to do it this way, or would it not ?
Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
may also include the pegasos patches Ben has had no time to checkin)
tomorrow.
Next thing i need is a solution for builtin initrd's of bigger sizes.
1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
initrd is uncompressed to some partition, it work fine).
Either that or support for standalone initrd on the disk.
Any idea on how to do this ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
quoted
quoted
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
I appologize since I ramble a bit too much. For 2.4, the best fix is
(1) above. For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param. Or something along
those lines.
Ok, i have looked more, and the MC146818 is ok for my box. don't know
about other chrp boxes though.
There is also the todc code in the 2.4 tree though, so it should also be
possible to do it this way, or would it not ?
It would be possible, but it would be more intrusive for a stable
series.
Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
may also include the pegasos patches Ben has had no time to checkin)
tomorrow.
Next thing i need is a solution for builtin initrd's of bigger sizes.
1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
initrd is uncompressed to some partition, it work fine).
which code subset under arch/ppc/boot does pegasos use? Does it really
have OpenFirmware? I've booted large ramdisks in the past from the
arch/ppc/boot/simple/ stuff (And prep/) but I believe that chrp/pmac
place the initrd at a location high in memory, have holes to deal with,
etc, etc, while simple/ and prep/ (more or less) just ignore the
firmware once it's up.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2003-12-22 16:48:22
On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
quoted
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
quoted
quoted
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
I appologize since I ramble a bit too much. For 2.4, the best fix is
(1) above. For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param. Or something along
those lines.
Ok, i have looked more, and the MC146818 is ok for my box. don't know
about other chrp boxes though.
There is also the todc code in the 2.4 tree though, so it should also be
possible to do it this way, or would it not ?
It would be possible, but it would be more intrusive for a stable
series.
Ok, i will do it the rtc.h way then, and see what happens.
quoted
Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
may also include the pegasos patches Ben has had no time to checkin)
tomorrow.
Next thing i need is a solution for builtin initrd's of bigger sizes.
1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
initrd is uncompressed to some partition, it work fine).
which code subset under arch/ppc/boot does pegasos use?
it is mostly a chrp, except for a few lines patch needed for things as
pci indirection and other such.
Does it really have OpenFirmware?
Yeah, and i even have the source of it (not free software though). OF
coding is a nightmare though.
I've booted large ramdisks in the past from the
arch/ppc/boot/simple/ stuff (And prep/) but I believe that chrp/pmac
Ok.
place the initrd at a location high in memory, have holes to deal with,
Mmm, indeed the initrd is moved to RAM_END - initrd_size by
arch/ppc/boot/chrp/main.c:chrpboot, where RAM_END is defined as 64<<20
(which is 64Mo and i have 128Mo). the pmac chrp boot uses only 16<<20.
Mmm, maybe arch/ppc/kernel/setup.c:plafrom_init does contain only stuff
for prep, not chrp, not sure, chrp_init.c in chrp_setup.c does use r6
and r7 for determining the initrd location and size.
Actually, i don't really know enough about this to fix this issue alone,
i have no knowledge of the holes you speak about for example :((
Time for more kernel source reading then :))
etc, etc, while simple/ and prep/ (more or less) just ignore the
firmware once it's up.
Mmm I didn't know about simple, what subarches use that one exactly ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Dec 22, 2003 at 05:48:22PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
quoted
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
quoted
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
quoted
quoted
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
I appologize since I ramble a bit too much. For 2.4, the best fix is
(1) above. For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param. Or something along
those lines.
Ok, i have looked more, and the MC146818 is ok for my box. don't know
about other chrp boxes though.
There is also the todc code in the 2.4 tree though, so it should also be
possible to do it this way, or would it not ?
It would be possible, but it would be more intrusive for a stable
series.
Ok, i will do it the rtc.h way then, and see what happens.
quoted
quoted
Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
may also include the pegasos patches Ben has had no time to checkin)
tomorrow.
Next thing i need is a solution for builtin initrd's of bigger sizes.
1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
initrd is uncompressed to some partition, it work fine).
which code subset under arch/ppc/boot does pegasos use?
it is mostly a chrp, except for a few lines patch needed for things as
pci indirection and other such.
quoted
Does it really have OpenFirmware?
Yeah, and i even have the source of it (not free software though). OF
coding is a nightmare though.
quoted
I've booted large ramdisks in the past from the
arch/ppc/boot/simple/ stuff (And prep/) but I believe that chrp/pmac
Ok.
quoted
place the initrd at a location high in memory, have holes to deal with,
Mmm, indeed the initrd is moved to RAM_END - initrd_size by
arch/ppc/boot/chrp/main.c:chrpboot, where RAM_END is defined as 64<<20
(which is 64Mo and i have 128Mo). the pmac chrp boot uses only 16<<20.
Which introduces a (potential) problem of the initrd growing down into
the kernel, for very large initrds. I don't recall why it's done this
way here.
Mmm, maybe arch/ppc/kernel/setup.c:plafrom_init does contain only stuff
for prep, not chrp, not sure, chrp_init.c in chrp_setup.c does use r6
and r7 for determining the initrd location and size.
One potential problem is that perhaps chrp hasn't been updated to prefer
(or the boot/ code updated) to use BI_INITRD stuff, ala simple/ and
prep/, and perhaps there's still someone assuming that it's being passed
in start/end, not start/size information.
Actually, i don't really know enough about this to fix this issue alone,
i have no knowledge of the holes you speak about for example :((
The holes would be in OF itself. IIRC this is true of some oldworld
pmacs for example.
quoted
etc, etc, while simple/ and prep/ (more or less) just ignore the
firmware once it's up.
Mmm I didn't know about simple, what subarches use that one exactly ?
From: Mark Guertin <hidden> Date: 2003-12-22 17:02:43
On 22-Dec-03, at 11:48 AM, Sven Luther wrote:
quoted
Does it really have OpenFirmware?
Yeah, and i even have the source of it (not free software though). OF
coding is a nightmare though.
It's not really OpenFirmware ... it's SmartFirmware is it not? it's
sort of an open firmware/openboot derivative...
Slightly OT, but Sven, is there access to /dev/nvram available yet on
pegasos? I've still got a forth bootloader menu somewhere here that I
made for the pegasos, which I've never been able to load (without
massive typing at SF prompt)...but my pegasos is non functional so I
may find it this week and email the file to you to fight with :)
Gerk
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2003-12-22 17:27:36
On Mon, Dec 22, 2003 at 12:02:43PM -0500, Mark Guertin wrote:
On 22-Dec-03, at 11:48 AM, Sven Luther wrote:
quoted
quoted
Does it really have OpenFirmware?
Yeah, and i even have the source of it (not free software though). OF
coding is a nightmare though.
It's not really OpenFirmware ... it's SmartFirmware is it not? it's
Yes, it is based on SmartFirmware.
Slightly OT, but Sven, is there access to /dev/nvram available yet on
No, there is no /dev/nvram, i don't believe there ever will be, not
sure. I think there is no physical nvram for such a device in the
hardware.
pegasos? I've still got a forth bootloader menu somewhere here that I
made for the pegasos, which I've never been able to load (without
massive typing at SF prompt)...but my pegasos is non functional so I
may find it this week and email the file to you to fight with :)
Well, my own solution to this, is to implement the boot loader thingy
directly in the OS/SF/whatever. My plan is to have a function to read a
file on disk, which would contain a grub like format (i like it more
than yaboot/lilo like format) and construct a boot-loader menu from
this.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 06:54:58
On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
quoted
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
quoted
quoted
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.
I appologize since I ramble a bit too much. For 2.4, the best fix is
(1) above. For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param. Or something along
those lines.
Ok, i have looked more, and the MC146818 is ok for my box. don't know
about other chrp boxes though.
There is also the todc code in the 2.4 tree though, so it should also be
possible to do it this way, or would it not ?
It would be possible, but it would be more intrusive for a stable
series.
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?
If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-07 07:22:25
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?
If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?
will the kernel let you build both drivers in ?
then you can do, in 2.4, something ugly like that:
#ifdef CONFIG_ALL_PPC
if (_machine == _MACH_Pmac)
return -ENODEV;
#endif
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 07:43:12
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
quoted
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?
If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?
will the kernel let you build both drivers in ?
Yes, sure. But naturally they die horribly on pmac hardware, or so i am
told.
then you can do, in 2.4, something ugly like that:
#ifdef CONFIG_ALL_PPC
if (_machine == _MACH_Pmac)
return -ENODEV;
#endif
Ok, cool, will try that out.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 07:47:40
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
quoted
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?
If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?
will the kernel let you build both drivers in ?
then you can do, in 2.4, something ugly like that:
#ifdef CONFIG_ALL_PPC
if (_machine == _MACH_Pmac)
return -ENODEV;
#endif
Mmm, two questions :
1) could a #ifdef __powerpc__ not be enough ?
2) The other failures in rtc_init return -EIO, not -ENODEV.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
quoted
BTW, i didn't manage to get the generic RTC code working on my
pegasos, and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be
to add a test for the presence of a pmac in the CONFIG_RTC code, and
abort if one is found ?
If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?
will the kernel let you build both drivers in ?
yes, which will cause all powermacs to hang on bootup when hwclock is run.
then you can do, in 2.4, something ugly like that:
#ifdef CONFIG_ALL_PPC
if (_machine == _MACH_Pmac)
return -ENODEV;
#endif
which im betting will instead cause hwclock to fail on all powermacs
with: hwclock: /dev/rtc: No such device
but i could be missing something obvious with your suggestion.
--
Ethan Benson
http://www.alaska.net/~erbenson/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-07 08:30:06
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
2) The other failures in rtc_init return -EIO, not -ENODEV.
Well, in this case, -ENODEV makes more sense, though nothing really
cares except the kind of error message the user will get when using
it as a module.
Friendly,
Sven Luther
--
Benjamin Herrenschmidt [off-list ref]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 09:53:58
On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
quoted
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
Ok. I suppose it doesn't make sense also to include the #ifdef
CONFIG_ALL_PPC in a #ifdef __powerpc__ ?
quoted
2) The other failures in rtc_init return -EIO, not -ENODEV.
Well, in this case, -ENODEV makes more sense, though nothing really
cares except the kind of error message the user will get when using
it as a module.
I think i will keep it as the others for the debian package.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-07 10:44:28
On Wed, 2004-01-07 at 20:53, Sven Luther wrote:
On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
quoted
quoted
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
Ok. I suppose it doesn't make sense also to include the #ifdef
CONFIG_ALL_PPC in a #ifdef __powerpc__ ?
Yup, useless to stack them.
quoted
quoted
2) The other failures in rtc_init return -EIO, not -ENODEV.
Well, in this case, -ENODEV makes more sense, though nothing really
cares except the kind of error message the user will get when using
it as a module.
I think i will keep it as the others for the debian package.
Why ? The error is definitely not an IO error :) Nothing really relies
on this error code anyway...
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 10:54:37
On Wed, Jan 07, 2004 at 09:44:28PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2004-01-07 at 20:53, Sven Luther wrote:
quoted
On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
quoted
quoted
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
Ok. I suppose it doesn't make sense also to include the #ifdef
CONFIG_ALL_PPC in a #ifdef __powerpc__ ?
Yup, useless to stack them.
quoted
quoted
quoted
2) The other failures in rtc_init return -EIO, not -ENODEV.
Well, in this case, -ENODEV makes more sense, though nothing really
cares except the kind of error message the user will get when using
it as a module.
I think i will keep it as the others for the debian package.
Why ? The error is definitely not an IO error :) Nothing really relies
on this error code anyway...
So, would it be meaningfull to change all the others to NODEV too ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 11:27:26
On Tue, Jan 06, 2004 at 10:51:51PM -0900, Ethan Benson wrote:
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
quoted
quoted
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?
If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?
will the kernel let you build both drivers in ?
yes, which will cause all powermacs to hang on bootup when hwclock is run.
Yeah, that i know, and want to workaround.
quoted
then you can do, in 2.4, something ugly like that:
#ifdef CONFIG_ALL_PPC
if (_machine == _MACH_Pmac)
return -ENODEV;
#endif
which im betting will instead cause hwclock to fail on all powermacs
with: hwclock: /dev/rtc: No such device
Mmm, notice that this is the rtc_init code, not the rtc ioctl's
themself. In my understanding this is launched when the kernel is
loaded, and is used to setup the rtc clock. If it fails, then no harm
should be done, since the generic rtc driver should take over, not sure
though.
but i could be missing something obvious with your suggestion.
Maybe. i need someone who would like to test this. Do you volunteer ?
Below is my current patch. Please someone with pmac hardware, please
build a kernel with this applied and the CONFIG_RTC enabled in the
character driver section and report back to me. It would be nice if i
could upload a package which includes this fix today yet.
------------------- patch ------------------------
@@ -707,6 +707,12 @@#endif#endif+#ifdef CONFIG_ALL_PPC+/* This driver will make pmac hardware die horribly */+if(_machine==_MACH_Pmac)+return-EIO;+#endif+#ifdef __sparc__for_each_ebus(ebus){for_each_ebusdev(edev,ebus){-------------------patch------------------------
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-07 11:47:37
So, would it be meaningfull to change all the others to NODEV too ?
You are beeing anal or what ? :)
Who cares about that legacy driver in 2.4 anyway :)
If you really want, I suppose the failure on request_region could
return -EBUSY, not sure about the best error to return from failures
on request_irq...
Nobody really cares about those codes though. At least not in this driver.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-07 11:53:22
On Wed, Jan 07, 2004 at 10:47:37PM +1100, Benjamin Herrenschmidt wrote:
quoted
So, would it be meaningfull to change all the others to NODEV too ?
You are beeing anal or what ? :)
Who cares about that legacy driver in 2.4 anyway :)
If you really want, I suppose the failure on request_region could
return -EBUSY, not sure about the best error to return from failures
on request_irq...
Nobody really cares about those codes though. At least not in this driver.
Ok, i will return whatever you want, and we don't really care about the
code, provided it boots ok, doesn't hang the powermacs at hwclock
invocation time, and clock works for them.
Still in search for a volunteer.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Jan 07, 2004 at 12:27:26PM +0100, Sven Luther wrote:
Mmm, notice that this is the rtc_init code, not the rtc ioctl's
themself. In my understanding this is launched when the kernel is
loaded, and is used to setup the rtc clock. If it fails, then no harm
should be done, since the generic rtc driver should take over, not sure
though.
sounds iffy to me. especially if both are compiled as modules, in
which case the rtc module will be loaded, fail and im betting the
whole thing stops right there.
debian used to ship kernels with both PPC_RTC and RTC as modules,
hoping the right one would magically load and work on the right
hardware, of couse this was not the case, RTC was always loaded, and
broke powermacs.
quoted
but i could be missing something obvious with your suggestion.
Maybe. i need someone who would like to test this. Do you volunteer ?
i don't have time, sorry.
quoted hunk
Below is my current patch. Please someone with pmac hardware, please
build a kernel with this applied and the CONFIG_RTC enabled in the
character driver section and report back to me. It would be nice if i
could upload a package which includes this fix today yet.
------------------- patch ------------------------
@@ -707,6 +707,12 @@#endif#endif+#ifdef CONFIG_ALL_PPC+/* This driver will make pmac hardware die horribly */+if(_machine==_MACH_Pmac)+return-EIO;+#endif+#ifdef __sparc__for_each_ebus(ebus){for_each_ebusdev(edev,ebus){-------------------patch------------------------
From: Sven Luther <hidden> Date: 2004-01-07 14:47:44
On Wed, Jan 07, 2004 at 03:28:28AM -0900, Ethan Benson wrote:
On Wed, Jan 07, 2004 at 12:27:26PM +0100, Sven Luther wrote:
quoted
Mmm, notice that this is the rtc_init code, not the rtc ioctl's
themself. In my understanding this is launched when the kernel is
loaded, and is used to setup the rtc clock. If it fails, then no harm
should be done, since the generic rtc driver should take over, not sure
though.
sounds iffy to me. especially if both are compiled as modules, in
which case the rtc module will be loaded, fail and im betting the
whole thing stops right there.
Yeah, not sure also, need a volunteer to test it.
debian used to ship kernels with both PPC_RTC and RTC as modules,
hoping the right one would magically load and work on the right
hardware, of couse this was not the case, RTC was always loaded, and
broke powermacs.
Yeah, but this was because the RTC driver does some rtc register probing
the pmac hardware does not like. If the RTC clock detects it is a pmac,
it will fail to initialize before causing damage.
The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the RTC driver should be ok.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
quoted
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
Technically it's '0' on !CONFIG_ALL_PPC, but (for the sake of fullness)
I don't know if ppc64 defines __powerpc__ :)
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Jan 07, 2004 at 10:27:33PM -0900, Ethan Benson wrote:
On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
quoted
The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the RTC driver should be ok.
which breaks hwclock, not acceptable.
This is getting _much_ uglier, but how about:
1) Modify genrtc.c and rtc.c so that they do _not_ initalize on their
own.
2) Create a 'dummy_rtc.c' driver that just tests _machine and calls
rtc.c's init bits on chrp (or just pegasos) and genrtc's bits otherwise.
And again, this is ugly ugly ugly, and I disavow any knowledge of
typing the above.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-08 17:47:40
On Thu, Jan 08, 2004 at 08:53:31AM -0700, Tom Rini wrote:
On Wed, Jan 07, 2004 at 10:27:33PM -0900, Ethan Benson wrote:
quoted
On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
quoted
The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the RTC driver should be ok.
This doesn't work anyway, it stops pmacs from hanging but still there is
a long wait, which you can ^C interrupt.
I believe this is because since there is the RTC clock, the GENERIC_RTC
code will not be called or something.
quoted
which breaks hwclock, not acceptable.
This is getting _much_ uglier, but how about:
1) Modify genrtc.c and rtc.c so that they do _not_ initalize on their
own.
2) Create a 'dummy_rtc.c' driver that just tests _machine and calls
rtc.c's init bits on chrp (or just pegasos) and genrtc's bits otherwise.
And again, this is ugly ugly ugly, and I disavow any knowledge of
typing the above.
That would be a solution, but i think i will look again at my previous
effort.
Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
the clock is set, but only _later_. This has as result that the clock is
wrong when it is the time for filesystem checks, and thus filesystems
are checked each time.
Strange.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-08 21:53:07
Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
the clock is set, but only _later_. This has as result that the clock is
wrong when it is the time for filesystem checks, and thus filesystems
are checked each time.
Your arch code should set an initial UTC time in the kernel
that is correct, which is why you really want to properly
implement working ppc_md.{get,set_rtc_time}, that will get you
this functionality along with working GENERIC_RTC
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-08 21:57:32
On Fri, Jan 09, 2004 at 08:53:07AM +1100, Benjamin Herrenschmidt wrote:
quoted
Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
the clock is set, but only _later_. This has as result that the clock is
wrong when it is the time for filesystem checks, and thus filesystems
are checked each time.
Your arch code should set an initial UTC time in the kernel
that is correct, which is why you really want to properly
implement working ppc_md.{get,set_rtc_time}, that will get you
this functionality along with working GENERIC_RTC
Yep, that is what i thought to.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/