Date: Sat, 4 Mar 2017 15:32:52 -0800 From: Mark Millard <markmi@dsl-only.net> To: Andrew Gierth <andrew@tao11.riddles.org.uk> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> In-Reply-To: <87tw7820fc.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <87tw7820fc.fsf@news-spur.riddles.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-4, at 1:47 PM, Andrew Gierth <andrew at = tao11.riddles.org.uk> wrote: >=20 >>>>>> "Warner" =3D=3D Warner Losh <imp at bsdimp.com> writes: >=20 >>> Is building with CPUTYPE=3Dcortex-A7 (this is on an RPI2) known to >>> work, known to not work, or of unknown working status? >=20 > Warner> I've not had good luck getting it to work. (cortex-a7 is the > Warner> proper type name, btw). It kinda works, but ports are kinda > Warner> wonky. >=20 > My findings so far: >=20 > 1. openssl speed (base system's openssl, not a port) produces a bunch = of > errors, such as: >=20 > 542635024:error:0407006A:rsa = routines:RSA_padding_check_PKCS1_type_1:block type is not = 01:/home/FreeBSD/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/r= sa/rsa_pk1.c:103: > 542635024:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding = check = failed:/home/FreeBSD/src/secure/lib/libcrypto/../../../crypto/openssl/cryp= to/rsa/rsa_eay.c:705: >=20 > 2. git fails with semi-random sha1 failures when cloning a repo of any > size; these failures go away if you make it use its internal sha1 = rather > than the openssl one it defaults to. HOWEVER, testing in a world build > without CPUTYPE and shoehorning the vectorized sha1 from openssl back = in > does not reproduce the failure. Also, extensive testing with "openssl > dgst -sha1" did not produce any failure. >=20 > (I've confirmed that both the above go away from recompiling without > CPUTYPE.) >=20 > I've also noticed some breakage probably not related to openssl for > which I'm still waiting on recompilations in order to definitively = test. >=20 > --=20 > Andrew. Trying (1) on a bpim3 with head instead (still clang 3.9.1 based), I get such notices for: Doing 512 bit public rsa's for 10s: RSA verify failure Doing 2048 bit public rsa's for 10s: RSA verify failure Doing 4096 bit public rsa's for 10s: RSA verify failure I also get: Doing 512 bit sign dsa's for 10s: 10527 512 bit DSA signs in 10.09s DSA verify failure. No DSA verify will be done. Doing 1024 bit sign dsa's for 10s: 4035 1024 bit DSA signs in 10.02s Doing 1024 bit verify dsa's for 10s: DSA verify failure 1 1024 bit DSA verify in 10.00s Doing 2048 bit sign dsa's for 10s: 1239 2048 bit DSA signs in 10.07s DSA verify failure. No DSA verify will be done. Doing 409 bit verify ecdsa's for 10s: ECDSA verify failure 1 409 bit ECDSA verify in 10.02s # uname -paKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r314479M arm armv6 = 1200022 1200022 The openssl issue likely is worth submitting as a bugzilla report, with speed as an example way to see the issue. (Note: I use CFLAGS and the like because sometimes I experiment with other options as well. No such extra options involved for the above.) =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?644D1F49-BF5D-409D-BFC4-4F7E6E73085B>