From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 22:30:12 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8816D95; Sun, 20 Oct 2013 22:30:12 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E1B224EA; Sun, 20 Oct 2013 22:30:12 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VY1Vh-0002PR-Hz; Sun, 20 Oct 2013 23:30:11 +0100 Subject: Re: ARM counter registers and get_cyclecount() Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <1382306602.92499.117.camel@revolution.hippie.lan> Date: Sun, 20 Oct 2013 23:30:08 +0100 Message-Id: <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1510) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 22:30:13 -0000 --Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Oct 2013, at 23:03, Ian Lepore wrote: > On Sun, 2013-10-20 at 17:13 +0100, Mark Robert Vaughan Murray wrote: >> Hi folks >>=20 >> I asked a similar question to this a month or so ago, then got = involved in other work, so apologies for the repetition! >>=20 >> 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. >>=20 >> 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. >>=20 >> Things it could conceivably do better: >>=20 >> 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. >>=20 >=20 > 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)? >>=20 >=20 > 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. >>=20 >=20 > 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 --=20 Mark R V Murray --Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmRZcN58vKOKE6LNAQoMTgP/Ukw1hcoN0xkjKB2kwX+n5tXDmRwUCp8L Z1EQyFA030ku8/KFs5jYMnMV1t86GSYTYg8zQLn3IAWprosPckkC0nEXLUibJ0Qy JTjheXCpG1MhbWPxgWPb0DJI/g60xMnmmhftN6nFnA+9gZvduokMYSAr/M1OX4jv HdJc23NTzp0= =hbd7 -----END PGP SIGNATURE----- --Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C--