The basis for this patch has been discussed on l-a-k on a thread
with subject line "IXP4xx timer interupt bug" then later on
[email protected] on a thread "ixp4xx variable
timer base issue".
The problem is that the NSLU2 deviates from the Intel IXDP425
system by using a cystal with frequency 66MHz as opposed to the
Intel stated (not quite mandated) value of 66.666666MHz. This
results in serious errors in the RTC (1%).
The patch configs in the correct value for the NSLU2. The problem
with the patch is that a multi-config kernel which includes NSLU2
support will use the NSLU2 frequency. However such kernels are
not a requirement as generic kernels are never flashed into NSLU2
systems (so there is no need to build NSLU2 support into a generic
kernel).
Signed-off-by: John Bowler <[email protected]>
--- linux-2.6.13.1/include/asm-arm/arch-ixp4xx/timex.h 2005-09-17 12:42:45.000000000 +0200
+++ nslu2-2.6.13.1/include/asm-arm/arch-ixp4xx/timex.h 2005-09-17 12:15:31.000000000 +0200
@@ -9,7 +9,12 @@
* We use IXP425 General purpose timer for our timer needs, it runs at
* 66.66... MHz. We do a convulted calculation of CLOCK_TICK_RATE b/c the
* timer register ignores the bottom 2 bits of the LATCH value.
+ * The NSLU2 has a 33.00MHz crystal, so a different FREQ is required.
*/
+#ifdef CONFIG_MACH_NSLU2
+#define FREQ 66000000
+#else
#define FREQ 66666666
+#endif
#define CLOCK_TICK_RATE (((FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
John,
On Thu, Oct 27, 2005 at 11:32:25PM -0700, John Bowler wrote:
> The problem is that the NSLU2 deviates from the Intel IXDP425
> system by using a cystal with frequency 66MHz as opposed to the
> Intel stated (not quite mandated) value of 66.666666MHz. This
> results in serious errors in the RTC (1%).
>
> The patch configs in the correct value for the NSLU2. The problem
> with the patch is that a multi-config kernel which includes NSLU2
> support will use the NSLU2 frequency. However such kernels are
> not a requirement as generic kernels are never flashed into NSLU2
> systems (so there is no need to build NSLU2 support into a generic
> kernel).
As previously stated: with this patch, compiling in support for the
NSLU2 will make the timer tick base right for the NSLU2 but wrong
for everything else.
There are two ways of dealing with this problem:
1/ The patch you sent, plus some config hacks to make it impossible
to compile in NSLU2 support together with support for another ixp4xx
machine type that has FREQ=66666666, sidestepping the issue; or
2/ Make the ixp4xx timer tick base runtime selectable altogether, for
example with the patch that I sent to linux-arm-kernel a while ago.
I'm not very much in favor of 1/, but at least it's better than not
having any kind of protection at all. If you leave it to the user,
they simply _are_ going to get it messed up.
--L