Nitrogen6x clock inconsistency

[amin_rahimi]

I'm running a Yocto (Dora) build on my Nitrogen6x board and I'm having some issues with the software clock speed. Any sleep or timer functions in my C++ code or my console take about 3 times longer than they should.  As a simple demonstration, I ran two commands in my console:

root@nitrogen6x:~# hwclock; sleep 10; hwclock

Sun Nov 23 23:11:59 2014  0.000000 seconds

Sun Nov 23 23:12:29 2014  0.000000 seconds

root@nitrogen6x:~# date; sleep 10; date

Sun Nov 23 23:01:48 UTC 2014

Sun Nov 23 23:01:58 UTC 2014

The sleep command returns after 30 seconds, instead of 10. hwclock correctly shows an elapsed time of 30 seconds, while date shows the sleep command as only having taken 10 seconds.

I don't know if this is related, but /proc/cpuinfo shows the BogoMIPS of the first processor as being roughly 3 times that of the other three while the U-Boot output (attached) shows 9487.15 BogoMIPS total.

Processor       : ARMv7 Processor rev 10 (v7l)

processor       : 0

BogoMIPS        : 2371.98

processor       : 1

BogoMIPS        : 790.52

processor       : 2

BogoMIPS        : 790.52

processor       : 3

BogoMIPS        : 790.52

Features        : swp half thumb fastmult vfp edsp neon vfpv3

CPU implementer : 0x41

CPU architecture: 7

CPU variant     : 0x2

CPU part        : 0xc09

CPU revision    : 10

Hardware        : Boundary Devices Nitrogen6X/SABRE Lite Board

Revision        : 63000

Serial          : 0000000000000000

Any thoughts on what could be causing this?  Thanks in advance for your help.

Original Attachment has been moved to: uboot_output.txt.zip

[EricNelson]

Hello Amin,

Can you double-check the silicon revision?

The second line of output should show something like this, and the "rev1.x" is the

processor version:

CPU:  Freescale i.MX6Q rev1.2 at 792 MHz

If memory serves, there was a bug in the clock handling for older CPUs.

I believe we addressed it, but I'm not sure whether it was applied to the 3.0.35 kernel used in Dora.

[amin_rahimi]

Eric,

Thanks for your response.  The output reads "CPU:   Freescale i.MX6Q rev1.0 at 792 MHz".

[EricNelson · Accepted solution]

Hello Amin,

Please try an image with a later kernel to see if the problem persists.

The easiest to test is probably the December Ubuntu release:

     http://boundarydevices.com/ubuntu-trusty-december-2014-release/

Or perhaps this Yocto Dizzy image from November:

     http://boundarydevices.com/dizzy-release-yocto/

Note that silicon revision 1.0 isn't actively being supported, so there are likely to be some other bugs.

In particular, Gary Bisson fixed an HDMI clocking bug in December:
     https://lists.yoctoproject.org/pipermail/meta-freescale/2014-December/011776.html

There may be others lingering.

Regards,

Eric

[OtavioSalvador]

You can also test the image we auto-build[1]. It has this patches applied.

http://ci.ossystems.com.br/public/fsl-community-bsp/dizzy/

[amin_rahimi]

The Dizzy image works just fine. Looks like I'll need to update our system. Thanks for the help, all!

[igorpadykov]

Hi Amin

please use latest dizzy release, it is much more polished

http://boundarydevices.com/dizzy-release-yocto/

Best regards

igor