Date: Fri, 2 Oct 2015 18:20:59 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288492 - head/sys/arm/arm Message-ID: <20151002152059.GY11284@kib.kiev.ua> In-Reply-To: <1443795970.66572.68.camel@freebsd.org> References: <201510021326.t92DQ0Ds002986@repo.freebsd.org> <1443795970.66572.68.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 02, 2015 at 08:26:10AM -0600, Ian Lepore wrote: > Some arm documentation refers to the need for "support code" when the > flush-to-zero option is disabled on VFPv2 hardware (which for us would > be just the RPi I think). Do we have that support code? What happens > if it's missing? I can't actually find any info on exactly what that > support code is supposed to do. For all I know, we have the required > code in libm. Or maybe what's needed is exception-handling code in the > kernel. I can't find any info on what they mean by "support code" in > this context. The fpscr register is user-modifiable, so whatever happens after the change, could as well happen before it. I saw the references to the support code in e.g. ARM v7-A A2.7.5 Flush-to-zero. But I was sure that the text refers to the modes when e.g. FZ is cleared and UFE or IXE bits are enabled. In this situation, fault handler must do something to allow the computation to proceed. > > I don't think this is an issue for VFPv3 and later hardware. I've > looked in a few of the TRMs for different cortex-a series processors and > they say the hardware handles all combinations of rounding and flush to > zero without support software. But we should probably be on the lookout > for reports of misbehaving apps on RPi after this change, just in case > this setting has been protecting us from our ignorance there. I did found the reference to the support code in the VFP11 TRM, which in turns point to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.epm049219/index.html Does FreeBSD enable and handle this variant of coprocessor ? If yes, then indeed I would need to not enable FZ on the affected hardware.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151002152059.GY11284>