Date: Fri, 5 May 2017 17:44:16 -0700 From: Mark Millard <markmi@dsl-only.net> To: bob prohaska <fbsd@www.zefox.net> Cc: ports@freebsd.org, freebsd-arm@freebsd.org Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <C2340D34-1A84-42CD-ADD5-FA5D5ADD553F@dsl-only.net> In-Reply-To: <20170505230106.GA52464@www.zefox.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-May-5, at 4:01 PM, bob prohaska <fbsd@www.zefox.net> wrote: > On Fri, May 05, 2017 at 12:38:14PM -0700, Mark Millard wrote: >> >> An rpi2 has Cortex-A7 (armv7-A) cores that have NEON >> but armv6 does not. >> >> There is some possibility that with something like >> -mcpu=cortex-a7 in use as a compiler option that >> NEON would be used. > > What's the simplest way to try it on a self-hosted RPI2 running > -current? At this point I'm just using make -DBATCH in > /usr/ports/www/firefox and following my nose. There's nothing > valuable on the system, it's only for testing. I've never built firefox for anything. The only place I have set up a (fairly minimal) x11 environment is on amd64 virtual machine guests, again no firefox or anything else major, just lumina and xterm (local use, not internet use). So it would be a research project for me to get a special/non-default firefox build done on a rpi2. (There are some fairly general, but not universal, techniques for supplying compiler options to ports. I've no clue were firefox lands for such properties.) >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 >> >> (VFP and NEON are related by the registers used.) >> >> So there could be other problems with NEON enabled code >> until it is all resolved. (And head gets the work before >> stable/11 gets the result.) >> > > Most of the discussion in the thread is beyond me, but it > is appreciated that the problem isn't simple. The overall effect: you may get odd results from corrupted NEON register values when NEON is put to use. (I do not know the detailed status of what is working vs. not for NEON/VFP at this point.) === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C2340D34-1A84-42CD-ADD5-FA5D5ADD553F>