svn commit: r288492 - head/sys/arm/arm

[Glen Barber]

On Sat, Oct 03, 2015 at 10:30:40AM +0300, Konstantin Belousov wrote:
> On Sat, Oct 03, 2015 at 10:02:56AM +0300, Konstantin Belousov wrote:
> > On Fri, Oct 02, 2015 at 10:27:56AM -0600, Ian Lepore wrote:
> > > On Fri, 2015-10-02 at 18:20 +0300, Konstantin Belousov wrote:
> > > > 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.
> > > > 
> > > 
> > > That link opened a reference to a cortex-a57 chip for me.  I've had
> > > problems trying to share links to arm's documentation site, something
> > > about the way that navbar stuff works makes pasting links not-work.
> > I tried to reference
> > App Notes and tutorials -> All Application Notes -> AN098 - VFP
> >    Support Code
> > 
> > > 
> > > We support one arm11/VFPv2 chipset, the one used on RPi.  It's the only
> > > actual armv6 chip we support, all the other stuff supported by the arch
> > > we call armv6 is really armv7.  The TRM for the arm1176JZF-S core used
> > > on RPi is the one that mentions needing support code.
> > 
> > Yes, testing on original RPi, done by Glen, demostrates it. The test
> > program I used is at
> > https://www.kib.kiev.ua/kib/perl_opbasic_arith_175.c
> > https://www.kib.kiev.ua/kib/perl_opbasic_arith_175 is the compiled binary
> > with -mfloat-abi=softfp
> > 
> > Also the following untested on RPi patch should fix this. I verified
> > that it still starts with FZ bit cleared, on VFP v3 (RPi 2):
> > https://www.kib.kiev.ua/kib/rpi-fz.1.patch
> Use https://www.kib.kiev.ua/kib/rpi-fz.2.patch instead, VFP v3 might also
> declare that denormals are not supported in hw, apparently.
> 

With the rpi-fz.2.patch applied, cron no longer dumps core, and the
perl_opbasic_arith_175.f runs successfully without floating exception.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20151004/2a9c8b8a/attachment.bin>