From owner-freebsd-arm@freebsd.org Sun Nov 26 11:47: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 B8F83DC15C1 for ; Sun, 26 Nov 2017 11:47:30 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56ACC687C2 for ; Sun, 26 Nov 2017 11:47:29 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 26 Nov 2017 12:42:17 +0100 id 00DE187E.5A1AA899.0000CC3E Date: Sun, 26 Nov 2017 12:42:17 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Allwinner H3/H2+ dts question - regression? Message-ID: <20171126124217.2a512392@zeta.dino.sk> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; i386-portbld-freebsd10.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 11:47:30 -0000 Hi, after some time I am playing a bit again with my Allwinner H3/H2+ based boards. First I crossbuild world and kernel using svn rev. 324530, after trying to upgrade older armv6 to current armv7 with no success, put them on micro SD card and tested it. I found there are some dtb's for this SOC, but none worked well. I tested ethernet, USB and thermal devices. Ethernet worked only with sun8i-h3-nanopi-neo.dtb, but using it USB did not work. Then I upgraded sources to svn rev. 326187 and built new kernel natively. While resulting kernel loads, none of dtb's provided have ethernet working. Using nanopi-neo.dtb from old revision, originally identical with sun8i-h3-nanopi-neo.dtb, provides me again with working ethernet. This raises a question what changed with dts sources and why we have no stable working dts... By the way, I am using GENERIC-NOCTF-NOINET6 kernel (plain GENERIC, just with CTF and INET6 options removed), currently on Orange Pi Zero and Orange Pi R1 boards, the later being almost identical with the former, just there is second USB connected ethernet port instead of usual USB port, and changed wifi module, which does not works for us anyway. I looked over our sources and could not find any definition of emac for Allwinner H3/H2+ SoC. Is it just me or is it really somehow lost? One more question, loosely related - how does one build dtb file? I mean, I know I can just invoke 'make buildkernel -DNO_CLEAN' and all dtb's for boards defined in makefile will be created. However, I think it is handy to do it on board tested, because you can simply stop u-boot, type env set fdtfile sun8i-h2-plus-orangepi-zero.dtb;boot and test new definition. Reboot is quick on Allwinner board I have, but 'make buildkernel -DNO_CLEAN' takes ~ 3 minutes, additionally, your dts needs to be mentioned in Makefile. I found it is actually done with /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys sun8i-h2-plus-orangepi-zero.dts /usr/obj/usr/src/arm.armv7/sys/GENERIC-NOCTF-NOINET6/modules/usr/src/sys/modules/dtb/allwinner (in one line) invoked from some make command, but this does not give me exactly the same result, probably environment differs. dtb file created this way is larger than one produced with 'make buildkernel' command, there are some fixups added. No idea whether it does any harm or not. From owner-freebsd-arm@freebsd.org Mon Nov 27 04:45: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 51D61DF8B95 for ; Mon, 27 Nov 2017 04:45:43 +0000 (UTC) (envelope-from eval@iptk.ru) Received: from newmail.iptk.ru (newmail.iptk.ru [IPv6:2a00:d8c0:0:2:215:60ff:feed:ebc8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.iptk.ru", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDC14634EF for ; Mon, 27 Nov 2017 04:45:42 +0000 (UTC) (envelope-from eval@iptk.ru) Received: from localhost (localhost [127.0.0.1]) by newmail.iptk.ru (Postfix) with SMTP id 5D9DC1B0066A for ; Mon, 27 Nov 2017 08:45:27 +0400 (+04) Received: from HP7320 (unknown [IPv6:2a00:d8c0:0:1:9885:68d4:8a50:284c]) by newmail.iptk.ru (Postfix) with ESMTPA id CBD7A1B000A4; Mon, 27 Nov 2017 08:45:26 +0400 (+04) Date: Mon, 27 Nov 2017 08:43:55 +0400 From: Eugene Sevastyanov To: freebsd-arm@freebsd.org Subject: Re: Allwinner H3/H2+ dts question - regression? Message-Id: <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> In-Reply-To: <20171126124217.2a512392@zeta.dino.sk> References: <20171126124217.2a512392@zeta.dino.sk> Reply-To: eval@iptk.ru Organization: IPTelecom Ltd. X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.23; i686-pc-mingw32) Mime-Version: 1.0 X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 27 08:45:27 2017 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5a1b986714692524516841 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 04:45:43 -0000 Hi, Faced with exactly the same problem. Installed FreeBSD on the Orange Pi Zero board, but in the regular dts there is no description for emac. So I wrote my dts, partly taking information from the native file, and partly from Linux. To avoid rebuilding the whole kernel for the compilation of dtb, I created a separate project. In the attached archive, the project with the original dts and the received dtb for Orange Pi Zero. In fact, this is a copy of the structure of the native FreeBSD source tree with only the necessary files for DTS compilation. The script arm.sh takes care of all the work on creating a bootable flash drive. Uncomment there only the necessary sections. The script DOES NOT COPY the resulting dtb on the USB flash drive, be careful. > Hi, > > after some time I am playing a bit again with my Allwinner H3/H2+ based > boards. First I crossbuild world and kernel using svn rev. 324530, > after trying to upgrade older armv6 to current armv7 with no success, > put them on micro SD card and tested it. I found there are some dtb's > for this SOC, but none worked well. I tested ethernet, USB and thermal > devices. Ethernet worked only with sun8i-h3-nanopi-neo.dtb, but using > it USB did not work. > > Then I upgraded sources to svn rev. 326187 and built new kernel > natively. While resulting kernel loads, none of dtb's provided have > ethernet working. Using nanopi-neo.dtb from old revision, originally > identical with sun8i-h3-nanopi-neo.dtb, provides me again with working > ethernet. > > This raises a question what changed with dts sources and why we have no > stable working dts... By the way, I am using GENERIC-NOCTF-NOINET6 > kernel (plain GENERIC, just with CTF and INET6 options removed), > currently on Orange Pi Zero and Orange Pi R1 boards, the later being > almost identical with the former, just there is second USB > connected ethernet port instead of usual USB port, and changed wifi > module, which does not works for us anyway. > > I looked over our sources and could not find any definition of emac for > Allwinner H3/H2+ SoC. Is it just me or is it really somehow lost? > > One more question, loosely related - how does one build dtb file? I > mean, I know I can just invoke 'make buildkernel -DNO_CLEAN' and all > dtb's for boards defined in makefile will be created. However, I think > it is handy to do it on board tested, because you can simply stop > u-boot, type > > env set fdtfile sun8i-h2-plus-orangepi-zero.dtb;boot > > and test new definition. Reboot is quick on Allwinner board I have, but > 'make buildkernel -DNO_CLEAN' takes ~ 3 minutes, additionally, your dts > needs to be mentioned in Makefile. I found it is actually done with > > /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys sun8i-h2-plus-orangepi-zero.dts /usr/obj/usr/src/arm.armv7/sys/GENERIC-NOCTF-NOINET6/modules/usr/src/sys/modules/dtb/allwinner > > (in one line) invoked from some make command, but this does not give me > exactly the same result, probably environment differs. dtb file created > this way is larger than one produced with 'make buildkernel' command, > there are some fixups added. No idea whether it does any harm or not. > > _______________________________________________ > 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" > > From owner-freebsd-arm@freebsd.org Mon Nov 27 06:28:16 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 6F1C1DFA3F9 for ; Mon, 27 Nov 2017 06:28:16 +0000 (UTC) (envelope-from eval@iptk.ru) Received: from newmail.iptk.ru (newmail.iptk.ru [83.217.3.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.iptk.ru", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3A2865C99 for ; Mon, 27 Nov 2017 06:28:15 +0000 (UTC) (envelope-from eval@iptk.ru) Received: from localhost (localhost [127.0.0.1]) by newmail.iptk.ru (Postfix) with SMTP id 89EFA1B00666 for ; Mon, 27 Nov 2017 10:28:09 +0400 (+04) Received: from HP7320 (unknown [IPv6:2a00:d8c0:0:1:9885:68d4:8a50:284c]) by newmail.iptk.ru (Postfix) with ESMTPA id 4189F1B00084 for ; Mon, 27 Nov 2017 10:28:09 +0400 (+04) Date: Mon, 27 Nov 2017 10:26:37 +0400 From: Eugene Sevastyanov To: freebsd-arm@freebsd.org Subject: Re: Allwinner H3/H2+ dts question - regression? Message-Id: <20171127102637.3340c8a8df935b8bec3a4312@iptk.ru> In-Reply-To: <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> References: <20171126124217.2a512392@zeta.dino.sk> <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> Reply-To: eval@iptk.ru Organization: IPTelecom Ltd. X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.23; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 27 10:28:09 2017 X-DSPAM-Confidence: 0.9960 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5a1bb07914691430116795 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 06:28:16 -0000 Sorry, attachments are not allowed. To whom it is interesting, the archive can be downloaded from http://opi.iptk.ru/OrangePi.tgz > Hi, > > Faced with exactly the same problem. Installed FreeBSD on the Orange Pi Zero board, but in the regular dts there is no description for emac. So I wrote my dts, partly taking information from the native file, and partly from Linux. > To avoid rebuilding the whole kernel for the compilation of dtb, I created a separate project. In the attached archive, the project with the original dts and the received dtb for Orange Pi Zero. In fact, this is a copy of the structure of the native FreeBSD source tree with only the necessary files for DTS compilation. > The script arm.sh takes care of all the work on creating a bootable flash drive. Uncomment there only the necessary sections. The script DOES NOT COPY the resulting dtb on the USB flash drive, be careful. > > > Hi, > > > > after some time I am playing a bit again with my Allwinner H3/H2+ based > > boards. First I crossbuild world and kernel using svn rev. 324530, > > after trying to upgrade older armv6 to current armv7 with no success, > > put them on micro SD card and tested it. I found there are some dtb's > > for this SOC, but none worked well. I tested ethernet, USB and thermal > > devices. Ethernet worked only with sun8i-h3-nanopi-neo.dtb, but using > > it USB did not work. > > > > Then I upgraded sources to svn rev. 326187 and built new kernel > > natively. While resulting kernel loads, none of dtb's provided have > > ethernet working. Using nanopi-neo.dtb from old revision, originally > > identical with sun8i-h3-nanopi-neo.dtb, provides me again with working > > ethernet. > > > > This raises a question what changed with dts sources and why we have no > > stable working dts... By the way, I am using GENERIC-NOCTF-NOINET6 > > kernel (plain GENERIC, just with CTF and INET6 options removed), > > currently on Orange Pi Zero and Orange Pi R1 boards, the later being > > almost identical with the former, just there is second USB > > connected ethernet port instead of usual USB port, and changed wifi > > module, which does not works for us anyway. > > > > I looked over our sources and could not find any definition of emac for > > Allwinner H3/H2+ SoC. Is it just me or is it really somehow lost? > > > > One more question, loosely related - how does one build dtb file? I > > mean, I know I can just invoke 'make buildkernel -DNO_CLEAN' and all > > dtb's for boards defined in makefile will be created. However, I think > > it is handy to do it on board tested, because you can simply stop > > u-boot, type > > > > env set fdtfile sun8i-h2-plus-orangepi-zero.dtb;boot > > > > and test new definition. Reboot is quick on Allwinner board I have, but > > 'make buildkernel -DNO_CLEAN' takes ~ 3 minutes, additionally, your dts > > needs to be mentioned in Makefile. I found it is actually done with > > > > /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys sun8i-h2-plus-orangepi-zero.dts /usr/obj/usr/src/arm.armv7/sys/GENERIC-NOCTF-NOINET6/modules/usr/src/sys/modules/dtb/allwinner > > > > (in one line) invoked from some make command, but this does not give me > > exactly the same result, probably environment differs. dtb file created > > this way is larger than one produced with 'make buildkernel' command, > > there are some fixups added. No idea whether it does any harm or not. > > From owner-freebsd-arm@freebsd.org Mon Nov 27 06:59: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 3D1D0DFABED for ; Mon, 27 Nov 2017 06:59:08 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8A1766A99 for ; Mon, 27 Nov 2017 06:59:06 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Mon, 27 Nov 2017 07:59:03 +0100 id 00DE187E.5A1BB7B7.00014621 Date: Mon, 27 Nov 2017 07:59:03 +0100 From: Milan Obuch To: Eugene Sevastyanov Cc: freebsd-arm@freebsd.org Subject: Re: Allwinner H3/H2+ dts question - regression? Message-ID: <20171127075903.1ce9c40e@zeta.dino.sk> In-Reply-To: <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> References: <20171126124217.2a512392@zeta.dino.sk> <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; i386-portbld-freebsd10.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 06:59:08 -0000 On Mon, 27 Nov 2017 08:43:55 +0400 Eugene Sevastyanov wrote: > Hi, > > Faced with exactly the same problem. Installed FreeBSD on the Orange > Pi Zero board, but in the regular dts there is no description for > emac. So I wrote my dts, partly taking information from the native > file, and partly from Linux. To avoid rebuilding the whole kernel for > the compilation of dtb, I created a separate project. In the attached > archive, the project with the original dts and the received dtb for > Orange Pi Zero. In fact, this is a copy of the structure of the > native FreeBSD source tree with only the necessary files for DTS > compilation. The script arm.sh takes care of all the work on creating > a bootable flash drive. Uncomment there only the necessary sections. > The script DOES NOT COPY the resulting dtb on the USB flash drive, be > careful. > Thank you, this helps a lot. I began to investigate the differences among various dtb's I have with some parts of system working and some not to suit my needs. As I am testing dtb provided by you, I see there is not aw_thermal working. On the positive side, both ethernet and usb are working, so I need just try to compile the dts myself to verify the process. One more question - do you have some devices connected to your board? I would like to know other people's experience attaching sensors and similar gadgets. Regards, Milan From owner-freebsd-arm@freebsd.org Mon Nov 27 07:28: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 818A3DFB0C6 for ; Mon, 27 Nov 2017 07:28:40 +0000 (UTC) (envelope-from eval@iptk.ru) Received: from newmail.iptk.ru (newmail.iptk.ru [IPv6:2a00:d8c0:0:2:215:60ff:feed:ebc8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.iptk.ru", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A313673CE for ; Mon, 27 Nov 2017 07:28:39 +0000 (UTC) (envelope-from eval@iptk.ru) Received: from localhost (localhost [127.0.0.1]) by newmail.iptk.ru (Postfix) with SMTP id BA6821B0066A for ; Mon, 27 Nov 2017 11:28:34 +0400 (+04) Received: from HP7320 (unknown [IPv6:2a00:d8c0:0:1:9885:68d4:8a50:284c]) by newmail.iptk.ru (Postfix) with ESMTPA id 41B9F1B000A4; Mon, 27 Nov 2017 11:28:34 +0400 (+04) Date: Mon, 27 Nov 2017 11:27:02 +0400 From: Eugene Sevastyanov To: Milan Obuch Cc: freebsd-arm@freebsd.org Subject: Re: Allwinner H3/H2+ dts question - regression? Message-Id: <20171127112702.7b945be0138484b05e517d49@iptk.ru> In-Reply-To: <20171127075903.1ce9c40e@zeta.dino.sk> References: <20171126124217.2a512392@zeta.dino.sk> <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> <20171127075903.1ce9c40e@zeta.dino.sk> Reply-To: eval@iptk.ru Organization: IPTelecom Ltd. X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.23; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 27 11:28:34 2017 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5a1bbea214691523687078 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 07:28:40 -0000 Currently, I'm trying to run a DS3231 real-time controller board. There are problems with I2C, but I'm still looking for a reason. At the moment, I checked the transmission protocol with an oscilloscope and made sure that the RTC is responding, i.e. ds3231 exactly working. However, the driver does not see the ACK signal sent by the device after sending the address. I continue to investigate this moment ... About aw_thermal - if you have a dts file where it is described, it can easily be added to my. This would be a useful feature for Zero. P.S. I installed on Orange Pi Zero FreeBSD 12.0-CURRENT > On Mon, 27 Nov 2017 08:43:55 +0400 > Eugene Sevastyanov wrote: > > > Hi, > > > > Faced with exactly the same problem. Installed FreeBSD on the Orange > > Pi Zero board, but in the regular dts there is no description for > > emac. So I wrote my dts, partly taking information from the native > > file, and partly from Linux. To avoid rebuilding the whole kernel for > > the compilation of dtb, I created a separate project. In the attached > > archive, the project with the original dts and the received dtb for > > Orange Pi Zero. In fact, this is a copy of the structure of the > > native FreeBSD source tree with only the necessary files for DTS > > compilation. The script arm.sh takes care of all the work on creating > > a bootable flash drive. Uncomment there only the necessary sections. > > The script DOES NOT COPY the resulting dtb on the USB flash drive, be > > careful. > > > > Thank you, this helps a lot. I began to investigate the differences > among various dtb's I have with some parts of system working and some > not to suit my needs. > > As I am testing dtb provided by you, I see there is not aw_thermal > working. On the positive side, both ethernet and usb are working, so I > need just try to compile the dts myself to verify the process. > > One more question - do you have some devices connected to your board? I > would like to know other people's experience attaching sensors and > similar gadgets. > > Regards, > Milan > > From owner-freebsd-arm@freebsd.org Mon Nov 27 14:26:44 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 54596E52622 for ; Mon, 27 Nov 2017 14:26:44 +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 3AB3473131 for ; Mon, 27 Nov 2017 14:26:44 +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 vAREQi14067720 for ; Mon, 27 Nov 2017 14:26:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223906] arm64 kassert failure on boot in efi_create_1t1_map Date: Mon, 27 Nov 2017 14:26:44 +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 Only Me X-Bugzilla-Who: emaste@freebsd.org 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:26:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223906 Bug ID: 223906 Summary: arm64 kassert failure on boot in efi_create_1t1_map Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org --- Kernel configuration --- include GENERIC ident PACKET nooptions VIMAGE options ALT_BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC ------- Panic on boot, 2-socket 96-core ThunderX at packet.net: FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs random: unblocking device. MAP 500000 mode 2 pages 2048 MAP fffec000 mode 2 pages 20 MAP 10ffe7b9000 mode 2 pages 3071 MAP 10fff3b8000 mode 2 pages 3143 MAP 803000000000 mode 1 pages 4096 MAP 804000001000 mode 1 pages 8192 MAP 87e006001000 mode 1 pages 4096 MAP 87e024000000 mode 1 pages 4096 MAP 87e0d0001000 mode 1 pages 1 MAP 903000000000 mode 1 pages 4096 MAP 904000001000 mode 1 pages 8192 MAP 97e006001000 mode 1 pages 4096 panic: efi_1t1_l3: Already mapped: va 0x97e006400000 *pt 0x87e007000707 cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005f2b08 lr =3D 0xffff000000087048 sp =3D 0xffff000000010710 fp =3D 0xffff000000010920 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000087048 lr =3D 0xffff000000316934 sp =3D 0xffff000000010930 fp =3D 0xffff0000000109b0 vpanic() at kassert_panic+0x158 pc =3D 0xffff000000316934 lr =3D 0xffff0000003167ac sp =3D 0xffff0000000109c0 fp =3D 0xffff000000010a80 kassert_panic() at efi_create_1t1_map+0x26c pc =3D 0xffff0000003167ac lr =3D 0xffff0000005f44a0 sp =3D 0xffff000000010a90 fp =3D 0xffff000000010b00 efi_create_1t1_map() at efirt_modevents+0x100 pc =3D 0xffff0000005f44a0 lr =3D 0xffff0000000ca6e4 sp =3D 0xffff000000010b10 fp =3D 0xffff000000010b20 efirt_modevents() at module_register_init+0xc8 pc =3D 0xffff0000000ca6e4 lr =3D 0xffff0000002f6654 sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 module_register_init() at mi_startup+0xc8 pc =3D 0xffff0000002f6654 lr =3D 0xffff0000002b4848 sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002b4848 lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at 0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Nov 27 14:27: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 38F9DE527A2 for ; Mon, 27 Nov 2017 14:27:29 +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 98F4873238 for ; Mon, 27 Nov 2017 14:27:28 +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 d0c7b688; Mon, 27 Nov 2017 15:27:25 +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=JQDmv4mi1m9T0zonLRCMq2Ov5xA=; b=Px47NYIyIJJcYMvghj5wNgCU9UaV 4JxYAL4bBawd2DW6SNYLBVpaiRYCJ8sOfJkQ5R5jpDhV4aNL1V72dHeF9AZGDE0k ztOPnbVBLBSWtryj5LATOAxWLbhZrFWdavwHzi6oGLsNux2zRXzoZBiKNAtJ9l6F Nio4K3DsxN7QEzg= 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=X9o4qk1WWHprdAaSBnnZSgOoBG3tHEN4KeLuSbEhLr9IwPHAic+CbzGu gDbGioTIeqoHh1a4URuhNNpBL7zwv7G6t4fnF8qUl8Mzp4yIbPIafsLWmJWGjnLn 1dPZrz08S8O0QTEJ0uE/wRh6mA7auf5lynDT/vxZ2oXizas4T9c= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6ab1ea0c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 27 Nov 2017 15:27:25 +0100 (CET) Date: Mon, 27 Nov 2017 15:27:24 +0100 From: Emmanuel Vadot To: Milan Obuch Cc: freebsd-arm@freebsd.org Subject: Re: Allwinner H3/H2+ dts question - regression? Message-Id: <20171127152724.679688f6189f27718d76344c@bidouilliste.com> In-Reply-To: <20171126124217.2a512392@zeta.dino.sk> References: <20171126124217.2a512392@zeta.dino.sk> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:27:29 -0000 On Sun, 26 Nov 2017 12:42:17 +0100 Milan Obuch wrote: > Hi, > > after some time I am playing a bit again with my Allwinner H3/H2+ based > boards. First I crossbuild world and kernel using svn rev. 324530, > after trying to upgrade older armv6 to current armv7 with no success, > put them on micro SD card and tested it. I found there are some dtb's > for this SOC, but none worked well. I tested ethernet, USB and thermal > devices. Ethernet worked only with sun8i-h3-nanopi-neo.dtb, but using > it USB did not work. > > Then I upgraded sources to svn rev. 326187 and built new kernel > natively. While resulting kernel loads, none of dtb's provided have > ethernet working. Using nanopi-neo.dtb from old revision, originally > identical with sun8i-h3-nanopi-neo.dtb, provides me again with working > ethernet. This is because emac isn't yet standardized, it will have a stable binding in dts from Linux 4.15 > This raises a question what changed with dts sources and why we have no > stable working dts... By the way, I am using GENERIC-NOCTF-NOINET6 > kernel (plain GENERIC, just with CTF and INET6 options removed), > currently on Orange Pi Zero and Orange Pi R1 boards, the later being > almost identical with the former, just there is second USB > connected ethernet port instead of usual USB port, and changed wifi > module, which does not works for us anyway. We have stable DTS, at least in the same "stable" definition as in Linux mainline. > I looked over our sources and could not find any definition of emac for > Allwinner H3/H2+ SoC. Is it just me or is it really somehow lost? We have the driver which work well on pine64 and also on H3, we just need to wait for dts from Linux 4.15 > One more question, loosely related - how does one build dtb file? I > mean, I know I can just invoke 'make buildkernel -DNO_CLEAN' and all > dtb's for boards defined in makefile will be created. However, I think > it is handy to do it on board tested, because you can simply stop > u-boot, type > > env set fdtfile sun8i-h2-plus-orangepi-zero.dtb;boot > > and test new definition. Reboot is quick on Allwinner board I have, but > 'make buildkernel -DNO_CLEAN' takes ~ 3 minutes, additionally, your dts > needs to be mentioned in Makefile. I found it is actually done with > > /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys sun8i-h2-plus-orangepi-zero.dts /usr/obj/usr/src/arm.armv7/sys/GENERIC-NOCTF-NOINET6/modules/usr/src/sys/modules/dtb/allwinner > > (in one line) invoked from some make command, but this does not give me > exactly the same result, probably environment differs. dtb file created > this way is larger than one produced with 'make buildkernel' command, > there are some fixups added. No idea whether it does any harm or not. Maybe you do not use the same dtc than buildkernel. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Nov 27 14:29:16 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 E62FBE528DD for ; Mon, 27 Nov 2017 14:29:16 +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 7B34E73393 for ; Mon, 27 Nov 2017 14:29:16 +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 f814f692; Mon, 27 Nov 2017 15:29:13 +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=Vs05tBn7rCb9q+rzwa7mbnMHWH4=; b=KaMUMLpA5mI29ilBuqbmw42+lgJP 4FCHvMD/Hp11Psuk3RfEI9bgN8Bd+Y11EYXoQ21XASe55VbudeNOKh4K9ts2aiGv 7lcrJWB9laZzbjMpIJ9xgeBBdql/Zz72SoHYioiyRBNP9WLw30d/QG+iLaDZtowv ztCSWEXeGrt1/qs= 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=icuhdDcoLXGEplHchy1WLpGlWBLHtBpe9gYoLKW7g7RRzIiAI/O6U7qY oK6Zxwtif6gsGRZFbvw0EEKcXQW0zExaNboIgfM9hBpGx7cdUYisuuJ42nmiO7LK 4sQl7GQHvnpxvBrJ6WBOXU8fH6Huv/ouE0uyJm3I+rMUgCamhH4= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 2d7f81ba TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 27 Nov 2017 15:29:13 +0100 (CET) Date: Mon, 27 Nov 2017 15:29:13 +0100 From: Emmanuel Vadot To: eval@iptk.ru Cc: Milan Obuch , freebsd-arm@freebsd.org Subject: Re: Allwinner H3/H2+ dts question - regression? Message-Id: <20171127152913.edbae8034abdbc65002ab027@bidouilliste.com> In-Reply-To: <20171127112702.7b945be0138484b05e517d49@iptk.ru> References: <20171126124217.2a512392@zeta.dino.sk> <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> <20171127075903.1ce9c40e@zeta.dino.sk> <20171127112702.7b945be0138484b05e517d49@iptk.ru> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:29:17 -0000 On Mon, 27 Nov 2017 11:27:02 +0400 Eugene Sevastyanov wrote: > Currently, I'm trying to run a DS3231 real-time controller board. There are problems with I2C, but I'm still looking for a reason. At the moment, I checked the transmission protocol with an oscilloscope and made sure that the RTC is responding, i.e. ds3231 exactly working. However, the driver does not see the ACK signal sent by the device after sending the address. I continue to investigate this moment ... > > About aw_thermal - if you have a dts file where it is described, it can easily be added to my. This would be a useful feature for Zero. I suggest to everyone writing "custom dts" to upstream their patches to Linux, the situation will be much better that way. > P.S. > I installed on Orange Pi Zero FreeBSD 12.0-CURRENT > > > On Mon, 27 Nov 2017 08:43:55 +0400 > > Eugene Sevastyanov wrote: > > > > > Hi, > > > > > > Faced with exactly the same problem. Installed FreeBSD on the Orange > > > Pi Zero board, but in the regular dts there is no description for > > > emac. So I wrote my dts, partly taking information from the native > > > file, and partly from Linux. To avoid rebuilding the whole kernel for > > > the compilation of dtb, I created a separate project. In the attached > > > archive, the project with the original dts and the received dtb for > > > Orange Pi Zero. In fact, this is a copy of the structure of the > > > native FreeBSD source tree with only the necessary files for DTS > > > compilation. The script arm.sh takes care of all the work on creating > > > a bootable flash drive. Uncomment there only the necessary sections. > > > The script DOES NOT COPY the resulting dtb on the USB flash drive, be > > > careful. > > > > > > > Thank you, this helps a lot. I began to investigate the differences > > among various dtb's I have with some parts of system working and some > > not to suit my needs. > > > > As I am testing dtb provided by you, I see there is not aw_thermal > > working. On the positive side, both ethernet and usb are working, so I > > need just try to compile the dts myself to verify the process. > > > > One more question - do you have some devices connected to your board? I > > would like to know other people's experience attaching sensors and > > similar gadgets. > > > > Regards, > > Milan > > > > > > > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Nov 27 18:32: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 90D30DE22E9 for ; Mon, 27 Nov 2017 18:32:42 +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 7665F7F784 for ; Mon, 27 Nov 2017 18:32:42 +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 vARIWg0C047014 for ; Mon, 27 Nov 2017 18:32:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223917] arm64: ddb 'c'ontinue does not continue Date: Mon, 27 Nov 2017 18:32:42 +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 Only Me X-Bugzilla-Who: emaste@freebsd.org 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 18:32:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223917 Bug ID: 223917 Summary: arm64: ddb 'c'ontinue does not continue Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org Running with this custom kernel config on 2 socket 96 core ThunderX at packet.net: nooptions VIMAGE options ALT_BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC Entered the debugger via ~ ^B. 'c' command to continue remained in the debugger, and it eventually reset: root@arm64-kernel-test:~ # KDB: enter: Break to debugger [ thread pid 11 tid 100004 ] Stopped at 0 db> bt Tracing pid 11 tid 100004 td 0xfffffd0007cb9a80 db_trace_self() at db_stack_trace+0xec pc =3D 0xffff0000005f7c58 lr =3D 0xffff000000084690 sp =3D 0xffff000aa498fef0 fp =3D 0xffff000aa498ff20 db_stack_trace() at db_command+0x224 pc =3D 0xffff000000084690 lr =3D 0xffff00000008431c sp =3D 0xffff000aa498ff30 fp =3D 0xffff000aa4990010 db_command() at db_command_loop+0x60 pc =3D 0xffff00000008431c lr =3D 0xffff0000000840dc sp =3D 0xffff000aa4990020 fp =3D 0xffff000aa4990040 db_command_loop() at db_trap+0xf4 pc =3D 0xffff0000000840dc lr =3D 0xffff0000000871b0 sp =3D 0xffff000aa4990050 fp =3D 0xffff000aa4990270 db_trap() at kdb_trap+0x190 pc =3D 0xffff0000000871b0 lr =3D 0xffff00000035ad74 sp =3D 0xffff000aa4990280 fp =3D 0xffff000aa49902e0 kdb_trap() at do_el1h_sync+0x90 pc =3D 0xffff00000035ad74 lr =3D 0xffff0000006119c4 sp =3D 0xffff000aa49902f0 fp =3D 0xffff000aa4990320 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006119c4 lr =3D 0xffff0000005fa074 sp =3D 0xffff000aa4990330 fp =3D 0xffff000aa4990440 handle_el1h_sync() at kdb_alt_break_internal+0x1a4 pc =3D 0xffff0000005fa074 lr =3D 0xffff00000035a65c sp =3D 0xffff000aa4990450 fp =3D 0xffff000aa49904f0 kdb_alt_break_internal() at kdb_alt_break+0xc pc =3D 0xffff00000035a65c lr =3D 0xffff00000035a4a8 sp =3D 0xffff000aa4990500 fp =3D 0xffff000aa4990500 kdb_alt_break() at uart_intr_rxready+0x88 pc =3D 0xffff00000035a4a8 lr =3D 0xffff00000019538c sp =3D 0xffff000aa4990510 fp =3D 0xffff000aa4990530 uart_intr_rxready() at uart_intr+0xfc pc =3D 0xffff00000019538c lr =3D 0xffff000000196078 sp =3D 0xffff000aa4990540 fp =3D 0xffff000aa4990570 uart_intr() at intr_event_handle+0xa8 pc =3D 0xffff000000196078 lr =3D 0xffff0000002e15a8 sp =3D 0xffff000aa4990580 fp =3D 0xffff000aa49905d0 intr_event_handle() at intr_isrc_dispatch+0x5c pc =3D 0xffff0000002e15a8 lr =3D 0xffff00000063aed8 sp =3D 0xffff000aa49905e0 fp =3D 0xffff000aa49905f0 intr_isrc_dispatch() at arm_gic_v3_intr+0x138 pc =3D 0xffff00000063aed8 lr =3D 0xffff0000005fd3e8 sp =3D 0xffff000aa4990600 fp =3D 0xffff000aa4990650 arm_gic_v3_intr() at intr_irq_handler+0x68 pc =3D 0xffff0000005fd3e8 lr =3D 0xffff00000063ad40 sp =3D 0xffff000aa4990660 fp =3D 0xffff000aa4990680 intr_irq_handler() at handle_el1h_irq+0x70 pc =3D 0xffff00000063ad40 lr =3D 0xffff0000005fa130 sp =3D 0xffff000aa4990690 fp =3D 0xffff000aa49907a0 handle_el1h_irq() at cpu_idle+0x3c pc =3D 0xffff0000005fa130 lr =3D 0xffff000000601484 sp =3D 0xffff000aa49907b0 fp =3D 0xffff000aa4990840 cpu_idle() at sched_idletd+0xe4 pc =3D 0xffff000000601484 lr =3D 0xffff000000345368 sp =3D 0xffff000aa4990850 fp =3D 0xffff000aa4990910 sched_idletd() at fork_exit+0x7c pc =3D 0xffff000000345368 lr =3D 0xffff0000002de724 sp =3D 0xffff000aa4990920 fp =3D 0xffff000aa4990950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002de724 lr =3D 0xffff0000006117a4 sp =3D 0xffff000aa4990960 fp =3D 0x0000000000000000 db> c [ thread pid 11 tid 100004 ] Stopped at $d.2+0x3: undefined 00010102 db> c [ thread pid 11 tid 100004 ] Stopped at $d.2+0x7: undefined 00000000 db> c [ thread pid 11 tid 100004 ] Stopped at $d.9+0x1: undefined 00000000 db> continue timeout stopping cpus [ thread pid 11 tid 100004 ] Stopped at $d.9+0x5: undefined 00b70002 db> timeout stopping cpus panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ /root/freebsd/sys/arm64/arm64/pmap.c:4711 cpuid =3D 62 time =3D 1511807367 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005f7c58 lr =3D 0xffff000000087048 sp =3D 0xffff000ba8894ba0 fp =3D 0xffff000ba8894db0 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000087048 lr =3D 0xffff00000031a750 sp =3D 0xffff000ba8894dc0 fp =3D 0xffff000ba8894e40 vpanic() at kassert_panic+0x158 pc =3D 0xffff00000031a750 lr =3D 0xffff00000031a5c8 sp =3D 0xffff000ba8894e50 fp =3D 0xffff000ba8894f10 kassert_panic() at witness_checkorder+0x140 pc =3D 0xffff00000031a5c8 lr =3D 0xffff000000378a6c sp =3D 0xffff000ba8894f20 fp =3D 0xffff000ba8894f90 witness_checkorder() at __mtx_lock_flags+0xb0 pc =3D 0xffff000000378a6c lr =3D 0xffff0000002fb5e8 sp =3D 0xffff000ba8894fa0 fp =3D 0xffff000ba8894fe0 __mtx_lock_flags() at pmap_fault+0x40 pc =3D 0xffff0000002fb5e8 lr =3D 0xffff00000060fae0 sp =3D 0xffff000ba8894ff0 fp =3D 0xffff000ba8895010 pmap_fault() at data_abort+0xb8 pc =3D 0xffff00000060fae0 lr =3D 0xffff000000611be8 sp =3D 0xffff000ba8895020 fp =3D 0xffff000ba88950d0 data_abort() at do_el1h_sync+0xf8 pc =3D 0xffff000000611be8 lr =3D 0xffff000000611a2c sp =3D 0xffff000ba88950e0 fp =3D 0xffff000ba8895110 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000611a2c lr =3D 0xffff0000005fa074 sp =3D 0xffff000ba8895120 fp =3D 0xffff000ba8895230 handle_el1h_sync() at vfp_save_state+0x4c pc =3D 0xffff0000005fa074 lr =3D 0xffff000000612e90 sp =3D 0xffff000ba8895240 fp =3D 0xffff000ba88952d0 vfp_save_state() at savectx+0x50 pc =3D 0xffff000000612e90 lr =3D 0xffff000000611858 sp =3D 0xffff000ba88952e0 fp =3D 0xffff000ba88952f0 savectx() at arm_gic_v3_intr+0x100 pc =3D 0xffff000000611858 lr =3D 0xffff0000005fd3b0 sp =3D 0xffff000ba8895300 fp =3D 0xffff000ba8895350 arm_gic_v3_intr() at intr_irq_handler+0x68 pc =3D 0xffff0000005fd3b0 lr =3D 0xffff00000063ad40 sp =3D 0xffff000ba8895360 fp =3D 0xffff000ba8895380 intr_irq_handler() at handle_el1h_irq+0x70 pc =3D 0xffff00000063ad40 lr =3D 0xffff0000005fa130 sp =3D 0xffff000ba8895390 fp =3D 0xffff000ba88954a0 handle_el1h_irq() at uma_zalloc_arg+0x488 pc =3D 0xffff0000005fa130 lr =3D 0xffff0000005a30d4 sp =3D 0xffff000ba88954b0 fp =3D 0xffff000ba88955a0 uma_zalloc_arg() at namei+0xdc pc =3D 0xffff0000005a30d4 lr =3D 0xffff0000003cded4 sp =3D 0xffff000ba88955b0 fp =3D 0xffff000ba8895680 namei() at kern_statat+0x9c pc =3D 0xffff0000003cded4 lr =3D 0xffff0000003e5f40 sp =3D 0xffff000ba8895690 fp =3D 0xffff000ba88958a0 kern_statat() at sys_fstatat+0x2c pc =3D 0xffff0000003e5f40 lr =3D 0xffff0000003e6534 sp =3D 0xffff000ba88958b0 fp =3D 0xffff000ba88959a0 sys_fstatat() at do_el0_sync+0x890 pc =3D 0xffff0000003e6534 lr =3D 0xffff000000612614 sp =3D 0xffff000ba88959b0 fp =3D 0xffff000ba8895a70 do_el0_sync() at handle_el0_sync+0x74 pc =3D 0xffff000000612614 lr =3D 0xffff0000005fa1f4 sp =3D 0xffff000ba8895a80 fp =3D 0xffff000ba8895b90 handle_el0_sync() at 0x4029de18 pc =3D 0xffff0000005fa1f4 lr =3D 0x000000004029de18 sp =3D 0xffff000ba8895ba0 fp =3D 0x0000ffffffffe100 Uptime: 9m46s --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Nov 27 19:17: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 85273DE3478 for ; Mon, 27 Nov 2017 19:17:10 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a1i475.smtp2go.com (a1i475.smtp2go.com [43.228.185.219]) (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 4361680FFB for ; Mon, 27 Nov 2017 19:17:09 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1511811130; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=MzfS4zSaCnkBeYSWYrpJk3EF6O05T7XDMOWkoes2Ss8=; b=SjjfemQK 4yzQSTJxrsab18rs6LxGAM6s6lvvyEH9kjCeTZGz9AGPxfEfe8HbafxOW8X71u5HdCtLjdAAFCKWF iSUBM3gRA9njfLnPvR9zuJwcF2cThFoTN6QQQ9i9T9emnZEI6AFujQ25ipxCINTpDCEHx+YoWcG0j vH/1UFBxO0YMBDrcOc01ziv+XExq5EtwsyQdPAGZZF6h981RWSna/vQ4Ds8b5dRwPKkBbkZqRAtis VDvtZoqgSpfFVSrIDuSVXix9DkOgTMfHr/OBGOujfZkmIqcHI4vr93fSNMGrwIj15iGCbJc3oc9dI zoX3CnZ8rPtNASc3DtnCOVINuQ==; From: Jedi Tek'Unum Message-Id: <5624E144-42E7-48F5-95F7-FF9F980E7855@jeditekunum.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Allwinner H3/H2+ dts question - regression? Date: Mon, 27 Nov 2017 13:14:04 -0600 In-Reply-To: <20171127112702.7b945be0138484b05e517d49@iptk.ru> Cc: Milan Obuch , freebsd-arm@freebsd.org To: eval@iptk.ru References: <20171126124217.2a512392@zeta.dino.sk> <20171127084355.1dabd642748f25cb87c16b44@iptk.ru> <20171127075903.1ce9c40e@zeta.dino.sk> <20171127112702.7b945be0138484b05e517d49@iptk.ru> X-Mailer: Apple Mail (2.3273) X-Smtpcorp-Track: 1-JOr2r_ZUbtHe.HCQCCtJIv Feedback-ID: 207158m:207158azGM_-I:207158sgr5CmUg23:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 19:17:10 -0000 I have a NanoPi NEO (very similar to Orange Pi) working except for I2C = with an older revision (325705). I haven=E2=80=99t been able to get it = to boot without doing a =E2=80=9Cload -t dtb /boot/dtb/nanopi-neo.dtb=E2=80= =9D first. Not as lucky with current revisions. I started with = https://framkant.org/2017/07/running-freebsd-on-nanopi-neo-or-orangepi-zer= o/ = and made the following changes: u-boot-nanopi-neo/Makefile MODEL needs to be nanopi_neo = (underscore instead of dash) crochet/board/NanoPi-NEO/setup.sh SUNXIO_UBOOT needs to also be = underscore instead of dash (u-boot-nanopi_neo). Built on FreeBSD 11.1 (amd64) release. Using current ports, these two patches were needed to get u-boot to = build: *** work/u-boot-ports-v2017.09.00/scripts/config_whitelist.txt.orig = Sun Nov 26 06:58:51 2017 --- work/u-boot-ports-v2017.09.00/scripts/config_whitelist.txt Sun Nov = 26 07:06:33 2017 *************** CONFIG_SYS_USBCTRL *** 4770,4775 **** --- 4770,4776 ---- CONFIG_SYS_USBD_BASE CONFIG_SYS_USB_EHCI_CPU_INIT CONFIG_SYS_USB_EHCI_REGS_BASE + CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE CONFIG_SYS_USB_FAT_BOOT_PARTITION CONFIG_SYS_USB_HOST CONFIG_SYS_USB_OHCI_BOARD_INIT *** work/u-boot-ports-v2017.09.00/scripts/Makefile.lib.orig Sun Nov = 26 06:15:10 2017 --- work/u-boot-ports-v2017.09.00/scripts/Makefile.lib Sun Nov 26 = 06:15:34 2017 *************** quiet_cmd_dtc =3D DTC $@ *** 308,315 **** # Modified for U-Boot # Bring in any U-Boot-specific include at the end of the file cmd_dtc =3D mkdir -p $(dir ${dtc-tmp}) ; \ ! cat $< $(if $(u_boot_dtsi),\ ! | sed "$$ a\#include \"$(u_boot_dtsi)\"") | \ $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o = $(dtc-tmp) - ; \ $(DTC) -O dtb -o $@ -b 0 \ -i $(dir $<) $(DTC_FLAGS) \ --- 308,315 ---- # Modified for U-Boot # Bring in any U-Boot-specific include at the end of the file cmd_dtc =3D mkdir -p $(dir ${dtc-tmp}) ; \ ! echo "\#include \"$(u_boot_dtsi)\"" | \ ! cat $< - | \ $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o = $(dtc-tmp) - ; \ $(DTC) -O dtb -o $@ -b 0 \ -i $(dir $<) $(DTC_FLAGS) \ I also want to use I2C so I added this to the bottom of = sys/boot/fdt/dts/arm/nanopi-neo.dts: &i2c0 { status =3D "okay"; }; &i2c1 { status =3D "okay"; }; It looks ok at boot but I don=E2=80=99t see any I2C devices when I scan. = Same hardware is showing 2 devices on Friendlyarm (manufacturer) linux. = I see sys/boot/fdt/dts/arm/orangepi-plus-2e.dts has &r_i2c as well and = perhaps I need that. (this stuff is definitely not my area of expertise) U-Boot SPL 2017.09 (Nov 26 2017 - 07:07:31) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2017.09 (Nov 26 2017 - 07:07:31 -0600) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 239260 bytes read in 34 ms (6.7 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @0x5bf3f3c0 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Mon Nov 27 09:55:39 CST 2017 root@corellia) DRAM: 512MB MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=3D0x8246dc+0x1df924 = syms=3D[0x4+0x95040+0x4+0xd980b] / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 No valid device tree blob found! Type '?' for a list of commands, 'help' for more detailed help. loader>=20 loader> load -t dtb /boot/dtb/nanopi-neo.dtb /boot/dtb/nanopi-neo.dtb size=3D0x6459 loader>=20 loader> boot Booting... Using DTB from loaded file '/boot/dtb/nanopi-neo.dtb'. Kernel entry at 0x42200100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r325705M: Mon Nov 27 09:55:30 CST 2017 = root@corellia:/scratch/builds/crochet/work/obj/scratch/src/freebsd/arm.arm= v6/sys/GENERIC arm FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. module_register: cannot register simplebus/ahci from kernel; already = loaded from kernel Module simplebus/ahci failed to register: 17 module_register: cannot register simplebus/ehci from kernel; already = loaded from kernel Module simplebus/ehci failed to register: 17 module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel Module simplebus/pcib failed to register: 17 module_register: cannot register simplebus/ehci from kernel; already = loaded from kernel Module simplebus/ehci failed to register: 17 CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features:=20 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, PXN, LPAE, Coherent Walk Optional instructions:=20 SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2=20 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory =3D 536870912 (512 MB) avail memory =3D 507846656 (484 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 clk_fixed2: on aw_ccu0 simplebus0: on ofwbus0 aw_ccung0: mem 0x1c20000-0x1c203ff on = simplebus0 iichb0: mem = 0x1c2ac00-0x1c2afff irq 30 on simplebus0 iicbus0: on iichb0 iichb1: mem = 0x1c2b000-0x1c2b3ff irq 31 on simplebus0 iicbus1: on iichb1 aw_ccung1: mem 0x1f01400-0x1f014ff on = simplebus0 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803,0x1c1c800-0x1c= 1c803,0x1c1d800-0x1c1d803 on simplebus0 gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 33 on simplebus0 gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 gpio0: mem 0x1c20800-0x1c20bff irq = 17,18 on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 37 = on simplebus0 gpiobus1: on gpio1 gpioregulator0: on ofwbus0 rtc0: mem 0x1f00000-0x1f00053 irq 34,35 on simplebus0 rtc0: registered as a time-of-day clock, resolution 1.000000s generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 a31dmac0: mem 0x1c02000-0x1c02fff irq 4 on = simplebus0 a10_mmc0: mem = 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 ehci0: mem 0x1c1d000-0x1c1d0ff = irq 15 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ohci0: mem 0x1c1d400-0x1c1d4ff irq 16 on = simplebus0 usbus1 on ohci0 gpioc0: on gpio0 aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 23 on = simplebus0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 26 on = simplebus0 uart0: console (115384,n,8,1) iic0: on iicbus0 iic1: on iicbus1 gpioc1: on gpio1 awg0: mem = 0x1c30000-0x1c30103,0x1c00030-0x1c00033 irq 38 on simplebus0 miibus0: on awg0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow ukphy1: PHY 1 on miibus0 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow awg0: Ethernet address: 02:81:5f:3d:9d:3c aw_thermal0: mem = 0x1c25000-0x1c253ff irq 40 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 gpioled0: on ofwbus0 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on = usbus0 ugen1.1: at usbus1 uhub1: on = usbus1 mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/65535-block Release APs WARNING: WITNESS option enabled, expect reduced performance. arc4random: no preloaded entropy cache Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... uhub1: 1 port with 1 removable, self powered arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache uhub0: 1 port with 1 removable, self powered Growing root partition to fill device GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` = to revert them. g_access(931): provider ufsid/5a1c3599c0dd5263 has error 6 set g_access(931): provider ufsid/5a1c3599c0dd5263 has error 6 set mmcsd0s2 resized mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, = 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 33338432, 34620672, 35902912, 37185152, 38467392, 39749632, 41031872, 42314112, 43596352, 44878592, 46160832, 47443072, 48725312, 50007552, 51289792, 52572032, 53854272, 55136512, 56418752, 57700992, 58983232, 60265472, 61547712 g_dev_taste: make_dev_p() failed (gp->name=3Dufsid/5a1c3599c0dd5263, = error=3D17) /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, = generating a new one Setting hostuuid: ada99681-f668-11de-892d-0f28dbe4086e. Setting hostid: 0x1318234b. No suitable dump device was found. Starting file system checks: /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2a: clean, 7163697 free (457 frags, 895405 blocks, 0.0% = fragmentation) g_dev_taste: make_dev_p() failed (gp->name=3Dufsid/5a1c3599c0dd5263, = error=3D17) Mounting local filesystems:random: unblocking device. . ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting hostname: nanopineo. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . awg0: link state changed to DOWN Starting Network: lo0 awg0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 awg0: flags=3D8843 metric 0 mtu = 1500 options=3D8000b ether 02:81:5f:3d:9d:3c media: Ethernet autoselect (none) status: no carrier nd6 options=3D29 Starting devd. awg0: link state changed to UP Starting dhclient. DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 6 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPOFFER from 10.0.1.3 DHCPREQUEST on awg0 to 255.255.255.255 port 67 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPACK from 10.0.1.3 bound to 10.0.100.75 -- renewal in 7200 seconds. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. lock order reversal: 1st 0xcd32e0c0 bufwait (bufwait) @ = /scratch/src/freebsd/sys/kern/vfs_bio.c:3553 2nd 0xc34bba00 dirhash (dirhash) @ = /scratch/src/freebsd/sys/ufs/ufs/ufs_dirhash.c:281 stack backtrace: Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting powerd. Generating RSA host key. 2048 SHA256:eNEyFA6HtGcUtyagsPPIZoNyO/qNhvl4hz3pNOXTZwI root@nanopineo = (RSA) Generating ECDSA host key. 256 SHA256:Ujovz8Tzkky2HfTUoBmCa48GCL+PFhEkd0A8X9g8YzM root@nanopineo = (ECDSA) Generating ED25519 host key. 256 SHA256:4ZYDaObSrmQijPjIGFZC9eKpLz9Th/ZYCy7P/OO7//A root@nanopineo = (ED25519) Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. lock order reversal: 1st 0xc35055d4 ufs (ufs) @ = /scratch/src/freebsd/sys/kern/vfs_subr.c:2606 2nd 0xcd32e0c0 bufwait (bufwait) @ = /scratch/src/freebsd/sys/ufs/ffs/ffs_vnops.c:280 3rd 0xc331d934 ufs (ufs) @ = /scratch/src/freebsd/sys/kern/vfs_subr.c:2606 stack backtrace: mount: /dev/mmcsd0s2a: Device busy Fri Jan 1 00:00:56 UTC 2010 FreeBSD/arm (nanopineo) (ttyu0) login: =20 > On Nov 27, 2017, at 1:27 AM, Eugene Sevastyanov wrote: >=20 > Currently, I'm trying to run a DS3231 real-time controller board. = There are problems with I2C, but I'm still looking for a reason. At the = moment,=20 From owner-freebsd-arm@freebsd.org Tue Nov 28 21:53: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 158BDDEFF6B for ; Tue, 28 Nov 2017 21:53:30 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 D47F67A404 for ; Tue, 28 Nov 2017 21:53:28 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1eJnoj-0002o1-Ut for freebsd-arm@freebsd.org; Tue, 28 Nov 2017 22:53:26 +0100 Content-Type: multipart/mixed; boundary=----------54ftJcp2iLoNgAPGZIjI0I To: freebsd-arm@freebsd.org Date: Tue, 28 Nov 2017 22:44:08 +0100 Subject: minor fix for https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi MIME-Version: 1.0 From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 2394e6fd9f1e9f86011669f8146dc264 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 21:53:30 -0000 ------------54ftJcp2iLoNgAPGZIjI0I Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, The table at the bottom of https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi mentions 'RPI2 12-CURRENT (armv6)'. This snapshot does not exist anymore. Attached patch removes this mention. Ronald. ------------54ftJcp2iLoNgAPGZIjI0I Content-Disposition: attachment; filename="Raspberry Pi.diff" Content-Type: application/octet-stream; name="Raspberry Pi.diff" Content-Transfer-Encoding: Base64 LS0tIFJhc3BiZXJyeSBQaS5vcmlnCTIwMTctMTEtMjggMjI6Mzc6MzUuNDg5MDUx MDAwICswMTAwCisrKyBSYXNwYmVycnkgUGkJMjAxNy0xMS0yOCAyMjozOToxMC4x MzMzMzkwMDAgKzAxMDAKQEAgLTEwOSw1ICsxMDksNSBAQAogDQogfHwgVmVyc2lv biB8fCBSZWxlYXNlcyB8fCBTbmFwc2hvdHMgfHwNCiB8fCBSUEktQiB8fCBbW2Z0 cDovL2Z0cC5mcmVlYnNkLm9yZy9wdWIvRnJlZUJTRC9yZWxlYXNlcy9hcm0vYXJt djYvSVNPLUlNQUdFUy98MTAuMSssIDExLjArXV0gfHwgW1tmdHA6Ly9mdHAuZnJl ZWJzZC5vcmcvcHViL0ZyZWVCU0Qvc25hcHNob3RzL2FybS9hcm12Ni9JU08tSU1B R0VTL3wxMC1TVEFCTEUsIDExLVNUQUJMRSwgMTItQ1VSUkVOVF1dIHx8DQotfHwg UlBJMiAgfHwgW1tmdHA6Ly9mdHAuZnJlZWJzZC5vcmcvcHViL0ZyZWVCU0QvcmVs ZWFzZXMvYXJtL2FybXY2L0lTTy1JTUFHRVMvfDExLjArXV0gfHwgW1tmdHA6Ly9m dHAuZnJlZWJzZC5vcmcvcHViL0ZyZWVCU0Qvc25hcHNob3RzL2FybS9hcm12Ni9J U08tSU1BR0VTL3wxMS1TVEFCTEUsIDEyLUNVUlJFTlQgKGFybXY2KV1dLCBbW2Z0 cDovL2Z0cC5mcmVlYnNkLm9yZy9wdWIvRnJlZUJTRC9zbmFwc2hvdHMvYXJtL2Fy bXY3L0lTTy1JTUFHRVMvMTIuMC98MTItQ1VSUkVOVCAoYXJtdjcpXV0gfHwNCit8 fCBSUEkyICB8fCBbW2Z0cDovL2Z0cC5mcmVlYnNkLm9yZy9wdWIvRnJlZUJTRC9y ZWxlYXNlcy9hcm0vYXJtdjYvSVNPLUlNQUdFUy98MTEuMCtdXSB8fCBbW2Z0cDov L2Z0cC5mcmVlYnNkLm9yZy9wdWIvRnJlZUJTRC9zbmFwc2hvdHMvYXJtL2FybXY2 L0lTTy1JTUFHRVMvfDExLVNUQUJMRV1dLCBbW2Z0cDovL2Z0cC5mcmVlYnNkLm9y Zy9wdWIvRnJlZUJTRC9zbmFwc2hvdHMvYXJtL2FybXY3L0lTTy1JTUFHRVMvMTIu MC98MTItQ1VSUkVOVF1dIHx8DQogfHwgUlBJMyAgfHwgfHwgW1tmdHA6Ly9mdHAu ZnJlZWJzZC5vcmcvcHViL0ZyZWVCU0Qvc25hcHNob3RzL2FybTY0L2FhcmNoNjQv SVNPLUlNQUdFUy8xMi4wfEZyZWVCU0QgMTItQ1VSUkVOVF1dIHx8DQo= ------------54ftJcp2iLoNgAPGZIjI0I-- From owner-freebsd-arm@freebsd.org Wed Nov 29 08:09: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 8EEE6DFD2DA for ; Wed, 29 Nov 2017 08:09:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 5C8E26AA00 for ; Wed, 29 Nov 2017 08:09:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 22A7D260072; Wed, 29 Nov 2017 09:09:16 +0100 (CET) Subject: Re: minor fix for https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi To: Ronald Klop , freebsd-arm@freebsd.org References: From: Hans Petter Selasky Message-ID: <09b85069-84d8-fc68-52e6-9c86d3d9007f@selasky.org> Date: Wed, 29 Nov 2017 09:06:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 08:09:23 -0000 On 11/28/17 22:44, Ronald Klop wrote: > Hi, > > The table at the bottom of > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi mentions 'RPI2 > 12-CURRENT (armv6)'. This snapshot does not exist anymore. > Attached patch removes this mention. > Done and thank you! --HPS From owner-freebsd-arm@freebsd.org Wed Nov 29 22:22: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 E25D0DEBA45 for ; Wed, 29 Nov 2017 22:22:58 +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 D0B3F6746D for ; Wed, 29 Nov 2017 22:22:58 +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 vATMMwZl071953 for ; Wed, 29 Nov 2017 22:22:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223977] UBLDR network packets not aligned to DCACHE in ARMv7. Date: Wed, 29 Nov 2017 22:22:58 +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.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: parakleta@darkreality.org 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 22:22:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223977 Bug ID: 223977 Summary: UBLDR network packets not aligned to DCACHE in ARMv7. Product: Base System Version: 11.1-RELEASE Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: parakleta@darkreality.org In the file `sys/boot/uboot/lib/libuboot.h:47` it says: #define PKTALIGN 32 Unfortunately this causes an error "CACHE: Misaligned operation at range [x= xx, xxx]" since this is not enough to aligned to the data cache in ARMv7 cpus (= such as the AM335x). This value should be changed to reflect the setting in U-B= oot of `CONFIG_SYS_CACHELINE_SIZE` which is determined by `SYS_CACHE_SHIFT_X` define in the U-Boot file `arch/arm/Kconfig`. I have temporarily changed the line to: #define PKTALIGN 64 This change may be sufficient given that the block of memory being aligned = is `ETHER_MAX_LEN` in size (so 1518 bytes) this only wastes ~2% storage. This will fail however for CPUs with a CACHELINE_SIZE of 128 (currently only lis= ted as the ThunderX and the Uniphier). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Nov 30 00:21:49 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 8F53EDEDD93 for ; Thu, 30 Nov 2017 00:21:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 4312A6A9C0 for ; Thu, 30 Nov 2017 00:21:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22a.google.com with SMTP id g9so6738991qth.9 for ; Wed, 29 Nov 2017 16:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=PMPwl70WYvmLG1mRyr6BL6rJpQPcugQXqdKu32seC/s=; b=eN6B7UCoZKY+Pg2P8sYYhfSycLduBorEEiYsEEAt02XHbfn/Bni1xWcuvGQOKtX4Ml IUwEqzjkud3++LD7K/f34m3BwZE0/cA875Y/VC7ANGHoiWf2Jw+tC1mFgIZHoPBb305A Z9kwQH1FktZLyEByb5WOv3kIUFSappNOrlt0swcnKrzy4M/XskDWqqmRDkM7uYxNkudV Hwdii2eVC5BE/s/3P85Bh3B/vrTGNua908COB6UvgBwiZ3LmV3frICyb+LR7D4mMKmsx mdAumYQmKffRzfaNqqgi14SpZjXbUElkfrEp80GuMKSD/HO7Ntd0vtrtYKlB9X9bZP2T FcRg== 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:subject:message-id:mime-version :content-disposition:user-agent; bh=PMPwl70WYvmLG1mRyr6BL6rJpQPcugQXqdKu32seC/s=; b=Z9M0tBYeVI6Py9aAZIRXMDOSGJWXnaJZmr1ywGEBNjFR34AUR5y9wqA0Du9NxXnDdL 9SUdtZEihaj7Du1CSrQvtU9UU5/qSI2kCav6V1t7rTlFlun3sda8UHLiRzX3S7lbsI5Z p9FUlJgePu1jV9Mhp91Oa+yZo5a/dlOqPLrIlp9346bOyV5iIp6cCUYmy38pvSHlXHoy 7wzjH3+lpL0+EX986GZ/2JHu3P+rMge2Miwc0I6NFTUbESQEFcp+txxlWft4hMYm5CAn 105WrT+0ID3IecVAqYqzMKJ/0xcLkb/OhOh/IMNG/yXdEOPLQdU327F0uMoPvDNuFcyT nYjA== X-Gm-Message-State: AKGB3mIQ4gDSMLDZ1u0oV8pPK5twtL4O7GDsG1GjWmQS5Pkoz3Ajoosh TJnavA7x41ajESY6P6ZRzXsLc/eBXNQo+biWlQxQeYQ0QLRn91wNflfquXZITHgx5EQR64kBW12 9iYtLEGgmUh1nSch+Xfp9vU1Spd5Plq+oW4Rr16RDJluSNkdOLqShSELmFX9fGIilnCVAkkStrt wLdg== X-Google-Smtp-Source: AGs4zMY8GTr/lQvngeojXNCT2JuPoa9j/zUw2uU5VBtn98eZpvxbs4kE5wReY+DKo1MCh/sR78CrHA== X-Received: by 10.200.63.125 with SMTP id w58mr1150085qtk.82.1512001308054; Wed, 29 Nov 2017 16:21:48 -0800 (PST) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id x52sm2127193qta.26.2017.11.29.16.21.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Nov 2017 16:21:47 -0800 (PST) Date: Wed, 29 Nov 2017 19:21:35 -0500 From: Shawn Webb To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Booting UEFI ZFS is broken on arm64 Message-ID: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fxivhl56ughxifsu" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:21:49 -0000 --fxivhl56ughxifsu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to this line: Using DTB provided by EFI at 0x801fe00000. Then all output stops. I'm in the process of building a custom install ISO that has DEBUG turned on in the fdt code. I hope to report back soon-ish, unless anyone else has any ideas as to what could be wrong. 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 --fxivhl56ughxifsu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlofTwwACgkQaoRlj1JF bu7MDg//WN1HKBlxEGtm5IZLxFm+268ZABFV50fVLix3E97a4D1M1+VJuq61bkC8 dqFBcvPpEIM7LxCXjSOXR9gIzhPNrVt2u27QcpPvIkCjXYB44wHB1dbcceC5rqMw xUhvBPX86dPRp0z8qxpWC3QlXoVEv9RgeWMzYwY/H/cYztcVbfDTljsxiZ7dF9pE lX3y1gFMuBqNag18sTgLoo0Filmw/UYGPLoEajmdBjxOXhFS5zb+dUOti5m7wiyf empux/McfjIWmExZO+F7CSmymIT9X882TeTUicis4DZcPtLbUIU1RxjG/74LYybl VzUzr3pIA33T5eCxuhrdH/yopXY7Pwt0KNUzjRcaHdyL5wPpjTahkIauOEkLpsjX X+t4RLk6oUruiDPahyeUlElFtunSgvZ5MViwfy5Gqaw+UeFaGnLEwSFrrT9gmcHA SbrpMTvceZ+VMZhNLflh8Bw6HOt2XmdUdU/oJRGEUdng6W2VqD3SMvtqYcWvMeis zA7KoIPYTzVW+EAIbGce4grDDd2GeboS9U/qBS1OzMtEuPhCOJzIf+mrqpuWxPNW JSFZybtVywNZFuXJ3U/lhCqgZqCVuyfBU2UdVOgLhKB+KaHmE/pfntHBMBVVS1yu tnRQM+P8iGhHkjaCPkxF+Vc0MvHnFtLkQqoNB2mXeGRPL/KqQO4= =E7xM -----END PGP SIGNATURE----- --fxivhl56ughxifsu-- From owner-freebsd-arm@freebsd.org Thu Nov 30 00:33: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 981E1DEE832 for ; Thu, 30 Nov 2017 00:33:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 5C36C6B678 for ; Thu, 30 Nov 2017 00:33:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id d14so5691762ioc.5 for ; Wed, 29 Nov 2017 16:33:48 -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=z2gIB7V5Pl2227RCbzpYJanHSyMag/rx8+k4p+qkcuk=; b=qx2tR5nmXaHgHX0ZBnq/GwhMXc5arvPnpVpvU8uzQwl1zMFKrQ7cwmTvNz5TILJpVf 806wDpKATihtP/2I6k/bLpKjdQKFz4p2jpbUwLZGM3igWWD49O7Q0XS1mqxAVvYeKEW9 qFUdRri2wGxvlXA2aS3OeLoo2jeI1T0dgP0xmUcdnYtXD05OPnopbQgmkKmnZZHVBvuz 5zWQoti4ZtDZvR1OhcxWltT0Ns13IplMUgBencCXyzPzAiZwTJXpYMvimC2Kz5E52X6R 08XS9yPkX1WC51p067v9wYd9j6lhbwpKLw04OqysMEU6Yy9OuMO1nmsOMAHGXhoCBYBc JXIg== 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=z2gIB7V5Pl2227RCbzpYJanHSyMag/rx8+k4p+qkcuk=; b=PS8nlRbyf5KvxFfr9VTdC8rGpezP/nSCjZY0uVnD3tBvFGg7kES2J4149qTrAsGoX4 cJz6vZVKMzNNDY9NjrLXXYrhojpZd/9Sf93WdiDDrT3cm9U17ByZn6jVsKBZJQb1uaNO kic47hguNNW6MIvjIh1EstL2BFFzTx/OnJP2UzwL2gLHjvZkyWqgTocTIRraU9aWDrY8 UkWRMfsDY/+Z5YkXQBJ26Qvanse2GpBIkPq/nlMShhfA13fR4zYHbyxkHpJUog0P2ila DHRhmrfgAS4DxcKxqgLLpq8P0mRbXuD3GMLZQSpen01NdwVP8cAoLa5jQ4etDHzHs0uO kuBQ== X-Gm-Message-State: AKGB3mLE6CsK5snBrpiYc4SUD7BF51JEgFSywS3Gr6IoS6CaoY0nCnqb TBqYjFmTn9A3UMBLKwSmvhendXBOElKIUtAIwBJhCw== X-Google-Smtp-Source: AGs4zMZ0/RJR+FIe96xBtF9SCn5BtWBjfERk+VN+v/pAtHEHYN7w8f3yge2xKGZGyXF2Y139vYH28pjnDi6mdmyLsx8= X-Received: by 10.107.52.140 with SMTP id b134mr2106940ioa.291.1512002027427; Wed, 29 Nov 2017 16:33:47 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 16:33:46 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 17:33:46 -0700 X-Google-Sender-Auth: tYEcAb85_Pt7uDa2GOxC4JkuclY Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:33:48 -0000 On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb wrote: > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > this line: > > Using DTB provided by EFI at 0x801fe00000. Which snapshot is that? Boot1 was broken until recently. Warner From owner-freebsd-arm@freebsd.org Thu Nov 30 00:35:12 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 05FEEDEE9B4 for ; Thu, 30 Nov 2017 00:35:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 AF3496B87C for ; Thu, 30 Nov 2017 00:35:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22a.google.com with SMTP id z203so6855966qkb.5 for ; Wed, 29 Nov 2017 16:35:11 -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=ltoSGPEtDXSFR9psuV7qBalnoqhiZx5GWN94dyH8fyo=; b=xuYn/On/xaCpQGdzAit7ZLI5cVseSHdaNZMzYr1TvtsutNQ/Tkpm80G4P7733QPGyT nR5cCFKp7FqDC7v3xtUqZ/xuv9v6aapulqW9yP2LPxPEe9dEjYWlkcwS9nXNFrcZ4PO6 QfJWlIs7uWZMn5hs0ltDME9zx5/gna1S50W9gSbiwgEEGweBVU1cZhgu4bXrSer+rw8D UgGPHK5tsY/rRFH8TI6BJL74D++SxZsYSUhpzRHsmpiMSBOK21Mk0+NrVTB19w62yz4c +qAh+dTpXispT2jtKoF5zzeADRNIP8HfYqCfZRqeSI6O6fJIn7PtimlMX6xh+zEqtzx3 PlAA== 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=ltoSGPEtDXSFR9psuV7qBalnoqhiZx5GWN94dyH8fyo=; b=fFEorBoL2jisfQbKClE3FFZObYx0XAnzrJNoCsZRqgz+H0kJRHMtPmNsFMumI4AJY1 7ZhNTw0n1IYkIzJBD3sr+4EnmCP1g6aB12YZ6bh8z8mWfvh7XdgBRlb+MCUiofhMPV/F jL+/ZuyipEReC9o/2JWy8EZMCq+uCnv66hfbxYQvEys+kIXMdR1YIJzFTqmlOtJmv1Nm 0tUhnI8vudwV2Plvop4CAaamnUcM0/QhE50jIibX5vmrK6c2zqYeAiRw1IV8AJ4g4Zru dj6+9Dg4O36ACnetx69yVl8xnULJRWPP+Ktx6dmhGtofnlzxbxGPM8Nt1BiUbrLX6kND DdTg== X-Gm-Message-State: AKGB3mJukaq5EfOLMSdkoab22Baw0wX0OPeASAdiD4HOLmsusFvb1NSi fUPiHiq8D+DbrqrImeK8mODxyw== X-Google-Smtp-Source: AGs4zMYbOC4Wr8U10GZFWGGsy6cZxhtr14W3seh0E+K2GwdErzXxd00u48hP+5RIYKSSBbCU7pJF1w== X-Received: by 10.55.183.132 with SMTP id h126mr348538qkf.259.1512002110599; Wed, 29 Nov 2017 16:35:10 -0800 (PST) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id y135sm2079741qka.48.2017.11.29.16.35.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Nov 2017 16:35:10 -0800 (PST) Date: Wed, 29 Nov 2017 19:34:58 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oraptaq7mf35otmx" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:35:12 -0000 --oraptaq7mf35otmx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > wrote: >=20 > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > this line: > > > > Using DTB provided by EFI at 0x801fe00000. >=20 >=20 > Which snapshot is that? Boot1 was broken until recently. FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img It also happens on latest HEAD, so it would appear to still be broken. --=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 --oraptaq7mf35otmx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlofUi8ACgkQaoRlj1JF bu7fnBAAwBzLtPIH7qjgvQwtKOr/L1AOhnjItXrmR8zvcSWYskZ788m96mpeJmEL 3q3PZdtNRfo6wNfuLdWWnxizgAY+tWRTvIew2e8IeflXUr84JYobj+LNap/YXEkV 1pR88hzWC0JUo/6UaapdQHeGQIREMbmlB0ih5wvj+t/yxjxoc6+9PLavQoYpMAwP c2BGXX3tzXSu5YHTxkC0AZxDw0UoSELuG63haHTzv/NUUi/QSYEGs+G+Q2zmiBIg BxV8Hm6rEvPNJOq9Ur+NJnnFutbaMVLkHVrBw65iPJ5R6HdDXHgkDA22Ej+nFc89 HxyPGrMi5/zUdMTe3J2bxDAjKGnAtWC98hDRQ55FCpk/Bbct1iphriH/s94DFuPh ouEi9qp19AxA7p0QEjOKaBd/ifaRduSf//DtkrL6qo8N1KBE6pPb276pKxRRcuTg yMpibR3xCkhryuEaFnOo8po2pvE8qOW3nvA+FZ8FdYVBWLHmnAezRMWK5Ga1MWXL Na+Sz/YUVAD4a0/udYYNQf7pi52SL9CIKptoJK1fNav9SBmkCDbOtTlbmGC+0NNf HLo4tTOx6c8nEfMEs18M59/8TBKvzxWT1JmrN8cPxet0xDMhyCTI1rVWo1JR1mNl nD1imqgWSvHz1YiYslCf1ASZd2fJ3ozk2ypdGjpXZO3X4NbM/N8= =U+r1 -----END PGP SIGNATURE----- --oraptaq7mf35otmx-- From owner-freebsd-arm@freebsd.org Thu Nov 30 00:42: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 0552CDEED5C for ; Thu, 30 Nov 2017 00:42:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 BD38A6BD09 for ; Thu, 30 Nov 2017 00:42:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id e204so5693665iof.12 for ; Wed, 29 Nov 2017 16:42:53 -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=5W/eDdLol7FAXbzSjld2e5w6aMrQ0gEYBBWAw9TjKpM=; b=Ib//RFwOOZkY+0ID4Uk0rdRsSjmLS9soSuVqN7EVQSSzLrjkYve70A/yHmeCW6Kk0Y AjcrsgtHzxmZ3JH4j6JL8uJF3HCCC8/xzDE/DVBSWYbEzyIvV5Xv173CrIxYpX3rzA5l 36Kz5FrApvp3eo1CrjVlBlzkIWGDp9mxc4XKNfTy20F84GzGlVJAf3npRg/CbbhfcJSn kLlRuWbBzIwVke3OLPQAd0WXS1zRQXIqJ+y32EdLEf+WKoEC6mttM6vKtqB0Lo8GiqI7 CHGOnzYQAbhzda2VTaOH5zQxUgFb646ZNwhqI/Ki4V49rIxVWNj8FYCgUuuP2l58BCHi JMxg== 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=5W/eDdLol7FAXbzSjld2e5w6aMrQ0gEYBBWAw9TjKpM=; b=Kad2GxIuiqHINNSB3sQB44m1rxOEJZQT9X1faqDtFqg4jYwfGgunw3ni4hT6itJfJP evcBfoIbUZvrnUTORT4XPYG3FY5wVDz4bWYkpHhTGqRfI4y7ol0yJs2NAuVPAbSz+9Bi gQpqx1MoVFHc6fsRZIqFIKdaK6qTwYNXV3NZpN2WEKZtecwxAPfJZ54MdtmbG8Zy5Pll SIIfNez46wWjsXtpa4xf6qyJ4HEp/FsI0UBiMYgalNU+94yXnFlCmOmI/oocmsDXdN2j KEBddw6RUUSWS+LbYRf/capS8kTYDXxncE3m/Aec1Spbx7aKROMCGpwJlzn9xpDEV7PP n+Pg== X-Gm-Message-State: AJaThX4T2YClzkX9curJ5KeYmVhc70FxzygQhF4kpBjQ7Ujsk3WM1gzs rGlJHU7OHRwcJPj4GYokPAwPD+kRtVFoO8Ar8tTXmw== X-Google-Smtp-Source: AGs4zMbXHBkuLGsIM1ZRtrUsvK0fSupBMaHvjOhZ5duCf1YhZTF9I6Nvis7hKiAurS2jMoMG1GkYw8PGQDNX7onDypE= X-Received: by 10.107.48.197 with SMTP id w188mr5826163iow.301.1512002572924; Wed, 29 Nov 2017 16:42:52 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 16:42:52 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 17:42:52 -0700 X-Google-Sender-Auth: dLQYSl1cNULwlotnr4o17iV2Kwo Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:42:54 -0000 On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > > wrote: > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > this line: > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > Which snapshot is that? Boot1 was broken until recently. > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > It also happens on latest HEAD, so it would appear to still be broken. Is this boot1.efi producing the output, or loader.efi? I'm guessing the latter, but wanted to make sure. If so, then we're past the point where boot1.efi would have failed (besides, it was fixed before that snapshot). Warner From owner-freebsd-arm@freebsd.org Thu Nov 30 00:44:12 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 212F0DEEEEB for ; Thu, 30 Nov 2017 00:44:12 +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 C76CC6BED9 for ; Thu, 30 Nov 2017 00:44:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x231.google.com with SMTP id r184so6861548qke.8 for ; Wed, 29 Nov 2017 16:44:11 -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=O3yEJQQPbkT0JYWRtkJg74AElJNmyhfF2tBxJym4K58=; b=ktP/XbZCLupD4b5EgdDXI2tG7boOQECwIyYAxLl0oSvKQuBufsxVy+vMrgzm0U65QB ZRISl0js7scfhzjiJ/+O0i+gXlImgx2hgZCITRUYG5M/5W/c7J7XMPXp/v4ZRCGpU0l1 zhuHn/Im1bjSgsG/x6LCdn3m0+kOCLDTz501WBr3YAh3szqvkJN3bADFYMKWTdhfvcxX xuWXIrZeEy58YlHbUVxDHvIJ1zL8pirPJ3ZlAnihHolvLM/WsJNWWJBbQEpS8CFwc78q UTIoueuXTSnjdIH1vtMwg9bhjm/5Ca+0RCQsahm8FMhORNE/MlNpIZPO3UMR9d4KdX22 LWNQ== 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=O3yEJQQPbkT0JYWRtkJg74AElJNmyhfF2tBxJym4K58=; b=a33cc+ZclWupGHWILUg/M1U8TNpKCLmAu7Edz8Fz0ykBg/V5UN4BfA5alUvIaVWBdX ekRjjGFteAfPIGNfcTthyqmAHmOvMjumtGd0HZgcVDyYBv/5c5hC5WolFkBgdBaxNM8h ZuMytW99rNoESY+CGhRgtyFDjegoPouvrg2zNpja+aLwQQFPAHtOW3koyx/qQ4ro/9lj ctBZWIEz3gTcxp8xyExWBqZsFVp6xrt7gfxmChf4TslIPceyyp3Lq1IM+b5HQm5BTThT GoWjAcEtdiE8b9OwM8XvNdBHMWoXUwnlxBAytDy7ZDVaN1f9LMdMNkUdp3pTwjre3p/p g9zA== X-Gm-Message-State: AKGB3mLqDkA9FzNG03DVWXQln8EdssYk5zDBpoySSqNDfewTeb7B30t/ gSibJR/rR7ujljkmWssKyMHleA== X-Google-Smtp-Source: AGs4zMZlGTWu0Xjf2u3PTDrdedn8RMWL7SScfghXNB3nyUkBOwD1GYq7Q+PZH/GXPCVAiuiNreUfsw== X-Received: by 10.55.134.195 with SMTP id i186mr378275qkd.261.1512002650675; Wed, 29 Nov 2017 16:44:10 -0800 (PST) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id s27sm2145904qtj.42.2017.11.29.16.44.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Nov 2017 16:44:10 -0800 (PST) Date: Wed, 29 Nov 2017 19:43:58 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171130004358.usia2jrvman4cvvz@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e3qipk7wfsn3ujwm" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:44:12 -0000 --e3qipk7wfsn3ujwm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > wrote: >=20 > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > > > wrote: > > > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > > this line: > > > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > > Which snapshot is that? Boot1 was broken until recently. > > > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > > > It also happens on latest HEAD, so it would appear to still be broken. >=20 >=20 > Is this boot1.efi producing the output, or loader.efi? I'm guessing the > latter, but wanted to make sure. If so, then we're past the point where > boot1.efi would have failed (besides, it was fixed before that snapshot). With DEBUG turned on for stand/fdt: Booting [/boot/kernel/kernel]... =20 fdt_copy(): fdt_copy va 0x01208000 fdt_setup_fdtp(): fdt_setup_fdtp() fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) Using DTB provided by EFI at 0x801fe00000. Loaded the platform dtb: 0x81f56f1630. fdt_fixup(): fdt_fixup() ^ hangs after that message --=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 --e3qipk7wfsn3ujwm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlofVE0ACgkQaoRlj1JF bu5AqQ//eWoXYVh12ZhH1017CCBXTG17WTjSj7vqU/OV6Gn5oy4ZKqQMjQpVvxeb m5I7Bo9MfTHWYTAV7H1Ii4C0dwjMuyGcFAxGcRx4hj6SbQY4mhuap/UowN7Tf3AW l0LpmzLLm0RXqQH6R+hdwyRKsYRslu9pY+YBmrsn2mk3G+LGL8I3nWKRDhPMklcy St5fGCWgkeJwg8aaO3XJQDpQCGg7iMwTJH/BFXfEx2sQlkIAljC7C5leUN8x3op+ X/j9jHlPWZwT7j3PXRC7kJJfZoEdaryz3M3lArBZRUU/amMtWAL6FUgH4aCckkrV Kxm2FqGdnsNvHTUnD/p47NPuHjaTfLdkaVFvjBK0/90LwQcO/FQzREedVKxlkNpC QP86LtMJRC6s3wTerhoaR82ZG9NR0FT6E3gvjS2zpjdb3wA/TrZPKnvj6mxhHzAM DryBUwHB2n3kwOpngnH+DoIsNfuCSMJl6OHW1oQPZhMJLOenTCixeaiyz2ZA+TGa o3jdT9Hdht/bV0fIL48cqEIKUUreSw+JIx3LQanttBqpV4M6+nNPyxMJXbOikm1p n5EBYJlXYHUITg4zyy2KKKw1vlZKFNe6hO49uogXRN8ewLhcgE6xhOUY+l7T9rEv HfEnH25uc+f/qfmtVxg1Dm4ytLmtTmbq/ju9tFKJd/yci/oIx+U= =El1d -----END PGP SIGNATURE----- --e3qipk7wfsn3ujwm-- From owner-freebsd-arm@freebsd.org Thu Nov 30 00:54: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 9E152DEF32A for ; Thu, 30 Nov 2017 00:54:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 609146C526 for ; Thu, 30 Nov 2017 00:54:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id d14so5731180ioc.5 for ; Wed, 29 Nov 2017 16:54:26 -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=QLMSAF9nLX8GKcendxGFBkU4afXy2lfIuGl7C8y9lFw=; b=txKGW12oR5WZ4K7hzBzsn3F9Jluy+KQAh/IV162hn3kt9Kph+EPbrBSpBSnsOKrLrK xoknvJOwg10lBWkHw2vdxYD4WkMp9AkVPx6zQcQp+N36Hksm+nctZVGoZjyQOBMTIwuP PxWmzNGAC5y0nGM5qPdaoGDbc/nPVWZy4UuajiuuzHkQWgQYwVLfxph0AOLBSNxlYVLo bt/mLfrp14gCeZC4mPlDI1Zsl0SiYlVVj836Z/Tx5PJh0pAAT6bI4donMMwfwx2rEcHn 1yOlvFrrbTeIAUGZLtOJoijmnK6Kyw4XBpnZgK6ceC1h1o2Op+s5k2EhA3UaJz2ojXa2 CCkA== 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=QLMSAF9nLX8GKcendxGFBkU4afXy2lfIuGl7C8y9lFw=; b=OXZOQGRMDOqDjV5OydPbtnh163WCKFkQ27YgjaYFz1M1u2pJTzh18ZLi7o9KvgAq3H ieGB1RAd3bqUFhr59ZaCo3+9uaf2nfECmRUje9YVBhOs3UjnXoYY5VSsqES3t/z5646P ORcmUdJ0ix5aNk/YBhtptzPDX8b0hdVbTGG9Rs5QAzWhXu8/s82xGDkFjgRGLLjTLEgq Dwxel13sHFQfT6kbgch3waO7aE4ieJsO5kWq8zUvxR26AJCfTmpTE9qgtb8vxt1F3zk9 hvdInafz7CxcI/LCWrPHQzS/wGMrYFfWDrRStNvPdOIJukTyD5ujm32HZtBJju3NjtV0 +ObA== X-Gm-Message-State: AJaThX5fldFM0r+NoQCUtaRl6JB/K+k6aSE9/sGd3DQehA90zD8MPiLU jRsrNadVoFMpJY6lF5KFEKPQ/1uKfc8jPoyweBo8IA== X-Google-Smtp-Source: AGs4zMb1mrLE8yhDuyCEp5pRjH3Q09rau7iJjxeHFN2zqnxeOTQI8UEEQkpYdRrnD069lOxM70l2Z3olR93GmHI4+uA= X-Received: by 10.107.104.18 with SMTP id d18mr5311566ioc.136.1512003265699; Wed, 29 Nov 2017 16:54:25 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 16:54:25 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171130004358.usia2jrvman4cvvz@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 17:54:25 -0700 X-Google-Sender-Auth: bndQhTjws8JqDaHqpehAC7sQyHs Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:54:26 -0000 On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > > wrote: > > > > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > shawn.webb@hardenedbsd.org> > > > > wrote: > > > > > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > > > this line: > > > > > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > > > > > Which snapshot is that? Boot1 was broken until recently. > > > > > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > > > > > It also happens on latest HEAD, so it would appear to still be broken. > > > > > > Is this boot1.efi producing the output, or loader.efi? I'm guessing the > > latter, but wanted to make sure. If so, then we're past the point where > > boot1.efi would have failed (besides, it was fixed before that snapshot). > > With DEBUG turned on for stand/fdt: > > Booting [/boot/kernel/kernel]... > fdt_copy(): fdt_copy va 0x01208000 > fdt_setup_fdtp(): fdt_setup_fdtp() > fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > Using DTB provided by EFI at 0x801fe00000. > Loaded the platform dtb: 0x81f56f1630. > fdt_fixup(): fdt_fixup() > > ^ hangs after that message That doesn't sound like anything I've changed, but it could well be... I think to find this breakage, you may need to bisect backwards along stand / sys/boot until we find the spot where it broke. Warner From owner-freebsd-arm@freebsd.org Thu Nov 30 02:31: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 AA64FDF2605 for ; Thu, 30 Nov 2017 02:31:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 6B1BC6F907 for ; Thu, 30 Nov 2017 02:31:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id d21so5917681ioe.7 for ; Wed, 29 Nov 2017 18:31:19 -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=t0zM1Ly+b6FMoO2miBpGpDkALNhPf+yrrjYzzUbUG6k=; b=YT/TsXwXIq7TlzDPI9ijhEzHHYqL1ZI52YmOgT5zEZxehhWIsulaFZYzQ2A/TPSZMX kGwpBAFWv4nb0BB4NI+zbEt2tJBQwIz8WxafSVR/8yc6tzlHRFOylNGS3MqLulP+Id+s iB1Qx2GACWn9z+OBjrN01yka0RjZvQVYzB9tXcGzXyApd0fTIWzaCtXhCgp4oDtp+QTu uRNtaWkTug5q+dWT1BNjOF28k4mSUe6ERmXxOAOTaRoowicKDoF7TCnNZ3TJ9B1njjng fEubI+3TWJ/ebxZjUTWw/wQxZmOCiqFfnk94gVyNuSSLh9CwL87KwCktz1Q2mZ3Sp0MN Vgrw== 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=t0zM1Ly+b6FMoO2miBpGpDkALNhPf+yrrjYzzUbUG6k=; b=GNHTXDDV3pzvaMOo/ebrNzwBG45dA9/sWEFf6UOTuLOqTa3VzBpPlqT6+xu80z9r35 ijbTq0y362qC6JwYG3iiZU0h6RxhLDZHHU1uSxjOJJOiFcFFYjBfAYnb557O9MbTvfI6 RCIIwlFdKid45QZEgfoBiKMmoAg3DQZng0f/XGsoSo/2hs9vnHWevvb1Uv9ki0aJHklj Oxa07SLr3jZjck6uIETvEMoxKuZGA/BTFhs1xFJ/prOn5PVCBfKEEcq6q3BCwKVYGtfw PAUVms6Mav9GNg9q3gBt7BUbbseSHWZAmbZ3ficl2J/F9FS2oDpeGuRWLZnC6Zg2SzMI /nsA== X-Gm-Message-State: AJaThX6hwa3jb/cPWqFzdrW8LCv+tviyhqhuNut613L3yuT5zyd82h+P dJSsva1TGsrLObw7StbKiJSLbnOojiSRdGUUKB9jpwS3 X-Google-Smtp-Source: AGs4zMbJm0gF17ersF1ewY9u3bIF+fktM/SYHVG8/E6bl9ABxxfjyIkcwjk0SlhX3GkJaVfTpUCTT/c2r3g3Hfevmeo= X-Received: by 10.107.81.24 with SMTP id f24mr5841036iob.63.1512009078633; Wed, 29 Nov 2017 18:31:18 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 18:31:17 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 19:31:17 -0700 X-Google-Sender-Auth: DycRMVjGxUxf7RZ6dh0eK5QDm0U Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 02:31:19 -0000 On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb > wrote: > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > > >> > wrote: >> > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < >> shawn.webb@hardenedbsd.org> >> > > > wrote: >> > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up >> to >> > > > > this line: >> > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. >> > > > >> > > > >> > > > Which snapshot is that? Boot1 was broken until recently. >> > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img >> > > >> > > It also happens on latest HEAD, so it would appear to still be broken. >> > >> > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing the >> > latter, but wanted to make sure. If so, then we're past the point where >> > boot1.efi would have failed (besides, it was fixed before that >> snapshot). >> >> With DEBUG turned on for stand/fdt: >> >> Booting [/boot/kernel/kernel]... >> fdt_copy(): fdt_copy va 0x01208000 >> fdt_setup_fdtp(): fdt_setup_fdtp() >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) >> Using DTB provided by EFI at 0x801fe00000. >> Loaded the platform dtb: 0x81f56f1630. >> fdt_fixup(): fdt_fixup() >> >> ^ hangs after that message > > > That doesn't sound like anything I've changed, but it could well be... I > think to find this breakage, you may need to bisect backwards along stand / > sys/boot until we find the spot where it broke. > There's been several conversations on IRC about how others are hitting a scheduler bug, at least on x86. hps' fix seems to do the trick for their issues. Author: hselasky Date: Wed Nov 29 23:28:40 2017 +0000 The sched_add() function is not only used when the thread is initially started, but also by the turnstiles to mark a thread as runnable for all locks, for instance sleepqueues do: setrunnable()->sched_wakeup()->sched_add() In r326218 code was added to allow booting from non-zero CPU numbers by setting the ts_cpu field inside the ULE scheduler's sched_add() function. This had an undesired side-effect that prior sched_pin() and sched_bind() calls got disregarded. This patch fixes the initialization of the ts_cpu field for the ULE scheduler to only happen once when the initial thread is constructed during system init. Forking will then later on ensure that a valid ts_cpu value gets copied to all children. Reviewed by: jhb, kib Discussed with: nwhitehorn MFC after: 1 month Differential revision: https://reviews.freebsd.org/D13298 Sponsored by: Mellanox Technologies git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f is the fix.... But the bug it fixes post-dates the snapshot, so maybe this isn't the same thing... Warner From owner-freebsd-arm@freebsd.org Thu Nov 30 07:35: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 AE344DFB660 for ; Thu, 30 Nov 2017 07:35:26 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 986CA797C2 for ; Thu, 30 Nov 2017 07:35:26 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 97B61DFB65E; Thu, 30 Nov 2017 07:35:26 +0000 (UTC) Delivered-To: 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 9724ADFB65D; Thu, 30 Nov 2017 07:35:26 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7592F797C1; Thu, 30 Nov 2017 07:35:26 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id BFDD63010; Thu, 30 Nov 2017 07:35:25 +0000 (UTC) From: Jan Beich To: Mark Linimon Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, arm@freebsd.org Subject: Re: svn commit: r455173 - in head: multimedia/ffmpeg multimedia/libass net/asterisk13 net/freerdp x11/rxvt-unicode References: <201711300702.vAU72oII050996@repo.freebsd.org> Date: Thu, 30 Nov 2017 08:35:20 +0100 In-Reply-To: <201711300702.vAU72oII050996@repo.freebsd.org> (Mark Linimon's message of "Thu, 30 Nov 2017 07:02:50 +0000 (UTC)") Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 07:35:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mark Linimon writes: > Author: linimon > Date: Thu Nov 30 07:02:49 2017 > New Revision: 455173 > URL: https://svnweb.freebsd.org/changeset/ports/455173 > > Log: > For ports that set particular flags/options for armv6, also set them > for armv7. [...] > Modified: head/multimedia/ffmpeg/Makefile > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/multimedia/ffmpeg/Makefile Thu Nov 30 07:01:14 2017 (r455172) > +++ head/multimedia/ffmpeg/Makefile Thu Nov 30 07:02:49 2017 (r455173) > @@ -54,6 +54,7 @@ OPTIONS_GROUP_LICENSE=3D GPL3 NONFREE >=20=20 > OPTIONS_DEFINE_amd64=3D MMX SSE > OPTIONS_DEFINE_armv6=3D VFP NEON > +OPTIONS_DEFINE_armv7=3D VFP NEON Are you sure about disabling VFP and NEON by default? If so bump PORTREVISI= ON. Otherwise, back this part out. $ cc -v FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM = 5.0.0svn) Target: armv7-unknown-freebsd12.0-gnueabihf Thread model: posix InstalledDir: /nxb-bin/usr/bin $ cc -dM -E -&1 | fgrep -i -e vfp -e neon #define __ARM_NEON 1 #define __ARM_NEON_FP 0x4 #define __ARM_NEON__ 1 #define __ARM_PCS_VFP 1 #define __ARM_VFPV3__ 1 #define __VFP_FP__ 1 > +CONFIGURE_ARGS_armv7=3D --disable-fast-unaligned Can anyone on arm@ list confirm bug 200609 affects armv7 as well? I'd prefer to avoid the pessimization otherwise. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJaH7S4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREQjQ0MzY3NEM3RDIzNTc4NkUxNDkyQ0VF NEM3Nzg4MzQ3OURCRERCAAoJEOTHeINHnb3bRicH/3tsVTZn6/qshkhGP8xAomGI Bb3LFHXTbTgS2nPUbJrlEqGh+6NIz2VOldr3pm72bIjpaEwF99wruLz6avRPYVfz 6uaEmmkesW2BGGqxjjikbxyydz5wFwBKIU22Byz7S4JHBwkZXpv3UbS5chyWmRfT yUwzomjOjQIW7CSjJU3dr5ZIAd1Ke/L0+b2aRR6OiC023vGA8hqhrt5vCj7GlapT aSe9Fficq11Kz2XqmyR7ekyipMrQdj0bqTMqdK1LgP5Y+LCLbu7wVNlXta3TV2DY AJARKv/U2dg20stVeO6DIWOTMJJ2/DM1MpYnodQtbbgsJskIn4TCcnibGaWDMDc= =exCS -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arm@freebsd.org Thu Nov 30 07:52:21 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 A37A6DFBC91 for ; Thu, 30 Nov 2017 07:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 878BE7A13B for ; Thu, 30 Nov 2017 07:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id 86C7CDFBC90; Thu, 30 Nov 2017 07:52:21 +0000 (UTC) Delivered-To: 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 84A01DFBC8F for ; Thu, 30 Nov 2017 07:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-164.reflexion.net [208.70.210.164]) (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 358427A137 for ; Thu, 30 Nov 2017 07:52:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14807 invoked from network); 30 Nov 2017 07:52:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Nov 2017 07:52:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 30 Nov 2017 02:52:11 -0500 (EST) Received: (qmail 25312 invoked from network); 30 Nov 2017 07:52:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Nov 2017 07:52:11 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 44012EC9316; Wed, 29 Nov 2017 23:52:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r455173 - in head: multimedia/ffmpeg multimedia/libass net/asterisk13 net/freerdp x11/rxvt-unicode From: Mark Millard In-Reply-To: Date: Wed, 29 Nov 2017 23:52:09 -0800 Cc: Mark Linimon , svn-ports-head@freebsd.org, arm@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201711300702.vAU72oII050996@repo.freebsd.org> To: Jan Beich X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 07:52:21 -0000 On 2017-Nov-29, at 11:35 PM, Jan Beich wrote: > Mark Linimon writes: >=20 >> Author: linimon >> Date: Thu Nov 30 07:02:49 2017 >> New Revision: 455173 >> URL: https://svnweb.freebsd.org/changeset/ports/455173 >>=20 >> Log: >> For ports that set particular flags/options for armv6, also set them >> for armv7. > [...] >> Modified: head/multimedia/ffmpeg/Makefile >> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/multimedia/ffmpeg/Makefile Thu Nov 30 07:01:14 2017 = (r455172) >> +++ head/multimedia/ffmpeg/Makefile Thu Nov 30 07:02:49 2017 = (r455173) >> @@ -54,6 +54,7 @@ OPTIONS_GROUP_LICENSE=3D GPL3 NONFREE >>=20 >> OPTIONS_DEFINE_amd64=3D MMX SSE >> OPTIONS_DEFINE_armv6=3D VFP NEON >> +OPTIONS_DEFINE_armv7=3D VFP NEON >=20 > Are you sure about disabling VFP and NEON by default? If so bump = PORTREVISION. > Otherwise, back this part out. >=20 > $ cc -v > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) > Target: armv7-unknown-freebsd12.0-gnueabihf > Thread model: posix > InstalledDir: /nxb-bin/usr/bin >=20 > $ cc -dM -E -&1 | fgrep -i -e vfp -e neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > #define __ARM_PCS_VFP 1 > #define __ARM_VFPV3__ 1 > #define __VFP_FP__ 1 >=20 >> +CONFIGURE_ARGS_armv7=3D --disable-fast-unaligned >=20 > Can anyone on arm@ list confirm bug 200609 affects armv7 as well? > I'd prefer to avoid the pessimization otherwise. I'm unsure of the detailed current status but there was a time when the save/restore of VFP/NEON was not working across context switches of at least some kinds. Bugzilla 217611 was for signal delivery (fixed) but I'm not sure that was all there was to it: There are some notes there about struct fpreg as well. Also did head -r324660 (and prior work) get its MFC? There is no commit-hook entry for the MFC listed in bugzilla 217611. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Nov 30 07:56: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 A47F3DFBE40 for ; Thu, 30 Nov 2017 07:56:08 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB107A3A2 for ; Thu, 30 Nov 2017 07:56:08 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 733F6DFBE3D; Thu, 30 Nov 2017 07:56:08 +0000 (UTC) Delivered-To: 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 72A95DFBE3C; Thu, 30 Nov 2017 07:56:08 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 EE3077A3A1; Thu, 30 Nov 2017 07:56:07 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id g75so11264988wme.0; Wed, 29 Nov 2017 23:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3kK2wrccPsWfuDYcMCURoyaJZIZzJ2Di1UcIzQzOTLg=; b=roZ56VXGMEb1W3kTnb/znJhqZ1SuveGzGDUkGDgDBy7pvef2MpUYQ8VrKNMeAomZ+q pDL1CA6i17jLqNaWnw9//voPwmdukXlG/BnwHfGr+PS63PvBALqgKTUApXL7sg3GWvqj PMFu6kv31m8BvfajsmDkcoqnuQJ4KZuRrDtw+CHqyU8ZI9GjzOi2Cv8sZTk7OfgxnZxO hUxdvpdk7OWuUV6Pndn8ZPsvMicbUYVxzzqtYOWIbujojFp2hfLAQwqb1k+Z+EYXxVGv DYthsOYZG29wmhuiTiDUh4JZ49KWyrOfuAWwvy8mxvfAWKxTqs9h+dI0TXXBur3Ngg8F 9inw== 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:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3kK2wrccPsWfuDYcMCURoyaJZIZzJ2Di1UcIzQzOTLg=; b=Lni759/VTFOpD7qfEmqTBexPTK1QaXP27W//UA+OXBhSFCJcM2V9oBEmaNKCgVbFEE lXnofKk+8eFQmoH6SRE1X/kVYB6jDNKLhAplBi59gRA7O1Qtxnt2HkDHNAt4LGbeKEOT cRhJc0kF6uFROMmotPORNG6fb+5F6PUZ0z6w4zNxFXmjs1pj8KGTf5A7ZYhjmbZQiVld tdb7FpPTQR7VdVnxB4MM0BztDn/jRj31kIO7v74RyAoI3FcBipUiSBWUIzF/RLZuFV7g MGmvfGTlolY9gNi2QPLV0J7PShPtUaWjqGlebcuiXnUXgAQ7HjUZiHJsToFT9JQm2v0c nlMw== X-Gm-Message-State: AJaThX4K7RitCkU/Rl+ns4FGsklaTtQtWzz3GCq15Rh1eVu32gG/NGvo mpEGQ2Bh37PLUhnmVTzbHIkfSqAooQo= X-Google-Smtp-Source: AGs4zMacNGKQaF+JipM6ELLNVAshp7WgYqIot63u3YNAVkIj3CS7kwHz6DfT8pbumJyLkIsC6GrFiQ== X-Received: by 10.80.170.70 with SMTP id p6mr11533318edc.203.1512028565851; Wed, 29 Nov 2017 23:56:05 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id m48sm2790086edd.7.2017.11.29.23.56.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 23:56:05 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: svn commit: r455173 - in head: multimedia/ffmpeg multimedia/libass net/asterisk13 net/freerdp x11/rxvt-unicode To: Jan Beich , Mark Linimon Cc: svn-ports-head@freebsd.org, arm@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org References: <201711300702.vAU72oII050996@repo.freebsd.org> Message-ID: Date: Thu, 30 Nov 2017 08:56:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 07:56:08 -0000 On 30.11.2017 8:35, Jan Beich wrote: > Mark Linimon writes: > >> Author: linimon >> Date: Thu Nov 30 07:02:49 2017 >> New Revision: 455173 >> URL: https://svnweb.freebsd.org/changeset/ports/455173 >> >> Log: >> For ports that set particular flags/options for armv6, also set them >> for armv7. > [...] >> Modified: head/multimedia/ffmpeg/Makefile >> ============================================================================== >> --- head/multimedia/ffmpeg/Makefile Thu Nov 30 07:01:14 2017 (r455172) >> +++ head/multimedia/ffmpeg/Makefile Thu Nov 30 07:02:49 2017 (r455173) >> @@ -54,6 +54,7 @@ OPTIONS_GROUP_LICENSE= GPL3 NONFREE >> >> OPTIONS_DEFINE_amd64= MMX SSE >> OPTIONS_DEFINE_armv6= VFP NEON >> +OPTIONS_DEFINE_armv7= VFP NEON > > Are you sure about disabling VFP and NEON by default? If so bump PORTREVISION. > Otherwise, back this part out. > It's not enabling instead of disabling ? > $ cc -v > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) > Target: armv7-unknown-freebsd12.0-gnueabihf > Thread model: posix > InstalledDir: /nxb-bin/usr/bin > > $ cc -dM -E -&1 | fgrep -i -e vfp -e neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > #define __ARM_PCS_VFP 1 > #define __ARM_VFPV3__ 1 > #define __VFP_FP__ 1 > >> +CONFIGURE_ARGS_armv7= --disable-fast-unaligned > > Can anyone on arm@ list confirm bug 200609 affects armv7 as well? > I'd prefer to avoid the pessimization otherwise. > We supports unaligned access for armv6 starting from r300701 so yes, it's supported for armv7 from beginning. From owner-freebsd-arm@freebsd.org Thu Nov 30 08: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 BDDB1DFC709 for ; Thu, 30 Nov 2017 08:14:31 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A99B17AC8A for ; Thu, 30 Nov 2017 08:14:31 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A5D48DFC708; Thu, 30 Nov 2017 08:14:31 +0000 (UTC) Delivered-To: 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 A54E6DFC707; Thu, 30 Nov 2017 08:14:31 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 829E47AC89; Thu, 30 Nov 2017 08:14:31 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id A870538E6; Thu, 30 Nov 2017 08:14:30 +0000 (UTC) From: Jan Beich To: Michal Meloun Cc: Mark Linimon , mmel@freebsd.org, svn-ports-head@freebsd.org, arm@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r455173 - in head: multimedia/ffmpeg multimedia/libass net/asterisk13 net/freerdp x11/rxvt-unicode References: <201711300702.vAU72oII050996@repo.freebsd.org> Date: Thu, 30 Nov 2017 09:14:27 +0100 In-Reply-To: (Michal Meloun's message of "Thu, 30 Nov 2017 08:56:05 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 08:14:31 -0000 Michal Meloun writes: > On 30.11.2017 8:35, Jan Beich wrote: >> Mark Linimon writes: >> >>> Author: linimon >>> Date: Thu Nov 30 07:02:49 2017 >>> New Revision: 455173 >>> URL: https://svnweb.freebsd.org/changeset/ports/455173 >>> >>> Log: >>> For ports that set particular flags/options for armv6, also set them >>> for armv7. >> [...] >>> Modified: head/multimedia/ffmpeg/Makefile >>> ============================================================================== >>> --- head/multimedia/ffmpeg/Makefile Thu Nov 30 07:01:14 2017 (r455172) >>> +++ head/multimedia/ffmpeg/Makefile Thu Nov 30 07:02:49 2017 (r455173) >>> @@ -54,6 +54,7 @@ OPTIONS_GROUP_LICENSE= GPL3 NONFREE >>> >>> OPTIONS_DEFINE_amd64= MMX SSE >>> OPTIONS_DEFINE_armv6= VFP NEON >>> +OPTIONS_DEFINE_armv7= VFP NEON >> >> Are you sure about disabling VFP and NEON by default? If so bump PORTREVISION. >> Otherwise, back this part out. >> > It's not enabling instead of disabling ? ffmpeg detects VFP and NEON during configure. By exposing the options without adding to defaults the port appends --disable-vfp --disable-neon. Build logs: - r455173 (this commit): http://sprunge.us/JjKT - r455176 (back out): http://sprunge.us/SUKJ >>> +CONFIGURE_ARGS_armv7= --disable-fast-unaligned >> >> Can anyone on arm@ list confirm bug 200609 affects armv7 as well? >> I'd prefer to avoid the pessimization otherwise. >> > We supports unaligned access for armv6 starting from r300701 so yes, > it's supported for armv7 from beginning. Mark, can you back this part out as well? From owner-freebsd-arm@freebsd.org Thu Nov 30 08:45: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 5E2A1DFD169 for ; Thu, 30 Nov 2017 08:45:09 +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 484DB7C04F for ; Thu, 30 Nov 2017 08:45:09 +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 vAU8j9Fq048394 for ; Thu, 30 Nov 2017 08:45:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 219110] www/firefox-i18n and www/firefox-esr-i18n: mark BROKEN on aarch64 due to "firefox --version" crashing Date: Thu, 30 Nov 2017 08:45:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 08:45:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219110 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Nov 30 23:03: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 AD5B9DEC29D for ; Thu, 30 Nov 2017 23:03:46 +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 9AE537A932 for ; Thu, 30 Nov 2017 23:03:46 +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 vAUN3kUT011482 for ; Thu, 30 Nov 2017 23:03:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224008] UBLDR doesn't save registers correctly in start.S Date: Thu, 30 Nov 2017 23:03:46 +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.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: parakleta@darkreality.org 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 23:03:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224008 Bug ID: 224008 Summary: UBLDR doesn't save registers correctly in start.S Product: Base System Version: 11.1-RELEASE Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: parakleta@darkreality.org Created attachment 188440 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188440&action= =3Dedit Save and Restore U-Boot registers. Using `ubldr.bin` I was getting intermittent behaviour depending on which options I compiled into U-Boot. Eventually I discovered that the issue is = that the entry point in `sys/boot/arm/uboot/start.S` is not correctly saving and restoring registers. Most importantly the r9 register is the base of the global data and this is not typically a callee-saved register, but must be = for U-Boot. There is a change to this file on April 2 by "ian" which saves the argument= and return address but it doesn't go far enough. My patch is to applied to the state before that patch. Essentially the important caller-saved registers are pushed (r0, r1, r9, lr) before the relocation call, and popped after. Then r8/r9 are saved as usual for the syscall trampoline, and lr is stored in r8 (now free) as a callee-s= aved value before calling into `main`. The call to `main` can no longer be a tail call because we must restore r9 especially after main returns (although since we have used r8 to hold lr we must also restore this). I don't know how this affects the ELF version, but this patch is critical f= or the correct functioning of the binary version of UBLDR. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Dec 1 21:50:25 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 0F811E6BD49 for ; Fri, 1 Dec 2017 21:50:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 B7206724F8 for ; Fri, 1 Dec 2017 21:50:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22c.google.com with SMTP id b10so7110983qti.11 for ; Fri, 01 Dec 2017 13:50:24 -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=uWIewsoVuQlZiS/UR4a7GOydBK9vZ7E3PxwWZhk1i8k=; b=fgaPjAG7FrtmvP6F98QlPFcxVraJo/GKeTbxEWW5EA8IaHbMIJUZAolr6KdM4h636t RRhdZ+Hwmx5GXsQkqw+nZHpTrfx04QmTtz9+HoSKosNpossTgTDSROeU1ZsAf46eUSC4 m1IaWS2DwrlwiakcKJVvv6dZ9Tlyg9WT+bJinZpaOf5OGwNvZFm7R5xXKhogxqDKoYDe u2mvjiME1yAngG8tS2CFNuB4Jdq3hlIAX+aZFZxBuXJ/TsxW/gQ3BCFCdXvQ6hw3W6Qs i/HuKGNGEAoWdnfXMMlmVqXKsDY+0bargYLm8d2z/XuQzFWFzI/GKo9PPgzcMvXf5PQJ MFtg== 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=uWIewsoVuQlZiS/UR4a7GOydBK9vZ7E3PxwWZhk1i8k=; b=LzzhHGWOKsWGShuFk8Hfhso45Qklnt48oD7J4ZMWbHMfdyMYuYGYoKL9d6wPt9ADNf f5BCHEQU/GfydvSA21D6N8tNej/aWWQLFrHDjlJAwkfjFvVbDnLBmQSauPT0BnpdWW2p +fRWtt7m/jdcH52rCSmtui1DrdqtXL8CLL3GwnTIAl1KXvhtDTKdsSq/yDOaAEuAzj84 bFO802bvk6+0smI8JGZsvO6/hEJt2eHEaRGC89jZfFO8qgHbfWGpYeQKWllmWOkN68ww F0XExNf/cvNDqBZdFzq5Iw+KaKVKr3QW+z1BWM8RPZTclhT6DCjbmR5jp10/wkg1kqRY KgYw== X-Gm-Message-State: AKGB3mJYvBmvDyJMNvyFyApiNG5eTrE051/rPzNkOZZqG93YiNR3fT1C vDt5JV5Q1Sx1UdlAbp5vMtyrrQ== X-Google-Smtp-Source: AGs4zMYyTb2MWV0Ss5tcHSYzSvCKYdUl3gpbdr/F2MB+U15LzmayoF5tBPReTUzaIm2syp3h0hdoqw== X-Received: by 10.200.42.122 with SMTP id l55mr8900627qtl.66.1512165023548; Fri, 01 Dec 2017 13:50:23 -0800 (PST) Received: from mutt-hbsd (tor-exit4-readme.dfri.se. [171.25.193.78]) by smtp.gmail.com with ESMTPSA id n64sm5188341qkf.49.2017.12.01.13.50.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Dec 2017 13:50:21 -0800 (PST) Date: Fri, 1 Dec 2017 16:49:55 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yaae3ulvhny5nors" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:50:25 -0000 --yaae3ulvhny5nors Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: >=20 > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb > > wrote: > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb >> > > >> > wrote: > >> > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > >> shawn.webb@hardenedbsd.org> > >> > > > wrote: > >> > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapsho= t, > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots = up > >> to > >> > > > > this line: > >> > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > >> > > > > >> > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > >> > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > >> > > > >> > > It also happens on latest HEAD, so it would appear to still be bro= ken. > >> > > >> > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing = the > >> > latter, but wanted to make sure. If so, then we're past the point wh= ere > >> > boot1.efi would have failed (besides, it was fixed before that > >> snapshot). > >> > >> With DEBUG turned on for stand/fdt: > >> > >> Booting [/boot/kernel/kernel]... > >> fdt_copy(): fdt_copy va 0x01208000 > >> fdt_setup_fdtp(): fdt_setup_fdtp() > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > >> Using DTB provided by EFI at 0x801fe00000. > >> Loaded the platform dtb: 0x81f56f1630. > >> fdt_fixup(): fdt_fixup() > >> > >> ^ hangs after that message > > > > > > That doesn't sound like anything I've changed, but it could well be... I > > think to find this breakage, you may need to bisect backwards along sta= nd / > > sys/boot until we find the spot where it broke. > > >=20 > There's been several conversations on IRC about how others are hitting a > scheduler bug, at least on x86. hps' fix seems to do the trick for their > issues. >=20 > Author: hselasky > Date: Wed Nov 29 23:28:40 2017 +0000 >=20 > The sched_add() function is not only used when the thread is initially > started, but also by the turnstiles to mark a thread as runnable for > all locks, for instance sleepqueues do: > setrunnable()->sched_wakeup()->sched_add() >=20 > In r326218 code was added to allow booting from non-zero CPU numbers > by setting the ts_cpu field inside the ULE scheduler's sched_add() > function. This had an undesired side-effect that prior sched_pin() and > sched_bind() calls got disregarded. This patch fixes the > initialization of the ts_cpu field for the ULE scheduler to only > happen once when the initial thread is constructed during system > init. Forking will then later on ensure that a valid ts_cpu value gets > copied to all children. >=20 > Reviewed by: jhb, kib > Discussed with: nwhitehorn > MFC after: 1 month > Differential revision: https://reviews.freebsd.org/D13298 > Sponsored by: Mellanox Technologies >=20 >=20 > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >=20 > is the fix.... But the bug it fixes post-dates the snapshot, so maybe this > isn't the same thing... Definitely is not the same thing. I've so far got it printf'd to where the uefi loader jumps into the kernel's entry point. So the loader itself might be fine. Something in the kernel, then, is going funky. Booting in verbose mode does not provide any additional input. Here's the output I get (some of the output is from printf's I've done): FreeBSD/arm64 EFI loader, Revision 1.1 (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7e0a78 data=3D0xaad80+0x443f62 syms=3D[0x8+0x1= 0ec78+0x8+0x1021d4] /boot/entropy size=3D0x1000 /boot/kernel/zfs.ko text=3D0x99070 text=3D0x130390 data=3D0x21ff8+0x9ef98 s= yms=3D[0x8+0x22c68+0x8+0x1b99b] /boot/kernel/opensolaris.ko text=3D0x1330 text=3D0xd00 data=3D0x10160+0x125= d0 syms=3D[0x8+0xff0+0x8+0x8d8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x801fe00000. fdt_copy returned. dtb_size is 9060. bi_load finished. err: 0 dev_cleanup finished About to call into the entry point at 0x81ee601000 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 --yaae3ulvhny5nors Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlohzoEACgkQaoRlj1JF bu4hQRAAgL0VhELWc/KkhQSEHEN1x44yfRuqBIeWSz39SLqA5g+YTnpheJ8KSfo4 QAjt1tKYZPaq+y5Q1sWDhF2y5G2TCIptmwZ3g3ks0FkrhAV7F7bPPWqL94WP4yZz PDJtzIWMiSEh/2mBAAsT2PpJiYaEoc+bEs6QqFB+xM/LK/4rTfZkmJVDR35eoBoh e/6SIJy5zc9bD/dbVlpwkJSXMk+kwB6aLNnXw13F09s6OXMe8sia2kfOAF6WUG+R OWAIldEVIdHLr1m4SYe6jzgiTEx1+IasHGVQN8NdlkCQhdQIaiAYEOIq84tewqsX +pEM1uSqwsyaOZybn+Rlbc/p4VhCIUf60lLwbZqyz6r6zZ7SJ1nmFNPJCHHZqlhM 04mcWR8pNP8CXvACZ0DAE3zIjiDI2zifany2oMKMxa536e5bqUImJrcVo1jPhZ7X 0BlY2yJm6SIYTObSK2EmSZc3w8NLkgFj5AQHJYuhMz8Cb1FirSxYxffdHHyU9UqF 1y4Rf09Is2l8vPsMVIXfHcyD5Ttxi4Y6ixmpj+d4NZS8bLgPQLUn3imvZRZ9BkX8 AG67PhTvfYAKFuU0bVjQEc4aOQw8E3+0OBaf6Qi5wOdpKWH2+CuuTlUPMDQzAqJT TUlfsTuwUyVEHmxNfRDKvG6OqIem0+r933CJ7r8sEu5eN3x68VM= =wEoZ -----END PGP SIGNATURE----- --yaae3ulvhny5nors-- From owner-freebsd-arm@freebsd.org Fri Dec 1 21:53: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 66B38E6C0F4 for ; Fri, 1 Dec 2017 21:53:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 3259772986 for ; Fri, 1 Dec 2017 21:53:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id d16so12794025iob.4 for ; Fri, 01 Dec 2017 13:53:55 -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=v0J7ha1Llo4zf5t0skenV3NOwG8sqBvKamPXAMxqDTY=; b=Bk4fjPgrxHanYjQNZUZIUfucOWzIpzlM+CSUes2s/zfsZ7G5UELlnkZ7YSZFQI34mr Slc9dA0JoHOBSF5sagetp6VQrnKgC9EXTYLKdWe4SCuaUJT2fxQuOSM/uet5kGSaVI1g HbVzP2y+BSuGiaEpz+QSYmRXusLPjUehTmA5oXPBFKUCBLfh7QYgrMoHRd4GLnjNv/5S h9Xkd1QFJb0+OSr3nVWE5qPob9t9d6n98A6q1NMxwSr082VBe/tRjYhzpb72iBDoDyEh 2HEIiwVnzgIuKHdJTF+Z4dFq/Uihi5FfNMMRy9WeW6SdsnlGMHDZP1avTwOxtw5Aht5B XOWg== 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=v0J7ha1Llo4zf5t0skenV3NOwG8sqBvKamPXAMxqDTY=; b=ToU326eZxhYoreCFWFoniGm1EPpV68J2NGDxzfKaG0eQuQis5A01QZYGqYDIeKJiff jid9z43PMIu7nwJ2R4MBMeSqqQD2IFQQ0HU1D+4BL46TpEltWI30mi4lR7uRPMU5vmZJ sosB7TjzzLgZGDsN6hG4j7Q72NWmO9oL7Q/DEotXNyCkKhRflYLZPB7PM55q3GDjvjS/ pEYTAMmZcY+Oqu3GG7/O5LckuIsz7YSu2Fe9bPwV20yejik1WFU+YQLQqeZD6r61TflB vZT6E98o0B3wQRoY2Jdck2RfpmqypsQ9xT1hxVrjX4BHXvce9PTaFe17QyIo/kM2L1+6 JSdw== X-Gm-Message-State: AKGB3mKbufgBRcaZRbNkwiIKg44IkuBjX6gv971sCLDU0qBkeP0tJFwi aJv+yIBJtRX1G94Tz4C0RejUEa64JrRO3Vs1mga5ng== X-Google-Smtp-Source: AGs4zMYShFlbLx5OCs+EKA2fCcAUKtFC8BpnU3TvWA6BmZJL7HVd3gqdhcnuU0Pw5n6fSQ9AjrgvAsQIRA7rdBeqgz8= X-Received: by 10.107.52.140 with SMTP id b134mr1715801ioa.291.1512165234381; Fri, 01 Dec 2017 13:53:54 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 1 Dec 2017 13:53:53 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> From: Warner Losh Date: Fri, 1 Dec 2017 14:53:53 -0700 X-Google-Sender-Auth: GnENBzzMvPJUa1FIQuWQfhGN_FQ Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:53:55 -0000 On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > shawn.webb@hardenedbsd.org> > > > wrote: > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > shawn.webb@hardenedbsd.org > > >> > > > >> > wrote: > > >> > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > >> shawn.webb@hardenedbsd.org> > > >> > > > wrote: > > >> > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > snapshot, > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots > up > > >> to > > >> > > > > this line: > > >> > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > > >> > > > > > >> > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > >> > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > >> > > > > >> > > It also happens on latest HEAD, so it would appear to still be > broken. > > >> > > > >> > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing > the > > >> > latter, but wanted to make sure. If so, then we're past the point > where > > >> > boot1.efi would have failed (besides, it was fixed before that > > >> snapshot). > > >> > > >> With DEBUG turned on for stand/fdt: > > >> > > >> Booting [/boot/kernel/kernel]... > > >> fdt_copy(): fdt_copy va 0x01208000 > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > > >> Using DTB provided by EFI at 0x801fe00000. > > >> Loaded the platform dtb: 0x81f56f1630. > > >> fdt_fixup(): fdt_fixup() > > >> > > >> ^ hangs after that message > > > > > > > > > That doesn't sound like anything I've changed, but it could well be... > I > > > think to find this breakage, you may need to bisect backwards along > stand / > > > sys/boot until we find the spot where it broke. > > > > > > > There's been several conversations on IRC about how others are hitting a > > scheduler bug, at least on x86. hps' fix seems to do the trick for their > > issues. > > > > Author: hselasky > > Date: Wed Nov 29 23:28:40 2017 +0000 > > > > The sched_add() function is not only used when the thread is > initially > > started, but also by the turnstiles to mark a thread as runnable for > > all locks, for instance sleepqueues do: > > setrunnable()->sched_wakeup()->sched_add() > > > > In r326218 code was added to allow booting from non-zero CPU numbers > > by setting the ts_cpu field inside the ULE scheduler's sched_add() > > function. This had an undesired side-effect that prior sched_pin() > and > > sched_bind() calls got disregarded. This patch fixes the > > initialization of the ts_cpu field for the ULE scheduler to only > > happen once when the initial thread is constructed during system > > init. Forking will then later on ensure that a valid ts_cpu value > gets > > copied to all children. > > > > Reviewed by: jhb, kib > > Discussed with: nwhitehorn > > MFC after: 1 month > > Differential revision: https://reviews.freebsd.org/D13298 > > Sponsored by: Mellanox Technologies > > > > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > > is the fix.... But the bug it fixes post-dates the snapshot, so maybe > this > > isn't the same thing... > > Definitely is not the same thing. I've so far got it printf'd to where > the uefi loader jumps into the kernel's entry point. So the loader > itself might be fine. Something in the kernel, then, is going funky. > > Booting in verbose mode does not provide any additional input. > > Here's the output I get (some of the output is from printf's I've > done): > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x7e0a78 data=0xaad80+0x443f62 > syms=[0x8+0x10ec78+0x8+0x1021d4] > /boot/entropy size=0x1000 > /boot/kernel/zfs.ko text=0x99070 text=0x130390 data=0x21ff8+0x9ef98 > syms=[0x8+0x22c68+0x8+0x1b99b] > /boot/kernel/opensolaris.ko text=0x1330 text=0xd00 data=0x10160+0x125d0 > syms=[0x8+0xff0+0x8+0x8d8] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x801fe00000. > fdt_copy returned. dtb_size is 9060. > bi_load finished. err: 0 > dev_cleanup finished > About to call into the entry point at 0x81ee601000 > You might try booting the same kernel off a small UFS partition. There's a tiny chance that the loader didn't load it right, but more likely the kernel is borked. Maybe DTB issues? Maybe something else... A quick test like that would remove ZFS from the equation, even if it's just a USB stick... Warner From owner-freebsd-arm@freebsd.org Fri Dec 1 21:55: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 B0829E6C22F for ; Fri, 1 Dec 2017 21:55:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 3E8FB72B50 for ; Fri, 1 Dec 2017 21:55:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wr0-x230.google.com with SMTP id o2so11505464wro.5 for ; Fri, 01 Dec 2017 13:55:59 -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=nJOil9JJd2wzxv0PujzibHIHszsTmNoZi0+vgYTIkNI=; b=iRzxmD6TFpJGZWstvKPfw7o/3DXLnHbRsZ7C6entpQpqcmr4GV4HGoPqwRhDzBC9O5 1xdTnogad0SKni4yJFe5L8fHgHrLLrYq/vtJfKmihlrH6QzCwL0ADU9sjCxAbTBa9PmQ dAqp5bmKPjWCLZWmu333zQaYD8K0laGjQdTBgNXw7RyvLfUQmMv7dqLLOiv8OZQ6/hex wS9/Eersxns2j8AfRtlUXQM0Lp4drKMbGgDh5OnEUqLhKCV1ANaaw1cZvfOvKD35syQb 1kXpTRLrHxF2B5xXA46T+tilKSor8tWZ1vQ8gdMfy36/CAHHCr5rRhbFqivUtPL5GXoC hURg== 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=nJOil9JJd2wzxv0PujzibHIHszsTmNoZi0+vgYTIkNI=; b=ftTSWjqxwbIoMN1s5VdqVZPcR4ggO93SC0Sjel81EOg+DETktwC0cZ0gT1YQRjG3lm RCUEFJdJlYfCGZ1QqwTJuyqPF72mLGjW2U2WIo3UWbBCJ5M9togfIG+Oh63fGygo390w 1g6Qde+NC1UllGhXB82kYY8ID8VpRd0IN0N77afewigxRpPnW3c1tsXdhE2psYSi9wAH bUCkZEd5YUrX79qIu+k2B6qArzsMD4bQv7lsH1/44UPOr6kxFyi34CcQQktbaxeGIHhl 2mZ+zfRIFKnomNU4ZMA0gJcXcsmGhLQ8LVIB9nQR0BgxNT1p6Fi/+qgKNBh9Wi7tqhPi BDQA== X-Gm-Message-State: AJaThX7ZgeUCinBjkqxHg+DzNTUNJa8W74QEBXFt/85yYXEiE+2oLVnU jTnaG2rROtJXOz5+M0I909MGqw== X-Google-Smtp-Source: AGs4zMaeFPtHlWM8CsbCG5O8VgGKuoaIoAo6NGU2RkkhrE77NOsmN6WPTzLFf1fWbc/4xruckP6kXQ== X-Received: by 10.223.202.1 with SMTP id o1mr2132835wrh.233.1512165357151; Fri, 01 Dec 2017 13:55:57 -0800 (PST) Received: from mutt-hbsd ([65.19.167.130]) by smtp.gmail.com with ESMTPSA id h7sm6844047wrb.35.2017.12.01.13.55.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Dec 2017 13:55:56 -0800 (PST) Date: Fri, 1 Dec 2017 16:55:31 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171201215531.u4f2c4eno7z5irxj@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yxqbpbqi3jogdpsy" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:55:59 -0000 --yxqbpbqi3jogdpsy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 01, 2017 at 02:53:53PM -0700, Warner Losh wrote: > On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb > wrote: >=20 > > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > > > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > > shawn.webb@hardenedbsd.org> > > > > wrote: > > > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > > shawn.webb@hardenedbsd.org > > > >> > > > > >> > wrote: > > > >> > > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > > >> shawn.webb@hardenedbsd.org> > > > >> > > > wrote: > > > >> > > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > > snapshot, > > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It bo= ots > > up > > > >> to > > > >> > > > > this line: > > > >> > > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > > > >> > > > > > > >> > > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > > >> > > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.i= mg > > > >> > > > > > >> > > It also happens on latest HEAD, so it would appear to still be > > broken. > > > >> > > > > >> > > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guess= ing > > the > > > >> > latter, but wanted to make sure. If so, then we're past the point > > where > > > >> > boot1.efi would have failed (besides, it was fixed before that > > > >> snapshot). > > > >> > > > >> With DEBUG turned on for stand/fdt: > > > >> > > > >> Booting [/boot/kernel/kernel]... > > > >> fdt_copy(): fdt_copy va 0x01208000 > > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > > > >> Using DTB provided by EFI at 0x801fe00000. > > > >> Loaded the platform dtb: 0x81f56f1630. > > > >> fdt_fixup(): fdt_fixup() > > > >> > > > >> ^ hangs after that message > > > > > > > > > > > > That doesn't sound like anything I've changed, but it could well be= =2E.. > > I > > > > think to find this breakage, you may need to bisect backwards along > > stand / > > > > sys/boot until we find the spot where it broke. > > > > > > > > > > There's been several conversations on IRC about how others are hittin= g a > > > scheduler bug, at least on x86. hps' fix seems to do the trick for th= eir > > > issues. > > > > > > Author: hselasky > > > Date: Wed Nov 29 23:28:40 2017 +0000 > > > > > > The sched_add() function is not only used when the thread is > > initially > > > started, but also by the turnstiles to mark a thread as runnable = for > > > all locks, for instance sleepqueues do: > > > setrunnable()->sched_wakeup()->sched_add() > > > > > > In r326218 code was added to allow booting from non-zero CPU numb= ers > > > by setting the ts_cpu field inside the ULE scheduler's sched_add() > > > function. This had an undesired side-effect that prior sched_pin() > > and > > > sched_bind() calls got disregarded. This patch fixes the > > > initialization of the ts_cpu field for the ULE scheduler to only > > > happen once when the initial thread is constructed during system > > > init. Forking will then later on ensure that a valid ts_cpu value > > gets > > > copied to all children. > > > > > > Reviewed by: jhb, kib > > > Discussed with: nwhitehorn > > > MFC after: 1 month > > > Differential revision: https://reviews.freebsd.org/D13298 > > > Sponsored by: Mellanox Technologies > > > > > > > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > > > > is the fix.... But the bug it fixes post-dates the snapshot, so maybe > > this > > > isn't the same thing... > > > > Definitely is not the same thing. I've so far got it printf'd to where > > the uefi loader jumps into the kernel's entry point. So the loader > > itself might be fine. Something in the kernel, then, is going funky. > > > > Booting in verbose mode does not provide any additional input. > > > > Here's the output I get (some of the output is from printf's I've > > done): > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) > > EFI boot environment > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=3D0x7e0a78 data=3D0xaad80+0x443f62 > > syms=3D[0x8+0x10ec78+0x8+0x1021d4] > > /boot/entropy size=3D0x1000 > > /boot/kernel/zfs.ko text=3D0x99070 text=3D0x130390 data=3D0x21ff8+0x9ef= 98 > > syms=3D[0x8+0x22c68+0x8+0x1b99b] > > /boot/kernel/opensolaris.ko text=3D0x1330 text=3D0xd00 data=3D0x10160+0= x125d0 > > syms=3D[0x8+0xff0+0x8+0x8d8] > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Using DTB provided by EFI at 0x801fe00000. > > fdt_copy returned. dtb_size is 9060. > > bi_load finished. err: 0 > > dev_cleanup finished > > About to call into the entry point at 0x81ee601000 > > >=20 > You might try booting the same kernel off a small UFS partition. There's a > tiny chance that the loader didn't load it right, but more likely the > kernel is borked. Maybe DTB issues? Maybe something else... A quick test > like that would remove ZFS from the equation, even if it's just a USB > stick... UFS works fine and dandy. It's ZFS that's b0rked. 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 --yxqbpbqi3jogdpsy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlohz9IACgkQaoRlj1JF bu4oXw/9EOPJzkBWeiYIsnLFVg05wSQVIIuMyhYE/oEmnY0lK5H+muPK6t9ETqM+ AVEGxjEpmgeOCkzt3tOOrC5jul/PSR/XGpmVi68ho5KEbuOFD+UPjtN50cZJraSD Uusjl8jtFWBDAybQ78O43XIrr2710NQ0PTbeZYJouQnTvLz+MkVhMgKF37YglZOK 4CLqEMzEqwNIxj/tKRvJt+G6NB12xpN3mp8w9Svq/G10v7GjxZC7ikqsd5FLH6iP hWpyqqRtoucbCpn66Ahc98c32EHpMvwx2XffsddWb8g1Z/dSjxAD1j7mBLLHBVbV 1e/CB5S7Fyexei66/UZ47q0ZIqTtVGwhYE1LqMVdvLUimhtd4t06nWJeRGUDrr0C NZuLRBOUiY8suaI5oYizyg84m4hjfCoEK27Hye5aYizF6gAh/eodllfm7YHde+oT Nos1YTb2/axrS60ibUdhom3a1gD1TvUqVVkrdRCf1+ds0RfIgAHiAAsZ9qogEoIP PBeumYz6+4Waq44VUjD1QKoEy9AG6yj0plLp/n/Dt6AoViM0nOT4puYMuhbgps+i RjBIjn8JiToBYsNppn3Gv7GTn7vwEiqU2OyfFs4CH8SZ6MIvhhLOrQ16B8BuBEGm 7erXmEi8ZtfOZHtJ6MZlJTXj48OYP1TwUuvVwuvEmPAO9LF4Mqk= =+uXh -----END PGP SIGNATURE----- --yxqbpbqi3jogdpsy-- From owner-freebsd-arm@freebsd.org Fri Dec 1 21:57: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 08D00E6C385 for ; Fri, 1 Dec 2017 21:57:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 AE71D72D1D for ; Fri, 1 Dec 2017 21:57:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id 81so12813761iof.3 for ; Fri, 01 Dec 2017 13:57:36 -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=L/djtXyGqNW5OYK2j4g158lvJMlJeskAGwvn9f0JbPw=; b=Xar4QR37b3bWHwQOjkJn6bCogtURFqzKEkqG1r4Te9Q+HLXFSLWSDF0WrskbFFtwfN H+9I+REtPuhbDjObme8KG6ICQIf/OgRdAcZn7VlRU4g/7itmjunlNrIj4GOu5oPeId6j pxZO2FkEvQJoUzbEqewwas4Om1bF94+EC+pv50BVbgI5hLyJ7Yw/y3H5+3QelgI/cUWW SSsp9W2lrke1x+oFHhTEbLqiyiqcdfd48ZTCq2//WA4zf2xHrKO2ijN3XeEhpzJOpfOg fDLOA4bqpBL6VLwlhZt/85o9AK0QQcCbqMgxfpnfXiEaIheoW8KbQEDiX3Jt3iqJ8O8U Cqrw== 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=L/djtXyGqNW5OYK2j4g158lvJMlJeskAGwvn9f0JbPw=; b=HQQ3jEF/89t3iANkEOWhV5L0FVLI76FszZ3aeCyqyLBqBqxURUnPIKYmkx8mHHuG1R ms3DXQTZUtIBFwVs3H7aIaLmTcw0Tx7wapb2gpHB4ifWFBtKeChsAmtlsaanWli9B3Fw 03MBgijGeSCIqQ/wB6iRVj1rDjplfBJoCAMMMG2LBgGgpBclhezPZoSwIznkhJnRNErL 8s/J/uj14YMxIzveSAJpbN+pscK85+UfafK/YmJ8YH8a6aJbYNQskXC2+B45uYnX0YLb EVrYP/jxXhxBll19h+Ek14ikhXUXhLf4lIfQSOWU9phNow/8CX8sr6U1nMM9bua5qzwf xxqA== X-Gm-Message-State: AJaThX6E3DnERr5sVDn6rhVE5WuNfAsGIsWh80tHAxAChQwt0mKwo3Xg bp8uJJxmjadF+Y0i5Nks3oC1nm4fN6wnhqG1g6kQ+w== X-Google-Smtp-Source: AGs4zMabXjER7YVIk99RjzfaQbftntnxWdQL69xuf9YkPvPmYOGNuPXUxjA672vurMpVy3szbk8/wAX+Fw6czM/yHn0= X-Received: by 10.107.104.18 with SMTP id d18mr13338163ioc.136.1512165455760; Fri, 01 Dec 2017 13:57:35 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 1 Dec 2017 13:57:35 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171201215531.u4f2c4eno7z5irxj@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> <20171201215531.u4f2c4eno7z5irxj@mutt-hbsd> From: Warner Losh Date: Fri, 1 Dec 2017 14:57:35 -0700 X-Google-Sender-Auth: xsnz_U60W-SoNe8P-kPUqgVwzR8 Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:57:37 -0000 On Fri, Dec 1, 2017 at 2:55 PM, Shawn Webb wrote: > On Fri, Dec 01, 2017 at 02:53:53PM -0700, Warner Losh wrote: > > On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb > > wrote: > > > > > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > > > shawn.webb@hardenedbsd.org> > > > > > wrote: > > > > > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > > > shawn.webb@hardenedbsd.org > > > > >> > > > > > >> > wrote: > > > > >> > > > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > > > >> shawn.webb@hardenedbsd.org> > > > > >> > > > wrote: > > > > >> > > > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > > > snapshot, > > > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It > boots > > > up > > > > >> to > > > > >> > > > > this line: > > > > >> > > > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > > > > >> > > > > > > > >> > > > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > > > >> > > > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056- > memstick.img > > > > >> > > > > > > >> > > It also happens on latest HEAD, so it would appear to still be > > > broken. > > > > >> > > > > > >> > > > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm > guessing > > > the > > > > >> > latter, but wanted to make sure. If so, then we're past the > point > > > where > > > > >> > boot1.efi would have failed (besides, it was fixed before that > > > > >> snapshot). > > > > >> > > > > >> With DEBUG turned on for stand/fdt: > > > > >> > > > > >> Booting [/boot/kernel/kernel]... > > > > >> fdt_copy(): fdt_copy va 0x01208000 > > > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > > > > >> Using DTB provided by EFI at 0x801fe00000. > > > > >> Loaded the platform dtb: 0x81f56f1630. > > > > >> fdt_fixup(): fdt_fixup() > > > > >> > > > > >> ^ hangs after that message > > > > > > > > > > > > > > > That doesn't sound like anything I've changed, but it could well > be... > > > I > > > > > think to find this breakage, you may need to bisect backwards along > > > stand / > > > > > sys/boot until we find the spot where it broke. > > > > > > > > > > > > > There's been several conversations on IRC about how others are > hitting a > > > > scheduler bug, at least on x86. hps' fix seems to do the trick for > their > > > > issues. > > > > > > > > Author: hselasky > > > > Date: Wed Nov 29 23:28:40 2017 +0000 > > > > > > > > The sched_add() function is not only used when the thread is > > > initially > > > > started, but also by the turnstiles to mark a thread as runnable > for > > > > all locks, for instance sleepqueues do: > > > > setrunnable()->sched_wakeup()->sched_add() > > > > > > > > In r326218 code was added to allow booting from non-zero CPU > numbers > > > > by setting the ts_cpu field inside the ULE scheduler's > sched_add() > > > > function. This had an undesired side-effect that prior > sched_pin() > > > and > > > > sched_bind() calls got disregarded. This patch fixes the > > > > initialization of the ts_cpu field for the ULE scheduler to only > > > > happen once when the initial thread is constructed during system > > > > init. Forking will then later on ensure that a valid ts_cpu value > > > gets > > > > copied to all children. > > > > > > > > Reviewed by: jhb, kib > > > > Discussed with: nwhitehorn > > > > MFC after: 1 month > > > > Differential revision: https://reviews.freebsd.org/D13298 > > > > Sponsored by: Mellanox Technologies > > > > > > > > > > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > > > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > > > > > > is the fix.... But the bug it fixes post-dates the snapshot, so maybe > > > this > > > > isn't the same thing... > > > > > > Definitely is not the same thing. I've so far got it printf'd to where > > > the uefi loader jumps into the kernel's entry point. So the loader > > > itself might be fine. Something in the kernel, then, is going funky. > > > > > > Booting in verbose mode does not provide any additional input. > > > > > > Here's the output I get (some of the output is from printf's I've > > > done): > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) > > > EFI boot environment > > > Loading /boot/defaults/loader.conf > > > /boot/kernel/kernel text=0x7e0a78 data=0xaad80+0x443f62 > > > syms=[0x8+0x10ec78+0x8+0x1021d4] > > > /boot/entropy size=0x1000 > > > /boot/kernel/zfs.ko text=0x99070 text=0x130390 data=0x21ff8+0x9ef98 > > > syms=[0x8+0x22c68+0x8+0x1b99b] > > > /boot/kernel/opensolaris.ko text=0x1330 text=0xd00 data=0x10160+0x125d0 > > > syms=[0x8+0xff0+0x8+0x8d8] > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > Using DTB provided by EFI at 0x801fe00000. > > > fdt_copy returned. dtb_size is 9060. > > > bi_load finished. err: 0 > > > dev_cleanup finished > > > About to call into the entry point at 0x81ee601000 > > > > > > > You might try booting the same kernel off a small UFS partition. There's > a > > tiny chance that the loader didn't load it right, but more likely the > > kernel is borked. Maybe DTB issues? Maybe something else... A quick test > > like that would remove ZFS from the equation, even if it's just a USB > > stick... > > UFS works fine and dandy. It's ZFS that's b0rked. OK. Let me know what you find... I assume the entry point matches with what you've loaded? Warner