Date: Sun, 20 Oct 2013 23:30:08 +0100 From: Mark Robert Vaughan Murray <markm@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM counter registers and get_cyclecount() Message-ID: <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> In-Reply-To: <1382306602.92499.117.camel@revolution.hippie.lan> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ian@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78B77E93-BE2E-4CA2-9D1B-F994B795FABB>