ARM counter registers and get_cyclecount()

[Mark Robert Vaughan Murray]

On 20 Oct 2013, at 23:03, Ian Lepore <ian at FreeBSD.org> wrote:

> On Sun, 2013-10-20 at 17:13 +0100, Mark Robert Vaughan Murray wrote:
>> Hi folks
>> 
>> I asked a similar question to this a month or so ago, then got involved in other work, so apologies for the repetition!
>> 
>> The random(4) device benefits from having a decent hardware get_cyclecount() implementation. In i386 and arm, we have a stopgap version that uses binuptime(), which is slow and prone to quantisation error.
>> 
>> I've hacked up a minimalist hardware version for ARMv6/RPI (which is the only ARM I have access to, and I'm keen to use it for other things as well), and I'm looking for improvement advice and/or commit blessing.
>> 
>> Things it could conceivably do better:
>> 
>> 1) The counter is 32 bits only. At clocks of hundreds-of-megahertz, this will overflow in some 10's of seconds to maybe a minute, so it would be nice (but to essential) to trap the overflow with an interrupt and increment an upper-half counter, making a 64-bit counter.
>> 
> 
> Wouldn't that amount to creating a one-off implementation of
> binuptime()?  (Except not one-off, but one-per-SoC-off).

Not sure, but its get_cyclecount() that I'm trying to get to work on as many systems/SoCs as possible.

On amd64 and i386 (not the really early ones) get_cyclecount() reads the TSC register (64-bit). This is hardware, and the timing info is really useful for stochastic event timestamping due to its resolution.

Last time I looked at binuptime(), it was not nearly as good in the low bits due to quantisation error.

> Does it really benefit from being a 64-bit counter?  In what way do the
> upper bits help contribute to whatever random(4) does with the counter
> to generate entropy?

Not much, its just tidier. If there is a wrap in-between the measurements used to calculate a delta-T, the result will look funny, but not lose any resolute due to the wrap. This may make verifying the entropy harder, but not impossible.

>> 2) Set up the debug/profile/counter registers as some kind of device (suggestion from a couple of months back that I have no more information on)?
>> 
> 
> Not all SoCs have such a thing.

Sure, but is it worthwhile for those that do, and if so how? (What API etc)

>> 3) Support more ARM arches in a more general way? I have very little ARM hardware (only other is a BeagleBoard-xM) to test/develop this on.
>> 
> 
> This is the way to solve #2, for some definition of solve.  For example,
> any platform that can do so would implement a cpu_get_fastcounter()
> function, and a weak-linkage default implementation would return
> binuptime() or something like that.  But then there's likely to be
> quibbling over what "fast" means.

Well, we already have get_cyclecount() on most arches, and as its just a wrapper for binuptime() in arm, I'm trying to fix it :-)

M
-- 
Mark R V Murray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 353 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20131020/6a35854d/attachment.sig>