On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
quoted
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.
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.
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
On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
quoted
On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
quoted
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.
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.
What about modifying qemu's OF to emulate a chrp machine instead ?
Friendly,
Sven Luther
On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
quoted
On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
quoted
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.
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.
--
Tom Rini
http://gate.crashing.org/~trini/