Skip to contentSkip to conversation

Use todc on Mot PReP platforms

PATCH In review Matt Porter 7 participants 12 messages Aug 10, 2005 – Sep 4, 2005

lore
Share & tools
lore

Matt Porter

author
#0 lore raw

PATCH 1/1 Use todc on Mot PReP platforms

This restores behavior from 2.4 where PReP platforms identified as Motorola would calibrate the decrementer using the RTC. On real Motorola PReP hardware this isn't needed. However, in order to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola PReP system) it is necessary to allow it to calibrate the decrementer using an emulated RTC. If the decrementer rate is read from residual data then timing is screwed since a qemu PReP system typically runs much faster than the original hardware.

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

-Matt

arch/ppc/platforms/prep_setup.c +3 -3
@@ -940,8 +940,7 @@ prep_calibrate_decr(void)
 			tb_to_us = mulhwu_scale_factor(freq/divisor, 1000000);
 			tb_ticks_per_jiffy = freq / HZ / divisor;
 		}
-	}
-	else
+	} else
 		todc_calibrate_decr();
 }
 

@@ -1155,16 +1154,17 @@ prep_init(unsigned long r3, unsigned lon
 
 	ppc_md.time_init      = todc_time_init;
 	if (_prep_type == _PREP_IBM) {
+		ppc_md.calibrate_decr = prep_calibrate_decr;
 		ppc_md.rtc_read_val = todc_mc146818_read_val;
 		ppc_md.rtc_write_val = todc_mc146818_write_val;
 		TODC_INIT(TODC_TYPE_MC146818, RTC_PORT(0), NULL, RTC_PORT(1),
 				8);
 	} else {
+		ppc_md.calibrate_decr = todc_calibrate_decr;
 		TODC_INIT(TODC_TYPE_MK48T59, PREP_NVRAM_AS0, PREP_NVRAM_AS1,
 				PREP_NVRAM_DATA, 8);
 	}
 
-	ppc_md.calibrate_decr = prep_calibrate_decr;
 	ppc_md.set_rtc_time   = todc_set_rtc_time;
 	ppc_md.get_rtc_time   = todc_get_rtc_time;
#1 lore raw
Quoted 9 lines · Matt Porter

This restores behavior from 2.4 where PReP platforms identified as Motorola would calibrate the decrementer using the RTC. On real Motorola PReP hardware this isn't needed. However, in order to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola PReP system) it is necessary to allow it to calibrate the decrementer using an emulated RTC. If the decrementer rate is read from residual data then timing is screwed since a qemu PReP system typically runs much faster than the original hardware.

Quoted 4 lines

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

So, I like this, and not just because I'm playing with qemu as well. Leigh, can you run this on any 'interesting' PReP you've got that might tickle a bug here? Thanks.

Signature · 2 lines
Tom Rini
http://gate.crashing.org/~trini/
#2 lore raw
Quoted 5 lines · Matt Porter
Quoted 4 lines

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

i applied the patch to the latest 2.6-git tree and my PReP[1] boots just fine!

thanks for maintaining this exotic platform,
Christian.

[1] http://www.nerdbynature.de/bits/hal/2.6.13-rc6

Signature · 3 lines
BOFH excuse #367:

Webmasters kidnapped by evil cult.
#3 lore raw

use of rtc.c on chrp/prep?

Does anyone enable CONFIG_RTC on chrp/prep? Tom tells me these are the only platforms that it is even valid to do so on.

- kumar

#4 lore raw

Re: use of rtc.c on chrp/prep?

Quoted 2 lines · Kumar Gala

Does anyone enable CONFIG_RTC on chrp/prep? Tom tells me these are the only platforms that it is even valid to do so on.

The debian powerpc kernels enables :

  $ grep RTC /boot/config-2.6.12-1-powerpc
  CONFIG_GEN_RTC=y
  CONFIG_GEN_RTC_X=y

and not the CONFIG_RTC variant, and it works well on pegasos, and prep boxes, and probably on ibm chrps too, altough i have not tested personally.

Friendly,

Sven Luther

#5 lore raw

Re: use of rtc.c on chrp/prep?

Quoted 8 lines · Sven Luther
Quoted 3 lines · Kumar Gala

Does anyone enable CONFIG_RTC on chrp/prep? Tom tells me these are the only platforms that it is even valid to do so on.

The debian powerpc kernels enables :

Quoted 7 lines
  $ grep RTC /boot/config-2.6.12-1-powerpc
  CONFIG_GEN_RTC=y
  CONFIG_GEN_RTC_X=y

and not the CONFIG_RTC variant, and it works well on pegasos, and prep boxes,
and probably on ibm chrps too, altough i have not tested personally.

Thanks, as far as I can tell no one is using CONFIG_RTC, which means I can "fix" asm-ppc/mc146818rtc.h to no longer #define RTC_IRQ 8

- kumar

#6 lore raw

Re: use of rtc.c on chrp/prep?

Quoted 14 lines · Kumar Gala
Quoted 12 lines · Sven Luther
Quoted 3 lines · Kumar Gala

Does anyone enable CONFIG_RTC on chrp/prep? Tom tells me these are the only platforms that it is even valid to do so on.

The debian powerpc kernels enables :

 $ grep RTC /boot/config-2.6.12-1-powerpc
 CONFIG_GEN_RTC=y
 CONFIG_GEN_RTC_X=y
Quoted 6 lines
Quoted 3 lines

and not the CONFIG_RTC variant, and it works well on pegasos, and prep boxes,
and probably on ibm chrps too, altough i have not tested personally.

Thanks, as far as I can tell no one is using CONFIG_RTC, which means I can "fix" asm-ppc/mc146818rtc.h to no longer #define RTC_IRQ 8

For the record, on MVME boards with PowerPlus bridges, the RTC driver cannot work because the interrupt output is not connected. IRQ 8 is instead connected to a front panel switch labelled abort that nobody uses either (at least under Linux).

Anyway, there are better ways to obtain regularly spaced interrupts on PPC. They are just not implemented (yet).

Gabriel

#7 lore raw

Re: use of rtc.c on chrp/prep?

In reply to Kumar Gala
Quoted 2 lines · Kumar Gala

Does anyone enable CONFIG_RTC on chrp/prep? Tom tells me these are the only platforms that it is even valid to do so on.

hm, "grep CONFIG_RTC arch/ppc/configs/*" returns nothing and i don't find this option in my .config (anymore?). CONFIG_GEN_RTC and CNFIG_GEN_RTC_X is working fine here [1].

Christian.

[1] http://nerdbynature.de/bits/hal/2.6.13/

Signature · 3 lines
BOFH excuse #1:

clock speed
author
#8 lore raw
In reply to Tom Rini
Quoted 11 lines · Tom Rini
Quoted 9 lines · Matt Porter

This restores behavior from 2.4 where PReP platforms identified as Motorola would calibrate the decrementer using the RTC. On real Motorola PReP hardware this isn't needed. However, in order to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola PReP system) it is necessary to allow it to calibrate the decrementer using an emulated RTC. If the decrementer rate is read from residual data then timing is screwed since a qemu PReP system typically runs much faster than the original hardware.

Quoted 6 lines
Quoted 4 lines

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

So, I like this, and not just because I'm playing with qemu as well.

Why? It has no other redeeming quality except that it makes qemu work. It's better to use residual data versus todc calibration in real machine cases since residual data is accurate for this particular value on these machines. I'm just curious why you would like this patch outside of its qemu value.

BTW, it's _possible_ that we might eventually modify the open hackware OF to do a timing loop and dynamically fill in the residual data time base freq but that's unfamiliar territory and this is an easy workaround.

Quoted 2 lines

Leigh, can you run this on any 'interesting' PReP you've got that might tickle a bug here? Thanks.

Let me know if there's anything more that needs to be tested. Otherwise, I plan to send upstream soon.

Thanks,
Matt

#9 lore raw
Quoted 25 lines · Matt Porter
Quoted 11 lines · Tom Rini
Quoted 9 lines · Matt Porter

This restores behavior from 2.4 where PReP platforms identified as Motorola would calibrate the decrementer using the RTC. On real Motorola PReP hardware this isn't needed. However, in order to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola PReP system) it is necessary to allow it to calibrate the decrementer using an emulated RTC. If the decrementer rate is read from residual data then timing is screwed since a qemu PReP system typically runs much faster than the original hardware.

Quoted 6 lines
Quoted 4 lines

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

So, I like this, and not just because I'm playing with qemu as well.

Why? It has no other redeeming quality except that it makes qemu work. It's better to use residual data versus todc calibration in real machine cases since residual data is accurate for this particular value on these machines. I'm just curious why you would like this patch outside of its qemu value.

Quoted 4 lines

BTW, it's _possible_ that we might eventually modify the open hackware OF to do a timing loop and dynamically fill in the residual data time base freq but that's unfamiliar territory and this is an easy workaround.

What about modifying qemu's OF to emulate a chrp machine instead ?

Friendly,

Sven Luther

author
#10 lore raw
Quoted 26 lines · Sven Luther
Quoted 25 lines · Matt Porter
Quoted 11 lines · Tom Rini
Quoted 9 lines · Matt Porter

This restores behavior from 2.4 where PReP platforms identified as Motorola would calibrate the decrementer using the RTC. On real Motorola PReP hardware this isn't needed. However, in order to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola PReP system) it is necessary to allow it to calibrate the decrementer using an emulated RTC. If the decrementer rate is read from residual data then timing is screwed since a qemu PReP system typically runs much faster than the original hardware.

Quoted 6 lines
Quoted 4 lines

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

So, I like this, and not just because I'm playing with qemu as well.

Why? It has no other redeeming quality except that it makes qemu work. It's better to use residual data versus todc calibration in real machine cases since residual data is accurate for this particular value on these machines. I'm just curious why you would like this patch outside of its qemu value.

Quoted 6 lines
Quoted 4 lines

BTW, it's _possible_ that we might eventually modify the open hackware OF to do a timing loop and dynamically fill in the residual data time base freq but that's unfamiliar territory and this is an easy workaround.

What about modifying qemu's OF to emulate a chrp machine instead ?

That's good, but not the point of this exercise...at least for me. :) Eventually, we should be able to boot a stock prep, chrp, or pmac image built from the mainline kernel defconfig. Personally, I want to boot some stock embedded kernels as well, but that's a lot more work emulating on-chip I/O.

FWIW, jmayer did PReP first because all the PeeCee hardware was already emulated. I believe CHRP/Pmac work to some degree but I haven't personally tried them yet.

-Matt

#11 lore raw
In reply to Matt Porter
Quoted 12 lines · Matt Porter
Quoted 11 lines · Tom Rini
Quoted 9 lines · Matt Porter

This restores behavior from 2.4 where PReP platforms identified as Motorola would calibrate the decrementer using the RTC. On real Motorola PReP hardware this isn't needed. However, in order to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola PReP system) it is necessary to allow it to calibrate the decrementer using an emulated RTC. If the decrementer rate is read from residual data then timing is screwed since a qemu PReP system typically runs much faster than the original hardware.

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

If anybody has objections to this as the default, let me know. It still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't affect the IBM PReP paths. My goal with this is to be able to run a stock 2.6 defconfig PReP build on qemu.

So, I like this, and not just because I'm playing with qemu as well.

Why? It has no other redeeming quality except that it makes qemu work.

And it gets us away from residual data which can be crap or non existant. FWIW, I've move past using qemu, and I still like the change.

Signature · 2 lines
Tom Rini
http://gate.crashing.org/~trini/