The tale of the S5P6818 architected timer

Working around a broken CPU to get high resolution timing on at least one CPU

Among the many projects I’m working on is a new version of the Tacronome pedal my company makes. It’s essentially a metronome that is tailored to live music production. The original version of the pedal was based on a Freescale MCU and ran FreeRTOS. The new version is based on a Samsung ARTIK710 module and runs Linux.

The 710 is near or at the top of the ARTIK line, with an octo-core CPU and blah blah. Pretty slick little board. But sometimes you don’t learn about all of the caveats until you actually build it into something.

Begin the tale of the S5P6818 architected timer.

One bright September day in 2012 (yes, I made that up — I pulled that date out of thin air and I have no idea when it really was), Samsung decided to put the Nexell S5P6818 CPU in the ARTIK 710 board. This CPU is from the ARMv8 lineage and has 8 Cortex-A53 cores. As an ARMv8 architecture, it has a per-core timer scheme called generic timers, or in Linux nomenclature, architected timers. I believe that the term architected timers is used because the actual per-core timer scheme that powers it is different depending on the CPU architecture. These per-core timers are perfect for things like Linux high-resolution timers.

Except they don’t work on this chip.

Given that I’m working on a timing product, HR timers are more than interesting. The signal I need to generate needs precision of 50 microseconds or so and is fairly tolerant of jitter, so Linux should be cool to handle this, even from userspace. When a fellow developer suggested on the ARTIK forum that the precision of delays was limited to the OS tick, it caught my attention. I’m not working on the timing stuff yet, but if my assumption that this platform can handle this is wrong, I don’t want to waste any more time on it.

After dispensing the usual “you have to enable high resolution timers in the kernel config” advice and then being informed that they already were, I decided to try myself on my own hot-rodded kernel and yep, nope, no HR timers.

I’m no expert on this stuff, though I sure know a lot more now. Long story short, I’ve already mentioned a point that I learned, which is that the way this is usually accomplished with CPUs like this is the ARM architected timer. There is a driver for this in the kernel, but it is explicitly disabled for this chip.

linux-artik/arch/arm64/Kconfig
...
    select ARCH_WANT_FRAME_POINTERS 
    select ARM_AMBA 
    select ARM_ARCH_TIMER if !ARCH_S5P6818 
    select ARM_GIC 
    select AUDIT_ARCH_COMPAT_GENERIC
...

After determining that this was done for a reason and that commenting it out and adding a node to the device tree won’t just magically make it work, I dug a bit further.

A developer with more feathers in his cap than I have in mine suggested this nugget.

The ARM Generic Timer (aka. arch timer) does not seem to work on this SoC.
Ideally there would be some (hidden?) register enabling the right clock
source, though we haven’t found one (yet). But as also other code for this
SoC out there on the net does not seem to be able to use the arch timer,
I am not too hopeful here. While this does not impose a real problem to
U-Boot (patch 3/13 takes care of that), it is a showstopper for mainline
arm64 Linux, which heavily relies on the arch timer (since it’s a mandatory
part of the ARMv8 architecture). [source]

So, we learn that the silicon is probably broken. This is alluded to only slightly in the S5P6818 manual; the only mention of any generic-timers-related registers is in the tie-off block, a block used in the chip to push values into configuration registers of unused parts of the silicon. The manual doesn’t say much about the tie-off section or about the things it ties off.

Without the per-core timers, that leaves only five timer channels — four that can actually be used. On the forum thread, a reply from a Samsung rep confirms this:

Due to some design limitations of the s5p6818 SoC, instead of using the per core (ARM Architected) HR timer, we are currently using PWM based timers.

PWM timer 0: clock source
PWM timer 1: clock event

Currently we are checking the resolution limitations of the PWM based timers with the development team. We should be able to provide an update on this next week. [source]

Samsung wrote up a clocksource and clockevent driver that uses the PWM timers on the chip. This works fine, except that the Linux high resolution timer architecture requires a per-core hardware timer, plus a tick broadcast timer if you have more cores than hardware timers. So as it stands, the stock kernel cannot support high resolution timers in any way (“stock” as in linux-artik…mainstream Linux has no support for these devices).

For fun, and because I’ll have to scrap this design and these expensive prototypes if I can’t get high resolution timing going, I extended the stock timer driver to at least allow multiple instances. The default instance is set up on channels 0 & 1, and if I set up another instance on channels 2 & 3, I essentially waste a timer (because we don’t need two clocksources), but I gain high resolution timers on CPU 0.

That’s the catch with this — high resolution timers only work on one CPU. But as long as I run my timing thread on CPU 0, I get acceptable timing.