Date: Sun, 20 Oct 2013 16:03:22 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Mark Robert Vaughan Murray <markm@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM counter registers and get_cyclecount() Message-ID: <1382306602.92499.117.camel@revolution.hippie.lan> In-Reply-To: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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? > 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. > 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. -- Ian > Anyone interested in helping me or taking this over? :-) > > M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1382306602.92499.117.camel>