Timer Read and Capture bug / errata for NS9210

Embedded Devices Linux
, , , ,
1

Hi,

About 3 years ago we discovered a problem on DigiConnect ME module. gettimeofday() on DigiEL-5.2 when called successively sometimes produced non-monotonic results. The test environment did not contain services that could adjust CLOCK_REALTIME (like ntpd). It just occasionally jumped backwards “by itself”.

We raised the issue with our local support, and through the support chain they got us a kernel patch that boiled down to the following code in arch/arm/mach-ns9xxx/time-ns921x.c: simple

static cycle_t ns921x_clocksource_read(void)
{
return __raw_readl(SYS_TRC(TIMER_CLOCKSOURCE));
}

was replaced with

/**

  • The Read an Capture register is divided in two parts of 16 bits that allows

  • to configure the timer as 16 or 32 bits. When configured as 32 bits, it

  • seems like the read is not totally atomic, as many times the lower 2 bytes

  • are stuck in 0xffff, producing a wrong value which might result in readings

  • going backwards in time. In this case a new read is necessary.

  • TODO: this is a HW bug to be verified with the ASIC team
    */
    static cycle_t ns921x_clocksource_read(void)
    {
    u32 newval, clkval;

     clkval = __raw_readl(SYS_TRC(TIMER_CLOCKSOURCE));
 if ((u16)clkval == 0xffff) {
         newval = __raw_readl(SYS_TRC(TIMER_CLOCKSOURCE));
         if (newval < clkval)
                clkval = newval;
 }
 return clkval;

}

The question is, has the ASIC bug been confirmed or fixed? Since what chip revision? Errata for NS9210 available on Digi website does not mention any bugs with Timer 0-9. Kernel from DigiEL-5.7 that we use in out products has the old (unpatched) implementation of ns921x_clocksource_read() function.

The reason why I ask is that we’re having problems with clock_gettime(CLOCK_MONOTONIC, …) that produces non-monotonic results (jump backwards) occasionally in our products, and we’d like to find what causes it.

Thanks!

2

Can you please provide more details on the case you had with Digi support when the patch for DEL 5.2 was provided?

I can try to trace it back that way.

Did the patch properly address the issue? If not , can you please explain why? Is DEL 5.7 already patched? or have you tried to apply the same fix?

To the best of my knowledge there was no re-spins or new revisions of NS9210

Have you tried to open a support case on this?

3

Latest DEL-5.7.2 build id: 20111124
has the patched version you listed above.
If your DEL-5.7 does not, you maybe have DEL-5.7.0 or DEL-5.7.1. Make sure you update your DEL with the ESP integrated package manager to latest DEL updates.

4

> Can you please provide more details on the case you had with Digi support when the patch for DEL 5.2 was provided?
I can only probably disclose the support case number here: 1329070.

> Did the patch properly address the issue?
According to my knowledge, yes.

> Is DEL 5.7 already patched?
No. The version that we use is not but see the other answer, looks like the patch has appeared in DEL 5.7.2. We originally thought that either the problem was fixed somewhere else in the kernel or the silicon has been fixed. We are using quite recent samples in production.

> Have you tried to open a support case on this?
In the past, yes. See the provided number.