From owner-freebsd-arm@freebsd.org Sun Mar 5 00:02:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6974CF9B8B for ; Sun, 5 Mar 2017 00:02:38 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 565F810F3 for ; Sun, 5 Mar 2017 00:02:38 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=41171 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckJdC-0000Xu-Ty; Sun, 05 Mar 2017 00:02:34 +0000 Received: from localhost ([127.0.0.1]:10613 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ckJdC-00043q-5j; Sun, 05 Mar 2017 00:02:34 +0000 From: Andrew Gierth To: Mark Millard Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> (Mark Millard's message of "Sat, 4 Mar 2017 15:32:52 -0800") Message-ID: <87lgsk1udz.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Sun, 05 Mar 2017 00:02:34 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 00:02:38 -0000 >>>>> "Mark" == Mark Millard writes: Mark> Trying (1) on a bpim3 with head instead (still clang 3.9.1 Mark> based), I get such notices for: Mark> Doing 512 bit public rsa's for 10s: RSA verify failure Mark> Doing 2048 bit public rsa's for 10s: RSA verify failure Mark> Doing 4096 bit public rsa's for 10s: RSA verify failure Mark> I also get: Mark> Doing 512 bit sign dsa's for 10s: 10527 512 bit DSA signs in 10.09s Mark> DSA verify failure. No DSA verify will be done. Mark> Doing 1024 bit sign dsa's for 10s: 4035 1024 bit DSA signs in 10.02s Mark> Doing 1024 bit verify dsa's for 10s: DSA verify failure Mark> 1 1024 bit DSA verify in 10.00s Mark> Doing 2048 bit sign dsa's for 10s: 1239 2048 bit DSA signs in 10.07s Mark> DSA verify failure. No DSA verify will be done. Mark> Doing 409 bit verify ecdsa's for 10s: ECDSA verify failure Mark> 1 409 bit ECDSA verify in 10.02s Yes, that seems identical to what I got. Just to be clear: what compile options is that with? But I'm not convinced this is a problem in openssl (rather than somewhere else). Here's why: 1. When looking at git, I tried logging the input and output of all the SHA1 calls, and replaying them through a test program that called the same openssl functions on the same data (with the same alignment); the test program always got the correct hashes, even for cases where the logged data showed that the hash had been computed incorrectly 2. Running openssl speed under gdb with a conditional breakpoint set to look for padding failures stops the error from occurring at all (!). 3. The errors aren't consistent at all. For example, sometimes I run openssl speed rsa512 and it succeeds without error. When testing with git, the failures were not always at the same place. -- Andrew. From owner-freebsd-arm@freebsd.org Sun Mar 5 00:42:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0814CEC94B for ; Sun, 5 Mar 2017 00:42:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-203.reflexion.net [208.70.211.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1AC11CB1 for ; Sun, 5 Mar 2017 00:42:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22815 invoked from network); 5 Mar 2017 00:36:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Mar 2017 00:36:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sat, 04 Mar 2017 19:35:55 -0500 (EST) Received: (qmail 22240 invoked from network); 5 Mar 2017 00:35:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Mar 2017 00:35:55 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A7549EC920D; Sat, 4 Mar 2017 16:35:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <87lgsk1udz.fsf@news-spur.riddles.org.uk> Date: Sat, 4 Mar 2017 16:35:54 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> To: Andrew Gierth X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 00:42:44 -0000 On 2017-Mar-4, at 4:02 PM, Andrew Gierth wrote: >>>>>> "Mark" =3D=3D Mark Millard writes: >=20 > Mark> Trying (1) on a bpim3 with head instead (still clang 3.9.1 > Mark> based), I get such notices for: >=20 > Mark> Doing 512 bit public rsa's for 10s: RSA verify failure > Mark> Doing 2048 bit public rsa's for 10s: RSA verify failure > Mark> Doing 4096 bit public rsa's for 10s: RSA verify failure >=20 > Mark> I also get: >=20 > Mark> Doing 512 bit sign dsa's for 10s: 10527 512 bit DSA signs in = 10.09s > Mark> DSA verify failure. No DSA verify will be done. > Mark> Doing 1024 bit sign dsa's for 10s: 4035 1024 bit DSA signs in = 10.02s > Mark> Doing 1024 bit verify dsa's for 10s: DSA verify failure > Mark> 1 1024 bit DSA verify in 10.00s > Mark> Doing 2048 bit sign dsa's for 10s: 1239 2048 bit DSA signs in = 10.07s > Mark> DSA verify failure. No DSA verify will be done. >=20 > Mark> Doing 409 bit verify ecdsa's for 10s: ECDSA verify failure > Mark> 1 409 bit ECDSA verify in 10.02s >=20 > Yes, that seems identical to what I got. Just to be clear: what = compile > options is that with? I happened to have cross built amd64->bpim3. # uname -paKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r314479M arm armv6 = 1200022 1200022 (I'm in the middle of updating to a clang 4.0 based vintage everywhere and the amd64 context has been updated for /usr/src/ since the bpim3 build.) # more ~/src.configs/make.conf CFLAGS.gcc+=3D -v (but no gcc was in use). # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DBPIM3-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) (historical binutils) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # more /usr/src/sys/arm/conf/BPIM3-NODBG=20 # # BPIM3 -- Custom configuration for the Banana Pi M3 # include "GENERIC" ident BPIM3-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC (/usr/src/ info below is from the bpim3 itself, not the amd64 cross build environment that is in the middle of an update sequence. It should be accurate to what the build was based on.) # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 314479 Last Changed Rev: 314479 # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c > But I'm not convinced this is a problem in openssl (rather than > somewhere else). Here's why: >=20 > 1. When looking at git, I tried logging the input and output of all = the > SHA1 calls, and replaying them through a test program that called the > same openssl functions on the same data (with the same alignment); the > test program always got the correct hashes, even for cases where the > logged data showed that the hash had been computed incorrectly >=20 > 2. Running openssl speed under gdb with a conditional breakpoint set = to > look for padding failures stops the error from occurring at all (!). >=20 > 3. The errors aren't consistent at all. For example, sometimes I run > openssl speed rsa512 and it succeeds without error. When testing with > git, the failures were not always at the same place. Interesting. My context had MALLOC_PRODUCTION. I wonder if without that and having junk filled in systematically might produce more stable results. (I've no specific evidence that this would make a difference.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Mar 5 02:39:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 172FFCF7B5F for ; Sun, 5 Mar 2017 02:39:53 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC65A1067 for ; Sun, 5 Mar 2017 02:39:52 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from [10.0.1.13] (cpe-173-93-191-209.sc.res.rr.com [173.93.191.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1AD5F26C88 for ; Sat, 4 Mar 2017 21:27:23 -0500 (EST) From: Tom Pusateri Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Cubox-i Hummingboard images gone Message-Id: Date: Sat, 4 Mar 2017 21:32:58 -0500 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 02:39:53 -0000 On the FreeBSD download page, https://www.freebsd.org/where.html, there = is a 11.0-RELEASE image for Solid Run Cubox-i Hummingboard systems. But = there are no longer any images for 11.0 Stable or 12.0 Current. It seems = as though new images are not being built. Is there a hardware problem or = lack of interest? I have several of these boards and loved having the = images built. Thanks, Tom From owner-freebsd-arm@freebsd.org Sun Mar 5 02:48:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E60DCF7F42 for ; Sun, 5 Mar 2017 02:48:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E641B16B5 for ; Sun, 5 Mar 2017 02:48:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5564bccb-014e-11e7-ba57-8bc134ee460a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 5564bccb-014e-11e7-ba57-8bc134ee460a; Sun, 05 Mar 2017 02:49:21 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v252mp3a005401; Sat, 4 Mar 2017 19:48:51 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488682131.69705.55.camel@freebsd.org> Subject: Re: Cubox-i Hummingboard images gone From: Ian Lepore To: Tom Pusateri , freebsd-arm@freebsd.org Date: Sat, 04 Mar 2017 19:48:51 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 02:48:59 -0000 On Sat, 2017-03-04 at 21:32 -0500, Tom Pusateri wrote: > On the FreeBSD download page, https://www.freebsd.org/where.html, > there is a 11.0-RELEASE image for Solid Run Cubox-i Hummingboard > systems. But there are no longer any images for 11.0 Stable or 12.0 > Current. It seems as though new images are not being built. Is there > a hardware problem or lack of interest? I have several of these > boards and loved having the images built. > > Thanks, > Tom > I would guess it's because the corresponding u-boot packages are no longer available.  I have no idea why that is (I used to maintain the u-boot stuff, but others are doing it now), but the list of images roughly corresponds to the list of available u-boot pkgs. -- Ian From owner-freebsd-arm@freebsd.org Sun Mar 5 03:17:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D400CCEDAEB for ; Sun, 5 Mar 2017 03:17:58 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 20D651976; Sun, 5 Mar 2017 03:17:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 210576fe; Sun, 5 Mar 2017 04:17:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=cs83QzHWpRH2V5SKkrR7N5KDhW4=; b=AZzMDaV/lIqYrGJqLUvxJck3bRbT wxK2R2YHuaNohdbC9YMLbjHqT+pNPlh102+fnT6D91QZZj0P5gFjVft8ufzuvRfv OqU3oBD6+it5AGR6Ik7qWNY2jDFtxg5KSLiii7SNB0I1c6Pa10NO9Jg+O7VPgBzp Fi4coPqT/Xl8tnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=o4q6gY2KyAU4K8Iqluq1sDdniE5FcXODy0NVd9No0ezWC4hgQFGSia+Z IxFhoBv6I2xe6eZtSFuAK7ql9h1F5l3QNALlHMseQah5r3NbZwuHnVNijb4hRUoO 1aa151Iy19mgPw+em5/Gwgg3/vK65rBTM0HSGN3SE9x9M4xK8V4= Received: from knuckles.blih.net (om126204172073.6.openmobile.ne.jp [126.204.172.73]) by mail.blih.net (OpenSMTPD) with ESMTPSA id a726a088 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 5 Mar 2017 04:17:48 +0100 (CET) Date: Sun, 5 Mar 2017 04:17:43 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: Tom Pusateri , freebsd-arm@freebsd.org Subject: Re: Cubox-i Hummingboard images gone Message-Id: <20170305041743.98af9e94662f8524a640b5d0@bidouilliste.com> In-Reply-To: <1488682131.69705.55.camel@freebsd.org> References: <1488682131.69705.55.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 03:17:58 -0000 On Sat, 04 Mar 2017 19:48:51 -0700 Ian Lepore wrote: > On Sat, 2017-03-04 at 21:32 -0500, Tom Pusateri wrote: > > On the FreeBSD download page, https://www.freebsd.org/where.html, > > there is a 11.0-RELEASE image for Solid Run Cubox-i Hummingboard > > systems. But there are no longer any images for 11.0 Stable or 12.0 > > Current. It seems as though new images are not being built. Is there > > a hardware problem or lack of interest? I have several of these > > boards and loved having the images built. > >=20 > > Thanks, > > Tom > >=20 >=20 > I would guess it's because the corresponding u-boot packages are no > longer available. =A0I have no idea why that is (I used to maintain the > u-boot stuff, but others are doing it now), but the list of images > roughly corresponds to the list of available u-boot pkgs. >=20 > -- Ian u-boot-cubox-hummingbird depends on gcc492 (which vendor u-boot needs) so it conflict with gcc6XX which the other ones use. Switching to upstream u-boot is needed but I don't have hardware to test. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Mar 5 03:18:30 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F836CEDB56 for ; Sun, 5 Mar 2017 03:18:30 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D71911AE9 for ; Sun, 5 Mar 2017 03:18:29 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22c.google.com with SMTP id v125so50019175qkh.2 for ; Sat, 04 Mar 2017 19:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=P7n5XtjpuPOslmycXdtnvLt468eC2xWS2eyVhowqwhM=; b=Au/6SWLhP6nHTQBoUnSXhQmAa+6OFV6qBdLw4nhPViQaNVbcZccliliocBy73AAlk3 WbXFD12Q5II+J6Y9pfHsgUQ885rCbzcNJ8ZTWoLJS/qNOtip5kAN4BTrNNFD7SYPaKub hm64q/hBT1UQqFhN+MWpO2LGRV6NieYxYKlyU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P7n5XtjpuPOslmycXdtnvLt468eC2xWS2eyVhowqwhM=; b=ColvNiI4bB7drIn8Qp7WkgKPmpWSDthSfmA9ikNN7RIUpMpTXK+Xc8msMFqfjgDbEg IDgJR+VNgrTPeJUzl+z+me8oyDGF5k1xnczjwoj3XvJCf/1s7iO/27oQtpn6RQ0Z+pVV wzbQG6dQ0PxGuxXxFf0Z3A+5tYpwpzScq6M7bDDD1UwmveDeRqmFuNh2pRRtLY9BcaIA yr2wpMx4M7NXkG5VtvZbqavAnp/lsB5ZyvT6AdB+coQmb66YdruFWE24jshdmxbwdmZc xihMT5w07buBwRVy6zi6mtHxYN9CJ4BI01rwPQidJJieexfLp5qBJK+nExEiKlXcqqqB W4pw== X-Gm-Message-State: AMke39nn/OW4GQEXMn0lDwqpmVrGfGtYUiWfi+g+rEEQ6dCY5cdYzr8b/NRuVBULPYifQQ== X-Received: by 10.200.48.118 with SMTP id g51mr10606845qte.19.1488683908688; Sat, 04 Mar 2017 19:18:28 -0800 (PST) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id a54sm10770110qta.48.2017.03.04.19.18.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 19:18:28 -0800 (PST) Subject: Fwd: Simple program immediately killed when running on a NFS References: To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= X-Forwarded-Message-Id: Message-ID: Date: Sun, 5 Mar 2017 00:18:01 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 03:18:30 -0000 Dears I'm trying to compile a simple hello world program on my RPI3. The program is on a directory mounted using NFS and stored in the amd64 machine. When I compile and try to run the program in the NFS mounted path it does not work, when I copy the same program to a local dir it works, and then when I copy the program from the local dir to the NFS dir it works !?!?!?! Someone can, please, explain it? Look at the historic program. On this same scenario, my beagleboneblack behaves without mistakes. root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cc -o conftest conftest.c root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # ./conftest Killed root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp conftest /usr/home/ota/conftest root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # /usr/home/ota/conftest Hello world! root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp /usr/home/ota/conftest ./conftest root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # ./conftest Hello world! root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # mount /dev/mmcsd0s2a on / (ufs, local, noatime, journaled soft-updates, nfsv4acls) devfs on /dev (devfs, local, multilabel) /dev/mmcsd0s1 on /boot/efi (msdosfs, local, noatime) /dev/md0 on /tmp (ufs, local, noatime, soft-updates) /dev/md1 on /var/log (ufs, local, noatime, soft-updates) /dev/md2 on /var/tmp (ufs, local, noatime, soft-updates) squitch:/usr/ports on /usr/ports (nfs) Thanks a lot! []'s -Otacílio From owner-freebsd-arm@freebsd.org Sun Mar 5 09:58:46 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5E7CF93A8 for ; Sun, 5 Mar 2017 09:58:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37F6F17C4 for ; Sun, 5 Mar 2017 09:58:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1ckSvx-0004Oa-U5; Sun, 05 Mar 2017 11:58:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Simple program immediately killed when running on a NFS From: Daniel Braniss In-Reply-To: Date: Sun, 5 Mar 2017 11:58:33 +0200 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?B?T3RhY8OtbGlv?= X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 09:58:46 -0000 > On 5 Mar 2017, at 05:18, Otac=C3=ADlio = wrote: >=20 > Dears >=20 > I'm trying to compile a simple hello world program on my RPI3. The > program is on a directory mounted using NFS and stored in the amd64 > machine. When I compile and try to run the program in the NFS mounted > path it does not work, when I copy the same program to a local dir it > works, and then when I copy the program from the local dir to the NFS = dir > it works !?!?!?! Someone can, please, explain it? Look at the historic > program. On this same scenario, my beagleboneblack behaves without = mistakes. >=20 > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cc -o > conftest conftest.c > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # = ./conftest > Killed > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp = conftest > /usr/home/ota/conftest > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # > /usr/home/ota/conftest > Hello world! > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp > /usr/home/ota/conftest ./conftest > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # = ./conftest > Hello world! > root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # mount > /dev/mmcsd0s2a on / (ufs, local, noatime, journaled soft-updates, = nfsv4acls) > devfs on /dev (devfs, local, multilabel) > /dev/mmcsd0s1 on /boot/efi (msdosfs, local, noatime) > /dev/md0 on /tmp (ufs, local, noatime, soft-updates) > /dev/md1 on /var/log (ufs, local, noatime, soft-updates) > /dev/md2 on /var/tmp (ufs, local, noatime, soft-updates) > squitch:/usr/ports on /usr/ports (nfs) >=20 >=20 > Thanks a lot! >=20 > []'s >=20 > -Otac=C3=ADlio take a look at /var/log/messages, there might be some more info as to = why the process was killed. danny From owner-freebsd-arm@freebsd.org Sun Mar 5 10:01:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B34BCF9483 for ; Sun, 5 Mar 2017 10:01:31 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 102F519FE for ; Sun, 5 Mar 2017 10:01:30 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=41684 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckSyj-0001Ei-NK; Sun, 05 Mar 2017 10:01:25 +0000 Received: from localhost ([127.0.0.1]:41886 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ckSyi-0008pL-Tp; Sun, 05 Mar 2017 10:01:25 +0000 From: Andrew Gierth To: Mark Millard Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> (Mark Millard's message of "Sat, 4 Mar 2017 16:35:54 -0800") Message-ID: <87h93814rb.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Sun, 05 Mar 2017 10:01:24 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 10:01:31 -0000 >>>>> "Mark" == Mark Millard writes: >> 3. The errors aren't consistent at all. For example, sometimes I run >> openssl speed rsa512 and it succeeds without error. When testing >> with git, the failures were not always at the same place. Mark> Interesting. My context had MALLOC_PRODUCTION. I wonder if Mark> without that and having junk filled in systematically might Mark> produce more stable results. (I've no specific evidence that this Mark> would make a difference.) I don't think this can explain my results with git; openssl's sha1 doesn't call malloc (or any library function other than memcpy, memset, OPENSSL_cleanse), and I have logs of the data being hashed that show the wrong results returned. Also, I've checked that while these hashes are being done, there are no other threads in the process. -- Andrew. From owner-freebsd-arm@freebsd.org Sun Mar 5 11:13:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F8BDCF904D for ; Sun, 5 Mar 2017 11:13:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-192.reflexion.net [208.70.211.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27D9F17F0 for ; Sun, 5 Mar 2017 11:13:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7226 invoked from network); 5 Mar 2017 11:16:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Mar 2017 11:16:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 05 Mar 2017 06:13:43 -0500 (EST) Received: (qmail 2158 invoked from network); 5 Mar 2017 11:02:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Mar 2017 11:02:25 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AE363EC8807; Sun, 5 Mar 2017 03:02:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <87h93814rb.fsf@news-spur.riddles.org.uk> Date: Sun, 5 Mar 2017 03:02:24 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> To: Andrew Gierth X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 11:13:51 -0000 On 2017-Mar-5, at 2:01 AM, Andrew Gierth wrote: >>>>>> "Mark" == Mark Millard writes: > >>> 3. The errors aren't consistent at all. For example, sometimes I run >>> openssl speed rsa512 and it succeeds without error. When testing >>> with git, the failures were not always at the same place. > > Mark> Interesting. My context had MALLOC_PRODUCTION. I wonder if > Mark> without that and having junk filled in systematically might > Mark> produce more stable results. (I've no specific evidence that this > Mark> would make a difference.) > > I don't think this can explain my results with git; openssl's sha1 > doesn't call malloc (or any library function other than memcpy, memset, > OPENSSL_cleanse), and I have logs of the data being hashed that show the > wrong results returned. Also, I've checked that while these hashes are > being done, there are no other threads in the process. > > -- > Andrew. FYI: I've updated to -r314687 (so now clang 4.0 based) and openssl speed still gets the same failures. (By contrast a pine64+ 2 GiByte [an arm64] worked fine.) I have not tried a normal build without the -mcpu=cortex-a7 use (or equivalent). Have you? === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Mar 5 11:17:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B682CCF9124 for ; Sun, 5 Mar 2017 11:17:05 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 708D018FA for ; Sun, 5 Mar 2017 11:17:05 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x235.google.com with SMTP id g129so51939181qkd.1 for ; Sun, 05 Mar 2017 03:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1wxXWnPDfih8Yr9Tn6TNsaw5365viR0w1DPPk5LfvE4=; b=NNSduW4WEyXxVKbr4iUubN+8/7LkqgK3Gje4ioWoda/Np5NVJo9OxyUREnkNNnZkt/ zmSBxsUnMVs6sNAPiNvKg+UYv8/KuQkvOQZblTvFNm2OurInKSgT5WV3O/VwvZr3z8cV y+4s8cNxyjNTJrG3IIFvmAT6lhhJCIVBplb4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1wxXWnPDfih8Yr9Tn6TNsaw5365viR0w1DPPk5LfvE4=; b=Ga2FQjW2L0QGeSpTQ04n6c42GZeK3dCIfYtMk0R/MIiITWwkXAAIPOsqictb+hl2iX TSFlWEYQSSEUNcKo3qlfffeloQkDg8T+g3aAYJkSy98J8ylM8JLHExolWNu1kGuC/+fv NixdwRE9O9CxEMWEThEwqu5GRrsgF5t9GHs009/uvmtHqUxKi6zN6q3P476fKMV36Eey kLW0Yx6DSsmhqjezi7JNbO5K3MKJXkNKM0cYfeMGz8wukij1SCpzGKLZHpNBYF/VEV0z LEYvLgvM026bDzXl3YDW/lUcmoocEJPG4MMDNqcFPFAVdKV4k1ptKAkBBYhrttnIHHQI +c8w== X-Gm-Message-State: AMke39ksibmwMouG06DTZYIfWTDV6+YGuLb+Q8eXbW8VYCJqRJZ0VQjh+oG43AuwxMR8gA== X-Received: by 10.55.6.7 with SMTP id 7mr11898958qkg.200.1488712624323; Sun, 05 Mar 2017 03:17:04 -0800 (PST) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id 23sm11329268qtu.47.2017.03.05.03.17.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 03:17:03 -0800 (PST) Subject: Re: Simple program immediately killed when running on a NFS To: Daniel Braniss References: Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Sun, 5 Mar 2017 08:16:35 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 11:17:05 -0000 Em 05/03/2017 06:58, Daniel Braniss escreveu: >> On 5 Mar 2017, at 05:18, Otacílio wrote: >> >> Dears >> >> I'm trying to compile a simple hello world program on my RPI3. The >> program is on a directory mounted using NFS and stored in the amd64 >> machine. When I compile and try to run the program in the NFS mounted >> path it does not work, when I copy the same program to a local dir it >> works, and then when I copy the program from the local dir to the NFS dir >> it works !?!?!?! Someone can, please, explain it? Look at the historic >> program. On this same scenario, my beagleboneblack behaves without mistakes. >> >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cc -o >> conftest conftest.c >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # ./conftest >> Killed >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp conftest >> /usr/home/ota/conftest >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # >> /usr/home/ota/conftest >> Hello world! >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp >> /usr/home/ota/conftest ./conftest >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # ./conftest >> Hello world! >> root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # mount >> /dev/mmcsd0s2a on / (ufs, local, noatime, journaled soft-updates, nfsv4acls) >> devfs on /dev (devfs, local, multilabel) >> /dev/mmcsd0s1 on /boot/efi (msdosfs, local, noatime) >> /dev/md0 on /tmp (ufs, local, noatime, soft-updates) >> /dev/md1 on /var/log (ufs, local, noatime, soft-updates) >> /dev/md2 on /var/tmp (ufs, local, noatime, soft-updates) >> squitch:/usr/ports on /usr/ports (nfs) >> >> >> Thanks a lot! >> >> []'s >> >> -Otacílio > > take a look at /var/log/messages, there might be some more info as to why the process was killed. > > danny > I tried three times, the two firsts building benchmarks/netperf and the last one compiling a simple hello world. I got this messages on /var/log/messages Mar 5 08:11:48 rpi3 kernel: pid 1589 (sh), uid 0, was killed: text file modification Mar 5 08:13:19 rpi3 kernel: pid 2114 (sh), uid 0, was killed: text file modification Mar 5 08:13:55 rpi3 kernel: pid 2134 (csh), uid 0, was killed: text file modification From owner-freebsd-arm@freebsd.org Sun Mar 5 11:48:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1370FCF9CD7 for ; Sun, 5 Mar 2017 11:48:03 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCBD61766 for ; Sun, 5 Mar 2017 11:48:02 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=54990 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckUdq-0001Lb-PB; Sun, 05 Mar 2017 11:47:58 +0000 Received: from localhost ([127.0.0.1]:55512 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ckUdp-0009fH-VY; Sun, 05 Mar 2017 11:47:58 +0000 From: Andrew Gierth To: Mark Millard Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> (Mark Millard's message of "Sun, 5 Mar 2017 03:02:24 -0800") Message-ID: <87d1dw0x6f.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Sun, 05 Mar 2017 11:47:57 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 11:48:03 -0000 >>>>> "Mark" == Mark Millard writes: Mark> I have not tried a normal build without the -mcpu=cortex-a7 use Mark> (or equivalent). Have you? Yes. So far, all the errors I can produce on the cortex-a7 build have gone away when compiling world without the flag (as I said initially). (Note that it's how world was compiled that matters, NOT kernel - I've tested both ways.) (Right now I have two systems set up, one built with cortex-a7 and one without, for comparison.) -- Andrew. From owner-freebsd-arm@freebsd.org Sun Mar 5 12:08:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02CEBCFA9B8 for ; Sun, 5 Mar 2017 12:08:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2A98154E for ; Sun, 5 Mar 2017 12:08:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1ckUxk-0007oO-Pz; Sun, 05 Mar 2017 14:08:32 +0200 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Simple program immediately killed when running on a NFS Date: Sun, 5 Mar 2017 14:08:32 +0200 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: =?utf-8?B?T3RhY8OtbGlv?= , richicalles@hotmail.com References: X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 12:08:38 -0000 > On 5 Mar 2017, at 13:16, Otac=C3=ADlio = wrote: >=20 > was killed: text file modification sounds like nfs issue,(hence involving Rick), but just in case, are the = dates in sync between the serve and client? with the hello world program, try running it again danny From owner-freebsd-arm@freebsd.org Sun Mar 5 12:43:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A12C5CF82E7 for ; Sun, 5 Mar 2017 12:43:38 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61FA11641 for ; Sun, 5 Mar 2017 12:43:37 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x234.google.com with SMTP id g129so53173873qkd.1 for ; Sun, 05 Mar 2017 04:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=VZElDfjKlAb0QVUkRcuCsX47eAp5S8ygPCzqH4UXHUE=; b=FXYs9UTcelHLRlFnq56YJ76pfzhLF++Guy7k0kvFirz9nvvWOVeTMyiDTgizndSiPi OYoqTo7KSnGUqrCLLpDMstGtp4WxqHroskGSvthikLuRi6UgYYlV/M2ajP6C8DSD3nx9 U0sMslb9ZBvAmqS3w8fVRS4Jyyp0uWHg5njv4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=VZElDfjKlAb0QVUkRcuCsX47eAp5S8ygPCzqH4UXHUE=; b=Vp2z9S0Ml9aAgK3SUyZiHbWxjzkTfMJjMMruWfTpJ+Us0T/K/ivvk+Wu4cveQoeufk dSGa1FlCaJLJr4ff3UzGYvkl+xL29caPuTzUorPldpQqPIcoxrI7obb3DQcVrwXPvcT2 NYhb9HctA3hNRj9cLLHJ/tnxld7uYosdbe1YxHQUnqxfshxVnePeEWZTIOuPxCv5YZPn ZYsF/RcjMSSk6SqVoNfw2nReBzVR525RKbw6VZ2s3gbVxZBvl0dhAZmuaawrM+QpZUlP NEBukI/B8SgIaTGkAUhDA2Z5DV1qyDunV4Y5mAnkShQNQK0e2cfVr9aydcHXiRjkKjm6 fl4Q== X-Gm-Message-State: AMke39klb4bTdrqv4+eH3RXDbPAWY/fSMm3s5KicBMpYv+Ev8zeE7YuVJJbVpctvIolQ8w== X-Received: by 10.55.11.141 with SMTP id 135mr10502884qkl.260.1488717816957; Sun, 05 Mar 2017 04:43:36 -0800 (PST) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id u8sm7894942qkg.25.2017.03.05.04.43.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 04:43:36 -0800 (PST) Subject: Re: Simple program immediately killed when running on a NFS To: Daniel Braniss , richicalles@hotmail.com References: Cc: "freebsd-arm@freebsd.org" , rmacklem@uoguelph.ca From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <4c54882b-1cde-911f-84b1-c184013b6810@bsd.com.br> Date: Sun, 5 Mar 2017 09:43:07 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 12:43:38 -0000 Em 05/03/2017 09:08, Daniel Braniss escreveu: > >> On 5 Mar 2017, at 13:16, Otacílio > > wrote: >> >> was killed: text file modification > > sounds like nfs issue,(hence involving Rick), but just in case, are > the dates in sync between the serve and client? > with the hello world program, try running it again > > danny > > > Server (amd64) is ntpd disabled while client (RPI3) is using : ntpd_enable="YES" ntpd_sync_on_start="YES" on rc.conf -Otacilio From owner-freebsd-arm@freebsd.org Sun Mar 5 12:57:46 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2649CF8886 for ; Sun, 5 Mar 2017 12:57:46 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82F4A1BD0 for ; Sun, 5 Mar 2017 12:57:46 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22d.google.com with SMTP id 1so117946178qkl.3 for ; Sun, 05 Mar 2017 04:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=w9BbBB0gIPPir66yl1qHcY9cGFNWR/qVFKrFst2lD6g=; b=CJiQ4p26x4WqfqjgmRu1RclEpbw6gQid5dqHgJvGz8z0nd2RMUhurbsuExH27zJdy8 zLtoGFaff9LyIlZyhZiSYl8HHsZqx/PraaTnBciHuItrueg1G1FGa2zJHH7mK+49X7uS dYom+cLXWQ/2NR2Kzu/FS5rj0YsevtDvloIQU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=w9BbBB0gIPPir66yl1qHcY9cGFNWR/qVFKrFst2lD6g=; b=DiNhh3pqVRElHZt3z9CgP+OIHQePt2LguBv8GEDp6TZpE3peHj0mJ48X9KxLKARSLi 7IojMkK22gywgVJPt0Em7RwsO5Di0Kxo8qfv67oGB/EdUy9YdkTxtkWvLTvZVxNyiq3N /nuBUc/kDbUWDRchDGPCb16PuWnuEcW51DfJ6wBQbeGbad/rY8Hg3bFI9ASTnQUdid8K M+pIcRaaWwp/vHwbcMpmx0jUmHkamQ9x0j6R21D4+2z30E4GmhaR0ICGklVCZUhK7koE z8HmrVfqeumFzzAqWSLZmTJruEmThJMkFNgC9YE0awErg1/L1c/ciq+XABX8Dm5c97C3 qfWA== X-Gm-Message-State: AMke39mMhVHEL7rgst5ecnElvr0VWsWVLzmSjd04z+VrWNYEybHBSNRimw7QY+JpkBmtLA== X-Received: by 10.55.148.71 with SMTP id w68mr11682458qkd.268.1488718665552; Sun, 05 Mar 2017 04:57:45 -0800 (PST) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id i140sm8538966qke.2.2017.03.05.04.57.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 04:57:45 -0800 (PST) Subject: Re: Simple program immediately killed when running on a NFS To: Daniel Braniss References: <4c54882b-1cde-911f-84b1-c184013b6810@bsd.com.br> Cc: "freebsd-arm@freebsd.org" , rmacklem@uoguelph.ca From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <55c83b2d-2f1f-697e-25ff-2c6c4c2e6fea@bsd.com.br> Date: Sun, 5 Mar 2017 09:57:15 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <4c54882b-1cde-911f-84b1-c184013b6810@bsd.com.br> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 12:57:46 -0000 Em 05/03/2017 09:43, Otacílio escreveu: > Em 05/03/2017 09:08, Daniel Braniss escreveu: >> >>> On 5 Mar 2017, at 13:16, Otacílio >> > wrote: >>> >>> was killed: text file modification >> >> sounds like nfs issue,(hence involving Rick), but just in case, are >> the dates in sync between the serve and client? >> with the hello world program, try running it again >> >> danny >> >> >> > Server (amd64) is ntpd disabled while client (RPI3) is using : > > ntpd_enable="YES" > ntpd_sync_on_start="YES" > > on rc.conf > > > -Otacilio > I edited the server /etc/rc.conf adding ntpd_enable="YES" ntpd_sync_on_start="YES" and started ntpd with: root@squitch:/home/ota # /etc/rc.d/ntpd start Restart nfsd: root@squitch:/home/ota # service nfsd stop Stopping nfsd. Waiting for PIDS: 42689 42690. root@squitch:/home/ota # service lockd stop Stopping lockd. Waiting for PIDS: 93028. root@squitch:/home/ota # service statd stop Stopping statd. root@squitch:/home/ota # service nfsd start NFSv4 is disabled Starting nfsd. root@squitch:/home/ota # service mountd reload root@squitch:/home/ota # service lockd start Starting statd. Starting lockd. And mount and compile hello.c on RPI3, but no luck: root@rpi3:~ # mount squitch:/usr/ports /usr/ports root@rpi3:~ # mount squitch:/usr/src /usr/src root@rpi3:~ # cd /usr/ports/ root@rpi3:/usr/ports # cp /usr/home/ota/hello.c ./ root@rpi3:/usr/ports # cc -o hello hello.c root@rpi3:/usr/ports # ./hello Killed root@rpi3:/usr/ports # -Otacilio From owner-freebsd-arm@freebsd.org Sun Mar 5 16:28:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94AAACFAD2C for ; Sun, 5 Mar 2017 16:28:24 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 329B41FBC for ; Sun, 5 Mar 2017 16:28:23 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=65057 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckZ19-0001n5-0e; Sun, 05 Mar 2017 16:28:19 +0000 Received: from localhost ([127.0.0.1]:50358 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckZ18-000JxL-GH; Sun, 05 Mar 2017 16:28:18 +0000 From: Andrew Gierth To: Mark Millard Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> (Mark Millard's message of "Sun, 5 Mar 2017 03:02:24 -0800") Message-ID: <87tw77iwx6.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Sun, 05 Mar 2017 16:27:56 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 16:28:24 -0000 Here's another issue that seems to go away as a result of removing the cortex-a7 option: On the cortex-a7 build (world and all packages built with CPUTYPE set): emacs-25.1,3 built with x11 support and running in graphical mode is unstable; crashes randomly either with a mutex assertion (enqueue_mutex complaining that the mutex is already owned) or with SEGV. Running in text mode, it doesn't crash, but hitting pagedown in some buffers (where there are many similar lines) _reliably_ produces incorrect display output in which some characters are displaced by 4: drwxr-xr-x 2 root wheel 512 Feb 18 09:35 isp drwxr-xr-x 2 root wheel 512 Feb 18 09:40 ispfw drwxr-xr-x 2 root wheel 512 20 10:31 iwi et drwxr-xr-x 2 root wheel 1024 Feb 18 09:38 iwm in place of drwxr-xr-x 2 root wheel 512 Feb 18 09:35 isp drwxr-xr-x 2 root wheel 512 Feb 18 09:40 ispfw drwxr-xr-x 2 root wheel 512 Feb 20 10:31 iwi drwxr-xr-x 2 root wheel 1024 Feb 18 09:38 iwm (the "et" is what was displayed at that point on the previous page) (by "reliably" I mean that for given buffer contents and sequence of scroll movements that exhibit the problem, it always happens at the same place in the same way) On the non-CPUTYPE build, I can't reproduce either of the issues (though it's a bit early yet to tell regarding the random-crashes one). Investigation continues... -- Andrew. (Clarke's second law: to discover the limits of the possible, one must venture past them into the realm of the impossible) From owner-freebsd-arm@freebsd.org Sun Mar 5 17:54:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0F7FCFA586 for ; Sun, 5 Mar 2017 17:54:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EF681BF5 for ; Sun, 5 Mar 2017 17:54:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id 203so37622895ith.0 for ; Sun, 05 Mar 2017 09:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LhQmhPHmBrstxAcMvAq7WZTk4rCY4YiiLsIW3uUVPbo=; b=d7xOzPonvtorSbIC4iY8Uy3BKXmeigqzzlFqE698Ck/nY25vwUbjFg3WFLKqpIt58F i7d3qsntGRgqi/f9GVB8bdWtK0mwan2WNZs8PdLV65VjvBW2Lbo8fF3Xv5GsekGLE44M 2lt8PVKIq6lw/klASAIl/YyRFJD78QjfR/A1v1OJZZQ+I96R5xdagUayu6pXZrpgd+Oa tNrH+tMtTekokkAAoB1leyqAdv5r++jxJIJizXdS/90pY/uu3P3Pm3XuxbZvob0fEqoM THpmitPtDgjJW8Aw37WMGubeACo5zSqZqMSeDItJ03IjLKcumPYKJRijXvNOVPf9Au4L iBQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LhQmhPHmBrstxAcMvAq7WZTk4rCY4YiiLsIW3uUVPbo=; b=kvatKUIvw3SHQwjWGHKywh7d+sjPLL98o+tBVxO0UdpokE3noFsp+uydcUUVLOmP+q CQafN92OCLdv2wpZb6GvU0GupfOqVx8hHAWhgJ5DXQcbUZeBSrKclg6i1/pJnxs5NhX5 MhZRuZAujdSAr5sBlUtKw0FQ15cIQOK2Uy3Vuw1VnXmLycbufqBJmxShuRJbVOhY2f7n invvFsKC31iKozNzxK+YNJipC8T/052d7z1YZSBKXjWoJo930axm2MoJTqH3huP6/Ejo TvQnAIlQdvmopn9PHUJkS7kME4ZehAb8Ku8YgB4r+Oz8Pby8k8r27M7ZCRapxguOU5Py AGWA== X-Gm-Message-State: AMke39nhZHFzWuqyb/kkWp0XdP6RIPLjusbPwFbqk6LzybeXNyEiu4wwgsJyNptTPSP3hw4XRmr37ZIXrrhbQA== X-Received: by 10.36.93.213 with SMTP id w204mr13173387ita.60.1488736443640; Sun, 05 Mar 2017 09:54:03 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Sun, 5 Mar 2017 09:54:03 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <20170305041743.98af9e94662f8524a640b5d0@bidouilliste.com> References: <1488682131.69705.55.camel@freebsd.org> <20170305041743.98af9e94662f8524a640b5d0@bidouilliste.com> From: Warner Losh Date: Sun, 5 Mar 2017 10:54:03 -0700 X-Google-Sender-Auth: Dj-e7XqhQWFN1sdYQf6klOxnVzY Message-ID: Subject: Re: Cubox-i Hummingboard images gone To: Emmanuel Vadot Cc: Ian Lepore , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 17:54:04 -0000 On Sat, Mar 4, 2017 at 8:17 PM, Emmanuel Vadot wrote: > On Sat, 04 Mar 2017 19:48:51 -0700 > Ian Lepore wrote: > >> On Sat, 2017-03-04 at 21:32 -0500, Tom Pusateri wrote: >> > On the FreeBSD download page, https://www.freebsd.org/where.html, >> > there is a 11.0-RELEASE image for Solid Run Cubox-i Hummingboard >> > systems. But there are no longer any images for 11.0 Stable or 12.0 >> > Current. It seems as though new images are not being built. Is there >> > a hardware problem or lack of interest? I have several of these >> > boards and loved having the images built. >> > >> > Thanks, >> > Tom >> > >> >> I would guess it's because the corresponding u-boot packages are no >> longer available. I have no idea why that is (I used to maintain the >> u-boot stuff, but others are doing it now), but the list of images >> roughly corresponds to the list of available u-boot pkgs. >> >> -- Ian > > u-boot-cubox-hummingbird depends on gcc492 (which vendor u-boot needs) > so it conflict with gcc6XX which the other ones use. > Switching to upstream u-boot is needed but I don't have hardware to > test. I have a iMX6 board, maybe two, that I bought for this. I think mine is the wandboard. But we can trivially switch to the new gcc. Even w/o switching to my new framework, it's just one file away from working (basically, snag gcc5.h or gcc6.h from newer u-boot and use them, or even just use the gcc4.h one). I fought this on other ports before I switched over to the new framework. But of course we should switch if we can... When I looked at the issue last, it appeared that all our iMX6-supported boards that had waco out-of-mailine u-boots had support for them added to upstream. Warner From owner-freebsd-arm@freebsd.org Sun Mar 5 18:14:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2550FCFAB24 for ; Sun, 5 Mar 2017 18:14:31 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C167516A1 for ; Sun, 5 Mar 2017 18:14:30 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=17198 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckafq-0009fl-CT; Sun, 05 Mar 2017 18:14:26 +0000 Received: from localhost ([127.0.0.1]:19523 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckafp-000NNd-Qm; Sun, 05 Mar 2017 18:14:25 +0000 From: Andrew Gierth To: Mark Millard Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <87tw77iwx6.fsf@news-spur.riddles.org.uk> (Andrew Gierth's message of "Sun, 05 Mar 2017 16:27:56 +0000") Message-ID: <8760jnfvwp.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Sun, 05 Mar 2017 18:14:25 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 18:14:31 -0000 >>>>> "Andrew" == Andrew Gierth writes: Andrew> emacs-25.1,3 built with x11 support and running in graphical Andrew> mode is unstable; crashes randomly either with a mutex Andrew> assertion (enqueue_mutex complaining that the mutex is already Andrew> owned) or with SEGV. Running in text mode, it doesn't crash, Andrew> but hitting pagedown in some buffers (where there are many Andrew> similar lines) _reliably_ produces incorrect display output in Andrew> which some characters are displaced by 4: Extra bonus strangeness: recompiling just emacs without cortex-a7 does not fix either of these, so it's not an issue with miscompiling any of the emacs code. This is consistent with my experimentation with git. -- Andrew. From owner-freebsd-arm@freebsd.org Sun Mar 5 19:12:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47B21CFA8AC for ; Sun, 5 Mar 2017 19:12:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA4F1037 for ; Sun, 5 Mar 2017 19:12:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id f84so100283076ioj.0 for ; Sun, 05 Mar 2017 11:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4O3FfZFX9JFtKO3IT1JlyUbWoPuWOad676zp+f0nUeQ=; b=R3jwKLVbSMIulIt4OASVrcwwikYoLpVuMIf6WcHcUfmOMkv22EY9idcn91KQTTsRHM rzRNa59eXveZtSqqSkLxdABY+Y5pd5jbJt2yaEcbV5+bM0BuhpTB4emPemwLvC4qgybJ +PS+TRb+2AjljSk0Ulr8dLSMW27dMT67Sxu/KIXkBZYQdApf92g62BN2yXPidaUbQumj QbZ121eYzz+oUbYcLz9s8yAUHpEh4mQxO6YKKGiZ+HRpEOnO5S2A2kGBT3C5+zHR/E2F gZf2r1pp+ymBzD7uQ7RCH0Lg/olSeXe3jojfUC4qal94Gc+M/PLitFPshS2+w6vpBPTr tHwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4O3FfZFX9JFtKO3IT1JlyUbWoPuWOad676zp+f0nUeQ=; b=d8GHSH0wX8Y3cymh8Yj/jzVWzuqxImUThPpsFyp9k+XwcwmTHxVbuhM4awd0GuMK2W xX845thPxDWI5gObppU8P2lvGqrHMpotJB419JKFebDThSpV9gXqutfeHDC1XTchKwl1 upuE5SCIxRltVS0gfTLZ1YK4Jx+zdK2+N2OMv9SonLWT32t4xlq3zNCI/ThRVOTJsYLX X3zfndzxr9h5/VSrrzuKTV0RPyTSWqASIdK2fP8GWdCzNtoO8rApV9EknqhMCL0Avn4A bwY57AGYXXoWsyMi5B7RSsz5Y4EXQ0a/0S410Ydn/LTIdewZP5OuttFZL0nQZYvxiPkv Aayg== X-Gm-Message-State: AMke39nVbRux8o73p74FAr3n7vWqCUjxY5uwa/FQJ1zH2BKhj6Zh0Z6an9dN73lWDEf61n4rsq7xnnsHZbYr5g== X-Received: by 10.107.174.220 with SMTP id n89mr12564514ioo.166.1488741127309; Sun, 05 Mar 2017 11:12:07 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Sun, 5 Mar 2017 11:12:06 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <8760jnfvwp.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> <8760jnfvwp.fsf@news-spur.riddles.org.uk> From: Warner Losh Date: Sun, 5 Mar 2017 12:12:06 -0700 X-Google-Sender-Auth: e2XcZCxkyDbFxrsxcjJeKeUbSiI Message-ID: Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? To: Andrew Gierth Cc: Mark Millard , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 19:12:08 -0000 On Sun, Mar 5, 2017 at 11:14 AM, Andrew Gierth wrote: >>>>>> "Andrew" == Andrew Gierth writes: > > Andrew> emacs-25.1,3 built with x11 support and running in graphical > Andrew> mode is unstable; crashes randomly either with a mutex > Andrew> assertion (enqueue_mutex complaining that the mutex is already > Andrew> owned) or with SEGV. Running in text mode, it doesn't crash, > Andrew> but hitting pagedown in some buffers (where there are many > Andrew> similar lines) _reliably_ produces incorrect display output in > Andrew> which some characters are displaced by 4: > > Extra bonus strangeness: recompiling just emacs without cortex-a7 does > not fix either of these, so it's not an issue with miscompiling any of > the emacs code. This is consistent with my experimentation with git. There's some mis-match issue somewhere... Like I said before: the base worked, more or less, but ports had issues of unknown scope and dimension. git, emace, etc are all ports :) Warner From owner-freebsd-arm@freebsd.org Mon Mar 6 02:03:54 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69AF2CF92F8 for ; Mon, 6 Mar 2017 02:03:54 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DFDA1350; Mon, 6 Mar 2017 02:03:54 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Cc:To:From; bh=VfZJe7eNUH62g4zMD8ZTE/q7mTVBNYn3s7c+Jgd54Yw=; b=AWgk0I5zE4HlgCMEJfupaNrlfoppuYr05uPX8owmLwQgCv5nLFIjsrYdELSxmc4HS0dvEaHBa8KEwTmCU70XsLvg0Znezaxsq0MDPChr20KemWyF2rJxVxx2lIelHHDMLvwRMv6pfz0ehimwI+6FnrAEc8sztaFM0CXoX/Se+evNsvvH; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cki02-0006QP-HQ; Sun, 05 Mar 2017 18:03:52 -0800 From: "Tony Hain" To: Cc: "'Ian Lepore'" Date: Sun, 5 Mar 2017 18:03:46 -0800 Message-ID: <01c701d2961d$e3dd6100$ab982300$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKWFnDH3u1k5S7URoq/cuLJiik7jA== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: BBB asymmetric stack? X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.net) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 02:03:54 -0000 FreeBSD 12.0-CURRENT #0 r314118M: Wed Feb 22 22:49:19 PST 2017 Trying to calibrate the ntp feed on the BBB I was suspecting some problem with the dmtpps driver, but then realized that network asymmetry would be more likely to explain the persistent offset. It would appear that there is an asymmetry within the stack on the am335x based system. ping6 Rpi -> BBB 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 0.503/0.567/0.642/0.047 ms ping6 BBB -> Rpi 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.878/0.967/1.141/0.134 ms Those are on adjacent ports on the same 100mbps switch. --- ping6 Fbsd-8 -> BBB 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.599/0.734/1.041/0.112 ms ping6 BBB -> Fbsd-8 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.855/0.970/1.816/0.296 ms Those are one router hop apart. --- Even localhost appears to indicate a problem in the FreeBSD-arm side of this: pi# ping6 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.220 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.222 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.221 ms i386# ping6 ::1 PING6(56=40+8+8 bytes) ::1 --> ::1 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.185 ms 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.135 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.129 ms bbb# ping6 ::1 PING6(56=40+8+8 bytes) ::1 --> ::1 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.672 ms 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.477 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.464 ms I realize the loopback ping by itself is not a good indicator of an asymmetry problem, but FreeBSD 8 on i386 systems ping::1 at ~ 130us, while all the FreeBSD 10/11 VMs (Hyper-V & VMware) and the pi ping ::1 at ~220us. The issue is that the time is always longer when the BBB initiates the ping, which would imply some transmit delay that does not exist when responding to an incoming ping, but it could be simply getting the reply back to user space which only happens in the BBB initiate case. ==== The ntp perspective might shed some light on which direction. pi pi# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================ == GPS_NMEA(0) .GPS. 0 s 342d 16 0 0.000 -29.245 0.000 oPPS(0) .PPS. 0 s 6 16 377 0.000 0.000 0.002 *172.20.0.18 .PPS. 1 u 12 64 377 0.492 0.030 0.026 <== i386 i386 # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================ == xPPS(1) .PPS. 0 l 14 16 377 0.000 0.001 0.002 oGPS_NMEA(1) .GPS. 0 l 8 16 377 0.000 0.000 0.002 +2001:470:e930:2 .PPS. 1 u 30 64 377 0.519 0.008 0.020 <==pi BBB # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================ == oPPS(0) .PPS. 0 s 32 32 377 0.000 0.000 0.004 *GPS_NMEA(0) .GPS. 0 s 7 8 377 0.000 -47.650 39.504 +2001:470:e930:2 .PPS. 1 u 28 32 377 0.682 -0.164 0.043 <== pi +2001:470:e930:7 .GPS. 1 u 44 64 377 0.963 -0.197 1.771 <== i386 The offset being about half of the path variance for an asymmetric path is expected ntp behavior. All of these systems are looking at the same PPS pulse, though the i386 is seeing it through an RS232 driver delay so it has an additional 1.3us fudge factor. In any case, it appears that there is some form of delay in getting bits out of the box. Tony From owner-freebsd-arm@freebsd.org Mon Mar 6 04:26:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7302FCFB9DB for ; Mon, 6 Mar 2017 04:26:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-200.reflexion.net [208.70.211.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F56018F3 for ; Mon, 6 Mar 2017 04:26:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 696 invoked from network); 6 Mar 2017 04:29:10 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Mar 2017 04:29:10 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 05 Mar 2017 23:26:51 -0500 (EST) Received: (qmail 14391 invoked from network); 6 Mar 2017 04:26:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Mar 2017 04:26:50 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 43429EC885D; Sun, 5 Mar 2017 20:26:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <8760jnfvwp.fsf@news-spur.riddles.org.uk> Date: Sun, 5 Mar 2017 20:26:49 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> <8760jnfvwp.fsf@news-spur.riddles.org.uk> To: Andrew Gierth , Warner Losh X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 04:26:59 -0000 On 2017-Mar-5, at 10:14 AM, Andrew Gierth = wrote: >>>>>> "Andrew" =3D=3D Andrew Gierth = writes: >=20 > Andrew> emacs-25.1,3 built with x11 support and running in graphical > Andrew> mode is unstable; crashes randomly either with a mutex > Andrew> assertion (enqueue_mutex complaining that the mutex is already > Andrew> owned) or with SEGV. Running in text mode, it doesn't crash, > Andrew> but hitting pagedown in some buffers (where there are many > Andrew> similar lines) _reliably_ produces incorrect display output in > Andrew> which some characters are displaced by 4: >=20 > Extra bonus strangeness: recompiling just emacs without cortex-a7 does > not fix either of these, so it's not an issue with miscompiling any of > the emacs code. This is consistent with my experimentation with git. >=20 > --=20 > Andrew. I'm currently sticking with some known failures in the base system: openssl speed failures. (A signal based program crash without X11 involved could be interesting.) Disabling the use of NEON via a hack removes the "openssl speed" problem. With: /usr/src/crypto/openssl/crypto/armcap.c : . . . void OPENSSL_cpuid_setup(void) { . . . } else if (sigsetjmp(ill_jmp, 1) =3D=3D 0) { _armv7_neon_probe(); #ifndef DISABLE_HACK_THAT_AVOIDS_NEON OPENSSL_armcap_P |=3D ARMV7_NEON; #endif . . . "openssl speed" completes normally. This can also be done from gdb by setting OPENSSL_armcap_P after the: OPENSSL_armcap_P |=3D ARMV7_NEON; executes in order to turn off the bit. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Mar 6 08:29:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7652CFBBED for ; Mon, 6 Mar 2017 08:29:27 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74C4E1390; Mon, 6 Mar 2017 08:29:27 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: by mail-yw0-x243.google.com with SMTP id p77so2606473ywg.0; Mon, 06 Mar 2017 00:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lIyAASuceHIFuf2+VYGNoZvc97oZQ4r44irPhq2xEi0=; b=dkh/USpXXFvnyBxqaYaTD01X0ZVTyIOPRiaguoCjuGNuivWk9ag71YxIPvZp/6hJdd I/IX8JmwN467rz+PeATLUMmDKZned1naBNcxcMl3tBqQB37/47wwmNwTdUxxv06jr4Bi l0l8CUiQsohRtfholKMsKlQhI2aN8APLRi59OidrS46cgYvEUevrHP4XOprsCW3Bet66 nFhqpLM8FlLpptP9g7V+DVrfvLdsC8KD3OJ/M0AjFgb7/UqhZJ/EW1R/xqoG6qtTDk1D pdNaAAEVCF8uz8qB5coIM7SqRyfAjMquoJS+IVNHYvVKDuczNHMEbL/Xosyfhcu2ks6e xbUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lIyAASuceHIFuf2+VYGNoZvc97oZQ4r44irPhq2xEi0=; b=F0MFzwZB/RCWdXWOvGsPR5poRbKRVV/TKvzOOa1Lcy3FmUgfkrcA0hxCe3lLZZji9E ECGqPATcBL6nolQTeeVVPYnePZrdIXKzsuBmiKrv00Hb1ePlUIqNB758ke2YIq0b/6Cl 5KOnBv/UxhPtSYQrmCHmNfRiaTEmVoBUWjr0nq3CIpmnEwc39XFH7dcdvrTaHNTtBIdn I/g9FryHjA5mZmyzw26VHWAIMSneh8ZVOZo9hcR72zPON2jwm5j/0h/Q/BX9nY4cHLmf BipRi9yqzxa82KWGierIpJSqYxXjqqX1lV5z78RYvzhR0gIyH0JlLsz1SmdJT9r0HU1T Fbsw== X-Gm-Message-State: AMke39mXfrwUGP2eCYmG2ILZPqUE2kVA2YJSU7sinGk+zSLwRuJ8rHWeQmg9gT0vMWeB1WUPQ2L4msJYinS3mw== X-Received: by 10.13.252.4 with SMTP id m4mr10003834ywf.232.1488788966531; Mon, 06 Mar 2017 00:29:26 -0800 (PST) MIME-Version: 1.0 Sender: c.jayachandran@gmail.com Received: by 10.83.42.214 with HTTP; Mon, 6 Mar 2017 00:29:26 -0800 (PST) In-Reply-To: <1488664965.69705.24.camel@freebsd.org> References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> From: "Jayachandran C." Date: Mon, 6 Mar 2017 13:59:26 +0530 X-Google-Sender-Auth: NDS2K-TSYWXnoYtvuRBxqHke5_4 Message-ID: Subject: Re: Odd-looking serial console prompt on RPI2 To: Ian Lepore Cc: Michael Tuexen , freebsd-arm@freebsd.org, Oleksandr Tymoshenko Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 08:29:27 -0000 Hi Ian, On Sun, Mar 5, 2017 at 3:32 AM, Ian Lepore wrote: > On Sat, 2017-03-04 at 22:24 +0530, Jayachandran C. wrote: >> On Thu, Mar 2, 2017 at 7:35 AM, Ian Lepore wrote: >> > >> > On Wed, 2017-03-01 at 18:01 -0800, Oleksandr Tymoshenko wrote: >> > > >> > > Ian Lepore (ian@freebsd.org) wrote: >> > > > >> > > > >> > > > On Wed, 2017-03-01 at 16:03 -0800, bob prohaska wrote: >> > > > > >> > > > > >> > > > > On Wed, Mar 01, 2017 at 09:20:13PM +0100, Michael Tuexen >> > > > > wrote: >> > > > > > >> > > > > > >> > > > > > >> > > > > > Interesting... Let us know what works and what doesn't... >> > > > > > >> > > > > > Best regards >> > > > > > Michael >> > > > > > >> > > > > As of FreeBSD 12.0-CURRENT (RPI2) #0 r314450: Wed Mar 1 >> > > > > 14:48:26 >> > > > > PST >> > > > > 2017 >> > > > > the serial console is still corrupt (output truncated, input >> > > > > not >> > > > > echoed >> > > > > but treated like the enter key). The serial console does >> > > > > seem to >> > > > > work >> > > > > with U-boot and loader, so I don't think it's the upstream >> > > > > hardware. >> > > > > >> > > > > The HDMI console looks normal and USB keyboard input seems to >> > > > > work. >> > > > > >> > > > > There have been several updates to /usr/src/sys/dev/uart and >> > > > > it >> > > > > looks >> > > > > as if kernel updates are still coming. Maybe the job simply >> > > > > isn't >> > > > > done yet. >> > > > > >> > > > > bob >> > > > > >> > > > It seems like this might be caused by r314318. Can someone >> > > > having >> > > > this problem confirm if 314317 works and 314318 fails? >> > > Tested on my RPi2, 314317 - works, 314318 - broken >> > > >> > CC'ing jchandra@. >> > >> > I wonder if there is some bad interaction when the same uart is >> > used as >> > a console and a tty? >> I don't have a RPi3 setup to test now, I will look at the code again >> to see if >> I can find an issue. >> >> Otherwise I will revert the change until we can find why the RPi UART >> breaks >> with these changes. >> >> Thanks, >> JC. > > The bugs should be fixed as of r314682. It looks like the bugs have > long been in the pl011 driver, but were masked by having a fifo depth > of 1 byte -- it all sorta worked by accident previously. Looked thru r314681 and r314682, thanks for fixing this up. There seems to be a difference in behavior in IFLS settings on different platforms. I did not see a reasonable way to handle the tx fifo being full when sc_txbuf is partially used, which is why I skipped this case in the original commit - that was a mistake. Thanks, JC. From owner-freebsd-arm@freebsd.org Mon Mar 6 09:23:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FD5DCFBE74 for ; Mon, 6 Mar 2017 09:23:57 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C0DC12DD for ; Mon, 6 Mar 2017 09:23:57 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1ckory-004k8U-Sq; Mon, 06 Mar 2017 10:23:54 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: freebsd-arm@freebsd.org Subject: Re: Booting an old kernel on RPI2 In-reply-to: <20170304165740.GA9625@www.zefox.net> References: <20170304165740.GA9625@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 06 Mar 2017 10:23:54 +0100 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 09:23:57 -0000 At Sat, 4 Mar 2017 08:57:40 -0800, bob prohaska wr= ote: > A recent world/kernel build went badly wrong, resulting in an > =22out of memory=22 report on the console and no further progress. >=20 > There are two spare kernels on the system, kernel.old and kernel.spare,= > but even kernel.spare, which I know worked, still produces the same > =22out of memory=22 prompt on the console.=20 > =5B...=5D I am having the same problem here. It happened during make installworld of r314701. I run make installworld while the former kernel r313407 was still active. Now both kernels will boot up, but produce the same =22out of memory=22 message while going to single- or multi-user. So it is not even possible to get a working shell in single-user mode. As it first happens during make installworld while still running the =22old=22 r313407 kernel I think the cause is not the kernel itself. Ralf From owner-freebsd-arm@freebsd.org Mon Mar 6 10:38:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7472DCFAB22 for ; Mon, 6 Mar 2017 10:38:08 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 082F81F96 for ; Mon, 6 Mar 2017 10:38:08 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id n11so60141855wma.1 for ; Mon, 06 Mar 2017 02:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:reply-to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ONSRxvSw0xaZHtIfYY+eNgiDL1o00u6zD+RnYHGlQpA=; b=Q2Cvclzh6gDQ61RfSPrf7XHM5dGobwYetmvcuwSBhC9OvYzaVohMwW+5Z99dBtzNnS MkVkJkyUb0BzQ955pFX4bzWq91v+SInvM/tnV6TOJwcD0kudE2GZEqSqQwTKv9piX7Pc Zo57S3hBHedrT4wf9NmjEjVraF9yiLbWkSa3naN2NuYNnJRLSQnkUOA9x8ISagDlgQqV pU7xYSm8oTfhUNSsgiizhMI4SdtnT6UGNGvx7tP5u5MCA4DGn3UQ8NoT+wtFzk6I35py P3jQ60x9sNQUCpanlOggtLcNvPYdEzh4oM3wT8lqTuToPRYznQLMxOg1dJpsTM4C2lRo HooA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:reply-to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ONSRxvSw0xaZHtIfYY+eNgiDL1o00u6zD+RnYHGlQpA=; b=gNJzBKZbml/ApZJBjYYFewhBneDDM9JNIe21kLMJHGigCfNWbaUXOlH3s8zm3OzSeN 8MNVD6lMeIJJz3hY7uR4sjsXncRPK+TCTN6Cu9oD5t35/dI/vThq7C80p76FEsCimEXD 9IB89kjTcs6mXnct8WMLQTrtOtfFBRxujJJYeLphLL12lg0yb2b0mPZjBOoroIZPbfoe SgVfr8Ev+MB77nXQSTURgkP+FWs4Mvbfjq1HLq7Xp+Sc5/fFAQzHt9aTJX4wRHb0H3Qz 1f+aVEBkfn4lKOap0RZ7OmxIygvyy39ohIwE+jy49YkxyhFKc+QZZla90W/4Y926YT/T JedQ== X-Gm-Message-State: AMke39nHkYfmK2CUlVQGb7kPxTbSdDThXHJF16VkEQicn8xUSAKFPTW9Nx8aU0RAPkwYMA== X-Received: by 10.28.181.80 with SMTP id e77mr13013965wmf.57.1488796686227; Mon, 06 Mar 2017 02:38:06 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id l21sm9854860wrl.59.2017.03.06.02.38.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 02:38:05 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Subject: Re: Booting an old kernel on RPI2 References: <20170304165740.GA9625@www.zefox.net> To: Ralf Wenk , freebsd-arm@freebsd.org Reply-To: mmel@freebsd.org Message-ID: <5b7c8f33-2ba7-540b-3957-de4103542ed7@freebsd.org> Date: Mon, 6 Mar 2017 11:38:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:38:08 -0000 On 06.03.2017 10:23, Ralf Wenk wrote: > At Sat, 4 Mar 2017 08:57:40 -0800, bob prohaska wrote: >> A recent world/kernel build went badly wrong, resulting in an >> "out of memory" report on the console and no further progress. >> >> There are two spare kernels on the system, kernel.old and kernel.spare, >> but even kernel.spare, which I know worked, still produces the same >> "out of memory" prompt on the console. >> [...] > > I am having the same problem here. > It happened during make installworld of r314701. I run make installworld > while the former kernel r313407 was still active. > Now both kernels will boot up, but produce the same "out of memory" > message while going to single- or multi-user. > So it is not even possible to get a working shell in single-user mode. > As it first happens during make installworld while still running the > "old" r313407 kernel I think the cause is not the kernel itself. > > Ralf Hi, I'm afraid that clang 4.0.0 miscompile jemalloc for armv6 architecture. As workaround please use r314564 for buildworld, identification of the problem takes some time. As alternative, you can put CPUTYPE=cortex-a[7][8][9][15] to make.conf. This works for me (with cortex-a15) with actual head. Michal From owner-freebsd-arm@freebsd.org Mon Mar 6 11:29:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E2AFCFBBA6 for ; Mon, 6 Mar 2017 11:29:19 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1F091BE0 for ; Mon, 6 Mar 2017 11:29:18 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=21983 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckqpA-0001Fl-LE; Mon, 06 Mar 2017 11:29:08 +0000 Received: from localhost ([127.0.0.1]:54517 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckqp9-000H9R-Nb; Mon, 06 Mar 2017 11:29:07 +0000 From: Andrew Gierth To: Mark Millard Cc: Warner Losh , "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> (Mark Millard's message of "Sun, 5 Mar 2017 20:26:49 -0800") Message-ID: <87tw76ekx6.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> <8760jnfvwp.fsf@news-spur.riddles.org.uk> <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Mon, 06 Mar 2017 11:29:06 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:29:19 -0000 >>>>> "Mark" == Mark Millard writes: Mark> I'm currently sticking with some known failures in the base Mark> system: Sure, but the emacs one is both more predictable than any of the other failures and _doesn't_ involve openssl (it might load 100 shared libs, but libcrypto is not amongst them; gnutls is, but isn't being called). The emacs text display bug is reproducible in emacs-nox11 build. Mark> Disabling the use of NEON via a hack removes the "openssl speed" Mark> problem. Right, but it's not simply the use of NEON which is the issue because importing the NEON sha1 code into git in an otherwise non-cortex-a7 build does not reproduce any problem. -- Andrew. From owner-freebsd-arm@freebsd.org Mon Mar 6 13:55:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29728CFB517 for ; Mon, 6 Mar 2017 13:55:32 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBEC71CAA for ; Mon, 6 Mar 2017 13:55:31 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=24214 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1ckt6l-0004cz-9w; Mon, 06 Mar 2017 13:55:27 +0000 Received: from localhost ([127.0.0.1]:48080 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ckt6k-000MAp-1V; Mon, 06 Mar 2017 13:55:26 +0000 From: Andrew Gierth To: Mark Millard Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <87tw76ekx6.fsf@news-spur.riddles.org.uk> (Andrew Gierth's message of "Mon, 06 Mar 2017 11:29:06 +0000") Message-ID: <8760jm1pem.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> <8760jnfvwp.fsf@news-spur.riddles.org.uk> <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> <87tw76ekx6.fsf@news-spur.riddles.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Mon, 06 Mar 2017 13:55:24 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 13:55:32 -0000 >>>>> "Andrew" == Andrew Gierth writes: Andrew> The emacs text display bug is reproducible in emacs-nox11 Andrew> build. Except this turns out to have been a total red herring, sorry. -- Andrew. From owner-freebsd-arm@freebsd.org Mon Mar 6 14:14:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE239CFBDFC for ; Mon, 6 Mar 2017 14:14:52 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A5E51976 for ; Mon, 6 Mar 2017 14:14:52 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id t193so65556629wmt.1 for ; Mon, 06 Mar 2017 06:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:references:to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ssS2CbTyhSF04g7oiO00x1VvAZkp2WLJaU210emhDMw=; b=TEMH6GufAtMTVid6/EXYhSy9wGt3Kv72Kw1K+D54426gv6xWXTLqxYLDqKRPneVmTN 79y+imRsglGyjtMHZB1LGMvjoU176uMKo9O/ARmsuZJScBNcHjvdWAjS6Dt5FKwoKVEK uNa90OxUa6NvwvjesAf3Vo4GI4oI341PAQtfWLffQKTd7VN253a48VndnNOXskOL5B82 66I6s4Y+ZQQwVuBbEBHJnBLzpSxH9cYQjsOAimh6ZiRAOc+dxK93h7uuAQ01E2xAHBF2 1fv3DVbmglhEShPOpmn51HGWLPXgReNsegX7OjjPRLelVc7FEBqerhZr0qcyVcSOi+t3 fhog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:references:to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ssS2CbTyhSF04g7oiO00x1VvAZkp2WLJaU210emhDMw=; b=jIIauzr/LpiAdooBjOfKcQCjvWkRhTiENfxIbjtwooZSN3SALdp8JkhNeSPZTJRqse p64DD5XWpNA5jB9i9/sPDFbRKuXQtmCaaUmJz/nuQuzPqqhvr2UEtT5jOaYwvb136Pdg xN60tEFqYCxcpG6XlJIVuk/PRpQYgKIG5Cv8wZx80QD4tXCs4Wxz+HlovofvrlcEKK0t CaSehIYTrNpNajBlI1HBbWIoOFzSb8HQiVGOGEDJJf+kSLfSEQSf3fQRz9Wt5gareS16 5fGKjoqA0lFeA9DcvsKlmzylIE74JnNvmdZD1LiJyFpFXVTElWDVQ7nUMk1BN+2WEW1I fbcg== X-Gm-Message-State: AMke39nqQbkc+ea7DfhPib1xK1rLCg+bb2zoycPtlImtOWfV7QLxznK1x0cgWt5+VK3zjg== X-Received: by 10.28.7.13 with SMTP id 13mr13791478wmh.16.1488809689821; Mon, 06 Mar 2017 06:14:49 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id y4sm11710582wmy.5.2017.03.06.06.14.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 06:14:49 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: Booting an old kernel on RPI2 References: <20170304165740.GA9625@www.zefox.net> <5b7c8f33-2ba7-540b-3957-de4103542ed7@freebsd.org> To: Ralf Wenk , "freebsd-arm@freebsd.org" Message-ID: <9529cdf4-2e8c-42c9-9659-ac5ade7e62fa@freebsd.org> Date: Mon, 6 Mar 2017 15:14:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 14:14:52 -0000 On 06.03.2017 13:55, Ralf Wenk wrote: > Hello Michal, > >> Hi, >> I'm afraid that clang 4.0.0 miscompile jemalloc for armv6 architecture. > ouch! Thank you for that information. > >> As workaround please use r314564 for buildworld, identification of the >> problem takes some time. > I might have some misunderstanding here: > r314564 is the release which brings clang 4.0.0 into head. > Do you mean the latest head release before r314564? Which is r314563. Oups. Yes, r314563 of course, sorry. > >> As alternative, you can put CPUTYPE=cortex-a[7][8][9][15] to make.conf. >> This works for me (with cortex-a15) with actual head. > The main challenge will be "how to exchange 'world' without an working > system/environment", I think. I cross-compile regularly, but have never > cross-installed. For me, "make installworld DESTDIR=/.. " works Michal From owner-freebsd-arm@freebsd.org Mon Mar 6 16:16:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63024CFBC25 for ; Mon, 6 Mar 2017 16:16:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 358031368; Mon, 6 Mar 2017 16:16:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v26GG5FU019235 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Mar 2017 08:16:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v26GG435019234; Mon, 6 Mar 2017 08:16:04 -0800 (PST) (envelope-from fbsd) Date: Mon, 6 Mar 2017 08:16:04 -0800 From: bob prohaska To: mmel@freebsd.org Cc: Ralf Wenk , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting an old kernel on RPI2 Message-ID: <20170306161603.GA19195@www.zefox.net> References: <20170304165740.GA9625@www.zefox.net> <5b7c8f33-2ba7-540b-3957-de4103542ed7@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b7c8f33-2ba7-540b-3957-de4103542ed7@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:16:06 -0000 On Mon, Mar 06, 2017 at 11:38:07AM +0100, Michal Meloun wrote: > > > > Hi, > I'm afraid that clang 4.0.0 miscompile jemalloc for armv6 architecture. > One of the kernels reporting "out of memory" during boot is FreeBSD 11.0-CURRENT #71 r297769: Sat Apr 9 18:11:07 PDT 2016 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) U-boot in all cases is U-Boot 2015.04 (May 30 2015 - 22:13:58) which I admit is rather old..... Is the bug in Clang old enough to be the culprit? bob prohaska From owner-freebsd-arm@freebsd.org Mon Mar 6 16:25:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63EAACFBFDB for ; Mon, 6 Mar 2017 16:25:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB4D91A9C for ; Mon, 6 Mar 2017 16:25:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 752187d1-0289-11e7-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 752187d1-0289-11e7-95b5-6dfd7dbb0ee5; Mon, 06 Mar 2017 16:25:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v26GOqOZ000944; Mon, 6 Mar 2017 09:24:52 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488817492.18764.14.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: "Jayachandran C." Cc: Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Date: Mon, 06 Mar 2017 09:24:52 -0700 In-Reply-To: References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:25:09 -0000 On Mon, 2017-03-06 at 13:59 +0530, Jayachandran C. wrote: > Hi Ian, > > On Sun, Mar 5, 2017 at 3:32 AM, Ian Lepore wrote: > > > > On Sat, 2017-03-04 at 22:24 +0530, Jayachandran C. wrote: > > > > > > On Thu, Mar 2, 2017 at 7:35 AM, Ian Lepore > > > wrote: > > > > > > > > > > > > On Wed, 2017-03-01 at 18:01 -0800, Oleksandr Tymoshenko wrote: > > > > > > > > > > > > > > > Ian Lepore (ian@freebsd.org) wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2017-03-01 at 16:03 -0800, bob prohaska wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 01, 2017 at 09:20:13PM +0100, Michael Tuexen > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Interesting... Let us know what works and what > > > > > > > > doesn't... > > > > > > > > > > > > > > > > Best regards > > > > > > > > Michael > > > > > > > > > > > > > > > As of FreeBSD 12.0-CURRENT (RPI2) #0 r314450: Wed Mar  1 > > > > > > > 14:48:26 > > > > > > > PST > > > > > > > 2017 > > > > > > > the serial console is still corrupt (output truncated, > > > > > > > input > > > > > > > not > > > > > > > echoed > > > > > > > but treated like the enter key).  The serial console does > > > > > > > seem to > > > > > > > work > > > > > > > with U-boot and loader, so I don't think it's the > > > > > > > upstream > > > > > > > hardware. > > > > > > > > > > > > > > The HDMI console looks normal and USB keyboard input > > > > > > > seems to > > > > > > > work. > > > > > > > > > > > > > > There have been several updates to /usr/src/sys/dev/uart > > > > > > > and > > > > > > > it > > > > > > > looks > > > > > > > as if kernel updates are still coming. Maybe the job > > > > > > > simply > > > > > > > isn't > > > > > > > done yet. > > > > > > > > > > > > > > bob > > > > > > > > > > > > > It seems like this might be caused by r314318.  Can someone > > > > > > having > > > > > > this problem confirm if 314317 works and 314318 fails? > > > > > Tested on my RPi2, 314317 - works, 314318 - broken > > > > > > > > > CC'ing jchandra@. > > > > > > > > I wonder if there is some bad interaction when the same uart is > > > > used as > > > > a console and a tty? > > > I don't have a RPi3 setup to test now, I will look at the code > > > again > > > to see if > > > I can find an issue. > > > > > > Otherwise I will revert the change until we can find why the RPi > > > UART > > > breaks > > > with these changes. > > > > > > Thanks, > > > JC. > > The bugs should be fixed as of r314682.  It looks like the bugs > > have > > long been in the pl011 driver, but were masked by having a fifo > > depth > > of 1 byte -- it all sorta worked by accident previously. > Looked thru r314681 and r314682, thanks for fixing this up. > > There seems to be a difference in behavior in IFLS settings on > different > platforms. I did not see a reasonable way to handle the tx fifo being > full > when sc_txbuf is partially used, which is why I skipped this case in > the > original commit - that was a mistake. > > Thanks, > JC. Hmm.  Does that imply the changes I made to set the fifo trigger level to 3/4 may not work on some other platforms?  I was only able to test on rpi-b. I've always hated the tx interface between the core uart code and the hardware drivers.  The idea that when a tx interrupt happens, the hardware code has to accept exactly as many characters as the tx fifo watermark level is just... strange.  It's especially hard to work with when a uart device has dma support.  But redoing it without breaking every existing driver is hard. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 6 16:30:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AE81CFB176 for ; Mon, 6 Mar 2017 16:30:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67A331D80 for ; Mon, 6 Mar 2017 16:30:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v26GU7wI019271 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Mar 2017 08:30:08 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v26GU6gj019270; Mon, 6 Mar 2017 08:30:06 -0800 (PST) (envelope-from fbsd) Date: Mon, 6 Mar 2017 08:30:05 -0800 From: bob prohaska To: Ralf Wenk Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting an old kernel on RPI2 Message-ID: <20170306163005.GB19195@www.zefox.net> References: <20170304165740.GA9625@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:30:01 -0000 On Mon, Mar 06, 2017 at 10:23:54AM +0100, Ralf Wenk wrote: > > I am having the same problem here. > It happened during make installworld of r314701. I run make installworld > while the former kernel r313407 was still active. > Now both kernels will boot up, but produce the same "out of memory" > message while going to single- or multi-user. > So it is not even possible to get a working shell in single-user mode. > As it first happens during make installworld while still running the > "old" r313407 kernel I think the cause is not the kernel itself. > > As I understand it, sometime before the FreeBSD loader starts up a division of memory is made between GPU and CPU. There is a config.txt file containing gpu_mem=64 on my FreeBSD systems, but some of the Linux literature mentions a file called uEnv.txt, which FreeBSD seems not to use (nor does Raspbian, far as I can see). I wonder if there might be a u-boot command to check if the setup routines have become corrupted, leaving too little memory for the kernel to function, even though it reports real memory = 989851648 (943 MB) avail memory = 957444096 (913 MB) during the failed boot attempts. Thanks for reading, and any ideas! bob prohaska From owner-freebsd-arm@freebsd.org Mon Mar 6 16:41:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62B32CFB6DA for ; Mon, 6 Mar 2017 16:41:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47ADE1509 for ; Mon, 6 Mar 2017 16:41:39 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ac370671-028b-11e7-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ac370671-028b-11e7-b3c2-c9f38144898e; Mon, 06 Mar 2017 16:40:57 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v26GfVw8000984; Mon, 6 Mar 2017 09:41:31 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488818491.18764.21.camel@freebsd.org> Subject: Re: Booting an old kernel on RPI2 From: Ian Lepore To: bob prohaska , Ralf Wenk Cc: freebsd-arm@freebsd.org Date: Mon, 06 Mar 2017 09:41:31 -0700 In-Reply-To: <20170306163005.GB19195@www.zefox.net> References: <20170304165740.GA9625@www.zefox.net> <20170306163005.GB19195@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:41:40 -0000 On Mon, 2017-03-06 at 08:30 -0800, bob prohaska wrote: > On Mon, Mar 06, 2017 at 10:23:54AM +0100, Ralf Wenk wrote: > > > > > > I am having the same problem here. > > It happened during make installworld of r314701. I run make > > installworld > > while the former kernel r313407  was still active. > > Now both kernels will boot up, but produce the same "out of memory" > > message while going to single- or multi-user. > > So it is not even possible to get a working shell in single-user > > mode. > > As it first happens during make installworld while still running > > the > > "old" r313407 kernel I think the cause is not the kernel itself. > > > > > As I understand it, sometime before the FreeBSD loader starts up a > division of memory is made between GPU and CPU. There is a config.txt > file containing gpu_mem=64 on my FreeBSD systems, but some of the > Linux literature mentions a file called uEnv.txt, which FreeBSD  > seems not to use (nor does Raspbian, far as I can see).  > > I wonder if there might be a u-boot command to > check if the setup routines have become corrupted, leaving too > little memory for the kernel to function, even though it reports > real memory  = 989851648 (943 MB) > avail memory = 957444096 (913 MB) > during the failed boot attempts. > > > Thanks for reading, and any ideas! > > bob prohaska > I'm pretty sure this out of memory error has nothing to do with the kernel at all.  It appears to be caused by clang 4.0 building the world incorrectly (most likely just jemalloc). It's a pity that both clang and jemalloc were updated to new versions within a few days of each other. It's even more of a pity that a series of other errors make it almost impossible to cross-build for arm from a stable-10 amd64 system after r313403, so that bisecting to find the exact point of the error is also almost impossible.  The problem with crossbuilding isn't fixed yet, (it's got something to do with libnetbsd and libmd bootstrapping), so it's hard to even look into this out of memory problem unless you have a stable-11 system to crossbuild on. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 6 17:02:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79D72CFB09D for ; Mon, 6 Mar 2017 17:02:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5779A1471; Mon, 6 Mar 2017 17:02:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v26H2gEf019360 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Mar 2017 09:02:43 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v26H2fm0019359; Mon, 6 Mar 2017 09:02:41 -0800 (PST) (envelope-from fbsd) Date: Mon, 6 Mar 2017 09:02:41 -0800 From: bob prohaska To: Ian Lepore Cc: Ralf Wenk , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting an old kernel on RPI2 Message-ID: <20170306170241.GC19195@www.zefox.net> References: <20170304165740.GA9625@www.zefox.net> <20170306163005.GB19195@www.zefox.net> <1488818491.18764.21.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1488818491.18764.21.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 17:02:37 -0000 On Mon, Mar 06, 2017 at 09:41:31AM -0700, Ian Lepore wrote: > almost impossible. ?The problem with crossbuilding isn't fixed yet, > (it's got something to do with libnetbsd and libmd bootstrapping), so > it's hard to even look into this out of memory problem unless you have > a stable-11 system to crossbuild on. > Maybe it's time to give up on the old system and reinstall. I do have a machine running root@ns2:/boot # uname -a FreeBSD ns2.zefox.net 11.0-STABLE FreeBSD 11.0-STABLE #4 r311959: Thu Jan 12 11:21:06 PST 2017 bob@ns2.zefox.net:/usr/obj/usr/src/sys/RPI2 arm Does the release-making machinery work well enough to concoct a bootable image? Last time I looked it didn't, but it's been six months at least. Thanks! bob prohaska From owner-freebsd-arm@freebsd.org Mon Mar 6 17:08:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0742ECFB1C5 for ; Mon, 6 Mar 2017 17:08:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id CEDE1161B for ; Mon, 6 Mar 2017 17:08:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 8851D214EF4 for ; Mon, 6 Mar 2017 11:08:02 -0600 (CST) Subject: Re: Booting an old kernel on RPI2 To: freebsd-arm@freebsd.org References: <20170304165740.GA9625@www.zefox.net> <20170306163005.GB19195@www.zefox.net> <1488818491.18764.21.camel@freebsd.org> From: Karl Denninger Message-ID: <33191ccf-75a3-82f8-ee23-bae3fb1c9425@denninger.net> Date: Mon, 6 Mar 2017 11:07:53 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1488818491.18764.21.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040200060707050606010905" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 17:08:04 -0000 This is a cryptographically signed message in MIME format. --------------ms040200060707050606010905 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/6/2017 10:41, Ian Lepore wrote: > On Mon, 2017-03-06 at 08:30 -0800, bob prohaska wrote: >> On Mon, Mar 06, 2017 at 10:23:54AM +0100, Ralf Wenk wrote: >>> >>> I am having the same problem here. >>> It happened during make installworld of r314701. I run make >>> installworld >>> while the former kernel r313407 was still active. >>> Now both kernels will boot up, but produce the same "out of memory" >>> message while going to single- or multi-user. >>> So it is not even possible to get a working shell in single-user >>> mode. >>> As it first happens during make installworld while still running >>> the >>> "old" r313407 kernel I think the cause is not the kernel itself. >>> >>> >> As I understand it, sometime before the FreeBSD loader starts up a >> division of memory is made between GPU and CPU. There is a config.txt >> file containing gpu_mem=3D64 on my FreeBSD systems, but some of the >> Linux literature mentions a file called uEnv.txt, which FreeBSD=20 >> seems not to use (nor does Raspbian, far as I can see).=20 >> >> I wonder if there might be a u-boot command to >> check if the setup routines have become corrupted, leaving too >> little memory for the kernel to function, even though it reports >> real memory =3D 989851648 (943 MB) >> avail memory =3D 957444096 (913 MB) >> during the failed boot attempts. >> >> >> Thanks for reading, and any ideas! >> >> bob prohaska >> > I'm pretty sure this out of memory error has nothing to do with the > kernel at all. It appears to be caused by clang 4.0 building the world= > incorrectly (most likely just jemalloc). > > It's a pity that both clang and jemalloc were updated to new versions > within a few days of each other. > > It's even more of a pity that a series of other errors make it almost > impossible to cross-build for arm from a stable-10 amd64 system after > r313403, so that bisecting to find the exact point of the error is also= > almost impossible. The problem with crossbuilding isn't fixed yet, > (it's got something to do with libnetbsd and libmd bootstrapping), so > it's hard to even look into this out of memory problem unless you have > a stable-11 system to crossbuild on. > > I have such system and in fact it's my production system on which I do all my crossbuilds! FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP What do you want me to play with? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040200060707050606010905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDYxNzA3NTNaME8GCSqGSIb3DQEJBDFCBEAWX5eL C4FezF2LMU9QN66ap6P/lCC27CxEjI3ItDUDxV2M/BCw0LJY57N7OAYLw93ti58Vy7oyWzVG XE+x52oEMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAZWexjSV9rPiB N8Mi9NSN9KUjCiosId8HKk3tBxdLSFovG5M7L4QpTbdWr67xiHG6/puRLchsAMEqaOehYotU zcG3yuISIQt+D9ifXM9hFflBOPQXYCPui07I7p/oo3rHWgIalr7P68rmXftAfxxADrdQCZkD pdLHcLdkVPDRC0+tW4bP9NOuZSGpinI6jfXy72716O69K+Du/IrvFPn/FQLfbTDf0mdLe4Uf Q+1tQDKtRPcG1R/UNBBnTFMdSm2kJQnm9OhEJ7yiUDv9XzV9sg7BAtFbzRGkt2flNyzTBcBl MbTsj2yGGCGiN6vtpX6dHBOJ7V5pjvy8wTHlRHowPoclt+JlFmHn//I+i6aJZTtJki7a9zUt OVQSXJEwDYvGMxXAThi0Y3w/fNRxOsJlPQ3l0UY+4FTGZIaSIxCsg2Q3rg97OIk6a+Xk6W/H UOIMyq25XksbYv6LGOb012frlXzyrr4TTTlMrvYTaNs7EXOOWYXdqOPP22wX0CfXGSURVQpU n7zUQ6R95qKWJX0Jw8zpkA0eSFVMavPUfF90vup43rxGJtBuA/f0IFDInMmiw4BKeMhyrDHs XgCaSBzD++uEdPRK8M4FMBRi94q7I4cV7y9Rfow6DVQhN+yTQv1c+mE0WrYOIYUqhHYP/tJ4 FYZXiRo1508XsDgwUa8z/48AAAAAAAA= --------------ms040200060707050606010905-- From owner-freebsd-arm@freebsd.org Mon Mar 6 17:15:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F171BCFB8C5 for ; Mon, 6 Mar 2017 17:15:53 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id C5BB21F4B for ; Mon, 6 Mar 2017 17:15:53 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 98E53214EE2 for ; Mon, 6 Mar 2017 11:06:48 -0600 (CST) Subject: Re: Booting an old kernel on RPI2 To: freebsd-arm@freebsd.org References: <20170304165740.GA9625@www.zefox.net> <20170306163005.GB19195@www.zefox.net> <1488818491.18764.21.camel@freebsd.org> <20170306170241.GC19195@www.zefox.net> From: Karl Denninger Message-ID: Date: Mon, 6 Mar 2017 11:06:39 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170306170241.GC19195@www.zefox.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020604040403060804020403" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 17:15:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020604040403060804020403 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/6/2017 11:02, bob prohaska wrote: > On Mon, Mar 06, 2017 at 09:41:31AM -0700, Ian Lepore wrote: >> almost impossible. ?The problem with crossbuilding isn't fixed yet, >> (it's got something to do with libnetbsd and libmd bootstrapping), so >> it's hard to even look into this out of memory problem unless you have= >> a stable-11 system to crossbuild on. >> > Maybe it's time to give up on the old system and reinstall. > > I do have a machine running > > root@ns2:/boot # uname -a > FreeBSD ns2.zefox.net 11.0-STABLE FreeBSD 11.0-STABLE #4 r311959: Thu J= an 12 11:21:06 PST 2017 bob@ns2.zefox.net:/usr/obj/usr/src/sys/RPI2 = arm > > Does the release-making machinery work well enough to concoct a bootabl= e > image? Last time I looked it didn't, but it's been six months at least.= > > Thanks! > > bob prohaska > > _______________________________________________ > I can build working 11-STABLE images for the RPI2 using Crochet, and they're fine -- dd them onto a card and boot it. I use it for production things with the "NanoBSD" option (and some home-brewed changes, a couple of which I've submitted back to the Crochet folks as there were what appear to be clear errors) but without that option it works fine as well. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020604040403060804020403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDYxNzA2MzlaME8GCSqGSIb3DQEJBDFCBEBDJKJY bL5dYIYrrrRrg2Fow6i1FTsIHrmy1Ujd/SyoQlaVckAlGLlNE7H+hyJBsP2/Fv7w4XJJfhF2 EriugR1IMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAwEy54bTiFA5P pDMbT8OB9FdtwI/UoW1TVrk1cqGx0Asr7Y8+BemopG4F30d/to5RzlhxOL3GZA4g+Zq5Dj47 vSew30z1OqsPo22sK6Fg/RGExCMsS9B5RarkZV67+VNJjtsQIARiguc7IWLfnipa/9sFgZtd kEc5VK+Q0Cbc2C0Tzfcw0+hNNaEZHUAbU8/Pl6LFX6Lx3nsQ6rO2Nq6JVF1Evyf1SJaMJXrG qqwTxUauOnWrYd1XSSdSOFMUgrwG7axM1aDwxoQ+hfh+fg+9qQtAkQ3IQ3G4NPCSNjHJZ0jd ySgf4uXHpc2aKJ7syuICOa6SpGbfdCs/zVq1UMkiXNzuAPu67l9xgjgZp0aG8ZQY6pvahtPx 5fM+9CBA/UcawxcRhicbudJT7JPn02fbekBpwRfUQmWTzBm7JpKrmEOBdVflutDAG7KAq8zb h/7mncYFYGWqGcb1B6iz0KmCNygXLHvI4N0u8vzEVpBg2wJe8Nj+cgabsdu9mk+TkgdgMHzj /dlIurJvnPnDA83wNBT+y0aPqn+4mrrc5K7+nJcvGAb7+Ld8nkvL2ctSpgYuV+L2GPYbX8J3 +u0PO6Dms/iRM8u93y8JCIv/Q+kNZbdAKowc7b21eECwDUmfahXsKo2TM/FGFTCS053Scb28 fCK6j5iHIHSICDp+l71ZU0kAAAAAAAA= --------------ms020604040403060804020403-- From owner-freebsd-arm@freebsd.org Tue Mar 7 00:02:17 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2F5ED00CEB for ; Tue, 7 Mar 2017 00:02:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B03D110D6 for ; Tue, 7 Mar 2017 00:02:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v2702JdM020290 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Mar 2017 16:02:20 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v2702IX9020289; Mon, 6 Mar 2017 16:02:18 -0800 (PST) (envelope-from fbsd) Date: Mon, 6 Mar 2017 16:02:18 -0800 From: bob prohaska To: Karl Denninger Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting an old kernel on RPI2 Message-ID: <20170307000218.GA20241@www.zefox.net> References: <20170304165740.GA9625@www.zefox.net> <20170306163005.GB19195@www.zefox.net> <1488818491.18764.21.camel@freebsd.org> <20170306170241.GC19195@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:02:18 -0000 On Mon, Mar 06, 2017 at 11:06:39AM -0600, Karl Denninger wrote: > I can build working 11-STABLE images for the RPI2 using Crochet, and Is there some intrinsic advantage to using Crochet for a self-hosted build (apart from the fact that make memstick in /usr/src/release seems to be broken)? My only tested Crochet installation is on an X86 box running 10.something that hasn't been plugged in for over a year. It'll take at least a little work to proceed in either case. If a small (or at least enumerable) list of binaries could be copied onto the damaged filesystem from a running RPI2 that would be easiest, I think... Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Mar 7 10:31:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04760D01FB1 for ; Tue, 7 Mar 2017 10:31:33 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEBAC15B3 for ; Tue, 7 Mar 2017 10:31:32 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 84-236-108-40.pool.digikabel.hu ([84.236.108.40] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clCOp-0006Mq-RP for freebsd-arm@freebsd.org; Tue, 07 Mar 2017 10:31:23 +0000 To: freebsd-arm@freebsd.org From: Gergely Czuczy Subject: How to use SPI Message-ID: <46d1021c-2ca7-d60b-3548-86f064aa8530@harmless.hu> Date: Tue, 7 Mar 2017 11:31:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 10:31:33 -0000 Hello, I've just got a Raspberry PI3, and I would like to use a couple of Adaruit MAX31856 breakout boards with it, which are using the SPI bus. I've noticed that it apparently has kernel level spi drivers: # kldstat -v | grep spi 259 simplebus/bcm2835_spi 109 spi/spibus 108 spi/ofw_spibus However, I wasn't able to find anything in the userland which would explain how to use it. Currently I'm using a raspbsd image: FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r313109M: Thu Feb 2 16:16:39 MST 2017 raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC arm64 Could you guys please give me a hand on starting using the SPI bus? I've tried googling around a bit, but unfortunately not much came up. Best regards, Gergely From owner-freebsd-arm@freebsd.org Tue Mar 7 10:55:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B60BD01738 for ; Tue, 7 Mar 2017 10:55:52 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B26EB1321 for ; Tue, 7 Mar 2017 10:55:51 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=38250 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clCmP-0001I7-VR; Tue, 07 Mar 2017 10:55:45 +0000 Received: from localhost ([127.0.0.1]:27507 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clCmP-000I1N-0V; Tue, 07 Mar 2017 10:55:45 +0000 From: Andrew Gierth To: Mark Millard Cc: Warner Losh , "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> (Mark Millard's message of "Sun, 5 Mar 2017 20:26:49 -0800") Message-ID: <87k281e5y7.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> <8760jnfvwp.fsf@news-spur.riddles.org.uk> <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Tue, 07 Mar 2017 10:55:44 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 10:55:52 -0000 >>>>> "Mark" == Mark Millard writes: Mark> I'm currently sticking with some known failures in the base Mark> system: openssl speed failures. (A signal based program crash Mark> without X11 involved could be interesting.) I've been continuing to look at git, as being the simplest test case I have on hand. I have determined that the sha1 failures occur only if the NEON-enabled SHA1 block function is interrupted by a signal. This explains why it fails in git (which is using SIGALRM to set a "display progress" flag) but not in standalone SHA1 tests; I believe openssl speed also uses SIGALRM to time tests. -- Andrew. From owner-freebsd-arm@freebsd.org Tue Mar 7 12:13:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80D66D00ADE for ; Tue, 7 Mar 2017 12:13:43 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32EA21EB4 for ; Tue, 7 Mar 2017 12:13:42 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=56395 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clDzg-0001O2-8J; Tue, 07 Mar 2017 12:13:32 +0000 Received: from localhost ([127.0.0.1]:14956 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clDzf-000I6I-Cl; Tue, 07 Mar 2017 12:13:31 +0000 From: Andrew Gierth To: Mark Millard Cc: Warner Losh , "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> (Mark Millard's message of "Sun, 5 Mar 2017 20:26:49 -0800") Message-ID: <87fuipe460.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk> <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> <87h93814rb.fsf@news-spur.riddles.org.uk> <70AE704A-C9FF-4742-88E9-147CD5B77BE8@dsl-only.net> <87tw77iwx6.fsf@news-spur.riddles.org.uk> <8760jnfvwp.fsf@news-spur.riddles.org.uk> <3056BE0A-6441-4878-905D-741C61BDC47C@dsl-only.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Tue, 07 Mar 2017 12:13:30 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:13:43 -0000 Bingo. Signal delivery isn't preserving the NEON registers (at all, as far as I can tell); if the signal handler changes any of them, those changes are visible in the interrupted code. If libthr is compiled with -mcpu=cortex-a7, then it uses NEON registers for data copying in thr_sighandler, so obviously things go south at that point. Equally bad things happen if the signal handler does any floating point or vector work itself whether linked with libthr or not. So it looks like this is a kernel bug after all, no? Looking at arm/arm/machdep.c reveals a noticable absence of any attempt to preserve the VFP state in sendsig(), contrary to what happens on other platforms. -- Andrew. From owner-freebsd-arm@freebsd.org Tue Mar 7 13:21:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 933F9D00783 for ; Tue, 7 Mar 2017 13:21:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 691001DB1 for ; Tue, 7 Mar 2017 13:21:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v27DLOTx055897 for ; Tue, 7 Mar 2017 13:21:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217611] ARM VFP/NEON regs not preserved in signal delivery Date: Tue, 07 Mar 2017 13:21:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: andrew@tao11.riddles.org.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:21:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217611 Bug ID: 217611 Summary: ARM VFP/NEON regs not preserved in signal delivery Product: Base System Version: 11.0-STABLE Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: andrew@tao11.riddles.org.uk Created attachment 180600 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180600&action= =3Dedit FP registers vs. signals Signal delivery to process is not saving/restoring the VFP/NEON registers. I found this on stable/11, but it also exists on CURRENT. I tested on an RP= I2 but the problem clearly exists on other ARM platforms. The bug is obvious by inspection, but I attach an example test program. (If= you try this on a much faster platform than cortex-a7 @900MHz, make sure you increase the loop count to ensure runtime exceeds 1 second.) cc fptst.c -o fptst ./fptst entering... h0: actual=3D10000000.000000 expected=3D10000000.000000 h1: actual=3D10000001.000000 expected=3D10000001.000000 h2: actual=3D10000002.000000 expected=3D10000002.000000 h3: actual=3D10000003.000000 expected=3D10000003.000000 h4: actual=3D10000004.000000 expected=3D10000004.000000 h5: actual=3D10000005.000000 expected=3D10000005.000000 h6: actual=3D10000006.000000 expected=3D10000006.000000 h7: actual=3D10000007.000000 expected=3D10000007.000000 ./fptst breakme entering... h0: actual=3D-18199474333245.414062 expected=3D10000000.000000 h1: actual=3D-18199474333245.414062 expected=3D10000001.000000 h2: actual=3D-18199476796269.414062 expected=3D10000002.000000 h3: actual=3D-18199476796271.312500 expected=3D10000003.000000 h4: actual=3D-18199479259296.312500 expected=3D10000004.000000 h5: actual=3D-18199479259295.312500 expected=3D10000005.000000 h6: actual=3D-18199481722320.312500 expected=3D10000006.000000 h7: actual=3D-18199481722319.312500 expected=3D10000007.000000 (actual results will vary) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Mar 7 17:42:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24DF5D01C74 for ; Tue, 7 Mar 2017 17:42:20 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D50371CFE; Tue, 7 Mar 2017 17:42:19 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id y76so16005971qkb.0; Tue, 07 Mar 2017 09:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CrIKk7cCUaTtWk3JMv4D5zIfQ3lY6VTfqcTrgykcyZY=; b=DGfyUDIjb5gFfKmdkqRHmiqHKd+is/wnBwsFqjDfuJVGz2klceuSZnXzLkIlYFfoc2 VxnIivPzP9lhLcrL0leqxpU4oca0fefMEWKmg7c7YgB4bWSIEDRDtfqroBKcioLMdQ4T gVr5za9QZJqjVub7KUnZngWWbisRLj/oHJq94I7yuNtnZek92sT+hdEQYrkXY3fQGUw+ TE9w9/cxXvvr0x/2Lh3icWczgbX2EwqqwOdbezR9rgazXLgTkMqboF+eRnIXnmIaiwHr /PtsZqnRUSCEegHnSSb5yT5gYex5vFOLJkfGGWPEfu485WgdlPTpIuJflrFvDXy2WcPS z5LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CrIKk7cCUaTtWk3JMv4D5zIfQ3lY6VTfqcTrgykcyZY=; b=nFx3TaV6uIeXnh3lLAuEc+QyYMf0WbNe1rP8nXd2YV33RGQkPlDB6L+6pWb1Xy0mJV oRcHGT0ujZ/j9BGx/eAoa2m1UCiKfKgQE4SWVywMR1lDyMH6YbhURsk+RkO8cbg+jp0C REXHJg8fXme4dkpv+r+gEzG2gAJF6o/TTYguvFi12vnq0VIqFrgVagAGxKO1xORGxe8v VLPgBdnNdd0P9YRQYR0oWFCDZCannZRxFmCSBfOJremrEuwCgsyhh9yxPPE2U/pDc8mR aJR8oAAnFxdb40h7Uo455RxHbn245zHeUY0i4vHE93or1Mkc8QJmi5NOAt0VluEV0Gnd l1RA== X-Gm-Message-State: AFeK/H0HyKb/3tR/hTmgkZpRrD5JsqlXp2CTWPyNRVhcMw+LazYJV0M/eS05ARhq6/oFLlhnvcm3NHHXP72ZVg== X-Received: by 10.55.169.135 with SMTP id s129mr1846941qke.91.1488908538370; Tue, 07 Mar 2017 09:42:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.104.116 with HTTP; Tue, 7 Mar 2017 09:41:47 -0800 (PST) In-Reply-To: <1488818491.18764.21.camel@freebsd.org> References: <20170304165740.GA9625@www.zefox.net> <20170306163005.GB19195@www.zefox.net> <1488818491.18764.21.camel@freebsd.org> From: Jia-Shiun Li Date: Wed, 8 Mar 2017 01:41:47 +0800 Message-ID: Subject: Re: Booting an old kernel on RPI2 To: Ian Lepore Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:42:20 -0000 On Tue, Mar 7, 2017 at 12:41 AM, Ian Lepore wrote: > > I'm pretty sure this out of memory error has nothing to do with the > kernel at all. It appears to be caused by clang 4.0 building the world > incorrectly (most likely just jemalloc). > > It's a pity that both clang and jemalloc were updated to new versions > within a few days of each other. > > It's even more of a pity that a series of other errors make it almost > impossible to cross-build for arm from a stable-10 amd64 system after > r313403, so that bisecting to find the exact point of the error is also > almost impossible. The problem with crossbuilding isn't fixed yet, > (it's got something to do with libnetbsd and libmd bootstrapping), so > it's hard to even look into this out of memory problem unless you have > a stable-11 system to crossbuild on. > > Out of courisity I installed a 10.3R VM and updated it to 10-stable r314848. Both 10.3R and 10-stable successfully built head r314842 for TARGET_ARCH=armv6. Looks crossbuild is fixed in r314794. -Jia-Shiun From owner-freebsd-arm@freebsd.org Tue Mar 7 19:09:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7475D010D3 for ; Tue, 7 Mar 2017 19:09:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A00E13BA for ; Tue, 7 Mar 2017 19:09:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x236.google.com with SMTP id y76so20377579qkb.0 for ; Tue, 07 Mar 2017 11:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JKBUup88wxySPandLJfr7wL7HAa3sEEhLsH+Oq1MsZ0=; b=bmGHnIqXbq1CpydtpdqU5AjnYUwjZvPhF/D01DI56vXTviTC+erreYq/+FgArBXI3R KdxPHioIn35KmekpcWl37F/uPVNdfUlWvNyO0pgDESzWYTzP8ZUQZ0olHrFijRAZejD6 2mWxoBzeV6R2hVcxbf7KDq1TZuSVPibqFhGRwIFNKYNOHnJU14PCd6rB2aZvqR4HpfnH gKBJxjbijnMu0NGIfnbB1V1MrjZaqFXzprlulnHd7nf2lSL0ebRh8HSGNjc3jRcCpHUC RgvMFRoGYE46wNrCwU9NaSbyvKzHxwN/3wBImpx2dGpq2pDCyFaRcMLIUY3emNUSWujf lN/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JKBUup88wxySPandLJfr7wL7HAa3sEEhLsH+Oq1MsZ0=; b=WShSrnXCH9im0NFTIlv0CW30w3y65Ov0tYohlbERZF9dfIAJPQY4ecritc4v5Vsx0a ar9P06IuSGzSaL5PH2OyvzDNbWp/JSMj3Qelcjek4+tuzlO1811Zcutb2GFw4Bpmvhqw bKRH5KAwFy0aijZK9L1ueErh1qzUilepBZoRLVvxNrJdcM+m+VCmQdYXQPwI+Yjld+0C +QSgMtgh5pi1rB5UEnvlkG7na5cg3d8MUhQw0N6ebzS20FGbzqyqTgpl0nmPbWHYoA57 GyA0qggrikWxuAfpxT9cs+yGBXRLttOMJ30weO7r+OCHPUZsY+0Iq5NxuJrLzeUFdmdg Xeew== X-Gm-Message-State: AMke39kKmvxWSN/97ClTeznVADtmzwLktDa05hObXTQpjoXHqWu7zkL7g8wtdwUJSjtEKqgt X-Received: by 10.55.74.198 with SMTP id x189mr2341496qka.17.1488913778514; Tue, 07 Mar 2017 11:09:38 -0800 (PST) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id u8sm579657qkg.25.2017.03.07.11.09.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 Mar 2017 11:09:37 -0800 (PST) Date: Tue, 7 Mar 2017 14:09:37 -0500 From: Shawn Webb To: Ian Lepore Cc: "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j725pj7pzexlcw22" Content-Disposition: inline In-Reply-To: <1488664965.69705.24.camel@freebsd.org> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:09:39 -0000 --j725pj7pzexlcw22 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > The bugs should be fixed as of r314682. ?It looks like the bugs have > long been in the pl011 driver, but were masked by having a fifo depth > of 1 byte -- it all sorta worked by accident previously. Thanks for the fix! But it looks to be only partial. When I connect to the serial console via either cu or screen, I don't get corrupted text, but no keypresses are registered. Hitting enter at the login prompt does absolutely nothing. I'm at the latest commit of hardened/current/master on HardenedBSD for both the RPI3 and my laptop. I'm using this serial cable from Adafruit: https://www.adafruit.com/product/954 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --j725pj7pzexlcw22 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAli/BW0ACgkQaoRlj1JF bu6tUw//Zfl0a9DnPOyOcpNdkLq0UTvCpQcMEm9jUxjPFoAyNFfkCbJA1eGKVDEC Ic+x/dDwXeMpHgmHookh9ieVHVoyynDENMRWkfbFAa+bscChdarwRy4Rv+dJhO7+ 6IYpacHaH6durk2GEVVnLGhVROXxHIBljrQHtpi7B62oTXOpLjLn5sJONXj/sr92 Lk65vlSN52/0foPglBYqlaUQpKm5jaDE168rUf/obtGkTfC5/z8TtubwZOvu22Yz tu6MwAL4VWsneg6DGuFTPoAUicNrFnEyGXfC1IG/mAGZk7+SLAjK2jTjW4Rpp+jR KFtiMT38eFk8zum3reQEPC0LD+439vGqLUUTJ2dbzwggjyBap7hcbTEOIa+c+kfL FiJJb2h24gZC46AE88MidKPlgnCjtQv05pq0hKdnnphvKGbCbtBFowW5h8iRZvaW HiUamt/d9AsH7DdcryoxGD0FLb5+Sn/HxgmBgzjKvw1dkhDV/QpU7S5o43Hvj60e u+4fkC7e/nSXjNNrix1NkXbmawwWGfVuaM8CHY8eVIR1t1p791lAuQn2a+vUaB0G g1HzUSA2Plj4VOWew3XoWp/IHvH0J1loteMlUKfiDbsdB0k8oysLU73FetCQmMPx h0OlgR6XfZglJ1EhiPx38AtAS/2Q9nkLTnHrJ4BuLeQHsyqiZZo= =wenF -----END PGP SIGNATURE----- --j725pj7pzexlcw22-- From owner-freebsd-arm@freebsd.org Tue Mar 7 19:29:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 948C8D0187D for ; Tue, 7 Mar 2017 19:29:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40CD61FA6 for ; Tue, 7 Mar 2017 19:29:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x230.google.com with SMTP id v125so20756748qkh.2 for ; Tue, 07 Mar 2017 11:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+XYtt7uLJXTyD7r5YvHKoKO69jF68++m0827Dtr3wRk=; b=pvxc3z0VGjhwIfltj47xu174declfgrDTg4UNMmfFjfsjtgPdgk7kRSab9g7YpLiaR nSZEK0ohrBO5/MDYaSJomvXqUznFlAESV4UvH8OC/5kw8zTyRkLLhDYhMoZjPe4DwKXk lS0MixcBR8nGdAuRIb6UVdp/Qpq92MYt5EU0z6cxTA2VaGvJquZ3Oi5pFZPYT32LviTr ZzMMpF4jDiyRgDJIHHgsq3Yx5+N63oCgYwkzwQRyF2VzaZtG5dGmd17slxpw3XNMfILr IK/xjyubHpq4QNv7a+MycYEZRi/0ydBjSLZ7VxseteaDhkWcfVcwQkZ54rGG8g6FP0qo yMcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+XYtt7uLJXTyD7r5YvHKoKO69jF68++m0827Dtr3wRk=; b=NXJmyaVCn8FbrI7VRplgLwgDHdd/N+VEfhrXRMIF7XTY4NQuEaP+o8ZX8PTC1P6cR5 dt8H7VDSAUM/dbgDqhRFce9Jdrr1smo/WSRgHnfNgGihmMuiIwZ7XP14C/7lqVdt55Yk K7zdV9Em5GZ1Xn+G4qBvD1T3gCpsEcubJoyWNJDvJrpqUb2KNjO+jHEcuJ18PvkQjnDH QCtIaDUMqH0D9xPKKkpA1elbxO5Dr7n3Bs2CiGYRFLAYfMbL/YSaKE1TJ4iEMC9AM0H5 jcDY3qKBRYlyyV2xARzeoPo97ieOKJqUoZdOvuGplTrXxoPrKQ34MIW78F9+ZyaC1pC8 63Ww== X-Gm-Message-State: AMke39mYlj29J4aMT2qjMPWgTR56HzXDb7B3I871de7euP0LexZpihmokreMLDK5iwP/eIH/ X-Received: by 10.237.55.229 with SMTP id j92mr2488734qtb.43.1488914959352; Tue, 07 Mar 2017 11:29:19 -0800 (PST) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id k51sm613338qtf.31.2017.03.07.11.29.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 Mar 2017 11:29:18 -0800 (PST) Date: Tue, 7 Mar 2017 14:29:18 -0500 From: Shawn Webb To: Ian Lepore Cc: "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170307192918.2garie2ow6lzekg7@mutt-hbsd> References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bel5xd3c6t6dkttg" Content-Disposition: inline In-Reply-To: <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:29:20 -0000 --bel5xd3c6t6dkttg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > The bugs should be fixed as of r314682. ?It looks like the bugs have > > long been in the pl011 driver, but were masked by having a fifo depth > > of 1 byte -- it all sorta worked by accident previously. >=20 > Thanks for the fix! But it looks to be only partial. When I connect to > the serial console via either cu or screen, I don't get corrupted text, > but no keypresses are registered. Hitting enter at the login prompt does > absolutely nothing. I'm at the latest commit of hardened/current/master > on HardenedBSD for both the RPI3 and my laptop. >=20 > I'm using this serial cable from Adafruit: > https://www.adafruit.com/product/954 It looks like I had a bad cable. Sorry for the line noise. Switching to a different cable worked. --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --bel5xd3c6t6dkttg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAli/CgsACgkQaoRlj1JF bu6unhAAlLlggGnm3PrmsMqtCrptbSUbM4wO9lqv/5M7Zqfz6wUTckkt49BSMsL7 4ENrgLwGort1BeD/qZAaq4pqTo+guWgCEpoNRha9qUur04uRKgsq9K6pwsswa6Lb jDqfwQhfD3oenwEzJrlfZOF8Oh7SmvrU/6XY0aHuw3wrTPtTGRL/tOC7xLpvtWD3 W5pPAiLZNi6zcSS+hj/Og1OkLvE9Tso5qmV8j3vtZO5Om9ovvH5J3T78n0TyrToS NCQn2/vRrkqIsOww8y11plfts7ySeNpRWpI4+mzpaKCAEPs3J3iLZUgUHdheKuDt o6JjgT4Hw3vFE2yVM9gj9rdZt8vG3UBO4bQ5iGZ2lAzZdm26m3eKvlUT8P9Ff1Ie ERaRWVeto3j6hzNZmdUS6Cwrc2HypNm0/7bgCz32okpYQWomwI7j9MPozbRUQ6yX TOs+zun3B8BcJlyMbVKgnRy7iAsZEqo0A3c5mPtyuoPFXeEdEfKy9AipxzqwGp6u ThvWbpBannYf1OvIHxb/nZSGpAv6+C0JB2Xn8nSw95Mumh2GvUj+h9woEGiUG1IP hxyrpL7rtv3FDpFfalI/J39DUSnm8oZqcnsFd8DzY+ISZ4Ya6PnnVn6MspckOqMQ aNe1B1jAan96AC6jem5FjNtUd8X0G4OOuJmzCoba8iU0clFNu3Y= =+DAi -----END PGP SIGNATURE----- --bel5xd3c6t6dkttg-- From owner-freebsd-arm@freebsd.org Tue Mar 7 21:48:23 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02F79D01B52 for ; Tue, 7 Mar 2017 21:48:23 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF28C1B7A; Tue, 7 Mar 2017 21:48:22 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id j127so5030426qke.0; Tue, 07 Mar 2017 13:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=clH0Ov8BCNzvKuR6H5gCCY8dVBTCki1WGPMeMhCXV94=; b=nJDllAENpRZHvwwn7DUaeKIuRIyjvHDkZezerbSd1tcVD2sJVVJFvVOzOMWR+4vtk9 z1ld8FBDtkjKgL4dnwlm1qL7WJ3PtOk4CuKvJMNIP0dRucM9wJXJ2zVXludFAXnGO5Qs UTci9TOW7Zc+gAz/Un/llTtynXrzFTkaAkIahNfiFvoCidoH6cJPExNLzXp7dCAEpNxy QvtzIv+YOmux8VS5bpa3CFLLbUhiHzSC1Wv2Gdq1qXB2kNg8iIrvN2hL3OUTrWlolO+e hFYPStEqhbT0AXIau7Qhyjod8kJNhs6Xkxt9JHmTPAkSCoJIiw3k6WP9oXT1T0/95maU TZ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=clH0Ov8BCNzvKuR6H5gCCY8dVBTCki1WGPMeMhCXV94=; b=KNBFlCiQPv4xvGbV4mpz/dsl+/fdT+37JsYNyLITX3z17H2hmVDhonva91YtIqM/hv 9jUVz2ENn+lUP1SfiUXQEDQcL6e52VTOuDXem6vy1Jv7ftx/f1sqCQlumsm7hihLVwJj OGScs6gbHiwR18Nsf+UlhACavnZ4MZZOyMKIGCbxz7nB4tiZ+7z0K6g+vgZYStiQTy7f loe9u9gLM2FA1mXmuKhoX/dX30ePV4Nif0FFCZYGr4yJrplKM45IiWml6w8Ara1Vnepe /X8kjJMHuBYR9ZSRq2NeukmUgb4dItQvsAtSL2csTuhRiF3qiyA2ttrIZpHRIag65KTh jBYg== X-Gm-Message-State: AMke39knyNg0rG+TTPfjrFvjAU30CW4RhbdTnIQfM3oMJWLq9qziBYRDMOJiKzihjhb9yTglCmxRz8ZprgrrCA== X-Received: by 10.13.231.130 with SMTP id q124mr665970ywe.84.1488923301804; Tue, 07 Mar 2017 13:48:21 -0800 (PST) MIME-Version: 1.0 Sender: c.jayachandran@gmail.com Received: by 10.83.42.214 with HTTP; Tue, 7 Mar 2017 13:48:21 -0800 (PST) In-Reply-To: <1488817492.18764.14.camel@freebsd.org> References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> From: "Jayachandran C." Date: Wed, 8 Mar 2017 03:18:21 +0530 X-Google-Sender-Auth: mqjFHeW8w7aEdnJhnemWLrtBXoU Message-ID: Subject: Re: Odd-looking serial console prompt on RPI2 To: Ian Lepore Cc: Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:48:23 -0000 On Mon, Mar 6, 2017 at 9:54 PM, Ian Lepore wrote: > On Mon, 2017-03-06 at 13:59 +0530, Jayachandran C. wrote: >> Hi Ian, >> >> On Sun, Mar 5, 2017 at 3:32 AM, Ian Lepore wrote: >> > >> > On Sat, 2017-03-04 at 22:24 +0530, Jayachandran C. wrote: >> > > >> > > On Thu, Mar 2, 2017 at 7:35 AM, Ian Lepore >> > > wrote: >> > > > >> > > > >> > > > On Wed, 2017-03-01 at 18:01 -0800, Oleksandr Tymoshenko wrote: >> > > > > >> > > > > >> > > > > Ian Lepore (ian@freebsd.org) wrote: >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, 2017-03-01 at 16:03 -0800, bob prohaska wrote: >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > On Wed, Mar 01, 2017 at 09:20:13PM +0100, Michael Tuexen >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Interesting... Let us know what works and what >> > > > > > > > doesn't... >> > > > > > > > >> > > > > > > > Best regards >> > > > > > > > Michael >> > > > > > > > >> > > > > > > As of FreeBSD 12.0-CURRENT (RPI2) #0 r314450: Wed Mar 1 >> > > > > > > 14:48:26 >> > > > > > > PST >> > > > > > > 2017 >> > > > > > > the serial console is still corrupt (output truncated, >> > > > > > > input >> > > > > > > not >> > > > > > > echoed >> > > > > > > but treated like the enter key). The serial console does >> > > > > > > seem to >> > > > > > > work >> > > > > > > with U-boot and loader, so I don't think it's the >> > > > > > > upstream >> > > > > > > hardware. >> > > > > > > >> > > > > > > The HDMI console looks normal and USB keyboard input >> > > > > > > seems to >> > > > > > > work. >> > > > > > > >> > > > > > > There have been several updates to /usr/src/sys/dev/uart >> > > > > > > and >> > > > > > > it >> > > > > > > looks >> > > > > > > as if kernel updates are still coming. Maybe the job >> > > > > > > simply >> > > > > > > isn't >> > > > > > > done yet. >> > > > > > > >> > > > > > > bob >> > > > > > > >> > > > > > It seems like this might be caused by r314318. Can someone >> > > > > > having >> > > > > > this problem confirm if 314317 works and 314318 fails? >> > > > > Tested on my RPi2, 314317 - works, 314318 - broken >> > > > > >> > > > CC'ing jchandra@. >> > > > >> > > > I wonder if there is some bad interaction when the same uart is >> > > > used as >> > > > a console and a tty? >> > > I don't have a RPi3 setup to test now, I will look at the code >> > > again >> > > to see if >> > > I can find an issue. >> > > >> > > Otherwise I will revert the change until we can find why the RPi >> > > UART >> > > breaks >> > > with these changes. >> > > >> > > Thanks, >> > > JC. >> > The bugs should be fixed as of r314682. It looks like the bugs >> > have >> > long been in the pl011 driver, but were masked by having a fifo >> > depth >> > of 1 byte -- it all sorta worked by accident previously. >> Looked thru r314681 and r314682, thanks for fixing this up. >> >> There seems to be a difference in behavior in IFLS settings on >> different >> platforms. I did not see a reasonable way to handle the tx fifo being >> full >> when sc_txbuf is partially used, which is why I skipped this case in >> the >> original commit - that was a mistake. >> >> Thanks, >> JC. > > Hmm. Does that imply the changes I made to set the fifo trigger level > to 3/4 may not work on some other platforms? I was only able to test > on rpi-b. I tested on QEMU's emulated pl011 and it works there too. I was thinking that IFLS behaved differently on ThunderX and that is why my original code worked there. But after going thru the spec again, it looks like the FIFO in newer pl011 implementations is 32 entry deep, and that may be real reason why ThunderX did not have any issues. JC. From owner-freebsd-arm@freebsd.org Tue Mar 7 22:25:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FEC0D0280F for ; Tue, 7 Mar 2017 22:25:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 991FA12AA for ; Tue, 7 Mar 2017 22:25:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: fb0c2694-0384-11e7-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id fb0c2694-0384-11e7-95b5-6dfd7dbb0ee5; Tue, 07 Mar 2017 22:25:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v27MPOh0004384; Tue, 7 Mar 2017 15:25:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488925524.18764.55.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: "Jayachandran C." Cc: Michael Tuexen , freebsd-arm@freebsd.org, Oleksandr Tymoshenko Date: Tue, 07 Mar 2017 15:25:24 -0700 In-Reply-To: References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:25:39 -0000 On Wed, 2017-03-08 at 03:18 +0530, Jayachandran C. wrote: > On Mon, Mar 6, 2017 at 9:54 PM, Ian Lepore wrote: > > > > On Mon, 2017-03-06 at 13:59 +0530, Jayachandran C. wrote: > > > > > > Hi Ian, > > > > > > On Sun, Mar 5, 2017 at 3:32 AM, Ian Lepore > > > wrote: > > > > > > > > > > > > On Sat, 2017-03-04 at 22:24 +0530, Jayachandran C. wrote: > > > > > > > > > > > > > > > On Thu, Mar 2, 2017 at 7:35 AM, Ian Lepore > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2017-03-01 at 18:01 -0800, Oleksandr Tymoshenko > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ian Lepore (ian@freebsd.org) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2017-03-01 at 16:03 -0800, bob prohaska wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 01, 2017 at 09:20:13PM +0100, Michael > > > > > > > > > Tuexen > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Interesting... Let us know what works and what > > > > > > > > > > doesn't... > > > > > > > > > > > > > > > > > > > > Best regards > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > As of FreeBSD 12.0-CURRENT (RPI2) #0 r314450: Wed > > > > > > > > > Mar  1 > > > > > > > > > 14:48:26 > > > > > > > > > PST > > > > > > > > > 2017 > > > > > > > > > the serial console is still corrupt (output > > > > > > > > > truncated, > > > > > > > > > input > > > > > > > > > not > > > > > > > > > echoed > > > > > > > > > but treated like the enter key).  The serial console > > > > > > > > > does > > > > > > > > > seem to > > > > > > > > > work > > > > > > > > > with U-boot and loader, so I don't think it's the > > > > > > > > > upstream > > > > > > > > > hardware. > > > > > > > > > > > > > > > > > > The HDMI console looks normal and USB keyboard input > > > > > > > > > seems to > > > > > > > > > work. > > > > > > > > > > > > > > > > > > There have been several updates to > > > > > > > > > /usr/src/sys/dev/uart > > > > > > > > > and > > > > > > > > > it > > > > > > > > > looks > > > > > > > > > as if kernel updates are still coming. Maybe the job > > > > > > > > > simply > > > > > > > > > isn't > > > > > > > > > done yet. > > > > > > > > > > > > > > > > > > bob > > > > > > > > > > > > > > > > > It seems like this might be caused by r314318.  Can > > > > > > > > someone > > > > > > > > having > > > > > > > > this problem confirm if 314317 works and 314318 fails? > > > > > > > Tested on my RPi2, 314317 - works, 314318 - broken > > > > > > > > > > > > > CC'ing jchandra@. > > > > > > > > > > > > I wonder if there is some bad interaction when the same > > > > > > uart is > > > > > > used as > > > > > > a console and a tty? > > > > > I don't have a RPi3 setup to test now, I will look at the > > > > > code > > > > > again > > > > > to see if > > > > > I can find an issue. > > > > > > > > > > Otherwise I will revert the change until we can find why the > > > > > RPi > > > > > UART > > > > > breaks > > > > > with these changes. > > > > > > > > > > Thanks, > > > > > JC. > > > > The bugs should be fixed as of r314682.  It looks like the bugs > > > > have > > > > long been in the pl011 driver, but were masked by having a fifo > > > > depth > > > > of 1 byte -- it all sorta worked by accident previously. > > > Looked thru r314681 and r314682, thanks for fixing this up. > > > > > > There seems to be a difference in behavior in IFLS settings on > > > different > > > platforms. I did not see a reasonable way to handle the tx fifo > > > being > > > full > > > when sc_txbuf is partially used, which is why I skipped this case > > > in > > > the > > > original commit - that was a mistake. > > > > > > Thanks, > > > JC. > > Hmm.  Does that imply the changes I made to set the fifo trigger > > level > > to 3/4 may not work on some other platforms?  I was only able to > > test > > on rpi-b. > I tested on QEMU's emulated pl011 and it works there too. > > I was thinking that IFLS behaved differently on ThunderX and that is > why my original code worked there. But after going thru the spec > again, > it looks like the FIFO in newer pl011 implementations is 32 entry > deep, > and that may be real reason why ThunderX did not have any issues. > > JC. > _______________________________________________ Yep, apparently rev r1p5, which can be detected at runtime, increased the size of the fifos.  But, just to add a bit of drama, the bcm2835 (rpi) scewed up and identified its pl011 as r1p5 even though it only has 16 byte fifos.  It looks like there is some info in the rpi dts file that we can use to tell the difference.  I can probably whip up something to fix all this later tonight. -- Ian From owner-freebsd-arm@freebsd.org Wed Mar 8 01:36:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0842FD01296 for ; Wed, 8 Mar 2017 01:36:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9580311AE for ; Wed, 8 Mar 2017 01:36:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 99bad4d2-039f-11e7-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 99bad4d2-039f-11e7-95b5-6dfd7dbb0ee5; Wed, 08 Mar 2017 01:36:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v281ZqZT004650; Tue, 7 Mar 2017 18:35:52 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488936952.18764.63.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: "Jayachandran C." Cc: Michael Tuexen , freebsd-arm@freebsd.org, Oleksandr Tymoshenko Date: Tue, 07 Mar 2017 18:35:52 -0700 In-Reply-To: References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> Content-Type: multipart/mixed; boundary="=-ftk80ddYYMvK4QgupW9h" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:36:07 -0000 --=-ftk80ddYYMvK4QgupW9h Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Wed, 2017-03-08 at 03:18 +0530, Jayachandran C. wrote: > On Mon, Mar 6, 2017 at 9:54 PM, Ian Lepore wrote: > > [...] > > I was thinking that IFLS behaved differently on ThunderX and that is > why my original code worked there. But after going thru the spec > again, > it looks like the FIFO in newer pl011 implementations is 32 entry > deep, > and that may be real reason why ThunderX did not have any issues. > > JC. Could you (and anybody else who has a board that uses pl011 uarts) please test the attached patch?  I tested already on an rpi-b and it works fine there, but I'd like to hear whether it works on something that actually has 32-byte fifos.  It should probably be tested on an rpi2 as well (which I don't have). -- Ian --=-ftk80ddYYMvK4QgupW9h Content-Disposition: inline; filename="uart_pl011_fifosizes.diff" Content-Type: text/x-patch; name="uart_pl011_fifosizes.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/uart/uart_dev_pl011.c =================================================================== --- sys/dev/uart/uart_dev_pl011.c (revision 314682) +++ sys/dev/uart/uart_dev_pl011.c (working copy) @@ -111,16 +111,24 @@ __FBSDID("$FreeBSD$"); #define UART_MIS 0x10 /* Masked interrupt status register */ #define UART_ICR 0x11 /* Interrupt clear register */ +#define UART_PIDREG_0 0x3f8 /* Peripheral ID register 0 */ +#define UART_PIDREG_1 0x3f9 /* Peripheral ID register 1 */ +#define UART_PIDREG_2 0x3fa /* Peripheral ID register 2 */ +#define UART_PIDREG_3 0x3fb /* Peripheral ID register 3 */ + /* - * The hardware FIFOs are 16 bytes each. We configure them to interrupt when - * 3/4 full/empty. For RX we set the size to the full hardware capacity so that - * the uart core allocates enough buffer space to hold a complete fifo full of - * incoming data. For TX, we need to limit the size to the capacity we know - * will be available when the interrupt occurs; uart_core will feed exactly that - * many bytes to uart_pl011_bus_transmit() which must consume them all. + * The hardware FIFOs are 16 bytes each on rev 2 and earlier hardware, 32 bytes + * on rev 3 and later. We configure them to interrupt when 3/4 full/empty. For + * RX we set the size to the full hardware capacity so that the uart core + * allocates enough buffer space to hold a complete fifo full of incoming data. + * For TX, we need to limit the size to the capacity we know will be available + * when the interrupt occurs; uart_core will feed exactly that many bytes to + * uart_pl011_bus_transmit() which must consume them all. */ -#define FIFO_RX_SIZE 16 -#define FIFO_TX_SIZE 12 +#define FIFO_RX_SIZE_R2 16 +#define FIFO_TX_SIZE_R2 12 +#define FIFO_RX_SIZE_R3 32 +#define FIFO_TX_SIZE_R3 24 #define FIFO_IFLS_BITS ((IFLS_LVL_6_8th << IFLS_RX_SHIFT) | (IFLS_LVL_2_8th)) /* @@ -440,11 +448,32 @@ uart_pl011_bus_param(struct uart_softc *sc, int ba static int uart_pl011_bus_probe(struct uart_softc *sc) { + uint8_t hwrev; + bool is_bcm2835; device_set_desc(sc->sc_dev, "PrimeCell UART (PL011)"); - sc->sc_rxfifosz = FIFO_RX_SIZE; - sc->sc_txfifosz = FIFO_TX_SIZE; + /* + * The FIFO sizes vary depending on hardware; rev 2 and below have 16 + * byte FIFOs, rev 3 and up are 32 byte. We get a bit of drama, as + * always, with the bcm2835 (rpi), which claims to be rev 3, but has 16 + * byte FIFOs. We check for both the old freebsd-historic and the + * proper bindings-defined compatible strings for bcm2835. + */ +#ifdef FDT + is_bcm2835 = ofw_bus_is_compatible(sc->sc_dev, "brcm,bcm2835-pl011") || + ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835-uart"); +#else + is_bcm2835 = false; +#endif + hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; + if (hwrev <= 2 || is_bcm2835) { + sc->sc_rxfifosz = FIFO_RX_SIZE_R2; + sc->sc_txfifosz = FIFO_TX_SIZE_R2; + } else { + sc->sc_rxfifosz = FIFO_RX_SIZE_R3; + sc->sc_txfifosz = FIFO_TX_SIZE_R3; + } return (0); } --=-ftk80ddYYMvK4QgupW9h-- From owner-freebsd-arm@freebsd.org Wed Mar 8 09:24:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9194ED025D9 for ; Wed, 8 Mar 2017 09:24:14 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBC11E4E; Wed, 8 Mar 2017 09:24:13 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from adsl-172-10-1-110.dsl.sndg02.sbcglobal.net (p76eca588.tokynt01.ap.so-net.ne.jp [118.236.165.136]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 4974D4E6DC; Wed, 8 Mar 2017 09:23:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Odd-looking serial console prompt on RPI2 From: Andrew Turner In-Reply-To: <1488936952.18764.63.camel@freebsd.org> Date: Wed, 8 Mar 2017 18:23:28 +0900 Cc: "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Content-Transfer-Encoding: 7bit Message-Id: References: <20170227195647.GA91329@www.zefox.net> <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> <1488936952.18764.63.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 09:24:14 -0000 > On 8 Mar 2017, at 10:35, Ian Lepore wrote: > > On Wed, 2017-03-08 at 03:18 +0530, Jayachandran C. wrote: >> On Mon, Mar 6, 2017 at 9:54 PM, Ian Lepore wrote: >>> [...] >> >> I was thinking that IFLS behaved differently on ThunderX and that is >> why my original code worked there. But after going thru the spec >> again, >> it looks like the FIFO in newer pl011 implementations is 32 entry >> deep, >> and that may be real reason why ThunderX did not have any issues. >> >> JC. > > Could you (and anybody else who has a board that uses pl011 uarts) > please test the attached patch? I tested already on an rpi-b and it > works fine there, but I'd like to hear whether it works on something > that actually has 32-byte fifos. It should probably be tested on an > rpi2 as well (which I don't have). It works for me on ThunderX. Andrew From owner-freebsd-arm@freebsd.org Wed Mar 8 10:01:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 467F3D020C9 for ; Wed, 8 Mar 2017 10:01:26 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh505-vm7.bullet.mail.kks.yahoo.co.jp (nh505-vm7.bullet.mail.kks.yahoo.co.jp [183.79.57.109]) by mx1.freebsd.org (Postfix) with SMTP id CBEC11342 for ; Wed, 8 Mar 2017 10:01:25 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.138] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 08 Mar 2017 09:58:18 -0000 Received: from [183.79.100.137] by t501.bullet.mail.kks.yahoo.co.jp with NNFMP; 08 Mar 2017 09:58:18 -0000 Received: from [127.0.0.1] by omp506.mail.kks.yahoo.co.jp with NNFMP; 08 Mar 2017 09:58:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 385024.44949.bm@omp506.mail.kks.yahoo.co.jp Received: (qmail 52800 invoked by uid 60001); 8 Mar 2017 09:58:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1488967098; bh=9tTznhpNaWclwfA0fOTct70hRGhiLPiD7CQd7vZaVK4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PjiHKVZDwRUnFom8H/WTvWilSOjgYEGx39oKso6QexVT34JE6U6em7ak5GpdfckV+GjhUsuCdwSevc5UTCeSC78FTVZH9dXXlQyIMwviNHdamZw1/Sc5isSBp6rPPHwfBSyOWLDy3y24C4EVvg31XW/8tjUNCfWy0RkkYq0y3rE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pfi79XzzA5W2pKjjCZqnKcH30cRXSOBGelWdnl6pBGH4wym6f58DKHLkOLUfwGnkm2u1NMT58NPv3eJ9pypH3v7S0JRh7CnMGONNNyhaRsgTmYDocv20kp+ZSm1dJ38/5+0prAAkGU9xpANDR0qqbdlg7Ts6dDy+WPFAL+Ne2gc=; Message-ID: <70974.52425.qm@web101714.mail.ssk.yahoo.co.jp> X-YMail-OSG: lf7QnOUVM1lZzL7cXL8yd8Ypzg.xhCV2_xHok4x2Sw_CrZ_E9REKFEbxB.oH7oGh9uqpevpL0iprNs7pqCCzCjc07pbCofmH.WKjv.6hvlsrTT9KRJssM8Ph9azdXFczidDVw8ytmxYphXAYIueOX8g.76Kq3T0Kz2zIVQOXTaQAAFQok4CV_uJxk7BPZqRRqNxchJw9nG3pP68tMzK2qDDAu.5axosnzBtREP6Rr7lDdhhNUP.oNz9OUg7X4yjLSoipWTs7pr7VwBcO06U4uNeXYhTLdhmp2h8TiM8zjGbyb4O6OyZVcLsm0RatASpPESKOW6U.WYW_c3RamXiDNPcypsOPZjh48NkDXN7R2hc3EIB6vctRmGrL3CVH2lOtMAndxaq_dRzBYZtm9P9GBk4.HIbuFi06DTu.tfvw0BzP.AwCrv4mhqd5BNWJ33PRVga23MYJGLHdBjwFEvDHmwAgPYhF90hmkWIhzwGffwNhaKkWy.gkkHT6.MX3aUkYZgY1Vpr6xtf8gonCAc0O2txyiYbDUJjkazBSpeDSiY8BlNp6N9tsGwAWVX4luy34HHTdt2eftTrtnAolZEssTKmTvdfcVI6QgUAlk12eWL5vzw-- Received: from [110.134.192.2] by web101714.mail.ssk.yahoo.co.jp via HTTP; Wed, 08 Mar 2017 18:58:17 JST X-Mailer: YahooMailWebService/0.8.111_70 X-YMail-JAS: EyZMPX8VM1nFlssvivPt0mPjkhviszkhYCYTyEMjQD4THJpl__LDZPIi4i67ZWHYEzkOJoNtJb6zWBqCtrb5l1mCgtr.anVK7hCHlGIqfzcPPvKPYcHJLlC6oQlw63pFEXro References: <46d1021c-2ca7-d60b-3548-86f064aa8530@harmless.hu> Date: Wed, 8 Mar 2017 18:58:17 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: How to use SPI To: Gergely Czuczy , "freebsd-arm@freebsd.org" In-Reply-To: <46d1021c-2ca7-d60b-3548-86f064aa8530@harmless.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 10:01:26 -0000 Hi.=0A=0AFreeBSD SPI support don't have userland interface.=0A=0AYou must u= se device driver for SPI device. But=A0MAX31856=0Adriver isn't exist.=0A=0A= Hiroki Mori=0A=0A=0A----- Original Message -----=0A> From: Gergely Czuczy <= gergely.czuczy@harmless.hu>=0A> To: freebsd-arm@freebsd.org=0A> Cc: =0A> Da= te: 2017/3/7, Tue 19:31=0A> Subject: How to use SPI=0A> =0A> Hello,=0A> =0A= > I've just got a Raspberry PI3, and I would like to use a couple of Adarui= t =0A> MAX31856 breakout boards with it, which are using the SPI bus. I've = noticed =0A> that it apparently has kernel level spi drivers:=0A> =0A> # kl= dstat -v | grep spi=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 259 simplebus/bcm28= 35_spi=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 109 spi/spibus=0A> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 108 spi/ofw_spibus=0A> =0A> However, I wasn't able to f= ind anything in the userland which would explain =0A> how to use it.=0A> = =0A> Currently I'm using a raspbsd image:=0A> =0A> FreeBSD rpi3 12.0-CURREN= T FreeBSD 12.0-CURRENT #0 r313109M: Thu Feb=A0 2 16:16:39 =0A> MST 2017 =0A= > raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarc= h64/usr/src/sys/GENERIC =0A> arm64=0A> =0A> Could you guys please give me a= hand on starting using the SPI bus? I've =0A> tried googling around a bit,= but unfortunately not much came up.=0A> =0A> Best regards,=0A> Gergely=0A>= =0A> =0A> _______________________________________________=0A> freebsd-arm@= freebsd.org mailing list=0A> https://lists.freebsd.org/mailman/listinfo/fre= ebsd-arm=0A> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@free= bsd.org"=0A> From owner-freebsd-arm@freebsd.org Wed Mar 8 16:27:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C7E0D035FF for ; Wed, 8 Mar 2017 16:27:53 +0000 (UTC) (envelope-from nacho@lascartasdelavida.com) Received: from fuu.naqiao.hk (static-ip-217-148-66-202.rev.dyxnet.com [202.66.148.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "server.lascartasdelavida.com", Issuer "server.lascartasdelavida.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B0A091D16 for ; Wed, 8 Mar 2017 16:27:51 +0000 (UTC) (envelope-from nacho@lascartasdelavida.com) Received: from fuu.naqiao.hk (localhost [127.0.0.1]) by fuu.naqiao.hk (8.15.2/8.15.2) with ESMTPS id v28GRkFe085227 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 Mar 2017 16:27:48 GMT (envelope-from nacho@lascartasdelavida.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lascartasdelavida.com; s=fuu; t=1488990468; bh=uwDdXOmbkK5VvJvoT16OfB3apC6OZ5kWP+FamrPZNlU=; h=Date:From:To:Subject:Reply-To; b=Kx7ARZ8zWpRcVJ4QEvX9j9rdf7RX28wBE4VorNYknVwHvTnzy2E6ITHAfvMxG4WVf osJBXDVh/GNW25hCiqXl9H+/3I81M9Ye+fEUVzj/9zy3/4JmqPeRadw52QgplKTggi zhCem6Zl4iGuBnD855blhvYbPApfBl04f189tuZ8wI5t01nD2UTeURY00G388i10Xd 9d0Gz6pJWPZrjt5mVDmPfByCESJ9N3mgd0j898Bhdjx/2mWrG2PYIGA5yHpUtx+BEY EScJQ3O/6MSCUov5ekm+k99jZ6bL6JKRuTSDlX9B6Th3ZVErr8gd92alShMyXtfmBt Fwo6LcFxyR8/w== Received: (from correo@localhost) by fuu.naqiao.hk (8.15.2/8.15.2/Submit) id v28GRklU085226 for freebsd-arm@freebsd.org; Wed, 8 Mar 2017 16:27:46 GMT (envelope-from nacho@lascartasdelavida.com) Date: Wed, 8 Mar 2017 16:27:46 +0000 From: Nacho Vidal To: freebsd-arm@freebsd.org Subject: no virtual/VGA console in Olimex A20 micro Message-ID: <20170308162746.GB78591@lascartasdelavida.com> Reply-To: Nacho Vidal MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lCAWRPmW1mITcIfM" Content-Disposition: inline X-PGP-Key: http://lascartasdelavida.com/nacho_pubkey.txt User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:27:53 -0000 --lCAWRPmW1mITcIfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm configuring an Olimex A20 micro with FreeBSD 11 r306420, it's the offic= ial image for the CubieBoard2 where I just changed the CB2 DTB for that of the A20micro compiled from kernel sources. Basically it boots fine, USB and ethernet seem to work and I can access it = by serial console and ssh; the problem is that I can't get virtual terminals o= n the VGA monitor, also the usb keyboard doesn't work, it doesn't even light the = Caps Lock key, however USB works because I connect to internet with a usb 3g mod= em. So I have the doubt if maybe there is no support at all for VGA output in t= his board, or if I should load any module, use some option some place or recomp= ile the kernel with some specific driver support. When booting it says: VT: init without driver. and: kbd0 at kbdmux0 (I guess this is the serial console keyboard?) When doing conscontrol, it says: Configured: ttyu0 Available: ttyu0,ttyv0 Muting: off Then " sysctl kern.console=3Dttyv0" returns: kern.console: ttyu0,/ttyu0,ttyv0, -> ttyv0,ttyu0,/ttyu0,ttyv0, And after that conscontrol returns: Configured: ttyv0,ttyu0 Available: ttyu0,ttyv0 Muting: off But no output in the VGA monitor and the usb keyboard doesn't work either. Then if I set kern.console=3Dttyv0 in /etc/sysctl.conf it hangs in the boot process just here: Starting file system checks: u It shows that "u" for 5 seconds or so and then reboot and does the same aga= in and again. I tried to enable ttyv[1-7] in /dev/ttys, but after booting it just says: getty[581]: open /dev/ttyv1: No such file or directory I was trying to set up X with the scfb driver, but it seems the driver is n= ot in the kernel, and I don't see a module for it, it should be "sc.ko" isn't it? If I could just get a 80x25 text console in the VGA monitor it would be gre= at, I guess it shouldn't be so difficult, isn't it? Thank you very much for your help: Nacho --=20 PGP signed email:=20 http://lascartasdelavida.com/chinese_horoscope/contact_signature.php --lCAWRPmW1mITcIfM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE6Uqgj8gnBJpt0lG6nN9rlZyn+TUFAljAMPkACgkQnN9rlZyn +TVFLw/9Hh6o6J0IqN0He9qnYJEiLkTk/UKc6WIudZHh+JOaS/Qng395+yr180P8 0tWdk3rkcD5Bw7B3B/Nz98PIxi+ho9SkAvs2T1lKwAlZaIFIGql3JqMTB1jEFuLG zMOf0UKLJFHkVvvc7ZseRydL3zyW2UP4jJsJ5I6wSUTzG173zp+ea5rfFk3FIJwB 4YinqrfxyMS1GjoGzMjTIC5rwo3Vw9kBU77tmRK+8rk/OS5ppjX0jRrblg8EqIe5 IuzzjKsO3y/BiLPwKQKW6hKbIidnSW2sCGsG+xEenfWqDzjLF6BFLFhTPD6Kd/kT EYC2Pz22wyDbATG75I7Q0rk8PYiqbvNlzfmy11G9Kq50SDiUpoi6FPND9WGFr39z 8OVrYCBOwZXTrUYqAxr3Yym5+Kki5g5MnXRklBeKJvG8I9NxSpnEr4hNxXLR0XK+ 0CSTA0086IccCszLaLPsackrWFmL8CyKtIF5cgHSGLOUom29etAQkNl70C3uy6uL Mvog5lm/0OSsHSIL5uYa3lPFhrpKjr7Be9dIduqAWwtFga4FerrAj23RvhMhGmWT oIIsF9eEFF1VJ6CrZDLSboC1gb/1hjP8Gs4sRnGezZKPCTcKSzVr6o60eHq4199u WdmBtS7fxW2rPAJ2rM7uqW8vk7GmGKJjgLF3c8B/KSwOJBFYRhk= =ljDk -----END PGP SIGNATURE----- --lCAWRPmW1mITcIfM-- From owner-freebsd-arm@freebsd.org Wed Mar 8 18:46:23 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7B03D03462 for ; Wed, 8 Mar 2017 18:46:23 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCF4415D8 for ; Wed, 8 Mar 2017 18:46:23 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1clgbJ-000JAC-CI; Wed, 08 Mar 2017 10:46:17 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v28IkGi9073667; Wed, 8 Mar 2017 10:46:16 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Wed, 8 Mar 2017 10:46:16 -0800 From: Oleksandr Tymoshenko To: Mori Hiroki Cc: Gergely Czuczy , "freebsd-arm@freebsd.org" Subject: Re: How to use SPI Message-ID: <20170308184616.GA73649@bluezbox.com> References: <46d1021c-2ca7-d60b-3548-86f064aa8530@harmless.hu> <70974.52425.qm@web101714.mail.ssk.yahoo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <70974.52425.qm@web101714.mail.ssk.yahoo.co.jp> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Mori Hiroki (yamori813@yahoo.co.jp) wrote: > Hi. > > FreeBSD SPI support don't have userland interface. Not entirely true. There is one but interface can really use some improvements. See my reply to Gregory in freebsd-hacker: https://lists.freebsd.org/pipermail/freebsd-hackers/2017-March/050683.html [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:46:23 -0000 Mori Hiroki (yamori813@yahoo.co.jp) wrote: > Hi. > > FreeBSD SPI support don't have userland interface. Not entirely true. There is one but interface can really use some improvements. See my reply to Gregory in freebsd-hacker: https://lists.freebsd.org/pipermail/freebsd-hackers/2017-March/050683.html > You must use device driver for SPI device. But MAX31856 > driver isn't exist. -- gonzo From owner-freebsd-arm@freebsd.org Thu Mar 9 18:56:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8854FD05DD5 for ; Thu, 9 Mar 2017 18:56:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 57AE012B9; Thu, 9 Mar 2017 18:56:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v29Ituen033688 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 10:55:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v29Itsun033684; Thu, 9 Mar 2017 10:55:54 -0800 (PST) (envelope-from fbsd) Date: Thu, 9 Mar 2017 10:55:54 -0800 From: bob prohaska To: Ian Lepore Cc: "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170309185554.GA33403@www.zefox.net> References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> <1488936952.18764.63.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1488936952.18764.63.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:56:10 -0000 On Tue, Mar 07, 2017 at 06:35:52PM -0700, Ian Lepore wrote: > > Could you (and anybody else who has a board that uses pl011 uarts) > please test the attached patch? ?I tested already on an rpi-b and it > What's an appropriate source tree revision number for testing the patch on an RPI2? What I have now is 314923, which seems suspect. Thanks! bob prohaska From owner-freebsd-arm@freebsd.org Thu Mar 9 19:05:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DD20D05166 for ; Thu, 9 Mar 2017 19:05:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78DDA1B79 for ; Thu, 9 Mar 2017 19:05:05 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5d064108-04fb-11e7-ba57-8bc134ee460a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 5d064108-04fb-11e7-ba57-8bc134ee460a; Thu, 09 Mar 2017 19:05:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v29J4vMf001402; Thu, 9 Mar 2017 12:04:57 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1489086297.40576.17.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: bob prohaska Cc: freebsd-arm@freebsd.org, Oleksandr Tymoshenko , Michael Tuexen Date: Thu, 09 Mar 2017 12:04:57 -0700 In-Reply-To: <20170309185554.GA33403@www.zefox.net> References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> <1488936952.18764.63.camel@freebsd.org> <20170309185554.GA33403@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:05:05 -0000 On Thu, 2017-03-09 at 10:55 -0800, bob prohaska wrote: > On Tue, Mar 07, 2017 at 06:35:52PM -0700, Ian Lepore wrote: > > > > > > Could you (and anybody else who has a board that uses pl011 uarts) > > please test the attached patch? ?I tested already on an rpi-b and > > it > > > What's an appropriate source tree revision number for testing the  > patch on an RPI2?  What I have now is 314923, which seems suspect. > > Thanks! > > bob prohaska The last commit I did related to fixing the pl011 uart is r314917 -- Ian From owner-freebsd-arm@freebsd.org Fri Mar 10 09:53:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37A3FD0527F for ; Fri, 10 Mar 2017 09:53:35 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5DC712D5 for ; Fri, 10 Mar 2017 09:53:34 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=17343 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cmHEh-0006kc-UG; Fri, 10 Mar 2017 09:53:23 +0000 Received: from localhost ([127.0.0.1]:34968 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cmHEg-0006wI-HD; Fri, 10 Mar 2017 09:53:22 +0000 From: Andrew Gierth To: Warner Losh Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: (Warner Losh's message of "Sat, 4 Mar 2017 14:07:22 -0700") Message-ID: <8737ely05c.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Fri, 10 Mar 2017 09:53:21 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 09:53:35 -0000 >>>>> "Warner" == Warner Losh writes: >> Is building with CPUTYPE=cortex-A7 (this is on an RPI2) known to >> work, known to not work, or of unknown working status? 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. Well, I can now report that with a local fix for #217611 in place and everything recompiled for cortex-a7, I'm not seeing any wonkiness at all even with a lot of ports in use. -- Andrew. From owner-freebsd-arm@freebsd.org Fri Mar 10 12:52:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40DF8D04E22 for ; Fri, 10 Mar 2017 12:52:52 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDB311DB9 for ; Fri, 10 Mar 2017 12:52:51 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489150368; l=1880; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=CzLaZ9qIuzKtY14YuKqnDShrLwSzMCVKFoI+MZwf0l8=; b=wk7aqu/zgbA99emC+LsjYRjBrOXfdxIhEHA6s+IUteIQp88XoYt3r9y+8PBj/Va2Tw VFYEcv/9vhaKu/Cx3GLHfO/3AfS/6R+oXNMkZJ5YxN1f+X/cGDsENjOJCwdRhd4CLe/7 WKdu0vY6vOFWo6MP9PrCkF/KTXASZY9IdRO8A= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id R06094t2ACql816 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 10 Mar 2017 13:52:47 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 2DD347506DAD for ; Fri, 10 Mar 2017 09:52:44 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: BeagleBone Black MMC ordering clashes From: "Dr. Rolf Jansen" In-Reply-To: <419A8740-2BA4-45A6-B73D-15012373A5A0@obsigna.com> Date: Fri, 10 Mar 2017 09:52:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D750433-59FC-4999-AC24-041683E17310@obsigna.com> <1483718084.96230.5.camel@freebsd.org> <0D800E14-799A-4926-AEF8-CD698D647E40@obsigna.com> <1483722560.96230.10.camel@freebsd.org> <1483928120.96230.61.camel@freebsd.org> <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.com> <1487735878.73144.140.camel@freebsd.org> <419A8740-2BA4-45A6-B73D-15012373A5A0@obsigna.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:52:52 -0000 Am 22.02.2017 um 15:52 schrieb Dr. Rolf Jansen : > Am 22.02.2017 um 00:57 schrieb Ian Lepore : >> On Thu, 2017-02-16 at 07:48 -0200, Dr. Rolf Jansen wrote: >>> Am 09.01.2017 um 00:32 schrieb Dr. Rolf Jansen : >>>=20 >>> I tried the FreeBSD 12 snapshot for the BeagleBone from 2017-02-10, >>> and it does not work at all. >>>=20 >>> The new u-boot is complaining that it cannot find a configured = device >>> and drops into the console, and I needed to revert to the previous = u- >>> boot, i.e. the one that was on the snapshot from 2017-01-05. >>>=20 >>> With that the new kernel loaded, however, when trying to mount root, >>> kernel's vfs complained that the indicated device /dev/mmcsd0s2a is >>> read-only, and booting was not finished. >>>=20 >>> I gave up with FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170210- >>> r313561, and I will try again with the next snapshot. >>=20 >> Sorry for the long delay on this. I had flagged this mail for = followup >> but somehow forgot to ever do so. It turns out that read-only = problem >> is a bug I introduced along with the card-detect changes. I've just >> committed a fix in r314071, which should hopefully show up in the = next >> shapshot build. >=20 > Thank you for following this up. For the time being I have a working = system, and I can patiently wait for the fixes. >=20 > I will inform about my results, once the next snapshot is out. Today the snapshot FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r314972 came up = on the FreeBSD ftp server. I installed this new one, and with that = everything is working perfectly, including booting from the internal = flash and enumeration of a SD card which has been inserted into the slot = after the system was booted. Many thanks to everybody for all your efforts. Best regards Rolf= From owner-freebsd-arm@freebsd.org Fri Mar 10 14:16:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BC35D04B12 for ; Fri, 10 Mar 2017 14:16:09 +0000 (UTC) (envelope-from bounce+306a47.da7392-freebsd-arm=freebsd.org@linx.com) Received: from so254-58.mailgun.net (so254-58.mailgun.net [198.61.254.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5E3C197F for ; Fri, 10 Mar 2017 14:16:08 +0000 (UTC) (envelope-from bounce+306a47.da7392-freebsd-arm=freebsd.org@linx.com) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=linx.com; q=dns/txt; s=smtp; t=1489155368; h=Date: Message-Id: From: Content-type: MIME-Version: Subject: To: Sender; bh=ZMmcWlvsu70DN56ZynqY90NPBAMs5W/cm8eOUqwTXQc=; b=GH5aUZolzDAEy6rWtCxvr7vty7GYqgWIoIbyS4NeRknn/4DPskimV12BpZvwycZFtsmtGG45 7jEzxvb8olcKkFyPkIUUJXOq2nC+h3C2JZRo18hw6raaMgyKWEGMT1csBghaF8SZdzSvn/xV bb4ek0Xr+oT8tLBGkytIaZGR8dw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=linx.com; s=smtp; q=dns; h=Sender: To: Subject: MIME-Version: Content-type: From: Message-Id: Date; b=eJQgsjt2xwyQbYkwZRK+ZjCGTYEIq5v3DUqpA6YwLGzds/0B7x5x57d8bBMXhOuJUaPcuw +WhODkGoMKcPDh46OYFUOd2DBTfz8qXlonCcLXCMaO4X9ofRfZ3qPn26kS4cBIbj8ln59Mtl tXt7B9DXocfcpcWaBhnu2ZoogpnPs= Sender: root=localhost.linx.com@linx.com X-Mailgun-Sending-Ip: 198.61.254.58 X-Mailgun-Sid: WyJiNzkxYSIsICJmcmVlYnNkLWFybUBmcmVlYnNkLm9yZyIsICJkYTczOTIiXQ== Received: from 578509-app3.linx.com (578509-app3.linx.com [23.253.17.101]) by mxa.mailgun.org with ESMTP id 58c2b2c7.7f5e884d6af0-smtp-out-n02; Fri, 10 Mar 2017 14:05:59 -0000 (UTC) Received: by 578509-app3.linx.com (Postfix, from userid 10006) id F2D7CA6140E; Fri, 10 Mar 2017 08:05:32 -0600 (CST) To: freebsd-arm@freebsd.org Subject: [iTunes-Connect]Someone has been logged into your account from another country X-PHP-Originating-Script: 10006:mailer.php From: AppleID Message-Id: <20170310140532.F2D7CA6140E@578509-app3.linx.com> Date: Fri, 10 Mar 2017 08:05:32 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:16:09 -0000 From owner-freebsd-arm@freebsd.org Fri Mar 10 14:32:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ED94D06283 for ; Fri, 10 Mar 2017 14:32:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5770A16 for ; Fri, 10 Mar 2017 14:32:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id f84so48137242ioj.0 for ; Fri, 10 Mar 2017 06:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5qpmzsD7FdX+9nMveIk2YTn0dS4X2OUfZiiZ9pgXvFo=; b=X6Nt6Ychxx0/vO9k3Twou09c7goLktxxMvsasj6ppmdAPKsxLnh2zR5cqLStx8vXzS 9R2LBlbCB0g0x6/XKWG5VbANXeUNyH12Be8jG78zydpQnmrK8Y28KfN9K807eCiWYbEo ZFj8EwVCcBu/3gDrhvFTts3fg09ZTk8OixVRmxGGsPSeKpvxd6+k+M3moxrP2X8U0zyR yaJojld2AGBe9oHjTpxW68PEh+UKeG4g411syLIZxs1eOpYmvvOpn7KTa9U8+fldlMyx z3uqzEp12LRT/el4tWOVFvZ8mR5diM8oiKPSFKTje4LkflOAweI4Vt8S1Z4cR/rrEdJu EFww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5qpmzsD7FdX+9nMveIk2YTn0dS4X2OUfZiiZ9pgXvFo=; b=Ee124DWOlO9G62knoCfayVJtsPctm10p1BM6aVa4WeH6wwUKximD5uhK+rXPY4KJI5 KsP5rNm/iBQjFMFgjxDHy8MdBHyPHhQb24dbnp/R94lZ0MjxUmJmyIAQZgEVG0tmxLkV bcknRJ8vHoRpENITdlmSb69y/x4PLcfV/7Cz7ZZ6MXtb5QU94ElEfnarlJj93XJbqYYb Vf/buxNgEptT/2GgB9MXex6f6/JDOfwpMgq+jrH5xRnKo2Yf94pHcu79YIP/DIoievuz eSS4uLBDgttx10YmkI0YN//AmZNKpEeapCF2082zPISv9uoxioDE5j8lVDzlMKm7gQgF H0IA== X-Gm-Message-State: AMke39k8o7l5mnx1KHXCje4EDekcbcDK9HCEml4rzAoBsN466skwFf4r/GnMhZhrX05MF/o8Q6nFhA9Ua+Dv+g== X-Received: by 10.107.174.220 with SMTP id n89mr18111226ioo.166.1489156365971; Fri, 10 Mar 2017 06:32:45 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Fri, 10 Mar 2017 06:32:45 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <8737ely05c.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> From: Warner Losh Date: Fri, 10 Mar 2017 07:32:45 -0700 X-Google-Sender-Auth: M_98JKebgwOIH-RRqGRVnBKa2oQ Message-ID: Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? To: Andrew Gierth Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:32:47 -0000 On Fri, Mar 10, 2017 at 2:53 AM, Andrew Gierth wrote: >>>>>> "Warner" == Warner Losh writes: > > >> Is building with CPUTYPE=cortex-A7 (this is on an RPI2) known to > >> work, known to not work, or of unknown working status? > > 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. > > Well, I can now report that with a local fix for #217611 in place and > everything recompiled for cortex-a7, I'm not seeing any wonkiness at all > even with a lot of ports in use. Awesome. What's the local fix? Is it in FreeBSD yet? Warner From owner-freebsd-arm@freebsd.org Fri Mar 10 14:47:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C91BD065D3 for ; Fri, 10 Mar 2017 14:47:45 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8443118B for ; Fri, 10 Mar 2017 14:47:44 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489157262; l=2397; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=ZtJv4P6kQ7ean/4BOlmUuyDbTv/bOXXFuHkCHEOXkCo=; b=L7VNFRmLrX+h6VrIA8UkH2yyiVlkSeLC4chqYHMmEDsLrRaI1T7IoLINl396sp1/wM 6GiOk9u7s/FwI4PkEPsjx7Z7R8KVG+JwA+y4tERDLUxkCO0VeQQsjUKudzQWOd3vSWfx zIhJ3eJiP38nPcYOpd0MdBU7bFXjkwZ9XYUpE= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id j04f7dt2AElf7gj (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 10 Mar 2017 15:47:41 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 6C53F7506DAD for ; Fri, 10 Mar 2017 11:47:39 -0300 (BRT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: BeagleBone Black MMC ordering clashes From: Dr. Rolf Jansen In-Reply-To: Date: Fri, 10 Mar 2017 11:47:38 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D45AE79-E31B-4E81-BE70-AEAC2CA093C0@obsigna.com> References: <7D750433-59FC-4999-AC24-041683E17310@obsigna.com> <1483718084.96230.5.camel@freebsd.org> <0D800E14-799A-4926-AEF8-CD698D647E40@obsigna.com> <1483722560.96230.10.camel@freebsd.org> <1483928120.96230.61.camel@freebsd.org> <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.com> <1487735878.73144.140.camel@freebsd.org> <419A8740-2BA4-45A6-B73D-15012373A5A0@obsigna.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:47:45 -0000 Am 10.03.2017 um 10:30 schrieb Otac=EDlio de Ara=FAjo Ramos Neto = : > Dear >=20 > Coud tou please indicate to me where you found the procedure to = install FreeBSD in BBB flash memory? >=20 > []'s > -Otacilio It's not exactly that I found the procedure anywhere, I simply did it in = accordance to the common sense of an experienced FreeBSD user. 1. Start the BBB using a FreeBSD installation on the SD card. 2. Partition the internal flash -- note, this will destroy the factory = installation: # gpart -F destroy mmcsd1 # gpart create -s MBR mmcsd1 # gpart add -b 8192 -s 8192 -t fat32 mmcsd1 # gpart add -s 7536640 -t freebsd mmcsd1 # gpart add -s 7536640 -t freebsd-ufs mmcsd1s2 # gpart set -a active -i 1 mmcsd1s1 3. Create the file systems: # newfs_msdos -L boot /dev/mmcsd1s1 # newfs -ntUE -L system /dev/mmcsd1s2a # tunefs -a enable /dev/mmcsd1s2a 4. Configure the snapshot image as virtual memory disk, assuming the unpacked image is present in the working dir: # mdconfig -a -t vnode -f = FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170309-r314972.img -u 0 5. Copy over the U-BOOT data: # mount_msdosfs -o noatime /dev/md0s1 /media # mount_msdosfs -o noatime /dev/mmcsd1s1 /mnt # cp -p /media/* /mnt # umount /mnt # umount /media 6. As a Prerequisite, install the filesystem cloning tool // I use the tool sysutils/clone, and it can be installed either from = the ports: # cd /usr/ports/sysutils/clone # make install clean // or install it directly from the GitHub repository: # mkdir ~/bin # cd ~/bin # ln -s /usr/bin/svnliteversion svnversion # cd # svnlite checkout https://github.com/cyclaero/clone/trunk/ clone # cd clone # make install clean 7. Copy over the FreeBSD Installation # mount -o noatime /dev/md0s2a /media # mount -o noatime /dev/mmcsd1s2a /mnt # clone -c rwoff /media /mnt # umount /mnt # umount /media # mdconfig -d -u 0 8. Edit /etc/fstab so it gets the following content: /dev/ufs/system / ufs rw 1 = 1 /dev/label/boot /boot/msdos msdosfs rw,noatime 0 = 0 tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m = 0 0 9. Shutdown the BBB, remove the SD card, then restart. The BBB should now start from the internal flash. If it does not, then = perhaps I have forgotten a crucial step in the above procedure. Best regards Rolf From owner-freebsd-arm@freebsd.org Fri Mar 10 15:22:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 202FBD0409F for ; Fri, 10 Mar 2017 15:22:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id E99FB896 for ; Fri, 10 Mar 2017 15:22:41 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 23570216FC2 for ; Fri, 10 Mar 2017 09:22:35 -0600 (CST) Subject: Re: Odd-looking serial console prompt on RPI2 To: freebsd-arm@freebsd.org References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <1488817492.18764.14.camel@freebsd.org> <1488936952.18764.63.camel@freebsd.org> <20170309185554.GA33403@www.zefox.net> <1489086297.40576.17.camel@freebsd.org> From: Karl Denninger Message-ID: <6f4f9a07-2081-01f7-46cc-e673d34c78c1@denninger.net> Date: Fri, 10 Mar 2017 09:22:23 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1489086297.40576.17.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090502060406040903020201" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:22:42 -0000 This is a cryptographically signed message in MIME format. --------------ms090502060406040903020201 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/9/2017 13:04, Ian Lepore wrote: > On Thu, 2017-03-09 at 10:55 -0800, bob prohaska wrote: >> On Tue, Mar 07, 2017 at 06:35:52PM -0700, Ian Lepore wrote: >>> >>> Could you (and anybody else who has a board that uses pl011 uarts) >>> please test the attached patch? ?I tested already on an rpi-b and >>> it >>> >> What's an appropriate source tree revision number for testing the=20 >> patch on an RPI2? What I have now is 314923, which seems suspect. >> >> Thanks! >> >> bob prohaska > The last commit I did related to fixing the pl011 uart is r314917 > > -- Ian > > Been out of town but just SVN updated/built an RPI2 image using Crochet o= ff FreeBSD 12.0-CURRENT #0 r315000M: Fri Mar 10 08:49:32 CST 2017 =20 freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/CrossBu= ild-12/src/sys/RPI2 Serial console is ok on the Pi2; someone was asking earlier since they didn't have one to check. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090502060406040903020201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMTAxNTIyMjNaME8GCSqGSIb3DQEJBDFCBECzydfC ZHqLXM5CuOoUrEbdX2f+uObkGhL0WCFHDxBH8PBJXtNcK2C7dFEhBL/iNG8MRwRFxPcmKEJO zSc/FpcDMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAj0o7Mkfa6Gns G1t3FujJDiiKV8mOaHYqq5fxixFeYVK/fPm3ydYpwsCCqhDRQjxkkpPBq2xL2//XhoXV8Gii LpwuMkxuK3dUvABESfhAJCF15saL2YELZ2hKi9QuaAAf/mM32mHQCYN2DVVBOOnZYY2i9Cj/ YbiW8XC3x3GBUQZhCJsDlVMD2XeoGa/CW1oEHs92R33crMzKn38hbZcGwAD2Hr7gCgcMW0c8 OKaI8jCbArig/eznT4IlgwU5lArNPN88jkXWBFrSsN7szN2HHcDGY/4Q4ou17UJRlc73nV0T u6k1z9Ts2WPIyfjYqGfIdkFr7J3TZwOKiw4+a1bY6kmgtaJEaCdBy1Jdiq9aN+ZMbJVQ18Z0 EEuY6sFDCtncwbVKkhgr9wd+lWZm6aSgzGSoAFgEKgQh8mRkrPGZM0gc4aVIb/65K1RQPM2N YeVd0564QLo59rgAApTrcufMRFy3RNx//8EUChUJIi8+BJ2pAJUQIOE5PRPpYuxJ+WnZ9Fwm AKKEr1c3wItBKwO0lNCtM1w0/m98Nv0w0rcVDZVd7XRdhSGBxwc5z22eh7cc0mGuO5zYhrZM IZqm09Q139aLGpzJ03VNNCHlV4EWYl1YlX7L8PsQPUTphxMYy7n01RtJqysrw0x/RXv26FuI usp/nB9dyGcVyBlGmAm0Q3QAAAAAAAA= --------------ms090502060406040903020201-- From owner-freebsd-arm@freebsd.org Fri Mar 10 16:10:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B9DED04F15 for ; Fri, 10 Mar 2017 16:10:55 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 238F0C35 for ; Fri, 10 Mar 2017 16:10:54 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=26183 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cmN7z-0007D0-KE; Fri, 10 Mar 2017 16:10:51 +0000 Received: from localhost ([127.0.0.1]:36073 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cmN7y-000AXZ-BT; Fri, 10 Mar 2017 16:10:50 +0000 From: Andrew Gierth To: Warner Losh Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: (Warner Losh's message of "Fri, 10 Mar 2017 07:32:45 -0700") Message-ID: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Fri, 10 Mar 2017 16:10:49 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:10:55 -0000 >>>>> "Warner" == Warner Losh writes: 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. >> Well, I can now report that with a local fix for #217611 in place >> and everything recompiled for cortex-a7, I'm not seeing any >> wonkiness at all even with a lot of ports in use. Warner> Awesome. What's the local fix? Is it in FreeBSD yet? No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff My fix requires breaking the ABI, since the definition of mcontext_t simply does not have enough space to store all the registers, so I'm assuming it won't go into stable/11 (though that really needs _some_ kind of fix, since the bug can be demonstrated with ordinary floating-point code and no compile options). It needs attention from someone with more kernel/arm experience than I have to see whether I've missed something obvious (or subtle). (Maybe I should have filed it under "kern" rather than "arm"?) -- Andrew. From owner-freebsd-arm@freebsd.org Fri Mar 10 17:44:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0FCDD06DD4 for ; Fri, 10 Mar 2017 17:44:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9ACB21ADD for ; Fri, 10 Mar 2017 17:44:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2AHijvO096233 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Mar 2017 19:44:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2AHijvO096233 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2AHiivt096232; Fri, 10 Mar 2017 19:44:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Mar 2017 19:44:44 +0200 From: Konstantin Belousov To: Andrew Gierth Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <20170310174444.GN16105@kib.kiev.ua> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:44:54 -0000 On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: > >>>>> "Warner" == Warner Losh writes: > > 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. > > >> Well, I can now report that with a local fix for #217611 in place > >> and everything recompiled for cortex-a7, I'm not seeing any > >> wonkiness at all even with a lot of ports in use. > > Warner> Awesome. What's the local fix? Is it in FreeBSD yet? > > No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla > report: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff > > My fix requires breaking the ABI, since the definition of mcontext_t > simply does not have enough space to store all the registers, so I'm > assuming it won't go into stable/11 (though that really needs _some_ > kind of fix, since the bug can be demonstrated with ordinary > floating-point code and no compile options). > > It needs attention from someone with more kernel/arm experience than I > have to see whether I've missed something obvious (or subtle). > > (Maybe I should have filed it under "kern" rather than "arm"?) When x86 AVX support was added, the very same problem existed: the x86 mcontext_t has no space to store AVX registers, and worse, architecture explicitely allowed for future coprocessors to extend the register file further. In other words, even if breaking ABI and adding the storage to mcontext_t for AVX once was decided, the solution would be not sustainable. Also note that extending mcontext_t is very painful, because it is embedded into ucontext_t in the middle, so the change means that whole signal-delivery ABI is broken. In other words, a lot of compat shims is needed, each time. The x86 solution was to put new coprocessor state outside of the mcontext_t and pointing to it. This allowed the grow to happens transparently, mostly controlled by kernel. The getcontextx(3) function was added to not change expectation of (rare) getcontext(3) consumers that ucontext_t is self-contained. One of the important getcontextx(3) users is libthr, and there the internal __getcontextx_size()/__fillcontextx2() interface was added. I am not sure which tier the ARMv6 architecture is. It would seems to migrate to tier1 almost, but the ABI was broken recently with switch to hardfp. If indeed tier1, then ABI breakage is considered imadmissible, and getcontextx() route is probably good enough. The issue I see is that there is no reserved unused fields in mcontext_t on ARM, so probably some trick with not using fpu save area at all for fpu registers might be needed. If applying your patch because the ABI breakage is permitted for ARM, note that besides requiring recompilation, we also loose ability to run older binaries, including jails. From owner-freebsd-arm@freebsd.org Fri Mar 10 18:33:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94D27D069D1 for ; Fri, 10 Mar 2017 18:33:59 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 462421A1A for ; Fri, 10 Mar 2017 18:33:58 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.3] (port=18194 helo=isig.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cmPMR-0007Pe-Sm; Fri, 10 Mar 2017 18:33:55 +0000 Received: from localhost ([127.0.0.1]:16231 helo=isig.riddles.org.uk) by isig.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cmPMQ-000PDm-Vp; Fri, 10 Mar 2017 18:33:55 +0000 From: Andrew Gierth To: Konstantin Belousov Cc: "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <20170310174444.GN16105@kib.kiev.ua> (Konstantin Belousov's message of "Fri, 10 Mar 2017 19:44:44 +0200") Message-ID: <87pohpvvei.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Fri, 10 Mar 2017 18:33:52 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:33:59 -0000 >>>>> "Konstantin" == Konstantin Belousov writes: Konstantin> The issue I see is that there is no reserved unused fields Konstantin> in mcontext_t on ARM, so probably some trick with not using Konstantin> fpu save area at all for fpu registers might be needed. There aren't any reserved fields, but the entire __fpu element of mcontext_t is currently unused in the sense that no register values are ever stored there by the kernel. -- Andrew. From owner-freebsd-arm@freebsd.org Fri Mar 10 18:42:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71309D06CC9 for ; Fri, 10 Mar 2017 18:42:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 511DC1FF6 for ; Fri, 10 Mar 2017 18:42:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v2AIgBdl038606 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Mar 2017 10:42:12 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v2AIgB07038605; Fri, 10 Mar 2017 10:42:11 -0800 (PST) (envelope-from fbsd) Date: Fri, 10 Mar 2017 10:42:10 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Message-ID: <20170310184210.GA38002@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:42:04 -0000 After a successful build of FreeBSD 12.0-CURRENT (RPI2) #5 r314923: Fri Mar 10 09:03:07 PST 2017 the next attempt at updating sources produced: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Trying root@www:/usr/src # svnlite info . Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 314923 Node Kind: directory Schedule: normal Last Changed Author: avos Last Changed Rev: 314923 Last Changed Date: 2017-03-08 14:49:22 -0800 (Wed, 08 Mar 2017) root@www:/usr/src # svnlite status . ? buildkernel.log ? buildscript ? buildscript.bak ? buildworld.log ? installkernel.log ? installworld.log reveals no very obvious mischief. Cleanup didn't have any effect, is there something else to try? I'd rather not checkout again if it can be avoided, it's very slow. Thanks for reading and any guidance, bob prohaska From owner-freebsd-arm@freebsd.org Fri Mar 10 18:51:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84E81D06042 for ; Fri, 10 Mar 2017 18:51:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46B722FC for ; Fri, 10 Mar 2017 18:51:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9116 invoked from network); 10 Mar 2017 17:51:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Mar 2017 17:51:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 10 Mar 2017 12:51:05 -0500 (EST) Received: (qmail 23927 invoked from network); 10 Mar 2017 17:51:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Mar 2017 17:51:05 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 85F62EC884C; Fri, 10 Mar 2017 09:51:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> Date: Fri, 10 Mar 2017 09:51:03 -0800 Cc: Andrew Gierth , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> To: Warner Losh X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:51:07 -0000 On 2017-Mar-10, at 8:10 AM, Andrew Gierth wrote: >=20 >>>>>> "Warner" =3D=3D Warner Losh writes: >=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 >>> Well, I can now report that with a local fix for #217611 in place >>> and everything recompiled for cortex-a7, I'm not seeing any >>> wonkiness at all even with a lot of ports in use. >=20 > Warner> Awesome. What's the local fix? Is it in FreeBSD yet? >=20 > No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla > report: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217611 > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180669&action=3Ddi= ff >=20 > My fix requires breaking the ABI, since the definition of mcontext_t > simply does not have enough space to store all the registers, so I'm > assuming it won't go into stable/11 (though that really needs _some_ > kind of fix, since the bug can be demonstrated with ordinary > floating-point code and no compile options). To be explicit: armv6 VFP use can have the issue too, depending on what signal handlers do. Also, as Andrew wrote in comment #2: > The use of -mcpu=3Dcortex-a7 or similar option just broadens the = problem > to include every program that might have vector operations in a signal > handler (which includes all programs with signal handlers if linked > with libthr) as well as in the main program. Going in another direction: There is a less common context with the problem that need not involve floating point code. But it takes a compiler option to enable Integer NEON and armv6 does not have NEON so the contexts are more limited. (I'm ignoring compiler directives internal to source code or assembler use.)=20 http://lists.llvm.org/pipermail/llvm-dev/2016-March/097613.html (2016-Mar-25) indicates that llvm/clang was intended to eventually have: > Examples: >=20 > Works today: > -mfpu=3Dsoft -> Int (ALU), FP (LIB), no VFP/NEON instructions > -mfpu=3Dsoftfp -> Int (ALU), FP (LIB), VFP/NEON instructions allowed > -mfpu=3Dvfp -> Int (ALU), FP (VFP) > -mfpu=3Dneon -> Int (NEON), FP (NEON) >=20 > Change proposed: > -mfpmath=3Dneon -mfpu=3Dvfp -> Int (ALU), FP (NEON) > -mfpmath=3Dvfp -mfpu=3Dneon -> Int (NEON), FP (VFP) So if -mfpu=3DNEON has been specified but there are no floating point data types in use at all the extra registers can still be in use for just integer data. Such code could have problems with signals not preserving those register values. So not only is armhf not implemented correctly in stable/11, release/11.0.1, and head, effectively FreeBSD does not support Integer NEON use when no floating point data types are in use. (Or it constrains what signal handlers are allowed to do.) So overall: If the ABI stays as it is for 11 (or 12), floating point in general (VFP with or without NEON) and Integer NEON can be broken when signals are involved that allow the code to keep going instead of exiting the process. (This means all NEON use is subject to the issue.) Or at least FreeBSD constrains what signal handlers are allowed to do but for some compiler options (such as -mcpu=3Dcortex-a7) FreeBSD itself currently violates those constraints. > It needs attention from someone with more kernel/arm experience than I > have to see whether I've missed something obvious (or subtle).=20 >=20 > (Maybe I should have filed it under "kern" rather than "arm"?) >=20 > --=20 > Andrew. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Mar 10 19:21:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12F93D06B55 for ; Fri, 10 Mar 2017 19:21:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C53F015A for ; Fri, 10 Mar 2017 19:21:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30544 invoked from network); 10 Mar 2017 18:54:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Mar 2017 18:54:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 10 Mar 2017 13:54:31 -0500 (EST) Received: (qmail 1386 invoked from network); 10 Mar 2017 18:54:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Mar 2017 18:54:31 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 5C5CEEC8051; Fri, 10 Mar 2017 10:54:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <20170310174444.GN16105@kib.kiev.ua> Date: Fri, 10 Mar 2017 10:54:29 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0B79BDF3-4BAF-4164-8387-D47B795915F1@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:21:13 -0000 On 2017-Mar-10, at 9:44 AM, Konstantin Belousov = wrote: > On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: >>>>>>> "Warner" =3D=3D Warner Losh writes: >>=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 >>>> Well, I can now report that with a local fix for #217611 in place >>>> and everything recompiled for cortex-a7, I'm not seeing any >>>> wonkiness at all even with a lot of ports in use. >>=20 >> Warner> Awesome. What's the local fix? Is it in FreeBSD yet? >>=20 >> No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla >> report: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217611 >> = https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180669&action=3Ddiff= >>=20 >> My fix requires breaking the ABI, since the definition of mcontext_t >> simply does not have enough space to store all the registers, so I'm >> assuming it won't go into stable/11 (though that really needs _some_ >> kind of fix, since the bug can be demonstrated with ordinary >> floating-point code and no compile options). >>=20 >> It needs attention from someone with more kernel/arm experience than = I >> have to see whether I've missed something obvious (or subtle).=20 >>=20 >> (Maybe I should have filed it under "kern" rather than "arm"?) >=20 > When x86 AVX support was added, the very same problem existed: the x86 > mcontext_t has no space to store AVX registers, and worse, = architecture > explicitely allowed for future coprocessors to extend the register = file > further. In other words, even if breaking ABI and adding the storage > to mcontext_t for AVX once was decided, the solution would be not > sustainable. armv7 has a similar issue/status for floating point (and potentially for Integer-only NEON): = http://liris.cnrs.fr/~mmrissa/lib/exe/fetch.php?media=3Darmv7-a-r-manual.p= df says: > Appendix F Common VFP Subarchitecture Specification > Defines version 2 of the Common VFP Subarchitecture. > Note > This specification is not part of the ARM architecture specification. = This > sub-architectural information is included here as supplementary = information, > for the convenience of developers and users who might require this = information. > . . . > Appendix F Common VFP Subarchitecture Specification includes examples = of how > a Floating-point subarchitecture might define additional registers, in = the > SUBARCHITECTURE DEFINED register space using addresses in the 0b1001 = to 0b1111 > range. Appendix F is not part of the ARMv7 architecture. It is = included as an > example of how a Floating-point subarchitecture might be defined. > . . . [presuming a Common VFP Subarchitecture context:] > Floating-point support code > A complete Floating-point implementation might require a software = component, > called the support code. For example, if an implementation includes = VFPv3U or > VFPv4U, support code must handle the trapped floating-point = exceptions. The > interface to the support code is called the VFP subarchitecture. ARM = has > defined a subarchitecture that is suitable for use with = implementations of > the ARM Floating-point Extension, see Appendix F Common VFP = Subarchitecture > Specification. [FreeBSD does not currently have such support code as I understand.] > Context switch software can be written to always save and restore the > subarchitecture registers. In this case appropriate context switch = software > must be chosen based on the registers implemented "Subarchitectures" need not be ones defined by arm but arm does provide some examples that are commonly used. armv7 does not have registers for supporting floating point control and general operation directly in its architecture at all: it is a bigger distinction than just being optional. VFP versions are just the most common floating point addition alternatives as far as I can tell, not required ones. FreeBSD may need to identify what range of floating point support for armv6/armv7 it intends to cover up front since floating point is beyond-architecture (i.e., it is implementation-defined subarchitecture material). My be an ABI definition used implies more specifics than armv7 = architecture does of itself? That might cover the issue if the ABI in question was then referenced very explicitly. Another option would be an explicit list of -mcpu=3D options that imply certain things are present for sure. -march=3Darmv7-a does presume some optional things/extensions from the architecture are present if I understand right. It takes more compiler options to avoid those things. But covering the compiler presumptions for a list of -march=3D might by an alternative/addition. Non-floating-point-only NEON for armv7 would have a similar status as = far as I can tell. = http://infocenter.arm.com/help/topic/com.arm.doc.dht0002a/DHT0002A_introdu= cing_neon.pdf says: > There is no architectural requirement for a processor to implement = both VFP > and NEON, but the common features in the programmers models for these > extensions mean an operating system that supports VFP requires little = or no > modifications to also support NEON. It appears that "extensions" means "subarchitecture defined" and subarchitectures need not be defined by arm examples. There is also: = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053d/IHI0053D_acle_2_= 1.pdf which says: > __ARM_NEON is defined to a value indicating the Advanced SIMD (NEON) = architecture > supported. The only current value is 1. >=20 > In principle, for AArch32, the NEON architecture can exist in an = integer-only > version. To test for the presence of NEON floating-point vector = instructions, > test __ARM_NEON_FP. When NEON does occur in an integer-only version, = the VFP > scalar instruction set is also not present. Integer-only NEON hardware (or just lack of any use of floating-point = data types but use of Integer Neon when VFP is present) would also have the = signal handler issues as things are. And http://lists.llvm.org/pipermail/llvm-dev/2016-March/097613.html (2016-Mar-25) indicates that llvm/clang was intended to eventually have: > Examples: >=20 > Works today: > -mfpu=3Dsoft -> Int (ALU), FP (LIB), no VFP/NEON instructions > -mfpu=3Dsoftfp -> Int (ALU), FP (LIB), VFP/NEON instructions allowed > -mfpu=3Dvfp -> Int (ALU), FP (VFP) > -mfpu=3Dneon -> Int (NEON), FP (NEON) >=20 > Change proposed: > -mfpmath=3Dneon -mfpu=3Dvfp -> Int (ALU), FP (NEON) > -mfpmath=3Dvfp -mfpu=3Dneon -> Int (NEON), FP (VFP) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Mar 10 23:39:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27849D06402 for ; Fri, 10 Mar 2017 23:39:15 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0108214B9; Fri, 10 Mar 2017 23:39:14 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:Cc:To:From; bh=AR0ajenEFSzwjS2q5HzOgkaj2ibINfUQjCclogne0+0=; b=Aockhbno+McgSoft3jAI/f8D7OBTZCoY79qEHHTB6nEkD1VOFVfMAwAh94YAk53KUhvapaJ8dGh7Cp9dF0jbY3RGWMMVr5Ufmm+roluIVBZri+fzSd4tGO437wrLMUMnmE6tCMTDJb7xhKZ3k1RBthrncXmQMZaHLvNec7XOsk4bCRNT; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cmU7m-0004gy-3i; Fri, 10 Mar 2017 15:39:13 -0800 From: "Tony Hain" To: Cc: "'Ian Lepore'" References: In-Reply-To: Date: Fri, 10 Mar 2017 15:39:08 -0800 Message-ID: <066b01d299f7$8336bc60$89a43520$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKWFnDH3u1k5S7URoq/cuLJiik7jAD1Qlaw Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB asymmetric stack? X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.net) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 23:39:15 -0000 Follow up: Using OWAMP (http://software.internet2.edu/owamp/) there is a clear asymmetry in the FreeBSD-12 arm stack. Measurements originating from the BBB consistently take longer than those originating in the opposite direction, and jitter is significantly worse when FreeBSD-12 arm is doing the echo. This level of error results in an offset for ntp. FreeBSD12_BBB -> ARM Cortex-A8 1.0GHz Rpi_raspberrypi_4.1.15+ -> model B ARM Cortex-A53 1.2 GHz FreeBSD8_i386a -> hw.model: Intel(R) Celeron(R) CPU 2.40GHz FreeBSD8_i386b -> hw.model: Intel(R) Pentium(R) 4 CPU 1.80GHz BBB & Rpi connected to the same switch. i386a & i386b are 2 local router hops off that switch with routing symmetry verified. Measurements done sequentially to avoid any cross impact ::::: FreeBSD12_BBB -> # owping -c 1000 -n u 2001:470:e930:1240:-i386a- Approximately 103.2 seconds until results available --- owping statistics from [2001:470:e930:2240:-BBB-]:8769 to [2001:470:e930:1240:-i386a-]:2259 --- SID: fe044c0adc6da10e3acf2a8a67086b90 first: 2017-03-10T14:02:55.463 last: 2017-03-10T14:04:38.162 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 288/500/1.74e+04 us, (err=3.02 us) one-way jitter = 100 us (P95-P50) Hops = 2 (consistently) no reordering --- owping statistics from [2001:470:e930:1240:-i386a-]:2263 to [2001:470:e930:2240:-BBB-]:8883 --- SID: fefbf6c6dc6da10e5380d38f54bbd8b6 first: 2017-03-10T14:02:55.466 last: 2017-03-10T14:04:34.525 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 350/500/1.99e+04 us, (err=3.02 us) one-way jitter = 300 us (P95-P50) Hops = 2 (consistently) no reordering FreeBSD8_i386a -> # owping -c 1000 -n u 2001:470:e930:2240:-BBB- Approximately 103.3 seconds until results available --- owping statistics from [2001:470:e930:1240:-i386a-]:10791 to [2001:470:e930:2240:-BBB-]:4212 --- SID: fefbf6c6dc6da19d78d6292c35ef1187 first: 2017-03-10T14:05:18.697 last: 2017-03-10T14:06:54.748 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 345/500/2.18e+04 us, (err=3.02 us) one-way jitter = 400 us (P95-P50) Hops = 2 (consistently) no reordering --- owping statistics from [2001:470:e930:2240:-BBB-]:4265 to [2001:470:e930:1240:-i386a-]:42582 --- SID: fe044c0adc6da19d7cfebce7630aea48 first: 2017-03-10T14:05:18.797 last: 2017-03-10T14:06:56.113 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 295/500/6.32e+04 us, (err=3.02 us) one-way jitter = 100 us (P95-P50) Hops = 2 (consistently) no reordering FreeBSD12_BBB -> # owping -c 1000 -n u 2001:470:e930:12c0:-i386b- Approximately 103.3 seconds until results available --- owping statistics from [2001:470:e930:2240:-BBB-]:8855 to [2001:470:e930:12c0:-i386b-]:2318 --- SID: fe794e70dc6da2372cea6331afc13440 first: 2017-03-10T14:07:52.407 last: 2017-03-10T14:09:29.933 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 254/400/1.42e+04 us, (err=3.02 us) one-way jitter = 100 us (P95-P50) Hops = 2 (consistently) no reordering --- owping statistics from [2001:470:e930:12c0:-i386b-]:2300 to [2001:470:e930:2240:-BBB-]:8887 --- SID: fefbf6c6dc6da237329d336cf9a12126 first: 2017-03-10T14:07:52.463 last: 2017-03-10T14:09:30.625 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 322/500/1.36e+04 us, (err=3.02 us) one-way jitter = 200 us (P95-P50) Hops = 2 (consistently) no reordering FreeBSD8_i386b -> # owping -c 1000 -n u 2001:470:e930:2240:-BBB- Approximately 103.2 seconds until results available --- owping statistics from [2001:470:e930:12c0:-i386b-]:57055 to [2001:470:e930:2240:-BBB-]:4211 --- SID: fefbf6c6dc6da2a71e6d9f99dfe5be1b first: 2017-03-10T14:09:44.324 last: 2017-03-10T14:11:26.464 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 305/500/2.57e+04 us, (err=4.02 us) one-way jitter = 200 us (P95-P50) Hops = 2 (consistently) no reordering --- owping statistics from [2001:470:e930:2240:-BBB-]:4231 to [2001:470:e930:12c0:-i386b-]:64099 --- SID: fe794e70dc6da2a7243e1ee38651110b first: 2017-03-10T14:09:44.355 last: 2017-03-10T14:11:25.457 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 254/400/2.5e+04 us, (err=4.02 us) one-way jitter = 100 us (P95-P50) Hops = 2 (consistently) no reordering FreeBSD12_BBB -> # owping -c 1000 -n u 2001:470:e930:2240:-Rpi- Approximately 103.4 seconds until results available --- owping statistics from [2001:470:e930:2240:-BBB-]:8928 to [2001:470:e930:2240:-Rpi-]:4226 --- SID: 4b031abcdc6da34676422beb5014dbd9 first: 2017-03-10T14:12:23.808 last: 2017-03-10T14:14:03.739 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 285/400/1.82e+04 us, (err=2.01 us) one-way jitter = 200 us (P95-P50) TTL not reported no reordering --- owping statistics from [2001:470:e930:2240:-Rpi-]:4236 to [2001:470:e930:2240:-BBB-]:8813 --- SID: fefbf6c6dc6da346861b906566678c71 first: 2017-03-10T14:12:23.828 last: 2017-03-10T14:14:12.996 1000 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 243/400/2.34e+04 us, (err=2.01 us) one-way jitter = 300 us (P95-P50) TTL not reported no reordering raspberrypi_4.1.15+ -> # owping -c 100 -n u 2001:470:e930:2240:-BBB- Approximately 12.9 seconds until results available --- owping statistics from [2001:470:e930:2240:-Rpi-]:8906 to [2001:470:e930:2240:-BBB-]:4214 --- SID: fefbf6c6dc6da414e9617290304594ab first: 2017-03-10T14:15:49.962 last: 2017-03-10T14:16:00.106 100 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 255/400/2.71e+03 us, (err=2.01 us) one-way jitter = 300 us (P95-P50) TTL not reported no reordering --- owping statistics from [2001:470:e930:2240:-BBB-]:4210 to [2001:470:e930:2240:-Rpi-]:8912 --- SID: 4b031abcdc6da414f059a52f753769e5 first: 2017-03-10T14:15:50.032 last: 2017-03-10T14:16:01.078 100 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 289/400/707 us, (err=2.01 us) one-way jitter = 200 us (P95-P50) TTL not reported no reordering > -----Original Message----- > From: Tony Hain [mailto:tony@tndh.net] > Sent: Sunday, March 05, 2017 6:04 PM > To: 'freebsd-arm@freebsd.org' > Cc: 'Ian Lepore' > Subject: BBB asymmetric stack? > > FreeBSD 12.0-CURRENT #0 r314118M: Wed Feb 22 22:49:19 PST 2017 > > Trying to calibrate the ntp feed on the BBB I was suspecting some problem > with the dmtpps driver, but then realized that network asymmetry would be > more likely to explain the persistent offset. It would appear that there is an > asymmetry within the stack on the am335x based system. > > ping6 Rpi -> BBB > 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt > min/avg/max/mdev = 0.503/0.567/0.642/0.047 ms > > ping6 BBB -> Rpi > 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip > min/avg/max/std-dev = 0.878/0.967/1.141/0.134 ms > > Those are on adjacent ports on the same 100mbps switch. > > --- > > ping6 Fbsd-8 -> BBB > 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip > min/avg/max/std-dev = 0.599/0.734/1.041/0.112 ms > > ping6 BBB -> Fbsd-8 > 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip > min/avg/max/std-dev = 0.855/0.970/1.816/0.296 ms > > Those are one router hop apart. > > --- > > Even localhost appears to indicate a problem in the FreeBSD-arm side of this: > pi# ping6 ::1 > PING ::1(::1) 56 data bytes > 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.220 ms > 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.222 ms > 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.221 ms > > i386# ping6 ::1 > PING6(56=40+8+8 bytes) ::1 --> ::1 > 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.185 ms > 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.135 ms > 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.129 ms > > bbb# ping6 ::1 > PING6(56=40+8+8 bytes) ::1 --> ::1 > 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.672 ms > 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.477 ms > 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.464 ms > > > I realize the loopback ping by itself is not a good indicator of an asymmetry > problem, but FreeBSD 8 on i386 systems ping::1 at ~ 130us, while all the > FreeBSD 10/11 VMs (Hyper-V & VMware) and the pi ping ::1 at ~220us. The > issue is that the time is always longer when the BBB initiates the ping, which > would imply some transmit delay that does not exist when responding to an > incoming ping, but it could be simply getting the reply back to user space > which only happens in the BBB initiate case. > > ==== > The ntp perspective might shed some light on which direction. > > pi > pi# ntpq -p > remote refid st t when poll reach delay offset jitter > ========================================================== > ==================== > GPS_NMEA(0) .GPS. 0 s 342d 16 0 0.000 -29.245 0.000 > oPPS(0) .PPS. 0 s 6 16 377 0.000 0.000 0.002 > *172.20.0.18 .PPS. 1 u 12 64 377 0.492 0.030 0.026 <== > i386 > > i386 > # ntpq -p > remote refid st t when poll reach delay offset jitter > ========================================================== > ==================== > xPPS(1) .PPS. 0 l 14 16 377 0.000 0.001 0.002 > oGPS_NMEA(1) .GPS. 0 l 8 16 377 0.000 0.000 0.002 > +2001:470:e930:2 .PPS. 1 u 30 64 377 0.519 0.008 0.020 <==pi > > BBB > # ntpq -p > remote refid st t when poll reach delay offset jitter > ========================================================== > ==================== > oPPS(0) .PPS. 0 s 32 32 377 0.000 0.000 0.004 > *GPS_NMEA(0) .GPS. 0 s 7 8 377 0.000 -47.650 39.504 > +2001:470:e930:2 .PPS. 1 u 28 32 377 0.682 -0.164 0.043 <== pi > +2001:470:e930:7 .GPS. 1 u 44 64 377 0.963 -0.197 1.771 <== > i386 > > The offset being about half of the path variance for an asymmetric path is > expected ntp behavior. All of these systems are looking at the same PPS > pulse, though the i386 is seeing it through an RS232 driver delay so it has an > additional 1.3us fudge factor. > > In any case, it appears that there is some form of delay in getting bits out of > the box. > > Tony From owner-freebsd-arm@freebsd.org Sat Mar 11 13:50:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C3C0D062E6 for ; Sat, 11 Mar 2017 13:50:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C17BFA0 for ; Sat, 11 Mar 2017 13:50:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2BDoXHr063618 for ; Sat, 11 Mar 2017 13:50:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217705] /etc/termcap on snapshots FreeBSD 12.0-CURRENT-arm-armv6 links to nowhere Date: Sat, 11 Mar 2017 13:50:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: cyclaero@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 13:50:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217705 Bug ID: 217705 Summary: /etc/termcap on snapshots FreeBSD 12.0-CURRENT-arm-armv6 links to nowhere Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: cyclaero@gmail.com I guess this should be fixed before releasing 12.0=20 Steps to reproduce: # mdconfig -a -t vnode -f FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170309-r314972.img # mount -o noatime /dev/md0s2a /media # ls -l /media/etc/termcap ------ lrwxr-xr-x 1 root wheel 36 Mar 9 22:25 /media/etc/termcap -> ../../../../../../share/misc/termcap ------ Workaround before copying the snapshot to the SD card (or possibly after the fact, on the running system): # cd /media/etc # rm termcap # ln -s ../usr/share/misc/termcap # umount /media # mdconfig -d -u 0 Best regards Rolf --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Mar 11 17:49:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D491D080A2 for ; Sat, 11 Mar 2017 17:49:43 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAB85A59 for ; Sat, 11 Mar 2017 17:49:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x229.google.com with SMTP id p64so199349654qke.1 for ; Sat, 11 Mar 2017 09:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3ZkoPq14BgoG+kPqqNQiHKwueX0X0r0Z9guyenePbEI=; b=1pp+5H2GWXx3vITkHhUW9BO25pS4LIn07nog5IDGr9HA9G5SbBEaGbdWlc43iJRqJA 8PsnceiY+RA8n4itlayo55IlJN+hE3QoPNI/Rkf/a38kK0Jw2YsC2YlW+Js9zcxnf9S0 JVzs8f2TDyTstNkuG2+0f/3nUGspHi+USOGlzx/txTCV8uEEjFVUSjEyO8v0e7mqKfhz O4oJfEhWYeSqmg0cMdUCAGjvwXC/k0SzcRDKHnm1jUd1pYoZOZ1qTiIInSQITUSSEhb4 ZI8DzfZbWFhHv2jYsSm3eJ42di84UNL07PyoG2n0bVewzannCADSdOu85NT09XD3HNwx 55bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3ZkoPq14BgoG+kPqqNQiHKwueX0X0r0Z9guyenePbEI=; b=GCrCwvnpjHVcWKX2lvH3sUCmRmbEo0W7SDCsLuDfZF1pcvm56BCrqPy73kMSc11qxR IbhSo/Rfp8XAh84CqM0LWiGhQdaHKtfqOMiNZXbGxdU4KShfCh/djqQ2vkgmj83x0CuH G/XPEP9aXkByEmSoFJ4qQ8HIfGK34So66CY/NHoHCkdMzHNO7KR8+t+AJ0xqHPcGdPFO jnksu+7Jm0gbRFEMK2w+wKwcfpGtoOOvAGUrxSkCCxF2KG32JNT7W1K0DB7iyfZC8p+q 827zrWlEKCOle+aZ7Tugl5dQQnvIFHDyEefXOB78u2q8vnTcKGJyLRn1E0IabsBbthRl I6Ug== X-Gm-Message-State: AFeK/H2L6sAfwMvlZHlHSBthl5eKDLEXUNMLoUNbso2g7A/QaYvu5vyDA1BoIKOy6nkpbUnQ X-Received: by 10.55.19.10 with SMTP id d10mr23309467qkh.312.1489254581954; Sat, 11 Mar 2017 09:49:41 -0800 (PST) Received: from mutt-hbsd (pool-100-16-218-40.bltmmd.fios.verizon.net. [100.16.218.40]) by smtp.gmail.com with ESMTPSA id c19sm8754722qtc.29.2017.03.11.09.49.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 Mar 2017 09:49:41 -0800 (PST) Date: Sat, 11 Mar 2017 12:49:40 -0500 From: Shawn Webb To: Ian Lepore Cc: "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arm@freebsd.org, Michael Tuexen Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> References: <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jzg4gled2o772coh" Content-Disposition: inline In-Reply-To: <20170307192918.2garie2ow6lzekg7@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 17:49:43 -0000 --jzg4gled2o772coh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > The bugs should be fixed as of r314682. ?It looks like the bugs have > > > long been in the pl011 driver, but were masked by having a fifo depth > > > of 1 byte -- it all sorta worked by accident previously. > >=20 > > Thanks for the fix! But it looks to be only partial. When I connect to > > the serial console via either cu or screen, I don't get corrupted text, > > but no keypresses are registered. Hitting enter at the login prompt does > > absolutely nothing. I'm at the latest commit of hardened/current/master > > on HardenedBSD for both the RPI3 and my laptop. > >=20 > > I'm using this serial cable from Adafruit: > > https://www.adafruit.com/product/954 >=20 > It looks like I had a bad cable. Sorry for the line noise. Switching to > a different cable worked. Looks like the problem is back, but manifest in a different way. Screenshot: https://goo.gl/photos/XYx6v1jCTVCGrnhd6 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --jzg4gled2o772coh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAljEOLEACgkQaoRlj1JF bu6CRhAAw+4dNRqC2m8ZOk6S2+BvA9RrYvvfGMATKs7pDKd5yNvYxpRL+DRorflT tdVrulnBYmH/EG/eXDX+gsQWM/DLibO99dCO8Q1LSBL8qjz+1oh5A0e5wHd6xlRx FHDOxuXghnB9V2DK2qHZ7KAiM2UcDnIlWU9ruBXsW/vC6xq3syDxsSM+p45WCNB9 9GNMYvvOmc3zjrBxScSF9YAs/ez9DEA+7GzqrlMf4d4nf/6eePM1UecEvN3Lb/TQ 3bpuOewGckfFcn9DTGXzk5n5G86jNw5zukTqR/u3IA/NIrXZSIfWMVGYBFh3E/eW lOAZGUP+kcfOgibeqn48n1pTofSfgpep6OxMHj3OGUmGD0rA1LT+VPVwtnjGa5Ls 4mBGRf/jhG+rAerLFN20nhwfza+PgI2yYuJZSrOfdBXeBAfIdLquS39hhrLf8ppI +ea1qqGw6ODdM1PtCRIGJ0dJVLq5wvhOq19LGlmZzA7BWBda2+1OoIcAFC6f18qq vt+2lCLXXQ5EPUpucp03a7ATxc+KirCOwzr4VEFu1KWeapJmC1aV4u6pKh/pQt4K HkiH2iQkOfGcnfA6Mg5rnJk/Uu6UGyQVQR3TsMwZ2340+pXHQHZnbO1jzngIFs6T /0Ioe5QjfOjnlFH28U0m4fDlLvANwu5kd4pb5sge8V8PIMw3jPA= =VZkQ -----END PGP SIGNATURE----- --jzg4gled2o772coh-- From owner-freebsd-arm@freebsd.org Sat Mar 11 17:54:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 866CCD0830D for ; Sat, 11 Mar 2017 17:54:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B4BDE67 for ; Sat, 11 Mar 2017 17:54:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9c4e6b69-0683-11e7-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 9c4e6b69-0683-11e7-b3c2-c9f38144898e; Sat, 11 Mar 2017 17:53:19 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2BHrsue001663; Sat, 11 Mar 2017 10:53:58 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1489254834.40576.55.camel@freebsd.org> Subject: Re: Booting Raspberry Pi with input on serial console From: Ian Lepore To: Peter =?ISO-8859-1?Q?Ankerst=E5l?= , FreeBSD Stable , "freebsd-arm@FreeBSD.org" Date: Sat, 11 Mar 2017 10:53:54 -0700 In-Reply-To: <30CFED65-9A38-4332-B935-095B26A6FFFD@pean.org> References: <30CFED65-9A38-4332-B935-095B26A6FFFD@pean.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 17:54:06 -0000 On Fri, 2017-03-10 at 11:40 +0100, Peter Ankerstål wrote: > Hi! > > I have a problem that should (?) have a simple solution but I havent > found one.  > > I have a raspberry pi with a NMEA-GPS constantly hooked up to the > serial console of the Pi.  > > My problem is that when booting the Pi it will interpet the output > from the GPS as input to the boot process and the boot will fail. How > can I have the serial interface of the GPS permanently hooked up to > the pi without preventing the system to boot? > > Thanks! > > /Peter. Ideally, the fix for this would be to "setenv stdin nulldev; saveenv", but unfortunately our copy of uboot is missing the option to include nulldev in uboot. I think a viable workaround for your case is probably to create a uEnv.txt file on the fat partition of the sdcard and put in it:  bootdelay=0  stderr=lcd  stdout=lcd That will prevent uboot from stopping if the gps receiver sends some text, and prevent uboot from sending most of its text output to the serial port, which may confuse the gps receiver (the uboot startup banner text still appears on the serial port tho). -- Ian From owner-freebsd-arm@freebsd.org Sat Mar 11 18:04:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 611A9D08818 for ; Sat, 11 Mar 2017 18:04:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF733184A for ; Sat, 11 Mar 2017 18:04:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 24916dda-0685-11e7-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 24916dda-0685-11e7-95b5-6dfd7dbb0ee5; Sat, 11 Mar 2017 18:04:18 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2BI44ex001696; Sat, 11 Mar 2017 11:04:04 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1489255444.40576.57.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: Shawn Webb Cc: freebsd-arm@freebsd.org Date: Sat, 11 Mar 2017 11:04:04 -0700 In-Reply-To: <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> References: <20170301200112.ymwkfd64tzz5f3b2@mutt-hbsd> <4194F030-4E5C-4EB6-82D7-FD725E3B7CEF@fh-muenster.de> <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> Content-Type: multipart/mixed; boundary="=-Qnj3Fz+amEJxWOW2DD65" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 18:04:19 -0000 --=-Qnj3Fz+amEJxWOW2DD65 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: > On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > > > > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > > > > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > > > > > > The bugs should be fixed as of r314682. ?It looks like the bugs > > > > have > > > > long been in the pl011 driver, but were masked by having a fifo > > > > depth > > > > of 1 byte -- it all sorta worked by accident previously. > > > Thanks for the fix! But it looks to be only partial. When I > > > connect to > > > the serial console via either cu or screen, I don't get corrupted > > > text, > > > but no keypresses are registered. Hitting enter at the login > > > prompt does > > > absolutely nothing. I'm at the latest commit of > > > hardened/current/master > > > on HardenedBSD for both the RPI3 and my laptop. > > > > > > I'm using this serial cable from Adafruit: > > > https://www.adafruit.com/product/954 > > It looks like I had a bad cable. Sorry for the line noise. > > Switching to > > a different cable worked. > Looks like the problem is back, but manifest in a different way. > Screenshot: > > https://goo.gl/photos/XYx6v1jCTVCGrnhd6 > > Thanks, > I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi.  Just to test that theory, can you see if the attached patch fixes problem?  If it does, I'll figure out how to detect rpi3 at runtime and set the sizes properly. -- Ian --=-Qnj3Fz+amEJxWOW2DD65 Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/uart/uart_dev_pl011.c =================================================================== --- sys/dev/uart/uart_dev_pl011.c (revision 314917) +++ sys/dev/uart/uart_dev_pl011.c (working copy) @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) is_bcm2835 = ofw_bus_is_compatible(sc->sc_dev, "brcm,bcm2835-pl011") || ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835-uart"); #else - is_bcm2835 = false; + is_bcm2835 = true; #endif hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; if (hwrev <= 2 || is_bcm2835) { --=-Qnj3Fz+amEJxWOW2DD65-- From owner-freebsd-arm@freebsd.org Sat Mar 11 18:09:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A748D0899F for ; Sat, 11 Mar 2017 18:09:50 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1667D1BD9 for ; Sat, 11 Mar 2017 18:09:50 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22c.google.com with SMTP id v125so195199463qkh.2 for ; Sat, 11 Mar 2017 10:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=L6p70uXvdFOyV7/ayJmB//Q2Fj8/lYmJc0/LZvInWA8=; b=GrJlL/r/5N+UtRjXhoeJfGOi+/hqgBn0FCoL/VYQEBx9lgTepM/89CTtbQoAmBWKyg JyScR9SLKzMOSJVC+M36dVY5knMAB6PW5tdHe1cOJPWLO87ta31IJQ574AjBbzvWceU2 8h429RsDfmVgc61FA6DELLav/vuUkKsqvX3bkHwWapJlwNd3BWMNAFZaBbV98E8uchuZ R5GmC/7ENoA/phy1ZiuLx7IPxFr8jjC+8I1I8piGfr+d2A18ne3Rei6el8B18r91jmbX abuZDWIkTPa9QlzrAHTMRMyH1lDlLhJGTGh8u+g+xx3Yax0Wtp/3xSHVlSfRGeF3A+kG s86g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=L6p70uXvdFOyV7/ayJmB//Q2Fj8/lYmJc0/LZvInWA8=; b=tB5+DQljzu7Kpd0G9e5eiAMgLNzCyM/ZtYenmdSJgB1UtybjWA+gWA304bUNEc6Tu/ X+Q23sCrqvHVxJDhWR9Xuo1dGRXyuZYUIWk6IyVHSrARFu2C40eBTWJnjsFrG8fuuhDJ anNg43RSQbQuQYkVg6P5IXOZcYwnGEQXsCFZ4PjHPJZkqvYUMl14kgMGzDXhr+a7YQdP Tc37YQp2zvturWAwb9MzfyWEfh/Lq+SHugZRgvheJpW6OjrMkjTC3Xxt2MC7AJP5nEbY Q4dPXPDYDLw0cZ2StTCN0S2/Jb11Jel9ENM8N0wTDM4SaXa/obgMTcz2DoeRCrFVHXnA eMiA== X-Gm-Message-State: AMke39mbudQXog2hxKTh8EwGWQud1BOVJnXis/2HTGE0tD91U43EvJ9Dk4qwhSIXQOBNujLg X-Received: by 10.233.222.197 with SMTP id s188mr23214117qkf.311.1489255789268; Sat, 11 Mar 2017 10:09:49 -0800 (PST) Received: from mutt-hbsd (pool-100-16-218-40.bltmmd.fios.verizon.net. [100.16.218.40]) by smtp.gmail.com with ESMTPSA id r189sm8759438qkf.58.2017.03.11.10.09.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 Mar 2017 10:09:48 -0800 (PST) Date: Sat, 11 Mar 2017 13:09:47 -0500 From: Shawn Webb To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170311180947.ro5obisuaemvudkp@mutt-hbsd> References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> <1489255444.40576.57.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wrrrn5gptp5ytu4l" Content-Disposition: inline In-Reply-To: <1489255444.40576.57.camel@freebsd.org> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 18:09:50 -0000 --wrrrn5gptp5ytu4l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 11, 2017 at 11:04:04AM -0700, Ian Lepore wrote: > On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: > > On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > > >=20 > > > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > > >=20 > > > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > > >=20 > > > > > The bugs should be fixed as of r314682. ?It looks like the bugs > > > > > have > > > > > long been in the pl011 driver, but were masked by having a fifo > > > > > depth > > > > > of 1 byte -- it all sorta worked by accident previously. > > > > Thanks for the fix! But it looks to be only partial. When I > > > > connect to > > > > the serial console via either cu or screen, I don't get corrupted > > > > text, > > > > but no keypresses are registered. Hitting enter at the login > > > > prompt does > > > > absolutely nothing. I'm at the latest commit of > > > > hardened/current/master > > > > on HardenedBSD for both the RPI3 and my laptop. > > > >=20 > > > > I'm using this serial cable from Adafruit: > > > > https://www.adafruit.com/product/954 > > > It looks like I had a bad cable. Sorry for the line noise. > > > Switching to > > > a different cable worked. > > Looks like the problem is back, but manifest in a different way. > > Screenshot: > >=20 > > https://goo.gl/photos/XYx6v1jCTVCGrnhd6 > >=20 > > Thanks, > >=20 >=20 > I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi. ?Just > to test that theory, can you see if the attached patch fixes problem? > ?If it does, I'll figure out how to detect rpi3 at runtime and set the > sizes properly. >=20 > -- Ian > Index: sys/dev/uart/uart_dev_pl011.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/uart/uart_dev_pl011.c (revision 314917) > +++ sys/dev/uart/uart_dev_pl011.c (working copy) > @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) > is_bcm2835 =3D ofw_bus_is_compatible(sc->sc_dev, "brcm,bcm2835-pl011") = || > ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835-uart"); > #else > - is_bcm2835 =3D false; > + is_bcm2835 =3D true; > #endif > hwrev =3D __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; > if (hwrev <=3D 2 || is_bcm2835) { Sure. I'll report back either tonight or tomorrow. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --wrrrn5gptp5ytu4l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAljEPWkACgkQaoRlj1JF bu5f7Q/9GypaIWvOGK715kufcfUNcYDFn85g4p1NxxXHupDx/INaonCjgXPZb2Rv vt3GvBC+imrq0vSsP1gyQ4YOBQ9Qirqlb+Q3qDTP93PFx/16hpWiRrvXIyik38vW tVHTefpCBfc9n7V+f3ExcBRRi95Nq8JAEEC7H+YBr6nWdxKNEIbF0Vx1gIuYPlNG MMMxFyPDoEjUwjxnVGDXNURH5hZ7gNv/JBcaDko4qqZbS2Yd1vMTF6nhyqrmstY1 7pPWV6ZD3pRZg3WiOTzFProwiedMS1YT64SjvuoV5CmKJyR/q68j9YrmKmK7Dgx/ Uv7GijDNSf2Q0oF/gUff/vjyhmAyQCsjCGyVgjkqpmB5mWEfbENAJYlLV6OLYr5Z dxPWThKAaT+dAgUTi4z+qida+9KCZTiggI2bU4kbh2IzuEOEmjnIzlWIoZxqOZ73 D8LQyHVzkmQkseSdYvdlT0SaeGxhQNkxoDqpF1dfmKyJT6FxyVVn/nQfOXNxUMah 8+d2sj2Jb3L0fWhlqUUMrCVaVjoGn+k/Er1appaA5ObngphReu6pZZjs8yrlzm34 ghwYut3PzPe5g/zKZ+8hp3P3DDvNkJfVPz4QPqIpdpGZrtWKmTj9ZELzy3gfgOv0 gLr9TWj9soTKCF+Bk7rSZ1OrYzLnp4hEFchuYyeNpPRoKVUjtNQ= =TBIY -----END PGP SIGNATURE----- --wrrrn5gptp5ytu4l-- From owner-freebsd-arm@freebsd.org Sat Mar 11 18:20:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E954D060C6 for ; Sat, 11 Mar 2017 18:20:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0023A264 for ; Sat, 11 Mar 2017 18:20:23 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 4b9424e8-0687-11e7-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 4b9424e8-0687-11e7-b3c2-c9f38144898e; Sat, 11 Mar 2017 18:19:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2BIKLbb001724; Sat, 11 Mar 2017 11:20:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1489256421.40576.59.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: Shawn Webb Cc: freebsd-arm@freebsd.org Date: Sat, 11 Mar 2017 11:20:21 -0700 In-Reply-To: <20170311180947.ro5obisuaemvudkp@mutt-hbsd> References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> <1489255444.40576.57.camel@freebsd.org> <20170311180947.ro5obisuaemvudkp@mutt-hbsd> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 18:20:24 -0000 On Sat, 2017-03-11 at 13:09 -0500, Shawn Webb wrote: > On Sat, Mar 11, 2017 at 11:04:04AM -0700, Ian Lepore wrote: > > > > On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: > > > > > > On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > > > > > > > > > > > > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > > > > > > > > > > > > > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > > > > > > > > > > > > > > > > The bugs should be fixed as of r314682. ?It looks like the > > > > > > bugs > > > > > > have > > > > > > long been in the pl011 driver, but were masked by having a > > > > > > fifo > > > > > > depth > > > > > > of 1 byte -- it all sorta worked by accident previously. > > > > > Thanks for the fix! But it looks to be only partial. When I > > > > > connect to > > > > > the serial console via either cu or screen, I don't get > > > > > corrupted > > > > > text, > > > > > but no keypresses are registered. Hitting enter at the login > > > > > prompt does > > > > > absolutely nothing. I'm at the latest commit of > > > > > hardened/current/master > > > > > on HardenedBSD for both the RPI3 and my laptop. > > > > > > > > > > I'm using this serial cable from Adafruit: > > > > > https://www.adafruit.com/product/954 > > > > It looks like I had a bad cable. Sorry for the line noise. > > > > Switching to > > > > a different cable worked. > > > Looks like the problem is back, but manifest in a different way. > > > Screenshot: > > > > > > https://goo.gl/photos/XYx6v1jCTVCGrnhd6 > > > > > > Thanks, > > > > > I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi. > > ?Just > > to test that theory, can you see if the attached patch fixes > > problem? > > ?If it does, I'll figure out how to detect rpi3 at runtime and set > > the > > sizes properly. > > > > -- Ian > > > > Index: sys/dev/uart/uart_dev_pl011.c > > =================================================================== > > --- sys/dev/uart/uart_dev_pl011.c (revision 314917) > > +++ sys/dev/uart/uart_dev_pl011.c (working copy) > > @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) > >   is_bcm2835 = ofw_bus_is_compatible(sc->sc_dev, > > "brcm,bcm2835-pl011") || > >       ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835- > > uart"); > >  #else > > - is_bcm2835 = false; > > + is_bcm2835 = true; > >  #endif > >   hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; > >   if (hwrev <= 2 || is_bcm2835) { > Sure. I'll report back either tonight or tomorrow. > > Thanks, > I've just learned that the rpi3 uses fdt data (I thought it was acpi), so that patch won't do anything as-is.  Move the is_bcm2835=true outside after the #endif so it's just always in effect, to test the concept.  I think I know a different way to detect the rpi3 at runtime if need be. -- Ian From owner-freebsd-arm@freebsd.org Sat Mar 11 19:18:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 571ABD0741E for ; Sat, 11 Mar 2017 19:18:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36E5C8BB for ; Sat, 11 Mar 2017 19:18:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 83d212ca-068f-11e7-ba57-8bc134ee460a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 83d212ca-068f-11e7-ba57-8bc134ee460a; Sat, 11 Mar 2017 19:18:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2BJHwZv001809; Sat, 11 Mar 2017 12:17:58 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1489259878.40576.62.camel@freebsd.org> Subject: Re: Odd-looking serial console prompt on RPI2 From: Ian Lepore To: Shawn Webb Cc: freebsd-arm@freebsd.org Date: Sat, 11 Mar 2017 12:17:58 -0700 In-Reply-To: <20170311180947.ro5obisuaemvudkp@mutt-hbsd> References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> <1489255444.40576.57.camel@freebsd.org> <20170311180947.ro5obisuaemvudkp@mutt-hbsd> Content-Type: multipart/mixed; boundary="=-q+0yLMX7JzA43d2N+dSS" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:18:07 -0000 --=-q+0yLMX7JzA43d2N+dSS Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Sat, 2017-03-11 at 13:09 -0500, Shawn Webb wrote: > On Sat, Mar 11, 2017 at 11:04:04AM -0700, Ian Lepore wrote: > > > > On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: > > > > > > On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > > > > > > > > > > > > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > > > > > > > > > > > > > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > > > > > > > > > > > > > > > > The bugs should be fixed as of r314682. ?It looks like the > > > > > > bugs > > > > > > have > > > > > > long been in the pl011 driver, but were masked by having a > > > > > > fifo > > > > > > depth > > > > > > of 1 byte -- it all sorta worked by accident previously. > > > > > Thanks for the fix! But it looks to be only partial. When I > > > > > connect to > > > > > the serial console via either cu or screen, I don't get > > > > > corrupted > > > > > text, > > > > > but no keypresses are registered. Hitting enter at the login > > > > > prompt does > > > > > absolutely nothing. I'm at the latest commit of > > > > > hardened/current/master > > > > > on HardenedBSD for both the RPI3 and my laptop. > > > > > > > > > > I'm using this serial cable from Adafruit: > > > > > https://www.adafruit.com/product/954 > > > > It looks like I had a bad cable. Sorry for the line noise. > > > > Switching to > > > > a different cable worked. > > > Looks like the problem is back, but manifest in a different way. > > > Screenshot: > > > > > > https://goo.gl/photos/XYx6v1jCTVCGrnhd6 > > > > > > Thanks, > > > > > I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi. > > ?Just > > to test that theory, can you see if the attached patch fixes > > problem? > > ?If it does, I'll figure out how to detect rpi3 at runtime and set > > the > > sizes properly. > > > > -- Ian > > > > Index: sys/dev/uart/uart_dev_pl011.c > > =================================================================== > > --- sys/dev/uart/uart_dev_pl011.c (revision 314917) > > +++ sys/dev/uart/uart_dev_pl011.c (working copy) > > @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) > >   is_bcm2835 = ofw_bus_is_compatible(sc->sc_dev, > > "brcm,bcm2835-pl011") || > >       ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835- > > uart"); > >  #else > > - is_bcm2835 = false; > > + is_bcm2835 = true; > >  #endif > >   hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; > >   if (hwrev <= 2 || is_bcm2835) { > Sure. I'll report back either tonight or tomorrow. > > Thanks, > Actually, I think a proper solution will be something like the attached patch.  After some spelunking on the web I think the rpi3 fifos are the smaller size because the fdt data contains the linux-style workaround (which overrides the primecell periphid value with fdt data).  This patch looks for that in addition to looking for the rpi compatible strings (still required to handle old-style freebsd fdt data). -- Ian --=-q+0yLMX7JzA43d2N+dSS Content-Disposition: inline; filename="uart_pl011_fifosizes_rpi.diff" Content-Type: text/x-patch; name="uart_pl011_fifosizes_rpi.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/uart/uart_dev_pl011.c =================================================================== --- sys/dev/uart/uart_dev_pl011.c (revision 314917) +++ sys/dev/uart/uart_dev_pl011.c (working copy) @@ -40,6 +40,7 @@ __FBSDID("$FreeBSD$"); #include #ifdef FDT #include +#include #endif #include #include "uart_if.h" @@ -449,25 +450,36 @@ static int uart_pl011_bus_probe(struct uart_softc *sc) { uint8_t hwrev; - bool is_bcm2835; +#ifdef FDT + pcell_t node; + uint32_t periphid; - device_set_desc(sc->sc_dev, "PrimeCell UART (PL011)"); - /* * The FIFO sizes vary depending on hardware; rev 2 and below have 16 - * byte FIFOs, rev 3 and up are 32 byte. We get a bit of drama, as - * always, with the bcm2835 (rpi), which claims to be rev 3, but has 16 - * byte FIFOs. We check for both the old freebsd-historic and the - * proper bindings-defined compatible strings for bcm2835. + * byte FIFOs, rev 3 and up are 32 byte. The hardware rev is in the + * primecell periphid register, but we get a bit of drama, as always, + * with the bcm2835 (rpi), which claims to be rev 3, but has 16 byte + * FIFOs. We check for both the old freebsd-historic and the proper + * bindings-defined compatible strings for bcm2835, and also check the + * workaround the linux drivers use for rpi3, which is to override the + * primecell periphid register value with a property. */ -#ifdef FDT - is_bcm2835 = ofw_bus_is_compatible(sc->sc_dev, "brcm,bcm2835-pl011") || - ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835-uart"); + if (ofw_bus_is_compatible(sc->sc_dev, "brcm,bcm2835-pl011") || + ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835-uart")) { + hwrev = 2; + } else { + node = ofw_bus_get_node(sc->sc_dev); + if (OF_getencprop(node, "arm,primecell-periphid", &periphid, + sizeof(periphid)) > 0) { + hwrev = (periphid >> 20) & 0x0f; + } else { + hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; + } + } #else - is_bcm2835 = false; + hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; #endif - hwrev = __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; - if (hwrev <= 2 || is_bcm2835) { + if (hwrev <= 2) { sc->sc_rxfifosz = FIFO_RX_SIZE_R2; sc->sc_txfifosz = FIFO_TX_SIZE_R2; } else { @@ -475,6 +487,8 @@ uart_pl011_bus_probe(struct uart_softc *sc) sc->sc_txfifosz = FIFO_TX_SIZE_R3; } + device_set_desc(sc->sc_dev, "PrimeCell UART (PL011)"); + return (0); } --=-q+0yLMX7JzA43d2N+dSS-- From owner-freebsd-arm@freebsd.org Sat Mar 11 19:19:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E458D0748C for ; Sat, 11 Mar 2017 19:19:29 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D66E7931 for ; Sat, 11 Mar 2017 19:19:28 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x231.google.com with SMTP id p64so200097024qke.1 for ; Sat, 11 Mar 2017 11:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iSDwyNhgA3RYtdTXAVfTnx2q19Is6FpVvBt0YMoHBmw=; b=yQaZ83on6UyEo33Z/wSR2EGbzftwdg4g/lVkwZ/gCLT5Fq8aT1twjzecLuLWfRx3iY PBVwEyEYEJqus/ffDDZiA4R4Z2PEkmgw1KNhFRDB9G9iH4O+zX92DwWoOWG8gpCs7CvV agt0Mn2guyxbr363W0pJpH6kDoDvpEPwg4W8KNSTJOZsS//aJhvCpHUpireJdsecTN8p ZAl8jVC6Top1HAHpt2ockxpsmqaiz3TxD4gsNr1TzHONoUEdzG8/SYacIxDVyhMzDcPm poGrFYcsDV+FE+C9tvoz0kD1jXRE1AJjkKB53GUwiAWWPrBebxMO9RK0uaZm+MwVQhu8 kUGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iSDwyNhgA3RYtdTXAVfTnx2q19Is6FpVvBt0YMoHBmw=; b=GKoWjF73rrd9pXoCfKLuZ5XslWocRAbRbE+VWEQ/rzew69xLnLZH9aZBdYVApZVvIM GwOwBrWe+jDyOWtblBxcWtdT+bG89iJ8wEOmy0u1RoPFdJCKDUgyZVNUEvfNz4Ffh5Ni c6FI7Kw140ughOjvq8W0wTpxcftb6fXwf5kk/p7kBwE9mpFBfsxPDAQXcUtae/eOm5Nu DHtLkbqqryDDRHnPun5FuAeQVXIkAHMAi2xbmktTVMrGXTRHq1XKIirK/FC9C7+tkrWx kigcGfBIA6ndYeAaS6l+NJUdAhSNBfWfNpyuF7T4sVW2nKboaOqgMKSSuL4mITPOzIdi pwLg== X-Gm-Message-State: AFeK/H0v0GbMSn9CD8HltUCFoB1eIYK35aO7cR255N06lIJqE3m/8maouYo6M92pyDLGV4LW X-Received: by 10.55.99.18 with SMTP id x18mr25478131qkb.185.1489259968009; Sat, 11 Mar 2017 11:19:28 -0800 (PST) Received: from mutt-hbsd (pool-100-16-218-40.bltmmd.fios.verizon.net. [100.16.218.40]) by smtp.gmail.com with ESMTPSA id q188sm8875004qkf.20.2017.03.11.11.19.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 Mar 2017 11:19:27 -0800 (PST) Date: Sat, 11 Mar 2017 14:19:26 -0500 From: Shawn Webb To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170311191926.le5ort7zdinxwppz@mutt-hbsd> References: <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> <1489255444.40576.57.camel@freebsd.org> <20170311180947.ro5obisuaemvudkp@mutt-hbsd> <1489259878.40576.62.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i57yfzzai7uts5vr" Content-Disposition: inline In-Reply-To: <1489259878.40576.62.camel@freebsd.org> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:19:29 -0000 --i57yfzzai7uts5vr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 11, 2017 at 12:17:58PM -0700, Ian Lepore wrote: > On Sat, 2017-03-11 at 13:09 -0500, Shawn Webb wrote: > > On Sat, Mar 11, 2017 at 11:04:04AM -0700, Ian Lepore wrote: > > >=20 > > > On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: > > > >=20 > > > > On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > > > > >=20 > > > > >=20 > > > > > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > > > > >=20 > > > > > >=20 > > > > > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > The bugs should be fixed as of r314682. ?It looks like the > > > > > > > bugs > > > > > > > have > > > > > > > long been in the pl011 driver, but were masked by having a > > > > > > > fifo > > > > > > > depth > > > > > > > of 1 byte -- it all sorta worked by accident previously. > > > > > > Thanks for the fix! But it looks to be only partial. When I > > > > > > connect to > > > > > > the serial console via either cu or screen, I don't get > > > > > > corrupted > > > > > > text, > > > > > > but no keypresses are registered. Hitting enter at the login > > > > > > prompt does > > > > > > absolutely nothing. I'm at the latest commit of > > > > > > hardened/current/master > > > > > > on HardenedBSD for both the RPI3 and my laptop. > > > > > >=20 > > > > > > I'm using this serial cable from Adafruit: > > > > > > https://www.adafruit.com/product/954 > > > > > It looks like I had a bad cable. Sorry for the line noise. > > > > > Switching to > > > > > a different cable worked. > > > > Looks like the problem is back, but manifest in a different way. > > > > Screenshot: > > > >=20 > > > > https://goo.gl/photos/XYx6v1jCTVCGrnhd6 > > > >=20 > > > > Thanks, > > > >=20 > > > I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi. > > > ?Just > > > to test that theory, can you see if the attached patch fixes > > > problem? > > > ?If it does, I'll figure out how to detect rpi3 at runtime and set > > > the > > > sizes properly. > > >=20 > > > -- Ian > > >=20 > > > Index: sys/dev/uart/uart_dev_pl011.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/dev/uart/uart_dev_pl011.c (revision 314917) > > > +++ sys/dev/uart/uart_dev_pl011.c (working copy) > > > @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) > > > ? is_bcm2835 =3D ofw_bus_is_compatible(sc->sc_dev, > > > "brcm,bcm2835-pl011") || > > > ? ????ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835- > > > uart"); > > > ?#else > > > - is_bcm2835 =3D false; > > > + is_bcm2835 =3D true; > > > ?#endif > > > ? hwrev =3D __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; > > > ? if (hwrev <=3D 2 || is_bcm2835) { > > Sure. I'll report back either tonight or tomorrow. > >=20 > > Thanks, > >=20 >=20 > Actually, I think a proper solution will be something like the attached > patch. ?After some spelunking on the web I think the rpi3 fifos are the > smaller size because the fdt data contains the linux-style workaround > (which overrides the primecell periphid value with fdt data). ?This > patch looks for that in addition to looking for the rpi compatible > strings (still required to handle old-style freebsd fdt data). >=20 > -- Ian Cool. I'll give that patch a shot soon. Thanks a lot! --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --i57yfzzai7uts5vr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAljETbsACgkQaoRlj1JF bu6ZDg//To8zE+axviS5/yWwhL0tAbGp8NBLVGa2BYNENK8Cr0rffwC7CGw6BMB9 z4VTCNQiZ/nEUY0q7MZEUb0FxSyMWOvswdEgZCugmj8+soBwPUIsc9haYr48hPdN JePXi5WOex7F8dfgvigwM102H62Ggm7N1MuIisBlk8gT7mDBUj9J/OWKyF/Cnlzc fbEHjehpUA+8GIOB/kUoff4O1910cVMpIwysc5yuyXeSX7nYliWGgA9ZFrC6HgSu XG8PbxH1O/nysmYmOkhg4m4ZfA2Wfv/tHh7XFT9ypYRiFFvBOzKpNrrnbn62Bc6D 1TQv6Y7zV/epuKvxokHMwO7fg1dPXhNcdAdfD6d1lW79t8XxEQvXaJaYMqaHS0MJ rH8nTntwrXuN9BBwBJzflorJb4qNhlQ2TJHUZau9GabwdRmKENX/K+w1Zh7IlyKO PC7cvpyr1U3YKtjtWcnoOTD+mYeVhAJ9y6TNf81onEy0WEwl9ydaRGN4SvS1/lro pYezS0pq4ykDUe/ZgtLOm2ulJEwJXBXYsho9r9degPxmZu1sncmymKK9Xc1JsN4D 3hmXbq3Gzf+9ZmWnI8wokXFnS4HwrYDEuLd1ZyjUyc6leDRuUvcAyN/V+41AK3iI chu6Wpuhz0494JUwS3x8NX3Wg+882Lu8gX71rv00dq1PoCqkgG0= =ut3c -----END PGP SIGNATURE----- --i57yfzzai7uts5vr-- From owner-freebsd-arm@freebsd.org Sat Mar 11 19:19:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E00CD074B8 for ; Sat, 11 Mar 2017 19:19:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 325F1965 for ; Sat, 11 Mar 2017 19:19:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 44AE0214634 for ; Sat, 11 Mar 2017 13:19:30 -0600 (CST) Subject: Re: Odd-looking serial console prompt on RPI2 To: freebsd-arm@freebsd.org References: <20170302000334.GA99403@www.zefox.net> <1488419304.60166.26.camel@freebsd.org> <20170302020116.GA98466@bluezbox.com> <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> <1489255444.40576.57.camel@freebsd.org> <20170311180947.ro5obisuaemvudkp@mutt-hbsd> <1489259878.40576.62.camel@freebsd.org> From: Karl Denninger Message-ID: Date: Sat, 11 Mar 2017 13:19:16 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1489259878.40576.62.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020604080404060700000807" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:19:37 -0000 This is a cryptographically signed message in MIME format. --------------ms020604080404060700000807 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/11/2017 13:17, Ian Lepore wrote: > On Sat, 2017-03-11 at 13:09 -0500, Shawn Webb wrote: >> On Sat, Mar 11, 2017 at 11:04:04AM -0700, Ian Lepore wrote: >>> On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: >>>> On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: >>>>> >>>>> On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: >>>>>> >>>>>> On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: >>>>>>> >>>>>>> The bugs should be fixed as of r314682. ?It looks like the >>>>>>> bugs >>>>>>> have >>>>>>> long been in the pl011 driver, but were masked by having a >>>>>>> fifo >>>>>>> depth >>>>>>> of 1 byte -- it all sorta worked by accident previously. >>>>>> Thanks for the fix! But it looks to be only partial. When I >>>>>> connect to >>>>>> the serial console via either cu or screen, I don't get >>>>>> corrupted >>>>>> text, >>>>>> but no keypresses are registered. Hitting enter at the login >>>>>> prompt does >>>>>> absolutely nothing. I'm at the latest commit of >>>>>> hardened/current/master >>>>>> on HardenedBSD for both the RPI3 and my laptop. >>>>>> >>>>>> I'm using this serial cable from Adafruit: >>>>>> https://www.adafruit.com/product/954 >>>>> It looks like I had a bad cable. Sorry for the line noise. >>>>> Switching to >>>>> a different cable worked. >>>> Looks like the problem is back, but manifest in a different way. >>>> Screenshot: >>>> >>>> https://goo.gl/photos/XYx6v1jCTVCGrnhd6 >>>> >>>> Thanks, >>>> >>> I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi. >>> ?Just >>> to test that theory, can you see if the attached patch fixes >>> problem? >>> ?If it does, I'll figure out how to detect rpi3 at runtime and set >>> the >>> sizes properly. >>> >>> -- Ian >>> >>> Index: sys/dev/uart/uart_dev_pl011.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/dev/uart/uart_dev_pl011.c (revision 314917) >>> +++ sys/dev/uart/uart_dev_pl011.c (working copy) >>> @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) >>> is_bcm2835 =3D ofw_bus_is_compatible(sc->sc_dev, >>> "brcm,bcm2835-pl011") || >>> ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835- >>> uart"); >>> #else >>> - is_bcm2835 =3D false; >>> + is_bcm2835 =3D true; >>> #endif >>> hwrev =3D __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; >>> if (hwrev <=3D 2 || is_bcm2835) { >> Sure. I'll report back either tonight or tomorrow. >> >> Thanks, >> > Actually, I think a proper solution will be something like the attached= > patch. After some spelunking on the web I think the rpi3 fifos are the= > smaller size because the fdt data contains the linux-style workaround > (which overrides the primecell periphid value with fdt data). This > patch looks for that in addition to looking for the rpi compatible > strings (still required to handle old-style freebsd fdt data). > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I can build for and test both the RPI2 and 3 if you'd like on serial console; I have both sitting here on my workbench. Just tell me which rev to check out and what to patch on it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020604080404060700000807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMTExOTE5MTZaME8GCSqGSIb3DQEJBDFCBEC7U0Gp yQsAlpNmf0Tfpoa5eiv0AK1yFl/+GJ092Djhevu8qzvqaotueW9peRHZyBLFVvdbn03mGz3q 3pSwG9v6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAbWv5SPKl65Iz osJJXgWokLgnGVHag/l3tt2qaRSSnjrI7eBihXBgBV0mLN+M8gnFpjNZ69by4+qXndPD6Qy1 hUQqA1B3X+LbPI1jnbFyvB0jF68BQ617BKe/HNlfIOdNKIHS/70PY0bnm4u1fr7DaW60MiZ1 tAaEjYv+giHS53smpDGnonIUO4mANIrdgwonYlif58OzvKQ+rNBCR0pNSnEutmeP9aEUIsJm pWD/3kHiyqsIPGVkrP2Zl75g6N7z16ScJX8A+Rm3fcY48uQdKPov5IMzU5qI/lu5OmLxS0xP QM+rGlUDNJueZ419O1X7R8rH/Fnc8tD1PukEnRTJRpa5M0jBIS9al5yGaC75MdrDbWumIxAy eVlfCOfvmW8V/sbudvE5+UlFec6GmfrRWWpSfkG91QYCX450URNGDMN+95M7+IvRWKQudPsj v82b/9pPXfsDX18BoCa8eX2LdsWc+auNtL+ZX9zhfxfXnr5OULl4nAiR0YvAZ9k5Z0tBCOYH e1lJpDE10Uz/gy5CT5GlSgKwy+/rbU1s4Ri8tx/cGRgoKHlXKoq8t5Ct7Gju63tfbHFA4gVg w4CVkXn/k3qMYqsLRwZs/hTc9393vkrFylXyTu1vd4sCfa81Bua7SlIrQMEcShMp0bU8OGY/ pom3Ou13e44n23FjZ6PhV4AAAAAAAAA= --------------ms020604080404060700000807-- From owner-freebsd-arm@freebsd.org Sat Mar 11 21:37:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59878D08DE4 for ; Sat, 11 Mar 2017 21:37:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 010C1189E for ; Sat, 11 Mar 2017 21:37:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22e.google.com with SMTP id x35so11032666qtc.2 for ; Sat, 11 Mar 2017 13:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8AQXB4KQftoN9fIZNh9rYakSNbzVY6Q13X28n5o1Whg=; b=0jXZnE+B622+Ie9f9mNKjoUFkNrbYUsEX3OqKATVtk40dVAtwLOPvyC17qU3ThIxUV QYqGUZhVtIYXO0cwNhPmid/8CqRJpZB0sIoDVVj5ArW5bVAvvFKyGio6REj0Rp0mP5UC RdBi/E9w2zazkCHA4Yg7v6Y5SMbpRrUPjDgOvqo0dYqmthr9Mq0SuRugBoAaF8RQv6s7 fB5cC+/mXfr/xytsTKKHDjwNrnM6hrTB2JBjuVY/Kc/LvoJG4nPxS3xvL9CoyQAijwu7 bDWzxCt6L9iL5OTNeKYUFfWRtEcj4xHbxn3zYZRCpLvBbotLV7W53E9j/2E465NHu6Mn gJSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8AQXB4KQftoN9fIZNh9rYakSNbzVY6Q13X28n5o1Whg=; b=igc1a0yFbXcSzV9k08G4hE3AyNbRQ3G23RHU7mxzLYvhponseeG+HIWQAZ5P1FmI22 zNJPWun0JKT1eUCmfTJdNqe/Psgd2u3dayjcVFCFt101G8Pv6bYqSgC6cPMXvBmEIkst uijYU54BTsvXF2A3Sr0fyZopYnGs4w3NFWoYCVOnGXKozPfuo5u73nl1YQLXsswrJhUF d/J/W+eAkLIDH3NmeQSE/tnb1ndKF9c8PYTfK59vLinI4KDq9lNSh47Q1X6ZEvEfUsy1 2aXxoa7l0YQzbYz2+esvdzb8TqPYwsOBOmBAJUh+l5cuwTKoNPPQSouB4IfZM30le4+G Auiw== X-Gm-Message-State: AMke39kK7aItPuIuKZEvlAsRGZQqN3e1oI0ZtsbN2rNKQXquLT20JlrPYhfYIB0ssnE+gqVV X-Received: by 10.237.62.176 with SMTP id n45mr27795798qtf.39.1489268267071; Sat, 11 Mar 2017 13:37:47 -0800 (PST) Received: from mutt-hbsd (pool-100-16-218-40.bltmmd.fios.verizon.net. [100.16.218.40]) by smtp.gmail.com with ESMTPSA id 27sm9034543qkx.3.2017.03.11.13.37.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 Mar 2017 13:37:46 -0800 (PST) Date: Sat, 11 Mar 2017 16:37:45 -0500 From: Shawn Webb To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: Odd-looking serial console prompt on RPI2 Message-ID: <20170311213745.eyn6kh26f76c2qu4@mutt-hbsd> References: <1488420309.60166.32.camel@freebsd.org> <1488664965.69705.24.camel@freebsd.org> <20170307190937.r7n45xj67tnhevv4@mutt-hbsd> <20170307192918.2garie2ow6lzekg7@mutt-hbsd> <20170311174940.bze4k7ndjdemmu4l@mutt-hbsd> <1489255444.40576.57.camel@freebsd.org> <20170311180947.ro5obisuaemvudkp@mutt-hbsd> <1489259878.40576.62.camel@freebsd.org> <20170311191926.le5ort7zdinxwppz@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gtbwqqbx4jbaqj5u" Content-Disposition: inline In-Reply-To: <20170311191926.le5ort7zdinxwppz@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 21:37:48 -0000 --gtbwqqbx4jbaqj5u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 11, 2017 at 02:19:26PM -0500, Shawn Webb wrote: > On Sat, Mar 11, 2017 at 12:17:58PM -0700, Ian Lepore wrote: > > On Sat, 2017-03-11 at 13:09 -0500, Shawn Webb wrote: > > > On Sat, Mar 11, 2017 at 11:04:04AM -0700, Ian Lepore wrote: > > > >=20 > > > > On Sat, 2017-03-11 at 12:49 -0500, Shawn Webb wrote: > > > > >=20 > > > > > On Tue, Mar 07, 2017 at 02:29:18PM -0500, Shawn Webb wrote: > > > > > >=20 > > > > > >=20 > > > > > > On Tue, Mar 07, 2017 at 02:09:37PM -0500, Shawn Webb wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > On Sat, Mar 04, 2017 at 03:02:45PM -0700, Ian Lepore wrote: > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > The bugs should be fixed as of r314682. ?It looks like the > > > > > > > > bugs > > > > > > > > have > > > > > > > > long been in the pl011 driver, but were masked by having a > > > > > > > > fifo > > > > > > > > depth > > > > > > > > of 1 byte -- it all sorta worked by accident previously. > > > > > > > Thanks for the fix! But it looks to be only partial. When I > > > > > > > connect to > > > > > > > the serial console via either cu or screen, I don't get > > > > > > > corrupted > > > > > > > text, > > > > > > > but no keypresses are registered. Hitting enter at the login > > > > > > > prompt does > > > > > > > absolutely nothing. I'm at the latest commit of > > > > > > > hardened/current/master > > > > > > > on HardenedBSD for both the RPI3 and my laptop. > > > > > > >=20 > > > > > > > I'm using this serial cable from Adafruit: > > > > > > > https://www.adafruit.com/product/954 > > > > > > It looks like I had a bad cable. Sorry for the line noise. > > > > > > Switching to > > > > > > a different cable worked. > > > > > Looks like the problem is back, but manifest in a different way. > > > > > Screenshot: > > > > >=20 > > > > > https://goo.gl/photos/XYx6v1jCTVCGrnhd6 > > > > >=20 > > > > > Thanks, > > > > >=20 > > > > I wonder if rpi3 needs the same smaller-fifo fix as a 32-bit rpi. > > > > ?Just > > > > to test that theory, can you see if the attached patch fixes > > > > problem? > > > > ?If it does, I'll figure out how to detect rpi3 at runtime and set > > > > the > > > > sizes properly. > > > >=20 > > > > -- Ian > > > >=20 > > > > Index: sys/dev/uart/uart_dev_pl011.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- sys/dev/uart/uart_dev_pl011.c (revision 314917) > > > > +++ sys/dev/uart/uart_dev_pl011.c (working copy) > > > > @@ -464,7 +464,7 @@ uart_pl011_bus_probe(struct uart_softc *sc) > > > > ? is_bcm2835 =3D ofw_bus_is_compatible(sc->sc_dev, > > > > "brcm,bcm2835-pl011") || > > > > ? ????ofw_bus_is_compatible(sc->sc_dev, "broadcom,bcm2835- > > > > uart"); > > > > ?#else > > > > - is_bcm2835 =3D false; > > > > + is_bcm2835 =3D true; > > > > ?#endif > > > > ? hwrev =3D __uart_getreg(&sc->sc_bas, UART_PIDREG_2) >> 4; > > > > ? if (hwrev <=3D 2 || is_bcm2835) { > > > Sure. I'll report back either tonight or tomorrow. > > >=20 > > > Thanks, > > >=20 > >=20 > > Actually, I think a proper solution will be something like the attached > > patch. ?After some spelunking on the web I think the rpi3 fifos are the > > smaller size because the fdt data contains the linux-style workaround > > (which overrides the primecell periphid value with fdt data). ?This > > patch looks for that in addition to looking for the rpi compatible > > strings (still required to handle old-style freebsd fdt data). > >=20 > > -- Ian >=20 > Cool. I'll give that patch a shot soon. The second revision patch worked beautifully. Thank you very much! --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --gtbwqqbx4jbaqj5u Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAljEbicACgkQaoRlj1JF bu6XCxAAoR+sRYJ9tkfPWjGusLCvVmamlXxsiuw6ZfAzssaOvMDeh2jhA8AgoK8g xM92Tn7pE+H1/dJpq6W2sQuwmp3rnkUKDSk/zw3xymjCWBeq8jS4m5OrkxJiYiy+ +zt+rmQ10IoW6Q+eoZBTRZXinnNXp7kVdeWTs/pMeEK+HkU4pjTrPbsWoXB3V0wo wo43+BjWRE9Gen/ZxUnVXNDVMOEsdP2rUmuVDZfbG8e4iEESNuIVQVhk9Lx/I7G5 47K3cp1LzMdmdWtM8DmXs6XCRYdbT9Iy7eTJJdLDn9A2kUY/teLaIdBvqWu19pKM Hb/2APiPVgl2fkBnssi+uiSE6efBWB0RdcpDVnov6nDL7EKwKdqirUrjGRytbTFb hXu5Bw9g12ILiCANzfaYuXlVYkdoDRfMPByu3EPFKJLnfIhWzpJnZC6KNYCa5lrw nWy/q+hI07pQjepIsZtCML8PvJC398d5Gy7bt4/Y0s+Ma/+fpCEF/ZydFRYd2tiL 25ZF0N/+D2sonauARhSYFuUUr1Wwc5bKaRlUgBgut+tGgrZaUf7senO7PwnTf+VQ ZQmJd4TSPpK2KSs8+GaJ1ibaKgfhChVtNuA0s/mD+0l3ybUtXsqTGqVWwt9adSQD IGZg5P0jEzlQ6X8esKuNfexxt8h8L0j4GsSxIlxG/EGKWeMMqA8= =WHyw -----END PGP SIGNATURE----- --gtbwqqbx4jbaqj5u--