From owner-freebsd-arm@freebsd.org Sun Oct 22 03:05: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 42B91E45401 for ; Sun, 22 Oct 2017 03:05:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 F17E4763A0 for ; Sun, 22 Oct 2017 03:05:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24188 invoked from network); 22 Oct 2017 03:05:27 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Oct 2017 03:05:27 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 21 Oct 2017 23:05:27 -0400 (EDT) Received: (qmail 15293 invoked from network); 22 Oct 2017 03:05:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 03:05:27 -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 E2A87EC7B9D; Sat, 21 Oct 2017 20:05:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Date: Sat, 21 Oct 2017 20:05:26 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 03:05:30 -0000 [Reporting what seems to be the case for /boot/dtb/sinovoip-bpi-m3.dtb old and newer and, so, its source files (old and newer).] On 2017-Oct-21, at 4:09 PM, Mark Millard wrote: > On 2017-Oct-21, at 2:06 PM, Mark Millard = wrote: >=20 >> On 2017-Oct-21, at 11:43 AM, Emmanuel Vadot wrote: >>=20 >>> On Sat, 21 Oct 2017 11:26:57 -0700 >>> Mark Millard wrote: >>>=20 >>>> On 2017-Oct-21, at 10:58 AM, Emmanuel Vadot wrote: >>>>=20 >>>>>>> . . . >>>>=20 >>>> If I understand the current status correctly, the >>>> recent changes to use upstream DTS materials took >>>> the BPI-M3 from having, e.g., USB working to USB >>>> not working. -r323641 removed AWUSBPHY_TYPE_A83T >>>> from enum awusbphy_type because of what was missing >>>> from upstream DTS materials and such. >>>=20 >>> Uses of upstream DTS is active since ~2 years ago. >>> I think I removed support for USB on A83T because I couldn't test, = but >>> maybe the code just work and adding the compatible string again = might >>> do it. Feel free to send a patch on phabricator if it does. >>=20 >> . . . . . . Using the .dtb files produced and using dtc to convert back to .dts files (via -s for allowing diffs) I get the following (comparing to -r324743). The list of types of changes is rather short (many instances, mostly not shown below). The types of differences may suggest some about compatibility for going forward. # diff -u ~/bpi-m3-sorted*.dts | more --- /root/bpi-m3-sorted-317015.dts 2017-10-22 01:47:30.424893000 = -0700 +++ /root/bpi-m3-sorted-324743.dts 2017-10-22 02:17:24.545620000 = -0700 @@ -7,6 +7,127 @@ compatible =3D "sinovoip,bpi-m3", "allwinner,sun8i-a83t"; interrupt-parent =3D <0x1>; model =3D "Sinovoip BananaPi M3 v1.2"; + __local_fixups__ { + + fixup =3D "/cpus/cpu@0:clocks:0"; + fixup =3D "/cpus/cpu@0:cpu-supply:0"; . . . + fixup =3D "/leds/blue_led:gpios:0"; + fixup =3D "/:interrupt-parent:0"; + }; (lots of such fixup's) and lots of things like: - linux,phandle =3D <0x46>; as well as some (17?) like: - phandle =3D <0x46>; but other plain phandle's are instead unchanged. There are 4 'function =3D "gpio_out";' related differences as well (usb tied): ahci_pwr_pin@0 { =20 - allwinner,drive =3D <0x0>; - allwinner,function =3D "gpio_out"; allwinner,pins =3D "PD25"; - allwinner,pull =3D <0x0>; - linux,phandle =3D <0x31>; + function =3D "gpio_out"; phandle =3D <0x31>; + pins =3D "PB8"; }; and later: usb0_vbus_pin@0 { =20 - allwinner,drive =3D <0x0>; - allwinner,function =3D "gpio_out"; - allwinner,pins =3D "PB9"; - allwinner,pull =3D <0x0>; - linux,phandle =3D <0x32>; + function =3D "gpio_out"; phandle =3D <0x32>; + pins =3D "PB9"; }; usb1_vbus_pin@0 { =20 - allwinner,drive =3D <0x0>; - allwinner,function =3D "gpio_out"; allwinner,pins =3D "PD24"; - allwinner,pull =3D <0x0>; - linux,phandle =3D <0x33>; + function =3D "gpio_out"; phandle =3D <0x33>; + pins =3D "PH6"; }; usb2_vbus_pin@0 { =20 - allwinner,drive =3D <0x0>; - allwinner,function =3D "gpio_out"; - allwinner,pins =3D "PH3"; - allwinner,pull =3D <0x0>; - linux,phandle =3D <0x34>; + function =3D "gpio_out"; phandle =3D <0x34>; + pins =3D "PH3"; }; [Note the 'allwinner,pins =3D "PD25";' and the 'allwinner,pins =3D "PD24";' that were not deleted when other "allwinner,pins" lines were deleted.] And that is it for types of sinovoip-bpi-m3.dtb changes as of -r324743 . I do not know if any of that suggests a .dtb handling incompatibility for going forward. As near as I can tell: /boot/dtb/sinovoip-bpi-m3.dtb content is irrelevant to u-boot and to ubldr, removing one of my worries. [The above is my first use of dtc as far as I remember. Interesting.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Oct 22 04:32:00 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 1947FE48889 for ; Sun, 22 Oct 2017 04:32:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 B9C577D17D for ; Sun, 22 Oct 2017 04:31:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11680 invoked from network); 22 Oct 2017 04:31:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Oct 2017 04:31:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 22 Oct 2017 00:31:58 -0400 (EDT) Received: (qmail 23726 invoked from network); 22 Oct 2017 04:31:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 04:31:57 -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 3676AEC7B89; Sat, 21 Oct 2017 21:31:57 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Date: Sat, 21 Oct 2017 21:31:56 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 04:32:00 -0000 [Ignoring message history here.] One of my assumptions was bad. It turns out that one reason that the BPI-M3 is working is that I've not been updating ubldr and ubldr.bin : # ls -lT /boot/msdos/ total 488 -rwxr-xr-x 1 root wheel 271949 Oct 24 03:28:54 2016 ubldr -rwxr-xr-x 1 root wheel 224044 Oct 24 03:28:54 2016 ubldr.bin vs. what was built for -r317015 : # ls -lT /boot/ubldr* -r--r--r-- 1 root wheel 286515 Apr 18 23:41:42 2017 /boot/ubldr -r--r--r-- 1 root wheel 234960 Apr 18 23:41:42 2017 /boot/ubldr.bin If I substitute the pair from /boot/ubldr* into /boot/msdos/ the boot fails with: Booting from: mmc 0 ubldr reading ubldr 286515 bytes read in 102 ms (2.7 MiB/s) ## Starting application at 0x01000098 ... undefined instruction pc : [<01401000>] lr : [] reloc pc : [<8b49c000>] lr : [<4a00369c>] sp : bbf42cb0 ip : 00000002 fp : bff68560 r10: 00000001 r9 : bbf44ee8 r8 : 00000000 r7 : 00000001 r6 : bbf47c50 r5 : 01000098 r4 : 00000000 r3 : 00000001 r2 : 0000000a r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... So overall my -r317015 build is broken as well, likely for different reasons. With the 2016-Oct-24 unbldr* pair the matching text is: Booting from: mmc 0 ubldr reading ubldr 271949 bytes read in 96 ms (2.7 MiB/s) ## Starting application at 0x42000098 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xbbf46368 FreeBSD/armv6 U-Boot loader, Revision 1.2 (markmi@FreeBSDx64, Mon Oct 24 00:41:23 PDT 2016) and so on. A very different "Starting application at" between the failing and working ones. I'd have to get past this before I could test an overall build with more modern issues. I have no clue if/when I'll figure this out. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Oct 22 05:52:22 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 8C50AE49DE8 for ; Sun, 22 Oct 2017 05:52:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 3A44E7EA16 for ; Sun, 22 Oct 2017 05:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 475 invoked from network); 22 Oct 2017 05:52:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 22 Oct 2017 05:52:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 22 Oct 2017 01:52:20 -0400 (EDT) Received: (qmail 14315 invoked from network); 22 Oct 2017 05:52:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 05:52:20 -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 82FE8EC7B89; Sat, 21 Oct 2017 22:52:19 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Date: Sat, 21 Oct 2017 22:52:18 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 05:52:22 -0000 [I was not controlling UBLDR_LOADADDR in my builds.] On 2017-Oct-21, at 9:31 PM, Mark Millard wrote: > [Ignoring message history here.] > > One of my assumptions was bad. It turns out > that one reason that the BPI-M3 is working > is that I've not been updating ubldr and > ubldr.bin : > > # ls -lT /boot/msdos/ > total 488 > -rwxr-xr-x 1 root wheel 271949 Oct 24 03:28:54 2016 ubldr > -rwxr-xr-x 1 root wheel 224044 Oct 24 03:28:54 2016 ubldr.bin > > vs. what was built for -r317015 : > > # ls -lT /boot/ubldr* > -r--r--r-- 1 root wheel 286515 Apr 18 23:41:42 2017 /boot/ubldr > -r--r--r-- 1 root wheel 234960 Apr 18 23:41:42 2017 /boot/ubldr.bin > > If I substitute the pair from /boot/ubldr* into > /boot/msdos/ the boot fails with: > > Booting from: mmc 0 ubldr > reading ubldr > 286515 bytes read in 102 ms (2.7 MiB/s) > ## Starting application at 0x01000098 ... > undefined instruction > pc : [<01401000>] lr : [] > reloc pc : [<8b49c000>] lr : [<4a00369c>] > sp : bbf42cb0 ip : 00000002 fp : bff68560 > r10: 00000001 r9 : bbf44ee8 r8 : 00000000 > r7 : 00000001 r6 : bbf47c50 r5 : 01000098 r4 : 00000000 > r3 : 00000001 r2 : 0000000a r1 : 00000000 r0 : 00000000 > Flags: nZCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > resetting ... > > So overall my -r317015 build is broken as well, > likely for different reasons. > > With the 2016-Oct-24 unbldr* pair the matching > text is: > > Booting from: mmc 0 ubldr > reading ubldr > 271949 bytes read in 96 ms (2.7 MiB/s) > ## Starting application at 0x42000098 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0xbbf46368 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (markmi@FreeBSDx64, Mon Oct 24 00:41:23 PDT 2016) > > > and so on. > > A very different "Starting application at" between > the failing and working ones. > > I'd have to get past this before I could test an > overall build with more modern issues. > > I have no clue if/when I'll figure this out. I was not controlling UBLDR_LOADADDR in my armv7 builds. My original build was via crochet and it established the ubldr ubldr.bin pair that was still in use --with the UBLDR_LOADADDR correctly filled in when they were generated. The two types of boards that I have access to need different UBLDR_LOADADDR values. Neither was being set. Both were dependent on having it being correct the first time and not updating ubldr* since then. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Oct 22 16:14:00 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 CCA54E55D35 for ; Sun, 22 Oct 2017 16:14:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABD4E6C396 for ; Sun, 22 Oct 2017 16:13:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0c784b7c-b744-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 0c784b7c-b744-11e7-a938-4f970e858fdb; Sun, 22 Oct 2017 16:14:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9MGDuuF001481; Sun, 22 Oct 2017 10:13:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508688836.7314.6.camel@freebsd.org> Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] From: Ian Lepore To: Mark Millard , Emmanuel Vadot , freebsd-arm Date: Sun, 22 Oct 2017 10:13:56 -0600 In-Reply-To: <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:14:00 -0000 On Sat, 2017-10-21 at 22:52 -0700, Mark Millard wrote: > [I was not controlling UBLDR_LOADADDR in > my builds.] > UBLDR_LOADADDR is meaningless; it's not significant on arm systems, dating back to well before 11.0 was released.  It used to set the fixed physical address at which ubldr[.bin] was linked to run, but now ubldr is self-relocating and can be loaded at any 2mb boundary (really 1mb boundary on most arm systems). It should be noted that ubldr is obsolete as well; only ubldr.bin is needed.  The older version with the elf headers intact was supposed to be kept around "for a few weeks, until crochet can be adjusted to not refer to it".  That was like 3 years ago, but it never got removed. Hmmm, actually, since UBLDR_LOADADDR does end up stored in the elf headers, I guess if you're using the obsolete ubldr with headers intact, maybe it is influencing uboot's behavior and causing failures. -- Ian From owner-freebsd-arm@freebsd.org Sun Oct 22 16:23:22 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 82FCFE5608F for ; Sun, 22 Oct 2017 16:23:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 430C66C831 for ; Sun, 22 Oct 2017 16:23:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x242.google.com with SMTP id r127so3411337itb.5 for ; Sun, 22 Oct 2017 09:23:22 -0700 (PDT) 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=KEpRyRToNlrzYSkaJhc9BqVfji4egZ4oWuJf4Coxdy0=; b=L4i4XNgvfjUIMJvozT0NtQNr+6zLXFlarjQFnKqZm2PIY738+pEfYy51Q+jPGX7uMC 6LoRFYZELFNbpZv4S/KBOt67Qnk+SQZJZFRaYCexSHkGJ1mukYfyYmMSl3sn0/vb3OCV Rxk1INAZOMmivfjVkVNi0Ayv3YOjIkbrSxi6mig0RlkquQucLmJ0wP654wQhsG1SDSYc 02Ec5exu1Onxww45oq/IWa44oV84SCUgKOdtfabSf9IAhcmP1iqAPvHz76vEdhwOKB5f TPFa8AMFv/tfMz7lKCvZO6sXB867AzER/Fw551xf0IQ0VhUM4k25Bk+Gtk+L6ed4HzEB bNig== 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=KEpRyRToNlrzYSkaJhc9BqVfji4egZ4oWuJf4Coxdy0=; b=M7vRYAQ3MdIU0AZCgCAy6MoA9QucRfyCDnTbRLH14tz9j/mtR2T8OnGYxjqIWe96n2 ANDVdBjo8SccGoA0CrDccC+EyvnZlG5wpVqki43g/gT9WqthrPHnMXR2dIm618h3ComA d4ajlxHYQsVCOMDuzycsSn0mWZ2SCXRwO0/GuEPH7x8itmWiDRKSuVv9+minU/cerOEf sNLtFdTepDr9Ly3EDyhXVEV6zbsZOStQ0nwJEpRbE517wiLlv++vQrkc6FtKYqgd9s+C 3k9ssbbb0yFDrjpI2aAm8yDqpiitSYQpAncP1aFbLUd1nQuSgh+vefbykEykIDEd85bp 3ljQ== X-Gm-Message-State: AMCzsaX2Mx1/89X9TMTL0bJqdSIl5vutzqxv2r9rJBwj5Lwhgy9O+WcH N71sDZLsRMu72qu+xgdZsWy6tuo4ApeIz2Ou2WEO7Q== X-Google-Smtp-Source: ABhQp+TnupP/6U/2n1GySR0+YrkEnz6n4HGWY30/UWpP0Iud3geFHRB20TwVA7f069vvEMNtIBI2oxxex9p9hRE+Ycs= X-Received: by 10.36.118.81 with SMTP id z78mr6164495itb.97.1508689401493; Sun, 22 Oct 2017 09:23:21 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Sun, 22 Oct 2017 09:23:20 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:df5:793f:4458:5cf6] In-Reply-To: <1508688836.7314.6.camel@freebsd.org> References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> <1508688836.7314.6.camel@freebsd.org> From: Warner Losh Date: Sun, 22 Oct 2017 10:23:20 -0600 X-Google-Sender-Auth: xL_ucBu9JOYu1AQ54TL0-pNLqcg Message-ID: Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] To: Ian Lepore Cc: Mark Millard , Emmanuel Vadot , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:23:22 -0000 On Sun, Oct 22, 2017 at 10:13 AM, Ian Lepore wrote: > On Sat, 2017-10-21 at 22:52 -0700, Mark Millard wrote: > > [I was not controlling UBLDR_LOADADDR in > > my builds.] > > > > UBLDR_LOADADDR is meaningless; it's not significant on arm systems, > dating back to well before 11.0 was released. It used to set the fixed > physical address at which ubldr[.bin] was linked to run, but now ubldr > is self-relocating and can be loaded at any 2mb boundary (really 1mb > boundary on most arm systems). > > It should be noted that ubldr is obsolete as well; only ubldr.bin is > needed. The older version with the elf headers intact was supposed to > be kept around "for a few weeks, until crochet can be adjusted to not > refer to it". That was like 3 years ago, but it never got removed. > > Hmmm, actually, since UBLDR_LOADADDR does end up stored in the elf > headers, I guess if you're using the obsolete ubldr with headers > intact, maybe it is influencing uboot's behavior and causing failures. > Maybe it's time to delete it, other build systems ready or not. Warner From owner-freebsd-arm@freebsd.org Sun Oct 22 16:36:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE0FCE56473 for ; Sun, 22 Oct 2017 16:36:14 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BA686CD9C for ; Sun, 22 Oct 2017 16:36:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 279d8725-b747-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 279d8725-b747-11e7-a938-4f970e858fdb; Sun, 22 Oct 2017 16:36:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9MGaBe1001514; Sun, 22 Oct 2017 10:36:11 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508690171.7314.9.camel@freebsd.org> Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] From: Ian Lepore To: Warner Losh Cc: Mark Millard , Emmanuel Vadot , freebsd-arm Date: Sun, 22 Oct 2017 10:36:11 -0600 In-Reply-To: References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> <1508688836.7314.6.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:36:14 -0000 On Sun, 2017-10-22 at 10:23 -0600, Warner Losh wrote: > On Sun, Oct 22, 2017 at 10:13 AM, Ian Lepore wrote: > > > > > On Sat, 2017-10-21 at 22:52 -0700, Mark Millard wrote: > > > > > > [I was not controlling UBLDR_LOADADDR in > > > my builds.] > > > > > UBLDR_LOADADDR is meaningless; it's not significant on arm systems, > > dating back to well before 11.0 was released.  It used to set the fixed > > physical address at which ubldr[.bin] was linked to run, but now ubldr > > is self-relocating and can be loaded at any 2mb boundary (really 1mb > > boundary on most arm systems). > > > > It should be noted that ubldr is obsolete as well; only ubldr.bin is > > needed.  The older version with the elf headers intact was supposed to > > be kept around "for a few weeks, until crochet can be adjusted to not > > refer to it".  That was like 3 years ago, but it never got removed. > > > > Hmmm, actually, since UBLDR_LOADADDR does end up stored in the elf > > headers, I guess if you're using the obsolete ubldr with headers > > intact, maybe it is influencing uboot's behavior and causing failures. > > > Maybe it's time to delete it, other build systems ready or not. > > Warner After digging through some old IRC logs, where we left off on this when it was last discussed in April 2017, we were waiting for a last few remaining uboot ports to either get converted to the new master scheme, or have their one-off patches updated to stop referring to the elf ubldr.  Also, there was a need to ensure the cache-flushing patches (flush before launching ubldr and in the API IO code) are in place in your uboot fork. I think at this point we're probably down to just the one-off uboot ports needing small changes. -- Ian From owner-freebsd-arm@freebsd.org Sun Oct 22 16:42:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3036E56677 for ; Sun, 22 Oct 2017 16:42:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 4FDEA6D08E for ; Sun, 22 Oct 2017 16:42:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27577 invoked from network); 22 Oct 2017 16:42:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 22 Oct 2017 16:42:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 22 Oct 2017 12:42:22 -0400 (EDT) Received: (qmail 9900 invoked from network); 22 Oct 2017 16:42:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 16:42:22 -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 B868CEC8EFB; Sun, 22 Oct 2017 09:42:21 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Date: Sun, 22 Oct 2017 09:42:21 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> <1508688836.7314.6.camel@freebsd.org> To: Warner Losh , Ian Lepore , Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <3923365A-21CB-46AD-9715-A2F687ED4B97@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:42:24 -0000 [Providing UBLDR_LOADADDR fixed the problem for BPI-M3.] On 2017-Oct-22, at 9:23 AM, Warner Losh wrote: > On Sun, Oct 22, 2017 at 10:13 AM, Ian Lepore wrote: >> On Sat, 2017-10-21 at 22:52 -0700, Mark Millard wrote: >> > [I was not controlling UBLDR_LOADADDR in >> > my builds.] >> > >> >> UBLDR_LOADADDR is meaningless; it's not significant on arm systems, >> dating back to well before 11.0 was released. It used to set the fixed >> physical address at which ubldr[.bin] was linked to run, but now ubldr >> is self-relocating and can be loaded at any 2mb boundary (really 1mb >> boundary on most arm systems). For BPI-M3 ubldr is used and providing UBLDR_LOADADDR=0x42000000 fixed the problem by changing the start address actually used. Systems that ignore ubldr.bin and use ubldr do use UBLDR_LOADADDR as I understand. So, at least the BPI-M3 fits my more general understanding. (Is it the only one?) As I understand Ian's comment is correct for systems that use ubldr.bin and ignore ubldr: ubldr.bin is the self relocating one and ubldr is for ones that do not deal with that. FYI: The sysutils/u-boot-sinovoip-bpi-m3 has never been updated from its original distfiles. >> It should be noted that ubldr is obsolete as well; only ubldr.bin is >> needed. The older version with the elf headers intact was supposed to >> be kept around "for a few weeks, until crochet can be adjusted to not >> refer to it". That was like 3 years ago, but it never got removed. >> >> Hmmm, actually, since UBLDR_LOADADDR does end up stored in the elf >> headers, I guess if you're using the obsolete ubldr with headers >> intact, maybe it is influencing uboot's behavior and causing failures. That is what happens on the BPI-M3 based on its sysutils/u-boot-sinovoip-bpi-m3 . > Maybe it's time to delete it, other build systems ready or not. If the BPI-M3 is the only one with the issue and if support is dropped for the other issues with supporting it, then sure. Otherwise the BPI-M3 needs to progress to ubldr.bin use first. FYI: BPI-M3 are an armv7 (cortex-a7) context. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Oct 22 21:35:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D101E3698E for ; Sun, 22 Oct 2017 21:35:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 6083275AEA for ; Sun, 22 Oct 2017 21:35:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24388 invoked from network); 22 Oct 2017 21:35:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 22 Oct 2017 21:35:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 22 Oct 2017 17:35:07 -0400 (EDT) Received: (qmail 25832 invoked from network); 22 Oct 2017 21:35:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 21:35:06 -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 077ACEC8683; Sun, 22 Oct 2017 14:35:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Date: Sun, 22 Oct 2017 14:35:05 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 21:35:14 -0000 My attempt to adjust code failed massively when tested. I've no clue what I'm doing and my guesses were clearly wrong. Mostly this is usb stuff but pcpu_find also reported "cpuid too large". (BPI-M3's have 8 cores, 2 clusters of 4, but FreeBSD only classically enabled/used 4 of the 8: one cluster.) Not stopping at 4 lead to a panic via ofw_cpu_attach and dpcpu_alloc. [The ubldr worked based on having supplied UBLDR_LOADADDR=3D0x42000000 to buildworld.] Unless an active committer is going to cover the BPI-M3 it likely needs to be dropped, sad to say for me. (I liked having the extra memory compared to the other cortex-a7 board that I've access to.) 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 r324743M arm FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) 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 . . . (normal looking stuff) . . . awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c82fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 18 on simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 gpio0: mem 0x1c20800-0x1c20bff irq = 11,12,13 on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 19 = on simplebus0 gpiobus1: on gpio1 aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 21 on = simplebus0 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 axp81x_pmu0: at addr 0x746 irq = 29 on iicbus3 gpiobus2: on axp81x_pmu0 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 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 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 awusbphy0: Cannot locate phy control resource awusbphy0: failed to initialize USB PHY, error 6 device_attach: awusbphy0 attach returned 6 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cpu4: on cpulist0 panic: pcpu_find: cpuid too large cpuid =3D 0 Note the attempt to try cpu4 after cpus 0-3. FreeBSD is no longer stopping at its own self-imposed limit of 4 cores (one of the 2 clusters). NOTE: The BPI-M3 is not BIG-little: all the cores are the same type: cortex-a7's. It looks like having BPI-M3 supported would be a notable effort by someone the proper background. The details for what I tried follow but I know so little for this type of activity that the material is likely of little or no use. Nothing below is targeting stopping at 4 cores: that was a surprise. The later greps of the -r324743 based sorted .dts produced from the .dtb shows references to: usb0-vbus usb1-vbus usb2-vbus I think that is the 2 USB ports and the SATA that is via a USB bridge as I understand. (It is known for not being fast because of this structure.) The clock-output-names list includes: "bus_usb_otg", "bus_ehci0", "bus_ehci1", "bus_ohci0", But there are only 2 or 3 usb resets?: fixup =3D "/soc/usb@01c1a000:resets:0"; . . . fixup =3D "/soc/usb@01c1b000:resets:0"; . . . reset-names =3D "usb0_reset", "usb1_reset", = "usb2_reset"; and 2 phys if I understand right (that show up various ways): fixup =3D "/soc/usb@01c1a000:phys:0"; . . . fixup =3D "/soc/usb@01c1b000:phys:0"; . . . clock-output-names =3D "usb_phy0", "usb_phy1", = "usb_hsic_pll", "usb_hsic_12m", "usb_ohci0"; . . . clock-names =3D "usb0_phy", "usb1_phy", = "hsic_pll", "hsic_12m"; . . . usb@01c1a000 { phy-names =3D "usb"; usb@01c1b000 { phy-names =3D "usb"; Although there is the following as well: fixup =3D "/soc/phy@01c19400:usb1_vbus-supply:0"; . . . usbphy =3D "/soc/phy@01c19400"; I have no clue for it. As stands I'm testing based on my guesses for .num_phys , .pmu_unk1 , and .phy0_route below. I do not know how to confirm or find what the values should be. # svnlite diff /usr/src/sys/arm/allwinner/aw_usbphy.c Index: /usr/src/sys/arm/allwinner/aw_usbphy.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) @@ -58,6 +58,7 @@ AWUSBPHY_TYPE_A13, AWUSBPHY_TYPE_A20, AWUSBPHY_TYPE_A31, + AWUSBPHY_TYPE_A83T, AWUSBPHY_TYPE_H3, AWUSBPHY_TYPE_A64 }; @@ -90,6 +91,13 @@ .phy0_route =3D false, }; =20 +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { + .num_phys =3D 2, // ???? SATA via USB too? ???? + .phy_type =3D AWUSBPHY_TYPE_A83T, + .pmu_unk1 =3D false, // ???? + .phy0_route =3D false, // ???? +}; + static const struct aw_usbphy_conf a31_usbphy_conf =3D { .num_phys =3D 3, .phy_type =3D AWUSBPHY_TYPE_A31, @@ -116,6 +124,7 @@ { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, { NULL, 0 } The details for the greps: # grep -i usb /root/bpi-m3-sorted-324743.dts | more fixup =3D "/soc/phy@01c19400:usb1_vbus-supply:0"; fixup =3D "/soc/usb@01c1a000:clocks:0"; fixup =3D "/soc/usb@01c1a000:resets:0"; fixup =3D "/soc/usb@01c1a000:phys:0"; fixup =3D "/soc/usb@01c1b000:clocks:0"; fixup =3D "/soc/usb@01c1b000:resets:0"; fixup =3D "/soc/usb@01c1b000:phys:0"; fixup =3D "/usb0-vbus:pinctrl-0:0"; fixup =3D "/usb0-vbus:gpio:0"; fixup =3D "/usb1-vbus:pinctrl-0:0"; fixup =3D "/usb1-vbus:gpio:0"; fixup =3D "/usb2-vbus:pinctrl-0:0"; fixup =3D "/usb2-vbus:gpio:0"; ehci0 =3D "/soc/usb@01c1a000"; ehci1 =3D "/soc/usb@01c1b000"; reg_usb0_vbus =3D "/usb0-vbus"; reg_usb1_vbus =3D "/usb1-vbus"; reg_usb2_vbus =3D "/usb2-vbus"; usb0_vbus_pin_a =3D = "/soc/pinctrl@01c20800/usb0_vbus_pin@0"; usb1_vbus_pin_a =3D = "/soc/pinctrl@01c20800/usb1_vbus_pin@0"; usb2_vbus_pin_a =3D = "/soc/pinctrl@01c20800/usb2_vbus_pin@0"; usb_clk =3D "/clocks/clk@01c200cc"; usbphy =3D "/soc/phy@01c19400"; clock-output-names =3D "bus_mipidsi", "bus_ss", = "bus_dma", "bus_mmc0", "bus_mmc1", "bus_mmc2", "bus_nand", "bus_sdram", = "bus_emac", "bus_hstimer", "bus_spi0", "bus_spi1", "bus_usb_otg", = "bus_ehci0", "bus_ehci1", "bus_ohci0", "bus_ve", "bus_lcd0", "bus_lcd1", = "bus_csi", "bus_hdmi", "bus_de", "bus_gpu", "bus_msgbox", = "bus_spinlock", "bus_spdif", "bus_pio", "bus_i2s0", "bus_i2s1", = "bus_i2s2", "bus_tdm", "bus_i2c0", "bus_i2c1", "bus_i2c2", "bus_uart0", = "bus_uart1", "bus_uart2", "bus_uart3", "bus_uart4"; clock-output-names =3D "usb_phy0", "usb_phy1", = "usb_hsic_pll", "usb_hsic_12m", "usb_ohci0"; compatible =3D "allwinner,sun8i-a83t-usb-clk"; clock-names =3D "usb0_phy", "usb1_phy", = "hsic_pll", "hsic_12m"; compatible =3D "allwinner,sun8i-a83t-usb-phy"; reset-names =3D "usb0_reset", "usb1_reset", = "usb2_reset"; usb1_vbus-supply =3D <0x2c>; usb0_vbus_pin@0 { usb1_vbus_pin@0 { usb2_vbus_pin@0 { usb@01c1a000 { phy-names =3D "usb"; usb@01c1b000 { phy-names =3D "usb"; usb0-vbus { regulator-name =3D "usb0-vbus"; usb1-vbus { regulator-name =3D "usb1-vbus"; usb2-vbus { regulator-name =3D "usb2-vbus"; # grep -i hci /root/bpi-m3-sorted-324743.dts | more fixup =3D "/ahci-5v:pinctrl-0:0"; fixup =3D "/ahci-5v:gpio:0"; ahci_pwr_pin_a =3D = "/soc/pinctrl@01c20800/ahci_pwr_pin@0"; ehci0 =3D "/soc/usb@01c1a000"; ehci1 =3D "/soc/usb@01c1b000"; reg_ahci_5v =3D "/ahci-5v"; ahci-5v { regulator-name =3D "ahci-5v"; clock-output-names =3D "bus_mipidsi", "bus_ss", = "bus_dma", "bus_mmc0", "bus_mmc1", "bus_mmc2", "bus_nand", "bus_sdram", = "bus_emac", "bus_hstimer", "bus_spi0", "bus_spi1", "bus_usb_otg", = "bus_ehci0", "bus_ehci1", "bus_ohci0", "bus_ve", "bus_lcd0", "bus_lcd1", = "bus_csi", "bus_hdmi", "bus_de", "bus_gpu", "bus_msgbox", = "bus_spinlock", "bus_spdif", "bus_pio", "bus_i2s0", "bus_i2s1", = "bus_i2s2", "bus_tdm", "bus_i2c0", "bus_i2c1", "bus_i2c2", "bus_uart0", = "bus_uart1", "bus_uart2", "bus_uart3", "bus_uart4"; clock-output-names =3D "usb_phy0", "usb_phy1", = "usb_hsic_pll", "usb_hsic_12m", "usb_ohci0"; ahci_pwr_pin@0 { compatible =3D "allwinner,sun8i-a83t-ehci", = "generic-ehci"; compatible =3D "allwinner,sun8i-a83t-ehci", = "generic-ehci"; =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Oct 23 04:27:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0B2E3FF95 for ; Mon, 23 Oct 2017 04:27:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 ACE3C15D2 for ; Mon, 23 Oct 2017 04:27:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4271 invoked from network); 23 Oct 2017 04:27:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 23 Oct 2017 04:27:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 23 Oct 2017 00:27:10 -0400 (EDT) Received: (qmail 14420 invoked from network); 23 Oct 2017 04:27:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Oct 2017 04:27:10 -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 C683FEC8683; Sun, 22 Oct 2017 21:27:09 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Why/how I get the panic for mp_ncpu <= cpuid in pcpu_find on the BPI-M3 in my modern code Date: Sun, 22 Oct 2017 21:27:08 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 04:27:13 -0000 [Some detail for the "cpuid too large" issue is added: It is my own check that is reporting the panic but what it reports might be a valid problem for all I know.] On 2017-Oct-22, at 2:35 PM, Mark Millard wrote: > . . . >=20 > Mostly this is usb stuff but pcpu_find also > reported "cpuid too large". (BPI-M3's have > 8 cores, 2 clusters of 4, but FreeBSD only > classically enabled/used 4 of the 8: one > cluster.) Not stopping at 4 lead to a panic > via ofw_cpu_attach and dpcpu_alloc. >=20 > . . . . . . 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory =3D 2147483648 (2048 MB) avail memory =3D 2089463808 (1992 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs . . . This is from /usr/src/sys/kern/subr_smp.c: printf("FreeBSD/SMP: Multiprocessor System Detected: %d CPUs\n", mp_ncpus); and: /usr/src/sys/arm/include/armreg.h:#define CPUV7_L2CTLR_NPROC(r) = ((((r) >> CPUV7_L2CTLR_NPROC_SHIFT) & 3) + 1) being used in sys/arm/allwinner/aw_mp.c code: void aw_mp_setmaxid(platform_t plat) { int ncpu; uint32_t reg; if (mp_ncpus !=3D 0) return; reg =3D cp15_l2ctlr_get(); ncpu =3D CPUV7_L2CTLR_NPROC(reg); mp_ncpus =3D ncpu; . . . But pcpu_find is being given larger cpuid values (from the unused cores as far as I can tell). [Turns out that I have some code in place for trying to help catch at an earlier stage an intermittent error that I've seen rarely (on powerpc) and that extra code is what is reporting the panic for mp_ncpu <=3D cpuid .] struct pcpu * pcpu_find(u_int cpuid) { if (mp_ncpus =3D=3D 0 && cpuid =3D=3D 0) {} // HACK: This combination is = used in the late bootstrap else if (mp_ncpus <=3D cpuid) { panic("pcpu_find: cpuid too large"); } = // HACK return (cpuid_to_pcpu[cpuid]); } If mp_ncpus <=3D cpuid is supposed to be valid when there are ignored cores/cpus then my hack is reporting a false positive for the BPI-M3 context. But I do not know if mp_ncpus <=3D cpuid is supposed to be valid for such contexts. FYI: /usr/src/sys/kern/subr_pcpu.c:struct pcpu *cpuid_to_pcpu[MAXCPU]; =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Oct 23 06:43:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36557E424CC for ; Mon, 23 Oct 2017 06:43:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (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 D5EC26420D for ; Mon, 23 Oct 2017 06:43:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28068 invoked from network); 23 Oct 2017 06:42:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Oct 2017 06:42:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 23 Oct 2017 02:42:59 -0400 (EDT) Received: (qmail 7896 invoked from network); 23 Oct 2017 06:42:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Oct 2017 06:42:58 -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 2F284EC8166; Sun, 22 Oct 2017 23:42:58 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r323640 kernel+.dtb works on BPI-M3; did -r323641 and later remove some legacy dtb support? (same .dtb until -r324820 changed it) Date: Sun, 22 Oct 2017 23:42:57 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> Message-Id: <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 06:43:01 -0000 [The notes here presume that mp_ncpu <=3D cpuid is considered valid for the BPI-M3. Otherwise what I'm running is a workaround allowing other aspects of things to be explored.] [Reminder: Most of the BPI-M3 *.dt* material is not from sys/gnu/dts/ at all but from sys/boot/fdt/dts/ instead: not updated with LINUX 4.?? updates. But some included *.dt* files are from sys/gnu/dts/ .] I was able to buildkernel for -r323640 and install and boot it on the BPI-M3. Basic operation seems okay so far. It appears to me that -r323641 and later can not interpret the same .dtb that -r323640 uses correctly. My guess is some legacy support has been (implicitly?) removed. (This may well be deliberate and more important than having the BPI-M3 working from an overall point of view.) FYI for what I've tried in order to show some context: Revision 320834 - Directory Listing=20 Modified Sun Jul 9 13:53:32 2017 UTC (3 months, 2 weeks ago) by manu Update DTS files from Linux 4.12 Notable changes: Allwinner: * H3/H5 were merged into a common dtsi file * include/dt-bindings/sun4i-a10.h is not included anymore in a lot of dts files * Add sun8i-h3-nanopi-neo-air board DTS file . . . Revision 323640 - Directory Listing=20 Modified Sat Sep 16 15:50:31 2017 UTC (5 weeks, 1 day ago) by manu A64 CCUNG: Correct gate and reset for OHCI0/1 Reported by: jmcneill Pointy Hat: manu Then the very next update changes some things about interpreting the .dtb greatly . . . Revision 323641 - Directory Listing=20 Modified Sat Sep 16 15:58:20 2017 UTC (5 weeks, 1 day ago) by manu Allwinner usb phy: Rework resource allocation The usbphy node for allwinner have two kind of resources, one for the phy_ctrl and one per phy. Instead of blindy allocating resources, alloc the phy_ctrl and pmu ones separately. Also add a configuration struct for all different phy that hold the = difference between them (number of phys, unknow needed register write etc ...). While here remove A83T code as upstream and FreeBSD dts don't have nodes for USB. This (plus 323640) re-enable OHCI on Pine64 on the bottom USB port. The top USB port is routed to the OHCI0/EHCI0 which is by default in OTG = mode. While the phy code can handle the re-route to standard OHCI/EHCI we = still need a driver for musb to probe and configure it in host mode. EHCI is still buggy on Pine64 (hang the board) so do not enable it for = now. Tested On: Bananapi (A20), BananapiM2 (A31S), OrangePi One (H3) = Pine64 (A64) . . . Revision 324820 - Directory Listing=20 Modified Sat Oct 21 15:47:40 2017 UTC (38 hours, 31 minutes ago) by manu dts: Update our device tree sources file fomr Linux 4.13 (I have not tried a .dtb partially based on -r324820 *.dts* material from sys/gnu/dts/ used with a -r323640 kernel.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Oct 23 12:57: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 0D7C7E4B25B for ; Mon, 23 Oct 2017 12:57:40 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EBF46F8FB for ; Mon, 23 Oct 2017 12:57:39 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3yLGdk3NcLzsSB Received: from restart.be (norquay.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3yLGdk3NcLzsSB for ; Mon, 23 Oct 2017 14:57:30 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v9NCvSwv002245 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 23 Oct 2017 14:57:29 +0200 (CEST) (envelope-from hlh@restart.be) To: freebsd-arm From: Henri Hennebert Subject: PINE64 - 12.0-CURRENT r320599 -> r324563 - USB VIA Labs no more detected Message-ID: <6837b35d-7998-d75c-64e6-0a8cae671bd1@restart.be> Date: Mon, 23 Oct 2017 14:57:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 12:57:40 -0000 Hello I try 12.0-CURRENT -r324563 on pine64+ 2GB and the USB VIA Labs hub and its 2 disks is no more detected. Wen running r320599, boot msg: [root@norquay norquay]# egrep -i 'usb|uhub' boot.cap-r320599M aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 awusbphy0: mem 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 usbus0 on ohci0 ehci0: mem 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci0 usbus2 on ohci1 ehci1: mem 0x1c1b000-0x1c1b0ff irq 29 on simplebus0 usbus3: EHCI version 1.0 usbus3 on ehci1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub1: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered ugen1.2: at usbus1 uhub4 on uhub0 uhub4: on usbus1 Root mount waiting for: usbus1 uhub4: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen1.3: at usbus1 umass0 on uhub4 umass0: on usbus1 Root mount waiting for: GMIRROR usbus1 Root mount waiting for: GMIRROR usbus1 ugen1.4: at usbus1 umass1 on uhub4 umass1: on usbus1 When running r324563, boot msg: [root@norquay norquay]# egrep -i 'usb|uhub' boot.cap-r324563M awusbphy0: mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 ehci0: mem 0x1c1b000-0x1c1b0ff irq 8 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 usbus1 on ohci0 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 uhub1: 1 port with 1 removable, self powered Enter full pathname of shell or RETURN for /bin/sh: uhub0: 1 port with 1 removable, self powered The differences seem strange to me. Henri From owner-freebsd-arm@freebsd.org Mon Oct 23 19:08: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 0C8A9E529C8 for ; Mon, 23 Oct 2017 19:08:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C986780603 for ; Mon, 23 Oct 2017 19:08:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id 72so7219721itk.3 for ; Mon, 23 Oct 2017 12:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=ItzKNeVLD5pa3Oyli4ooT7i2p/qqSjHF8mC1luILnTE=; b=sr/uvI2+hc2jYFoRTJO/r7T6HfXzvYih+4daVUlm9kyKPX7rEbhpfcOdUjMBFoCCmn CTMeWlxo/gm2Huq/IqFDgi0oDYO0NgxK0dq9hOla2dUrAj+WMAUGZ2xH8qqK/C5SeByj yr6GRfO7ZFEa7otk5hI4N8tsQxCLwFzKJHjmeNHUw3vbrOR8MXrjjqXeKTvfkyzVEPzN aRhqT5uyyTMK01YL+l0Qq/r1KHAOYPVwIF4teIGQFADTEho7hI9BFWoqzbM+NH1l+3fA 63+XJZ3uFAvixzPnCGIs7Qg6fFBp621lOhOl9fNIs5RQtFiU/lyDw2z3ZKAaEwa0RhX7 7Jug== 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:from:date:message-id:subject :to; bh=ItzKNeVLD5pa3Oyli4ooT7i2p/qqSjHF8mC1luILnTE=; b=C8pjMT3Yq3SPM2NqMOpumyZdng+aOAz/zfwARdAfvaJYCqvSvDp0UG3CmmUfyuahg5 /SgNenMtuA0sVjQ0RXS5EYwD1wVfssJO9xqosyyV+o71ztvWkCRuOlOd5AC8H4KSrVja JnJtxFQfaMQH6L6kntAWG5jw37mQYyTOphmtiJt003wJ3evsm++ln5o9edNdhDmFwFKK K06FaXuGDF08d2RLLEDlzwLUG8Q9sLAymL7va20UTbQ8A2jWeqENL/+K6RbSIKT9zApQ WSesfLlEHhZS+IU8BiFCoQiP+5RLkFgUwFrf/xKLfWcccYsBfKLo+5mO29+FmNoEIoy+ CbYA== X-Gm-Message-State: AMCzsaXWMr+BsxF0xXWFU51vNSN2v1T22TcsADy8hmGYBt8o1Bnb5H1R zDxJ4nHfNOFKdLC0REqcK6F/6wOou97+Vzf+x4sSGQ== X-Google-Smtp-Source: ABhQp+TiJxxjQTb1yhQRZSTbJ7ScF3JW0+kPYiM0zaOcLU7zZMTCqnJJedEbTIC38Szazxl4+VaN+JBTrk0uDpMiUTE= X-Received: by 10.36.69.100 with SMTP id y97mr10646775ita.50.1508785708040; Mon, 23 Oct 2017 12:08:28 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Mon, 23 Oct 2017 12:08:27 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:9c93:1751:a648:919b] From: Warner Losh Date: Mon, 23 Oct 2017 13:08:27 -0600 X-Google-Sender-Auth: NeRdIjXjI5KrKhapzN6XZdDlhvQ Message-ID: Subject: Removing sys/boot/arm/at91 and sys/boot/arm/ixp425 To: "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:08:29 -0000 I'd like to remove sys/boot/arm/at91 (bootstrap code for the AT91RM9200 that works on a couple of reference boards, but not universally) and sys/boot/arm/ixp425 (which is for Gateworks Cambria 235x and Avila 2348 boards). The AT91 boot stuff is likely better served by Atmel's AT91Bootstrap + uboot. The at91 stuff likely hasn't been tested in several years, though I know one company that uses a modified version with FreeBSD 8... It's been disconnected from the build forever. It does still build though. I have no clue if it works owing to the difficulty in tweaking it just so to work on the AT91RM9200 gear I still have left. This was always a super specialized build, and perhaps shouldn't have been committed in the first place given how the AT91SAM9 line evolved (its SRAM size shrank to 4k, making it simply impossible to fit). The ixp425 doesn't build, and likely hasn't for a while (there's undefined references to memset, despite trying to avoid such references). It needs to be reworked to support the current tree layout (even before my changes to libstand) and compiler technologies. This is for the Intel IXP 425 processors found on the Gateworks Avila and Cambria boards. They were released in 2006 and EOLd by intel in 2009. Redboot is a possible alternative. We don't create releases for it, and it's not otherwise referenced in the tree. Absent any real users that would be affected by these boot loaders, I'd like to just remove them from the tree rather than try to fix them up an modernize them and/or include them in the builds so breakage is discovered sooner... Comments? Warner From owner-freebsd-arm@freebsd.org Mon Oct 23 19:22:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E1C0E5300E for ; Mon, 23 Oct 2017 19:22:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 16C0880FDA for ; Mon, 23 Oct 2017 19:22:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id n195so7243823itg.0 for ; Mon, 23 Oct 2017 12:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=MxvGKayqMibXp4Qdf81AwbG5b3F8Azg4H3zkvX7N8+Y=; b=xSfzm52ogmUBmwtMgyCy9NNWhqq/F+n3HtGQbCyT4lGb6gUGb8XfqAxdhxlmMHWIsA 7vdgTVNVJN7ZMTmcWka0CsFrqocDAaN2JBnKuKt0FLdDaBDNGsH6s9Giv370TCOXeK92 4OarHlt0ryxNTcQ4mMGwl9QT+2s/MI0C924jBugpPnV0Vu7TAt9o8fSVvvhNt/VEBnh6 ehl9kDcVNcO606pEYyt/dgy1tBB+uNCkZ4dJvE6Vqfq780M7b0vcWo7SXDG0cJqZydeb EDZn1K30sLKlmahKDaWVWGVzZBDe98nYa2+upU6mp8CUqGeGxs+LFoiiwMYaPNv72Ba+ n58w== 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:from:date:message-id:subject :to; bh=MxvGKayqMibXp4Qdf81AwbG5b3F8Azg4H3zkvX7N8+Y=; b=FIaxBLP08T0fWpdkl+sALHOsUyC2Lty1HFBjRm7mCHKneaACsrO2Y/9OOKwqKjnWAj XCGB+i6ls5EhBHFNPguAWAke+LJsVGjma9BaXfjVEnU37BfzAvKTsChnXTrJt5CZMVBw VsaoW/sElbRYw1nz5M4bAMu/4iVWJ1MgNzio9oMxmkR95J4N3ImH13zveQ4rxKrofB8A hwUmhaTRRF8rKZhGIm/e88luhSDJsekVTOGNm+gFPq7Qj7OVOMCXdIevHYe9kJxiGSoX 5lWLzRRLkDbqkXrIDVvOt5sawC5+gZtFr5XKG13QW+tysXjUpXhDtL0vhqBZFykIkWTm bv4Q== X-Gm-Message-State: AMCzsaW62gpWb8Vl8qa+A6cg7e5sDRLYO6+C4Mr6TgCGQsuVCRmcs0Zz BPiTlKE25qtIHiXarfSs6+5u6ZdT00bje7jCEcvXMg== X-Google-Smtp-Source: ABhQp+STyUhudoa8veWPUxt614lSM4545zXtFXEQwyI5FuQYiMt5UE1v/wHqod1DPOYzvQV8T68Pbpivqqoy+JDI498= X-Received: by 10.36.118.81 with SMTP id z78mr10718090itb.97.1508786532058; Mon, 23 Oct 2017 12:22:12 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Mon, 23 Oct 2017 12:22:11 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:9c93:1751:a648:919b] From: Warner Losh Date: Mon, 23 Oct 2017 13:22:11 -0600 X-Google-Sender-Auth: GlsESCt7T6ZdqLmXom_luDwMETE Message-ID: Subject: Any AVILA / CAMBRIA users? To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:22:13 -0000 Is anybody still using the IXP425 systems on FreeBSD? Do you expect to run FreeBSD 12 on them? I'm asking because it seems support for them is dangerously decayed and likely wouldn't work. These are old systems, EOLd back in 2009. There's issues with the boot loader, and it's unclear if a kernel for these boards would still work (the boards have only 64MB of RAM, which puts them at the extreme low end of what can run FreeBSD without expert tuning of the kernel). A couple of years ago, I know we had one user, but I'm not sure that he's still using the board. The niche market for these boards was wifi, but the standard have evolved since then and there's no relevant hardware available for an upgrade. Warner From owner-freebsd-arm@freebsd.org Mon Oct 23 19:24:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2FB6E530B8 for ; Mon, 23 Oct 2017 19:24:45 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 DCECC81171 for ; Mon, 23 Oct 2017 19:24:45 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9NJOafo007004 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Oct 2017 12:24:36 -0700 Subject: Re: Any AVILA / CAMBRIA users? To: freebsd-arm@freebsd.org References: From: Nathan Whitehorn Message-ID: <027e0c63-9017-cb62-a6ba-1764a42a630c@freebsd.org> Date: Mon, 23 Oct 2017 12:24:35 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVY3EpWV+t/d7JuGLM7hemT9r3jf/B8SBz1NNyuBu3uEJYbPmxmbb+/3lerQ2trpjqI/67K5K3JSqjv+CjinOK9YLAw15erflDo= X-Sonic-ID: C;CO5Ezie45xGDgYKfRUfeDw== M;arOzzie45xGDgYKfRUfeDw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:24:46 -0000 I do, and run a reasonably recent 12-CURRENT on it. This is my home wifi router. I think the bootloader stuff has never worked (I've never used it, anyway), so have no objections to deleting it. -Nathan On 10/23/17 12:22, Warner Losh wrote: > Is anybody still using the IXP425 systems on FreeBSD? Do you expect to run > FreeBSD 12 on them? > > I'm asking because it seems support for them is dangerously decayed and > likely wouldn't work. These are old systems, EOLd back in 2009. There's > issues with the boot loader, and it's unclear if a kernel for these boards > would still work (the boards have only 64MB of RAM, which puts them at the > extreme low end of what can run FreeBSD without expert tuning of the > kernel). A couple of years ago, I know we had one user, but I'm not sure > that he's still using the board. The niche market for these boards was > wifi, but the standard have evolved since then and there's no relevant > hardware available for an upgrade. > > Warner > _______________________________________________ > 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 Oct 23 19:27:02 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 107C9E532CD for ; Mon, 23 Oct 2017 19:27:02 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AD04812AD for ; Mon, 23 Oct 2017 19:27:01 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id m72so11567509wmc.1 for ; Mon, 23 Oct 2017 12:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=G6l8Rr/X3iW0QZhYw33BjhRAkrvNPlUM0VC0r8Txd8U=; b=O+xazToUU75BBuJnIntfdJ9CY9tvq52krv4pJyMTzMvpDMPmXtfBIEE6vaHrWDfhn6 oKB5s0agLh756GI8Zo1l0G47lOEZ/JStIp3CllU5X2PPF+LD9xiLjFsPQyYEH2m7Vrhh Fuf3oJMIl4ifHGJgE9SZttuPRVfZdLUU1XDUq7IFPPiC5hG/TArEKAJhQeQ43yq7nhlN EFluoiU+PUK+7joOi7046SzUNobJwoQO8eTL7a3BH6O9NSOt0n4UqxHGUZttauNFw94R SL8YGGvZvbWiDQBzgMIUKaLrtzC/J3DOFjAuD6MxVELSOPzrmU0M6xwhUNpsPjeXxL46 yVEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=G6l8Rr/X3iW0QZhYw33BjhRAkrvNPlUM0VC0r8Txd8U=; b=Z4zHmqWLqliDNi/fKK9u0UMDuzYk+7vjo9KMvFpmdpGoX6EpnEoPTp5HS90G18lqLh YTgqB3yHDWc32O2BCeDGPG8gK2H+1YPPxRLC2ZBoj+/jtJhdzDj7ixFCffngkYC1mpfC kx9Tw8zW8gZSWm7TkmiTFZi5okxZPoqvk93+hnq4D5D2n2uLW4bL4fj+xk4mN0HUuCW0 ve3ESHg5zNM+nxIHoO6tMcMe9bxyCtpT7p7NPgI+t05sVMWDmw7n+aAg+3j0Hfpchabh 8FzuTLeQDuJIUi3To82vq/RZHDsfrHGU43T/b4s6Oxd8m4czIkDXwKVzPOhUnjmcze21 490w== X-Gm-Message-State: AMCzsaXk8YChp1+5gs8jThaKizWML6zdY65DhuqRLbXrV7owc9QYbffe yJoKKb4H/lAu7XqhMliah1sFuGw/4m1CVi2uWKpG6+Pd X-Google-Smtp-Source: ABhQp+RigjCZZInPnar13OCV3tte7khNCvM8d/nP2EOzmTIhDdLHXKWeqFsiU5oSFmxrXxY7e3p5po9yDKUeUQqQeGA= X-Received: by 10.28.231.25 with SMTP id e25mr4660760wmh.157.1508786819699; Mon, 23 Oct 2017 12:26:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Mon, 23 Oct 2017 12:26:59 -0700 (PDT) From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Mon, 23 Oct 2017 22:26:59 +0300 Message-ID: Subject: How does (src)/sys/x86/machine/endian.h get deplyoed as DESTDIR/usr/include/x86/endian.h To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:27:02 -0000 Hello, I am trying to add cross build support of FreeBSD from a Linux build system and I am taking it one small step at a time. I have a wrapper script to consistently set environment variables, to set the correct bmake and the proper MAKEFLAGS to pass the correct dirs for the .mk files and made some changes to map the uname -p/uname -m's reported x86_64 to amd64 for the MACHINE* variables. During 'make TARGET=3Damd64 toolchain' the compilation of contrib/libc-pwcache/pwcache.c fails to find some definitions. Of course, before implementing the changes in the build system (or my Linux wrapper script) definitons that might make sense for a build from Linux, I am trying to compile by hand the offending pwcache.c file, and, although some of them I was able to resolve either by using the files from freebsd-glue or by adding -Isys, I am a little puzzled by the mix of build and freebsd headers/definitions and also got stuck because in my mind the compilation at this stage needs to generate binaries for running on a linux system, but some definitions seem to be freebsd specfic. In either case, I saw that on the FreeBSD system I am using as a reference there are some files (such as endian.h) are in /usr/include/x86, but in the source tree they were in the source tree in sys/x86/machine. Since at this stage it looks like I need some kind of way to do an install-headers(?) from sys/$MACHINE/machine (+x86, in case of x86_64) to a $NON_BSD_WRAPPERSDIR/$MACHINE/usr/include directory: 1) does it make sense to try to use the headers from src, or is the right way (tm) to add definitions which are 100% correct for Linux? 1.1) I am thinking that since the definitions were originally in the src tree under sys, they are related to the FreeBSD kernel, so it makes little sense to try to define something for Linux. Am I wrong? Does it make sense to continue on this route? 2) is there such a target/script that I can run to populate my wrappers dir with the right headers no matter which $MACHINE we're talking about? --=20 Eddy Petri=C8=99or From owner-freebsd-arm@freebsd.org Mon Oct 23 19:30:56 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 A7C0FE534F8 for ; Mon, 23 Oct 2017 19:30:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 6BDDC8146B for ; Mon, 23 Oct 2017 19:30:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id y15so7246854ita.4 for ; Mon, 23 Oct 2017 12:30:56 -0700 (PDT) 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=dbC9DFuPy+Jq05bM4Wyc59ptDK049uRz6An2mf/aQqk=; b=xMbr9XTl8KRBvl6oLVRXAY7eqArQIjBmpgCR4tDwTD8Ojbf/+JtJHDUFS6sMzxBMAt qiOPoUHX96lNpKlBeyouYhil4zFyuTMG2iBp7DSpwOmz04zzgXjMcX6NK78ygxKhT2eN Vdw51kTOFUPP4qCG2b7Uf/xXQD3Gz8Ta9onInFyqT/qSVeIQPon8COjkgb9tlWq9fXu7 XAH8z586UNpawRa+Ct6obZKGpG5ExGm4Kmybw7Ad7ci+ZcyoaIzVcU0Kj6f64KgDWZmn 0jK2C96YHiyY0EdEvA+rOWqHmUf2smuwRgG/pX2c8W+TT5LVUtZChiuyaBq9mWMjMRno Cwvw== 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=dbC9DFuPy+Jq05bM4Wyc59ptDK049uRz6An2mf/aQqk=; b=OCIwKLUOtWGHaPhVZit1hQVpnQX9u7DrbJS/t7+/mANkUjTQkrw90IGOQ308SXc1uB qBfIu8V21P7FHE5eengITi0rs8tmqx0rk1zg/6XanV0mTbRAu6Z7+6/No76LCJ4yZoTa mCbLibjdBft8Ami1i44RIt3JyHnwh5nsp/5SlxbfZquD+N6ioqnos5SM/s2j+hwbJnMQ dSVk5dyT2L2K2ki7RxwYqwEA3nanx1isSc5B/6LfdioVtIyYHcAPuGTloZESqjoEWqMd F18u1E5BKW23DeZpsxnAosheINLoSbUP/1C6E2/78NoU9vtEJJgc/wXB3byajJ4U7W9q tTXw== X-Gm-Message-State: AMCzsaWxTpH/q2Uc7UiBtoru6hTP3Uk5v8uwkjIW1TuuZMk2ehLgUvhs Sdv5wHGwxhxr5DSUe/MwsWF5n7r7gD5GlaPONdJseg== X-Google-Smtp-Source: ABhQp+RmVSBkmaO6JM14Zj0RKbXN11h8DyKKF0zplDGTeV6eK6fpcBIl6McKghAYNIDFT2vUOH6W8oaejD9NN9MF23Q= X-Received: by 10.36.118.81 with SMTP id z78mr10746782itb.97.1508787055766; Mon, 23 Oct 2017 12:30:55 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Mon, 23 Oct 2017 12:30:55 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:9c93:1751:a648:919b] In-Reply-To: References: From: Warner Losh Date: Mon, 23 Oct 2017 13:30:55 -0600 X-Google-Sender-Auth: fkVCXJc3PbP4QbEm6PBg5jCtNlc Message-ID: Subject: Re: How does (src)/sys/x86/machine/endian.h get deplyoed as DESTDIR/usr/include/x86/endian.h To: =?UTF-8?Q?Eddy_Petri=C8=99or?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:30:56 -0000 On Mon, Oct 23, 2017 at 1:26 PM, Eddy Petri=C8=99or wrote: > Hello, > > I am trying to add cross build support of FreeBSD from a Linux build > system and I am taking it one small step at a time. > > I have a wrapper script to consistently set environment variables, to > set the correct bmake and the proper MAKEFLAGS to pass the correct > dirs for the .mk files and made some changes to map the uname -p/uname > -m's reported x86_64 to amd64 for the MACHINE* variables. > > During 'make TARGET=3Damd64 toolchain' the compilation of > contrib/libc-pwcache/pwcache.c fails to find some definitions. Of > course, before implementing the changes in the build system (or my > Linux wrapper script) definitons that might make sense for a build > from Linux, I am trying to compile by hand the offending pwcache.c > file, and, although some of them I was able to resolve either by using > the files from freebsd-glue or by adding -Isys, I am a little puzzled > by the mix of build and freebsd headers/definitions and also got stuck > because in my mind the compilation at this stage needs to generate > binaries for running on a linux system, but some definitions seem to > be freebsd specfic. > > In either case, I saw that on the FreeBSD system I am using as a > reference there are some files (such as endian.h) are in > /usr/include/x86, but in the source tree they were in the source tree > in sys/x86/machine. > > Since at this stage it looks like I need some kind of way to do an > install-headers(?) from sys/$MACHINE/machine (+x86, in case of x86_64) > to a $NON_BSD_WRAPPERSDIR/$MACHINE/usr/include directory: > > 1) does it make sense to try to use the headers from src, or is the > right way (tm) to add definitions which are 100% correct for Linux? > 1.1) I am thinking that since the definitions were originally in the > src tree under sys, they are related to the FreeBSD kernel, so it > makes little sense to try to define something for Linux. Am I wrong? > Does it make sense to continue on this route? > 2) is there such a target/script that I can run to populate my > wrappers dir with the right headers no matter which $MACHINE we're > talking about? In the past, I've walked through the bootstrapping steps to get a full sysroot to do the build of the rest of the system. That's likely the best path forward (so the binaries you are building for FreeBSD/arm are all built with gcc/clang --sysroot /path/to/arm/sysroot). Warner From owner-freebsd-arm@freebsd.org Mon Oct 23 19:40:00 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 ED66BE536B9 for ; Mon, 23 Oct 2017 19:40:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.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 9EC9681892 for ; Mon, 23 Oct 2017 19:40:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1661 invoked from network); 23 Oct 2017 19:33:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Oct 2017 19:33:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 23 Oct 2017 15:33:19 -0400 (EDT) Received: (qmail 22713 invoked from network); 23 Oct 2017 19:33:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Oct 2017 19:33:19 -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 8444DEC94EF; Mon, 23 Oct 2017 12:33:18 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r320599 -> r324563 - USB VIA Labs no more detected Date: Mon, 23 Oct 2017 12:33:17 -0700 References: <6837b35d-7998-d75c-64e6-0a8cae671bd1@restart.be> To: Henri Hennebert , freebsd-arm In-Reply-To: <6837b35d-7998-d75c-64e6-0a8cae671bd1@restart.be> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:40:01 -0000 On 2017-Oct-23, at 5:57 AM, Henri Hennebert wrote: > I try 12.0-CURRENT -r324563 on pine64+ 2GB and the USB VIA Labs hub = and its 2 disks is no more detected. >=20 > Wen running r320599, boot msg: >=20 > . . . >=20 > When running r324563, boot msg: >=20 > . . . Are you using the lower usb port to attach your hub? I ask because. . . The A64 support has been undergoing re-work by Emmanuel Vadot for some time. I'm running -r324743 of head and with that the lower usb port works, complete with EHCI support, which I'm using. -r324563 is what enabled ECHI on this lower port. Before it had been OHCI-only since -r323641 (and not working for a time before that). But the note from -r323641 still applies to the top usb port in that a "musb" driver is needed in the new implementation and is still missing as I understand: QUOTE: This (plus 323640) re-enable OHCI on Pine64 on the bottom USB port. The top USB port is routed to the OHCI0/EHCI0 which is by default in OTG = mode. While the phy code can handle the re-route to standard OHCI/EHCI we = still need a driver for musb to probe and configure it in host mode. :END QUOTE =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Oct 23 21:17:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9EE9E5543C for ; Mon, 23 Oct 2017 21:17:53 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD32384F45 for ; Mon, 23 Oct 2017 21:17:53 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 32AE83B4D1; Mon, 23 Oct 2017 15:08:45 -0600 (MDT) Date: Mon, 23 Oct 2017 15:08:45 -0600 From: Brad Davis To: Thomas Laus Cc: freebsd-arm@FreeBSD.org Subject: Re: Does FreeBSD-update work for ARM? Message-ID: <20171023210845.GB53537@corpmail.liquidneon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 21:17:53 -0000 On Sat, Oct 21, 2017 at 11:30:27AM -0400, Thomas Laus wrote: > I have a new 11.1 installation on a Beaglebone Black and wanted to > install the two patches that have been issued since it's release. I > receive the following dialog. No, unfortunately the way freebsd-update is implemented prevents it from being practical to use on slow media like SD Cards. Part of the motivation for those of us working on Package Base is to make updates to machines with less resources possible. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Mon Oct 23 22:49:18 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 1327BE57138 for ; Mon, 23 Oct 2017 22:49:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.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 BFD483751 for ; Mon, 23 Oct 2017 22:49:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1402 invoked from network); 23 Oct 2017 22:49:15 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 23 Oct 2017 22:49:15 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 23 Oct 2017 18:49:15 -0400 (EDT) Received: (qmail 31517 invoked from network); 23 Oct 2017 22:49:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Oct 2017 22:49:15 -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 EBE1EEC91A3; Mon, 23 Oct 2017 15:49:14 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r323640 kernel+.dtb works on BPI-M3; later code requires finding "reg-names" and "phy_ctrl" in .dtb but bpi-m3 has never had them Date: Mon, 23 Oct 2017 15:49:14 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:49:18 -0000 [Top post of some material that does not fit sequentially with prior material.] I think I've identified one aspect of "legacy" allwinner .dtb's that is not covered by modern FreeBSD kernel code, at least for the bpi-m3 .dtb that FreeBSD builds (which FreeBSD builds in a legacy form with old sources for all but some include files). I guess the overall BPI-M3 question comes down to a choice for BPI-M3 (and possibily other ALLWINNERS?): A) The BPI-M3 support being dropped, including its u-boot port. B) The head kernel supporting the legacy .dtb that it produces for the BPI-M3 (or similar ones). C) FreeBSD building a modern .dtb that is structured to match what the head kernel supports in .dtb's. (The implication being use of updated *.dt* source code for the BPI-M3.) D) Some mix of (B) and (C). As for the aspect identified (for me the material is unfamiliar, for others this may be obvious): It looks like modern .dtb's (and the *.dt* source files) use the string phy_ctrl and the string reg-names and that the modern kernel requires that for allwinner's: # grep -r "\" /usr/src/sys/arm/ | less /usr/src/sys/arm/allwinner/aw_usbphy.c: struct resource * = phy_ctrl; /usr/src/sys/arm/allwinner/aw_usbphy.c: /* Get phy_ctrl region */ /usr/src/sys/arm/allwinner/aw_usbphy.c: if = (ofw_bus_find_string_index(node, "reg-names", "phy_ctrl", &rid) !=3D 0) = { /usr/src/sys/arm/allwinner/aw_usbphy.c: sc->phy_ctrl =3D = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, /usr/src/sys/arm/allwinner/aw_usbphy.c: if (sc->phy_ctrl =3D=3D NULL) { /usr/src/sys/arm/allwinner/aw_usbphy.c: = CLR4(sc->phy_ctrl, OTG_PHY_CFG, /usr/src/sys/arm/allwinner/aw_usbphy.c: = SET4(sc->phy_ctrl, OTG_PHY_CFG, static int awusbphy_init(device_t dev) { . . . sc =3D device_get_softc(dev); node =3D ofw_bus_get_node(dev); sc->phy_conf =3D (struct aw_usbphy_conf = *)ofw_bus_search_compatible(dev, compat_data)->ocd_data; /* Get phy_ctrl region */ if (ofw_bus_find_string_index(node, "reg-names", "phy_ctrl", = &rid) !=3D 0) { device_printf(dev, "Cannot locate phy control = resource\n"); return (ENXIO); } . . . That "if" is new as of -r323641 and it rejects the BPI-M3 .dtb that FreeBSD generates (the same one by content that works with -r323640). This is because there are no reg-names or phy_ctrl string involved at all. Using the sorted output of dtc on the BPI-M3 .dtb from -r324743 : # grep reg-names ~/bpi-m3-sorted-324743.dts (Nothing found above.) # grep phy ~/bpi-m3-sorted-324743.dts fixup =3D "/soc/phy@01c19400:clocks:0"; fixup =3D "/soc/phy@01c19400:clocks:8"; fixup =3D "/soc/phy@01c19400:clocks:16"; fixup =3D "/soc/phy@01c19400:clocks:24"; fixup =3D "/soc/phy@01c19400:resets:0"; fixup =3D "/soc/phy@01c19400:resets:8"; fixup =3D "/soc/phy@01c19400:resets:16"; fixup =3D "/soc/phy@01c19400:usb1_vbus-supply:0"; fixup =3D "/soc/usb@01c1a000:phys:0"; fixup =3D "/soc/usb@01c1b000:phys:0"; fixup =3D "/soc/ethernet@01c30000:phy:0"; mii_phy_tx_clk =3D "/clocks/clk@1"; phy1 =3D "/soc/ethernet@01c30000/ethernet-phy@1"; usbphy =3D "/soc/phy@01c19400"; clock-output-names =3D "usb_phy0", "usb_phy1", = "usb_hsic_pll", "usb_hsic_12m", "usb_ohci0"; clock-output-names =3D "mii_phy_tx"; phy =3D <0x30>; phy-mode =3D "rgmii"; ethernet-phy@1 { phy@01c19400 { #phy-cells =3D <0x1>; clock-names =3D "usb0_phy", "usb1_phy", = "hsic_pll", "hsic_12m"; compatible =3D "allwinner,sun8i-a83t-usb-phy"; phy-names =3D "usb"; phys =3D <0x2d 0x1>; phy-names =3D "usb"; phys =3D <0x2d 0x2>; (No phy_ctrl examples above.) # grep pmu ~/bpi-m3-sorted-324743.dts pmu { compatible =3D "arm,cortex-a7-pmu", = "arm,cortex-a15-pmu"; Supporting detail (skip unless you care). . . As for the FreeBSD *.dt* source code in use in this ALLWINNER area: # grep -r phy_ctrl /usr/src/sys/gnu/dts/ | less /usr/src/sys/gnu/dts/arm/sun8i-a33.dtsi: reg-names =3D = "phy_ctrl", "pmu1"; /usr/src/sys/gnu/dts/arm/sun8i-a23.dtsi: reg-names =3D = "phy_ctrl", "pmu1"; /usr/src/sys/gnu/dts/arm/sunxi-h3-h5.dtsi: = reg-names =3D "phy_ctrl", /usr/src/sys/gnu/dts/arm/sun4i-a10.dtsi: = reg-names =3D "phy_ctrl", "pmu1", "pmu2"; /usr/src/sys/gnu/dts/arm/sun6i-a31.dtsi: = reg-names =3D "phy_ctrl", /usr/src/sys/gnu/dts/arm/am33xx.dtsi: = reg-names =3D "phy_ctrl", "wakeup"; /usr/src/sys/gnu/dts/arm/dm814x.dtsi: = reg-names =3D "phy_ctrl", "wakeup"; /usr/src/sys/gnu/dts/arm/sun8i-v3s.dtsi: = reg-names =3D "phy_ctrl", /usr/src/sys/gnu/dts/arm/sun5i.dtsi: reg-names =3D = "phy_ctrl", "pmu1"; /usr/src/sys/gnu/dts/arm/sun7i-a20.dtsi: = reg-names =3D "phy_ctrl", "pmu1", "pmu2"; # grep -r phy_ctrl /usr/src/sys/boot/fdt/dts/ | less /usr/src/sys/boot/fdt/dts/arm64/a64.dtsi: = reg-names =3D "phy_ctrl", "pmu1", "pmu2"; (Note the lack of a83t and bpi-m3 material above.) But the area with the BPI-M3 materials (other than some of the include files) does not have such in those materials:=20 # egrep -r "(reg-names|phy_ctrl)" /usr/src/sys/boot/fdt/dts/ | more /usr/src/sys/boot/fdt/dts/arm/armada-38x.dtsi: = reg-names =3D "rtc", "rtc-soc"; /usr/src/sys/boot/fdt/dts/arm/armada-38x.dtsi: = reg-names =3D "sdhci", "mbus", "conf-sdio3"; /usr/src/sys/boot/fdt/dts/arm/h3.dtsi: reg-names =3D = "emac", "syscon"; /usr/src/sys/boot/fdt/dts/arm/h3.dtsi: /* reg-names =3D = "codec", "pr"; */ /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi: = reg-names =3D "emac", "syscon"; /usr/src/sys/boot/fdt/dts/arm64/a64.dtsi: = reg-names =3D "phy_ctrl", "pmu1", "pmu2"; (Note again the lack of a83t and bpi-m3 material above.) vs. # ls -lt /usr/src/sys/boot/fdt/dts/arm | egrep -i "(a83t|m3)" -rw-r--r-- 1 root wheel 7985 Jan 2 2017 a83t.dtsi -rw-r--r-- 1 root wheel 3601 Nov 3 2016 sinovoip-bpi-m3.dts -rw-r--r-- 1 root wheel 2750 Nov 3 2016 = sun8i-a83t-sinovoip-bpi-m3.dts -rw-r--r-- 1 root wheel 13293 Nov 3 2016 sun8i-a83t.dtsi -rw-r--r-- 1 root wheel 6205 Nov 3 2016 yyhd18-m3.dts (That last is an amlogic associated file and does not apply here.) # grep -r phy /usr/src/sys/boot/fdt/dts/ | egrep -i "(a83t|m3)" /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = clock-output-names =3D "usb_phy0", "usb_phy1", /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: mii_phy_tx_clk: = clk@1 { /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = clock-output-names =3D "mii_phy_tx"; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: clocks =3D= <&mii_phy_tx_clk>, <&emac_int_tx_clk>; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: usbphy: = phy@01c19400 { /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = compatible =3D "allwinner,sun8i-a83t-usb-phy"; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = clock-names =3D "usb0_phy", /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = "usb1_phy", /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = #phy-cells =3D <1>; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: phys =3D = <&usbphy 1>; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = phy-names =3D "usb"; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: phys =3D = <&usbphy 2>; /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: = phy-names =3D "usb"; /usr/src/sys/boot/fdt/dts/arm/yyhd18-m3.dts: * usb-phy which depends on = gpio, also the timer should appear early on /usr/src/sys/boot/fdt/dts/arm/yyhd18-m3.dts: usb-phy@c1108400 = { /usr/src/sys/boot/fdt/dts/arm/yyhd18-m3.dts: /* usb-a = and usb-b phy */ /usr/src/sys/boot/fdt/dts/arm/yyhd18-m3.dts: = compatible =3D "amlogic,aml8726-m3-usb-phy"; /usr/src/sys/boot/fdt/dts/arm/sinovoip-bpi-m3.dts:&usbphy { /usr/src/sys/boot/fdt/dts/arm/sinovoip-bpi-m3.dts: phy =3D <&phy1>; /usr/src/sys/boot/fdt/dts/arm/sinovoip-bpi-m3.dts: phy-mode =3D = "rgmii"; /usr/src/sys/boot/fdt/dts/arm/sinovoip-bpi-m3.dts: phy1: = ethernet-phy@1 { # grep -r pmu /usr/src/sys/boot/fdt/dts/ | egrep -i "(a83t|m3)" /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: pmu { /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi: compatible =3D = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; =3D=3D=3D Mark Millard markmi at dsl-only.net > On 2017-Oct-22, at 11:42 PM, Mark Millard wrote: >=20 > [The notes here presume that mp_ncpu <=3D cpuid is > considered valid for the BPI-M3. Otherwise what > I'm running is a workaround allowing other aspects > of things to be explored.] >=20 > [Reminder: Most of the BPI-M3 *.dt* material > is not from sys/gnu/dts/ at all but from > sys/boot/fdt/dts/ instead: not updated > with LINUX 4.?? updates. But some included > *.dt* files are from sys/gnu/dts/ .] >=20 > I was able to buildkernel for -r323640 and install > and boot it on the BPI-M3. Basic operation seems > okay so far. >=20 > It appears to me that -r323641 and later can > not interpret the same .dtb that -r323640 uses > correctly. My guess is some legacy support has > been (implicitly?) removed. (This may well be > deliberate and more important than having the > BPI-M3 working from an overall point of view.) >=20 >=20 > FYI for what I've tried in order to show some > context: >=20 >=20 > Revision 320834 - Directory Listing=20 > Modified Sun Jul 9 13:53:32 2017 UTC (3 months, 2 weeks ago) by manu > Update DTS files from Linux 4.12 >=20 > Notable changes: >=20 > Allwinner: > * H3/H5 were merged into a common dtsi file > * include/dt-bindings/sun4i-a10.h is not included anymore > in a lot of dts files > * Add sun8i-h3-nanopi-neo-air board DTS file >=20 >=20 > . . . >=20 >=20 > Revision 323640 - Directory Listing=20 > Modified Sat Sep 16 15:50:31 2017 UTC (5 weeks, 1 day ago) by manu > A64 CCUNG: Correct gate and reset for OHCI0/1 >=20 > Reported by: jmcneill > Pointy Hat: manu >=20 >=20 > Then the very next update changes some things > about interpreting the .dtb greatly . . . >=20 >=20 > Revision 323641 - Directory Listing=20 > Modified Sat Sep 16 15:58:20 2017 UTC (5 weeks, 1 day ago) by manu > Allwinner usb phy: Rework resource allocation >=20 > The usbphy node for allwinner have two kind of resources, one for the > phy_ctrl and one per phy. Instead of blindy allocating resources, = alloc > the phy_ctrl and pmu ones separately. > Also add a configuration struct for all different phy that hold the = difference > between them (number of phys, unknow needed register write etc ...). >=20 > While here remove A83T code as upstream and FreeBSD dts don't have > nodes for USB. >=20 > This (plus 323640) re-enable OHCI on Pine64 on the bottom USB port. > The top USB port is routed to the OHCI0/EHCI0 which is by default in = OTG mode. > While the phy code can handle the re-route to standard OHCI/EHCI we = still need > a driver for musb to probe and configure it in host mode. >=20 > EHCI is still buggy on Pine64 (hang the board) so do not enable it for = now. >=20 > Tested On: Bananapi (A20), BananapiM2 (A31S), OrangePi One (H3) = Pine64 (A64) >=20 >=20 > . . . >=20 >=20 > Revision 324820 - Directory Listing=20 > Modified Sat Oct 21 15:47:40 2017 UTC (38 hours, 31 minutes ago) by = manu > dts: Update our device tree sources file fomr Linux 4.13 >=20 >=20 >=20 > (I have not tried a .dtb partially based on -r324820 > *.dts* material from sys/gnu/dts/ used with a > -r323640 kernel.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Oct 24 03:43: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 06F25E3B112 for ; Tue, 24 Oct 2017 03:43:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.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 BC88F6D97F for ; Tue, 24 Oct 2017 03:43:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18343 invoked from network); 24 Oct 2017 03:43:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2017 03:43:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 23 Oct 2017 23:43:52 -0400 (EDT) Received: (qmail 22553 invoked from network); 24 Oct 2017 03:43:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2017 03:43:52 -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 6EAD9EC7848; Mon, 23 Oct 2017 20:43:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen Date: Mon, 23 Oct 2017 20:43:50 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: Message-Id: <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 03:43:55 -0000 [This largely ignores my questions about mp_ncpu <=3D cpuid happening when there are 4 unused cores (of 8), as there are for the BPI-M3's A83T support.] For head -r324743, by making: sys/boot/fdt/dts/arm/a83t.dtsi slightly more modern (reg-names, phy_ctrl, pmu0, and pmu1) and putting in my guesses for A83T in: /usr/src/sys/arm/allwinner/aw_usbphy.c I've gotten -r324743 to boot with a root file system on an external USB drive in ECHI mode. I've tried both USB ports and both have worked as ECHI for this. The changes: # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) @@ -179,6 +179,9 @@ reg =3D <0x01c19400 0x2c>, <0x01c1a800 0x4>, <0x01c1b800 0x4>; + reg-names =3D "phy_ctrl", + "pmu0", + "pmu1"; clocks =3D <&usb_clk 8>, <&usb_clk 9>, <&usb_clk 10>, Other than some include file usage, the BPI-M3 is not and has not been using sys/gnu/dts/ files. The above makes the .dtb that FreeBSD produces be something that the modern kernel will not reject parts of. # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c Index: /usr/src/sys/arm/allwinner/aw_usbphy.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) @@ -58,6 +58,7 @@ AWUSBPHY_TYPE_A13, AWUSBPHY_TYPE_A20, AWUSBPHY_TYPE_A31, + AWUSBPHY_TYPE_A83T, AWUSBPHY_TYPE_H3, AWUSBPHY_TYPE_A64 }; @@ -90,6 +91,13 @@ .phy0_route =3D false, }; =20 +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { + .num_phys =3D 3, // SATA via USB bridge as well + .phy_type =3D AWUSBPHY_TYPE_A83T, + .pmu_unk1 =3D false, // ???? + .phy0_route =3D true, // ???? +}; + static const struct aw_usbphy_conf a31_usbphy_conf =3D { .num_phys =3D 3, .phy_type =3D AWUSBPHY_TYPE_A31, @@ -116,6 +124,7 @@ { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, { NULL, 0 } The SATA is why there are 3 USB phys for the BPI-M3 instead of 2. The root filesystem is on: da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 One new thing is: 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 I've not figured out what those messages are about yet. There is also: real memory =3D 2147483648 (2048 MB) avail memory =3D 2089332736 (1992 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs vs. cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cpu4: on cpulist0 cpufreq_dt1: on cpu4 cpufreq_dt1: no regulator for cpu@100 device_attach: cpufreq_dt1 attach returned 6 cpu5: on cpulist0 cpu6: on cpulist0 cpu7: on cpulist0 My understanding is: only the first cluster of 4 cores is supposed to be active/used and the 2nd cluster is supposed to not be in active use. I'm not sure that the 2nd cluster is being handled as intended, or what the intended details are. But top does show only 4. An old thing is still true: a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00008018 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 mmcsd1: 8GB at = mmc1 52.0MHz/8bit/65535-block mmcsd1boot0: 4MB partion 1 at mmcsd1 mmcsd1boot1: 4MB partion 2 at mmcsd1 mmcsd1rpmb: 524kB partion 3 at mmcsd1 FYI: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 = 1200051 1200051 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Oct 24 06:06:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14E94E412A1 for ; Tue, 24 Oct 2017 06:06:05 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF17671CCB for ; Tue, 24 Oct 2017 06:06:04 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=markmi@dsl-only.net DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3yLjSV1wYTzt0g Received: from restart.be (norquay.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3yLjSV1wYTzt0g; Tue, 24 Oct 2017 08:06:01 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v9O65xj7009475 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Oct 2017 08:06:00 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r320599 -> r324563 - USB VIA Labs no more detected To: Mark Millard , freebsd-arm References: <6837b35d-7998-d75c-64e6-0a8cae671bd1@restart.be> From: Henri Hennebert Message-ID: Date: Tue, 24 Oct 2017 08:05:59 +0200 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 06:06:05 -0000 On 10/23/2017 21:33, Mark Millard wrote: > On 2017-Oct-23, at 5:57 AM, Henri Hennebert wrote: > > >> I try 12.0-CURRENT -r324563 on pine64+ 2GB and the USB VIA Labs hub and its 2 disks is no more detected. >> >> Wen running r320599, boot msg: >> >> . . . >> >> When running r324563, boot msg: >> >> . . . > > Are you using the lower usb port to attach your hub? > I ask because. . . > > The A64 support has been undergoing re-work by > Emmanuel Vadot for some time. > > I'm running -r324743 of head and with that the > lower usb port works, complete with EHCI support, > which I'm using. -r324563 is what enabled ECHI > on this lower port. Before it had been OHCI-only > since -r323641 (and not working for a time > before that). You are right, I was using the upper USB port. I will try the lower one. Thanks for your information > > But the note from -r323641 still applies to the > top usb port in that a "musb" driver is needed > in the new implementation and is still missing > as I understand: > > QUOTE: > This (plus 323640) re-enable OHCI on Pine64 on the bottom USB port. > The top USB port is routed to the OHCI0/EHCI0 which is by default in OTG mode. > While the phy code can handle the re-route to standard OHCI/EHCI we still need > a driver for musb to probe and configure it in host mode. > :END QUOTE > > > === > Mark Millard > markmi at dsl-only.net > > From owner-freebsd-arm@freebsd.org Tue Oct 24 06:20:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9DA8E4163A for ; Tue, 24 Oct 2017 06:20:04 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 6C9B4720A0 for ; Tue, 24 Oct 2017 06:20:04 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id b189so13296396wmd.4 for ; Mon, 23 Oct 2017 23:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aTRDlBAiDzg2954LXRN/TUlDhO2LtnSegr1KXL3unbE=; b=BE57DcS2I5yZYdomJVJMasuZmMi6PCxXvvEy3YOOBtn5iceKtw15oxxSkimmXnCDVM fNSKMk6qRhIfbRtYc0QnKKvnbxvkEQiJCtz6vHTKG0xVOzDz00XCpDCszMnadfvkF7vz NhBU4OMbh07H1ORhoa+D0YD5m1o1WFfPQjrC+T5lP+SjOrsppnkzVScj57DrJ/4IFurC agzF7lBT6g1MWS1HZjrvCvhlw2zjfYZv3QlA/q0KkSN9erYk3iYpHNKmCIGCFFmpo1KA sKKLEeoSutWw2A0LvnQ70qCCXUhxonYilDArBDyfl21Z1Qyh0U85FpQeu623KDV+M5up BEww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aTRDlBAiDzg2954LXRN/TUlDhO2LtnSegr1KXL3unbE=; b=tT5uqe0feRAe3EZAwMTJmnW8/hW09jzLjxN2mGRpI43fOnOe5lgDoYLowGA+3nJz5X jfm7++hBT3iz2QjgOQx0nPZFE/VFaZZ5/imDizIsRfWbbvjFy1ipv////WlL6ksZhRTl /k0GnvbwqxHiMaCPfGcXYx0955iJPA3ygujxrZXQP6RgXjEnoN7OJbOdpIPUAW9J+IJC pfKs4QWey8YsJJpHMFClmi/9N1yrauD/3C4E1iB25kFnmmolE6LaR7bIeLyTZcCfp5BF sc3g1BcQpMo/2Bb6UVQAViG6XDZUlObGiiHFxXtR2w39Wreuey6wnnxIWIkzbJL0Puc0 DsbQ== X-Gm-Message-State: AMCzsaWpGznjkwN6aIva6EvkVuKtdXBzVwjnlt82JKYzcG81P9HDe8oQ xJeBxDrvHeqjMPxSR7SpVXImyBOQQHS2C4xLl7sKQQ== X-Google-Smtp-Source: ABhQp+SUUpaBPjgQued/GymjnF0JExDI12jgEVp1fXEm/aI9Vo+CfU2qRyB91ViXtmWYiGh5Qux/T35wbFAJ1X7VNw8= X-Received: by 10.28.231.25 with SMTP id e25mr5663897wmh.157.1508826002846; Mon, 23 Oct 2017 23:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Mon, 23 Oct 2017 23:20:01 -0700 (PDT) Received: by 10.223.173.129 with HTTP; Mon, 23 Oct 2017 23:20:01 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Tue, 24 Oct 2017 09:20:01 +0300 Message-ID: Subject: Re: How does (src)/sys/x86/machine/endian.h get deplyoed as DESTDIR/usr/include/x86/endian.h To: Warner Losh Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 06:20:05 -0000 Pe 23 oct. 2017 10:30 PM, "Warner Losh" a scris: On Mon, Oct 23, 2017 at 1:26 PM, Eddy Petri=C8=99or wrote: > Hello, > > I am trying to add cross build support of FreeBSD from a Linux build > system and I am taking it one small step at a time. > > I have a wrapper script to consistently set environment variables, to > set the correct bmake and the proper MAKEFLAGS to pass the correct > dirs for the .mk files and made some changes to map the uname -p/uname > -m's reported x86_64 to amd64 for the MACHINE* variables. > > During 'make TARGET=3Damd64 toolchain' the compilation of > contrib/libc-pwcache/pwcache.c fails to find some definitions. Of > course, before implementing the changes in the build system (or my > Linux wrapper script) definitons that might make sense for a build > from Linux, I am trying to compile by hand the offending pwcache.c > file, and, although some of them I was able to resolve either by using > the files from freebsd-glue or by adding -Isys, I am a little puzzled > by the mix of build and freebsd headers/definitions and also got stuck > because in my mind the compilation at this stage needs to generate > binaries for running on a linux system, but some definitions seem to > be freebsd specfic. > > In either case, I saw that on the FreeBSD system I am using as a > reference there are some files (such as endian.h) are in > /usr/include/x86, but in the source tree they were in the source tree > in sys/x86/machine. > > Since at this stage it looks like I need some kind of way to do an > install-headers(?) from sys/$MACHINE/machine (+x86, in case of x86_64) > to a $NON_BSD_WRAPPERSDIR/$MACHINE/usr/include directory: > > 1) does it make sense to try to use the headers from src, or is the > right way (tm) to add definitions which are 100% correct for Linux? > 1.1) I am thinking that since the definitions were originally in the > src tree under sys, they are related to the FreeBSD kernel, so it > makes little sense to try to define something for Linux. Am I wrong? > Does it make sense to continue on this route? > 2) is there such a target/script that I can run to populate my > wrappers dir with the right headers no matter which $MACHINE we're > talking about? In the past, I've walked through the bootstrapping steps to get a full sysroot to do the build of the rest of the system. I have thought of simply downloading a base.txz to get the headers, but I dislike that idea because I should be able to bootstrap everything without involving precompiled/prebuilt base.txz since all sources are available. That's likely the best path forward (so the binaries you are building for FreeBSD/arm are all built with gcc/clang --sysroot /path/to/arm/sysroot). Please note that I am still at the stage when I am trying to build the cross tool chain, so the TARGET at this stage is still amd64 (not arm64). Because of this there is no sysroot yet. That's why I was asking at 2 for a simple way to install the headers, and if that made sense 1.1. Does it? I preferred to try amd64 since I know there are some things to be ironed out for arm64/aarch64, while for amd64 things should be pretty solid. I expect that after I make my cross tool chain (to be ran on Linux) I will be able to generate binaries for FreeBSD and can buildworld and buildkernel no matter the TARGET (after building the proper toolchain). Warner From owner-freebsd-arm@freebsd.org Tue Oct 24 07:00:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73A2CE427C2 for ; Tue, 24 Oct 2017 07:00:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.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 35F027306C for ; Tue, 24 Oct 2017 07:00:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28835 invoked from network); 24 Oct 2017 07:00:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2017 07:00:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 24 Oct 2017 03:00:05 -0400 (EDT) Received: (qmail 12166 invoked from network); 24 Oct 2017 07:00:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2017 07:00:04 -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 2CB5CEC8074; Tue, 24 Oct 2017 00:00:04 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: armv7 perl5.24 build gets dt_modtrace:/. . ./dt_link.c(814): DOODAD and prepare_elf32:/. . ./dt_link.c(235): DOODAD notices; Context: head -r324743 Message-Id: <8255001E-6157-45FE-B15D-605652B70BEB@dsl-only.net> Date: Tue, 24 Oct 2017 00:00:03 -0700 To: freebsd-arm , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:00:07 -0000 I tried to build poudriere-devel on a BPI-M3 and indirectly it leads to perl5 trying to build, perl5.24 in my context. (security/ca_root_nss needs perl.) During that perl5.24 build it reported: = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.= c(814): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD = prepare_elf32:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_li= nk.c(235): DOODAD So far this has not stopped the build but the build is still running. FYI: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 = 1200051 1200051 I build with -mcpu=3Dcortex-a7 (buildworld, buildkernel, and ports builds). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Oct 24 07:33: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 0B080E432C3 for ; Tue, 24 Oct 2017 07:33:40 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCB1073FAC for ; Tue, 24 Oct 2017 07:33:39 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1e6tiR-007eDW-UU; Tue, 24 Oct 2017 09:33:35 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: freebsd-arm@freebsd.org Subject: rpi3 - changing MAC address of ue0 between GENERIC and GENERIC-NODEBUG kernels Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Oct 2017 09:33:35 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:33:40 -0000 Hello, as I noticed accidental, the MAC address of the ue0 interface on my rpi 3 is changing between a kernel build with KERNCONF=3DGENERIC and KERNCONF=3DGENERIC-NODEBUG from the same revision. It also changes between GENERIC kernels based on different revisions. It looks like the MAC address is stable for each kernel, because when I boot a kernel from an older revision with a known ue0 MAC address this older kernel uses the old known MAC address. I do crosscompiling the rpi3 world and kernel(s) on a amd64 FreeBSD 12.0-Current. The firmware in the FAT partition is not changed between the kernels. As I do not see a common pattern in the MAC addresses, I think they are more or less random memory bits. Examples: d2:8f:50:a0:71:7a GENERIC r324918 de:2a:39:1b:63:1f GENERIC-NODEBUG r324918 7e:45:9d:dc:5b:72 GENERIC r324694 =24 uname -a FreeBSD rpi3-b 12.0-CURRENT FreeBSD 12.0-CURRENT =230 r324918: Mon Oct 23= =20 21:46:36 CEST 2017 root=40home:/usr/obj/arm64.aarch64/usr/src/sys/GEN= ERIC-NOD EBUG arm64 =24=20 Is anybody experiencing the same behavior? Ralf From owner-freebsd-arm@freebsd.org Tue Oct 24 08:41:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C85BE44CB8 for ; Tue, 24 Oct 2017 08:41:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 D997275CAE for ; Tue, 24 Oct 2017 08:41:34 +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 2B5D5260457; Tue, 24 Oct 2017 10:41:26 +0200 (CEST) Subject: Re: rpi3 - changing MAC address of ue0 between GENERIC and GENERIC-NODEBUG kernels To: Ralf Wenk , freebsd-arm@freebsd.org References: From: Hans Petter Selasky Message-ID: <057df05d-9f0f-3cfd-516b-deb0444894b5@selasky.org> Date: Tue, 24 Oct 2017 10:38:48 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 08:41:35 -0000 On 10/24/17 09:33, Ralf Wenk wrote: > Hello, > > as I noticed accidental, the MAC address of the ue0 interface on my > rpi 3 is changing between a kernel build with KERNCONF=GENERIC and > KERNCONF=GENERIC-NODEBUG from the same revision. > > It also changes between GENERIC kernels based on different revisions. > > It looks like the MAC address is stable for each kernel, because when > I boot a kernel from an older revision with a known ue0 MAC address > this older kernel uses the old known MAC address. > > I do crosscompiling the rpi3 world and kernel(s) on a amd64 FreeBSD > 12.0-Current. > > The firmware in the FAT partition is not changed between the kernels. > > As I do not see a common pattern in the MAC addresses, I think they are > more or less random memory bits. Examples: > d2:8f:50:a0:71:7a GENERIC r324918 > de:2a:39:1b:63:1f GENERIC-NODEBUG r324918 > 7e:45:9d:dc:5b:72 GENERIC r324694 > > $ uname -a > FreeBSD rpi3-b 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r324918: Mon Oct 23 > 21:46:36 CEST 2017 root@home:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC-NOD > EBUG arm64 > $ > > Is anybody experiencing the same behavior? > Hi, I believe this topic has been discussed before. Try searching for this thread "How to change MAC address on RPI-B?" on this list first. --HPS From owner-freebsd-arm@freebsd.org Tue Oct 24 08:50:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8001E44F2D; Tue, 24 Oct 2017 08:50:27 +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 2BF1F75F59; Tue, 24 Oct 2017 08:50:26 +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 7d9d1fd1; Tue, 24 Oct 2017 10:50:17 +0200 (CEST) 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=4KV1VlfbFp64nsPuEcpgvb0uLjE=; b=JSVxGr+lLUn3wJc1xTX6nPZkx447 030ESUN+SORyrS3umMSUId1TY1xeyHPWnPiDS7qfps0bn4EaU/ei9oVSVQBdCUOA FnEHp3hc6hs0z1PmTMvjFO2ga/gS1L8Ly2e3vkMlDb8Zpa+g1N0+IsJraFphHIGp 9PokqN7K8do/mPU= 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=gGz7GQh++5CLyaMqH5xwDCrEOMmuIjHvFXjPrCVuUevHtSBNpA8oqJe8 j9464gZ/PwXFYzmqK4VGQzJBqNFB8kwxD7aY33a0Tn7EhgQJMGts2OA5S8D7vHlq XoEsRGlKulSp7Q8vC2Bgpq0VlbmBEG2nsyKjE/1SUVeGg5wVV/M= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 13f4c937 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 24 Oct 2017 10:50:15 +0200 (CEST) Date: Tue, 24 Oct 2017 10:50:14 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-arm , freebsd-hackers Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen Message-Id: <20171024105014.cd2012898a602408ee605183@bidouilliste.com> In-Reply-To: <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 08:50:28 -0000 Top posting as there is too much stuff in that mail. I find it really hard to understand you mail as there is too much data in it. But, to clarify the A83T situation (And general info on Allwinner clocks) : - Old Linux DTS (~4.8 iirc) for Allwinner SoCs had the clock directly defined in them under a /clock nodes, with jmcneill@ we added support for most (if not all) of them and this supported every Allwinner SoCs. - With the H3 DTS added things started to change, they removed the /clock node and simply add a ccu node (Clock Control Unit) as it's commonly done in ARM DTS. - This move a lot of information from the DTS to the kernel driver for the CCU. - Around that time the first H3 dts that was written (but not added in the Linux repository) was from the model, with the /clock node. And we added those file in FreeBSD under sys/boot/fdt/dts - I finally wrote a driver for the new clock ccu driver and currently it support H3, A64 and A31. - Linux started to convert old SoCs from /clock to ccu (A13 is done, A83T too and for A10 and A20 it will be available in 4.15 iirc) - I don't want us (us = FreeBSD) to derive from the Linux DTS as it's a pain to maintain, every change should be sent to Linux directly (it's really not that hard). So, that being said, what needs to be done for A83T support to stay in FreeBSD is adding a ccu driver for it. With the clkng stuff I did (see sys/arm/allwinner/clkng) it's not that hard, it's just a matter of reading the user manual clock section and translate table to macros/struct. You can have a look at H3 (or any other ccu driver) to see how it's done. As of today support for A83T and A13 don't work anymore if you use the current DTS, I've started working on A13 and should commit the driver soon. Someone with A83T should do the same. Cheers, On Mon, 23 Oct 2017 20:43:50 -0700 Mark Millard wrote: > [This largely ignores my questions about > mp_ncpu <= cpuid happening when there are > 4 unused cores (of 8), as there are for > the BPI-M3's A83T support.] > > For head -r324743, by making: > > sys/boot/fdt/dts/arm/a83t.dtsi > > slightly more modern (reg-names, phy_ctrl, > pmu0, and pmu1) and putting in my guesses > for A83T in: > > /usr/src/sys/arm/allwinner/aw_usbphy.c > > I've gotten -r324743 to boot with a root > file system on an external USB drive in > ECHI mode. I've tried both USB ports and > both have worked as ECHI for this. > > The changes: > > # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > =================================================================== > --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) > +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) > @@ -179,6 +179,9 @@ > reg = <0x01c19400 0x2c>, > <0x01c1a800 0x4>, > <0x01c1b800 0x4>; > + reg-names = "phy_ctrl", > + "pmu0", > + "pmu1"; > clocks = <&usb_clk 8>, > <&usb_clk 9>, > <&usb_clk 10>, > > Other than some include file usage, the BPI-M3 is > not and has not been using sys/gnu/dts/ files. The > above makes the .dtb that FreeBSD produces be > something that the modern kernel will not reject > parts of. > > # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c > Index: /usr/src/sys/arm/allwinner/aw_usbphy.c > =================================================================== > --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) > +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) > @@ -58,6 +58,7 @@ > AWUSBPHY_TYPE_A13, > AWUSBPHY_TYPE_A20, > AWUSBPHY_TYPE_A31, > + AWUSBPHY_TYPE_A83T, > AWUSBPHY_TYPE_H3, > AWUSBPHY_TYPE_A64 > }; > @@ -90,6 +91,13 @@ > .phy0_route = false, > }; > > +static const struct aw_usbphy_conf a83t_usbphy_conf = { > + .num_phys = 3, // SATA via USB bridge as well > + .phy_type = AWUSBPHY_TYPE_A83T, > + .pmu_unk1 = false, // ???? > + .phy0_route = true, // ???? > +}; > + > static const struct aw_usbphy_conf a31_usbphy_conf = { > .num_phys = 3, > .phy_type = AWUSBPHY_TYPE_A31, > @@ -116,6 +124,7 @@ > { "allwinner,sun5i-a13-usb-phy", (uintptr_t)&a13_usbphy_conf }, > { "allwinner,sun6i-a31-usb-phy", (uintptr_t)&a31_usbphy_conf }, > { "allwinner,sun7i-a20-usb-phy", (uintptr_t)&a20_usbphy_conf }, > + { "allwinner,sun8i-a83t-usb-phy", (uintptr_t)&a83t_usbphy_conf }, > { "allwinner,sun8i-h3-usb-phy", (uintptr_t)&h3_usbphy_conf }, > { "allwinner,sun50i-a64-usb-phy", (uintptr_t)&a64_usbphy_conf }, > { NULL, 0 } > > The SATA is why there are 3 USB phys for the BPI-M3 > instead of 2. > > The root filesystem is on: > > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number > da0: 40.000MB/s transfers > da0: 228936MB (468862128 512 byte sectors) > da0: quirks=0x2 > > > One new thing is: > > 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 > > I've not figured out what those messages are > about yet. > > There is also: > > real memory = 2147483648 (2048 MB) > avail memory = 2089332736 (1992 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > vs. > > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > cpu4: on cpulist0 > cpufreq_dt1: on cpu4 > cpufreq_dt1: no regulator for cpu@100 > device_attach: cpufreq_dt1 attach returned 6 > cpu5: on cpulist0 > cpu6: on cpulist0 > cpu7: on cpulist0 > > My understanding is: only the first cluster > of 4 cores is supposed to be active/used > and the 2nd cluster is supposed to not > be in active use. I'm not sure that the > 2nd cluster is being handled as intended, > or what the intended details are. But > top does show only 4. > > An old thing is still true: > > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00008018 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > mmcsd1: 8GB at mmc1 52.0MHz/8bit/65535-block > mmcsd1boot0: 4MB partion 1 at mmcsd1 > mmcsd1boot1: 4MB partion 2 at mmcsd1 > mmcsd1rpmb: 524kB partion 3 at mmcsd1 > > > FYI: > > # uname -apKU > FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 1200051 1200051 > > > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 24 10:03: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 66762E47A32 for ; Tue, 24 Oct 2017 10:03:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-164.reflexion.net [208.70.211.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 263677D01D for ; Tue, 24 Oct 2017 10:03:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28770 invoked from network); 24 Oct 2017 10:03:27 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2017 10:03:27 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 24 Oct 2017 06:03:27 -0400 (EDT) Received: (qmail 9082 invoked from network); 24 Oct 2017 10:03:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2017 10:03:27 -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 998DAEC91A3; Tue, 24 Oct 2017 03:03:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen From: Mark Millard In-Reply-To: <20171024105014.cd2012898a602408ee605183@bidouilliste.com> Date: Tue, 24 Oct 2017 03:03:25 -0700 Cc: freebsd-arm , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> <20171024105014.cd2012898a602408ee605183@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 10:03:29 -0000 [Top post.] Thanks for the notes. I'm gradually figuring a little bit out. Looking in: https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/?dir_pagestart=3D1000= (the linux 4.13 update) I see: sun6i-a31s-sinovoip-bpi-m2.dts but no .dts directly for the bpi-m3. So, it appears that the outer layer (.dts) does not have a Linux 4.13 or earlier version to be based on. There is an include file: sun8i-a83t.dtsi Unlike, say, sun6i-a31.dtsi, sun8i-a83t.dtsi does not seem to have, for example, usb material. There are A83T examples: sun8i-a83t-allwinner-h8homlet-v2.dts sun8i-a83t-cubietruck-plus.dts (But, also no usb material.) It looks to me like somewhat more than the ccu driver is needed to in order for the bpi-m3 to meet your criteria for staying in FreeBSD, and possibly even more to support things such as usb. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Oct-24, at 1:50 AM, Emmanuel Vadot = wrote: > Top posting as there is too much stuff in that mail. >=20 > I find it really hard to understand you mail as there is too much data > in it. >=20 > But, to clarify the A83T situation (And general info on Allwinner > clocks) : >=20 > - Old Linux DTS (~4.8 iirc) for Allwinner SoCs had the clock directly > defined in them under a /clock nodes, with jmcneill@ we added support > for most (if not all) of them and this supported every Allwinner SoCs. > - With the H3 DTS added things started to change, they removed > the /clock node and simply add a ccu node (Clock Control Unit) as it's > commonly done in ARM DTS. > - This move a lot of information from the DTS to the kernel driver for > the CCU. > - Around that time the first H3 dts that was written (but not added in > the Linux repository) was from the model, with the /clock node. And we > added those file in FreeBSD under sys/boot/fdt/dts > - I finally wrote a driver for the new clock ccu driver and currently > it support H3, A64 and A31. > - Linux started to convert old SoCs from /clock to ccu (A13 is done, > A83T too and for A10 and A20 it will be available in 4.15 iirc) > - I don't want us (us =3D FreeBSD) to derive from the Linux DTS as = it's > a pain to maintain, every change should be sent to Linux directly = (it's > really not that hard). >=20 > So, that being said, what needs to be done for A83T support to stay in > FreeBSD is adding a ccu driver for it. With the clkng stuff I did (see > sys/arm/allwinner/clkng) it's not that hard, it's just a matter of > reading the user manual clock section and translate table to > macros/struct. You can have a look at H3 (or any other ccu driver) to > see how it's done. > As of today support for A83T and A13 don't work anymore if you use > the current DTS, I've started working on A13 and should commit the > driver soon. Someone with A83T should do the same.=20 >=20 > Cheers, >=20 > On Mon, 23 Oct 2017 20:43:50 -0700 > Mark Millard wrote: >=20 >> [This largely ignores my questions about >> mp_ncpu <=3D cpuid happening when there are >> 4 unused cores (of 8), as there are for >> the BPI-M3's A83T support.] >>=20 >> For head -r324743, by making: >>=20 >> sys/boot/fdt/dts/arm/a83t.dtsi >>=20 >> slightly more modern (reg-names, phy_ctrl, >> pmu0, and pmu1) and putting in my guesses >> for A83T in: >>=20 >> /usr/src/sys/arm/allwinner/aw_usbphy.c >>=20 >> I've gotten -r324743 to boot with a root >> file system on an external USB drive in >> ECHI mode. I've tried both USB ports and >> both have worked as ECHI for this. >>=20 >> The changes: >>=20 >> # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >> Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) >> +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) >> @@ -179,6 +179,9 @@ >> reg =3D <0x01c19400 0x2c>, >> <0x01c1a800 0x4>, >> <0x01c1b800 0x4>; >> + reg-names =3D "phy_ctrl", >> + "pmu0", >> + "pmu1"; >> clocks =3D <&usb_clk 8>, >> <&usb_clk 9>, >> <&usb_clk 10>, >>=20 >> Other than some include file usage, the BPI-M3 is >> not and has not been using sys/gnu/dts/ files. The >> above makes the .dtb that FreeBSD produces be >> something that the modern kernel will not reject >> parts of. >>=20 >> # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c >> Index: /usr/src/sys/arm/allwinner/aw_usbphy.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) >> +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) >> @@ -58,6 +58,7 @@ >> AWUSBPHY_TYPE_A13, >> AWUSBPHY_TYPE_A20, >> AWUSBPHY_TYPE_A31, >> + AWUSBPHY_TYPE_A83T, >> AWUSBPHY_TYPE_H3, >> AWUSBPHY_TYPE_A64 >> }; >> @@ -90,6 +91,13 @@ >> .phy0_route =3D false, >> }; >>=20 >> +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { >> + .num_phys =3D 3, // SATA via USB bridge as well >> + .phy_type =3D AWUSBPHY_TYPE_A83T, >> + .pmu_unk1 =3D false, // ???? >> + .phy0_route =3D true, // ???? >> +}; >> + >> static const struct aw_usbphy_conf a31_usbphy_conf =3D { >> .num_phys =3D 3, >> .phy_type =3D AWUSBPHY_TYPE_A31, >> @@ -116,6 +124,7 @@ >> { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, >> { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, >> { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, >> + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, >> { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, >> { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, >> { NULL, 0 } >>=20 >> The SATA is why there are 3 USB phys for the BPI-M3 >> instead of 2. >>=20 >> The root filesystem is on: >>=20 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number >> da0: 40.000MB/s transfers >> da0: 228936MB (468862128 512 byte sectors) >> da0: quirks=3D0x2 >>=20 >>=20 >> One new thing is: >>=20 >> 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 >>=20 >> I've not figured out what those messages are >> about yet. >>=20 >> There is also: >>=20 >> real memory =3D 2147483648 (2048 MB) >> avail memory =3D 2089332736 (1992 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>=20 >> vs. >>=20 >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpufreq_dt0: on cpu0 >> cpu1: on cpulist0 >> cpu2: on cpulist0 >> cpu3: on cpulist0 >> cpu4: on cpulist0 >> cpufreq_dt1: on cpu4 >> cpufreq_dt1: no regulator for cpu@100 >> device_attach: cpufreq_dt1 attach returned 6 >> cpu5: on cpulist0 >> cpu6: on cpulist0 >> cpu7: on cpulist0 >>=20 >> My understanding is: only the first cluster >> of 4 cores is supposed to be active/used >> and the 2nd cluster is supposed to not >> be in active use. I'm not sure that the >> 2nd cluster is being handled as intended, >> or what the intended details are. But >> top does show only 4. >>=20 >> An old thing is still true: >>=20 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00008018 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> a10_mmc1: error rint: 0x00000100 >> mmcsd1: 8GB = at mmc1 52.0MHz/8bit/65535-block >> mmcsd1boot0: 4MB partion 1 at mmcsd1 >> mmcsd1boot1: 4MB partion 2 at mmcsd1 >> mmcsd1rpmb: 524kB partion 3 at mmcsd1 >>=20 >>=20 >> FYI: >>=20 >> # uname -apKU >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 = 1200051 1200051 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 24 11:12:36 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 0B59EE49685; Tue, 24 Oct 2017 11:12:36 +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 138387F3FF; Tue, 24 Oct 2017 11:12:34 +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 0f421562; Tue, 24 Oct 2017 13:12:31 +0200 (CEST) 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=z3azyNuEt3AnCGShhatUFJriAH8=; b=PcvmG9WTJ7owrOW5lJyIZJ9t95Jt Zaa/8lqL28SjdEq5nIGkVxQxpGGrVGPFLPY2ggMzy91JTlbToay82e6qFNyfQPzG GEQRBxtcaBqT/2ik1gvZdB7uYdVi9RDEk83iZBAELhn96AUGcCJXNChF0HjBh2m/ nkrcNWdby9B6oJE= 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=jO7vfd7cgjtiAVk6RRvoPmQ5D7Q+X4+1XZttPE20Bk+ZznU71m36ldye DhB1S3xPQNloH72Hdp4sObNddDO4vatiWRpPmXpqtipVTh58tiydBK26kiFcSqVB bqyj/NRnILU+Z7MSlP0v6K7vj7F3T2AHGIq6ffkPVs6NV9+aU1g= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id ce7e97ab TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 24 Oct 2017 13:12:31 +0200 (CEST) Date: Tue, 24 Oct 2017 13:12:30 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-hackers , freebsd-arm Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen Message-Id: <20171024131230.f9ec9141d9ec8917229ad54f@bidouilliste.com> In-Reply-To: References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> <20171024105014.cd2012898a602408ee605183@bidouilliste.com> 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 11:12:36 -0000 On Tue, 24 Oct 2017 03:03:25 -0700 Mark Millard wrote: > [Top post.] > > Thanks for the notes. I'm gradually figuring a > little bit out. > > Looking in: > > https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/?dir_pagestart=1000 > > (the linux 4.13 update) I see: > > sun6i-a31s-sinovoip-bpi-m2.dts > > but no .dts directly for the bpi-m3. It will be in 4.14 iirc. > So, it appears that the outer layer (.dts) > does not have a Linux 4.13 or earlier > version to be based on. > > There is an include file: > > sun8i-a83t.dtsi > > Unlike, say, sun6i-a31.dtsi, sun8i-a83t.dtsi > does not seem to have, for example, usb > material. A83T support is pretty recent in mainline Linux. > There are A83T examples: > > sun8i-a83t-allwinner-h8homlet-v2.dts > sun8i-a83t-cubietruck-plus.dts > > (But, also no usb material.) > > It looks to me like somewhat more than > the ccu driver is needed to in order > for the bpi-m3 to meet your criteria > for staying in FreeBSD, and possibly > even more to support things such as > usb. Yes but a working ccu driver is the first logical step. > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Oct-24, at 1:50 AM, Emmanuel Vadot wrote: > > > > Top posting as there is too much stuff in that mail. > > > > I find it really hard to understand you mail as there is too much data > > in it. > > > > But, to clarify the A83T situation (And general info on Allwinner > > clocks) : > > > > - Old Linux DTS (~4.8 iirc) for Allwinner SoCs had the clock directly > > defined in them under a /clock nodes, with jmcneill@ we added support > > for most (if not all) of them and this supported every Allwinner SoCs. > > - With the H3 DTS added things started to change, they removed > > the /clock node and simply add a ccu node (Clock Control Unit) as it's > > commonly done in ARM DTS. > > - This move a lot of information from the DTS to the kernel driver for > > the CCU. > > - Around that time the first H3 dts that was written (but not added in > > the Linux repository) was from the model, with the /clock node. And we > > added those file in FreeBSD under sys/boot/fdt/dts > > - I finally wrote a driver for the new clock ccu driver and currently > > it support H3, A64 and A31. > > - Linux started to convert old SoCs from /clock to ccu (A13 is done, > > A83T too and for A10 and A20 it will be available in 4.15 iirc) > > - I don't want us (us = FreeBSD) to derive from the Linux DTS as it's > > a pain to maintain, every change should be sent to Linux directly (it's > > really not that hard). > > > > So, that being said, what needs to be done for A83T support to stay in > > FreeBSD is adding a ccu driver for it. With the clkng stuff I did (see > > sys/arm/allwinner/clkng) it's not that hard, it's just a matter of > > reading the user manual clock section and translate table to > > macros/struct. You can have a look at H3 (or any other ccu driver) to > > see how it's done. > > As of today support for A83T and A13 don't work anymore if you use > > the current DTS, I've started working on A13 and should commit the > > driver soon. Someone with A83T should do the same. > > > > Cheers, > > > > On Mon, 23 Oct 2017 20:43:50 -0700 > > Mark Millard wrote: > > > >> [This largely ignores my questions about > >> mp_ncpu <= cpuid happening when there are > >> 4 unused cores (of 8), as there are for > >> the BPI-M3's A83T support.] > >> > >> For head -r324743, by making: > >> > >> sys/boot/fdt/dts/arm/a83t.dtsi > >> > >> slightly more modern (reg-names, phy_ctrl, > >> pmu0, and pmu1) and putting in my guesses > >> for A83T in: > >> > >> /usr/src/sys/arm/allwinner/aw_usbphy.c > >> > >> I've gotten -r324743 to boot with a root > >> file system on an external USB drive in > >> ECHI mode. I've tried both USB ports and > >> both have worked as ECHI for this. > >> > >> The changes: > >> > >> # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > >> Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > >> =================================================================== > >> --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) > >> +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) > >> @@ -179,6 +179,9 @@ > >> reg = <0x01c19400 0x2c>, > >> <0x01c1a800 0x4>, > >> <0x01c1b800 0x4>; > >> + reg-names = "phy_ctrl", > >> + "pmu0", > >> + "pmu1"; > >> clocks = <&usb_clk 8>, > >> <&usb_clk 9>, > >> <&usb_clk 10>, > >> > >> Other than some include file usage, the BPI-M3 is > >> not and has not been using sys/gnu/dts/ files. The > >> above makes the .dtb that FreeBSD produces be > >> something that the modern kernel will not reject > >> parts of. > >> > >> # svnlite diff /usr/src*/sys/arm/allwinner/aw_usbphy.c > >> Index: /usr/src/sys/arm/allwinner/aw_usbphy.c > >> =================================================================== > >> --- /usr/src/sys/arm/allwinner/aw_usbphy.c (revision 324743) > >> +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) > >> @@ -58,6 +58,7 @@ > >> AWUSBPHY_TYPE_A13, > >> AWUSBPHY_TYPE_A20, > >> AWUSBPHY_TYPE_A31, > >> + AWUSBPHY_TYPE_A83T, > >> AWUSBPHY_TYPE_H3, > >> AWUSBPHY_TYPE_A64 > >> }; > >> @@ -90,6 +91,13 @@ > >> .phy0_route = false, > >> }; > >> > >> +static const struct aw_usbphy_conf a83t_usbphy_conf = { > >> + .num_phys = 3, // SATA via USB bridge as well > >> + .phy_type = AWUSBPHY_TYPE_A83T, > >> + .pmu_unk1 = false, // ???? > >> + .phy0_route = true, // ???? > >> +}; > >> + > >> static const struct aw_usbphy_conf a31_usbphy_conf = { > >> .num_phys = 3, > >> .phy_type = AWUSBPHY_TYPE_A31, > >> @@ -116,6 +124,7 @@ > >> { "allwinner,sun5i-a13-usb-phy", (uintptr_t)&a13_usbphy_conf }, > >> { "allwinner,sun6i-a31-usb-phy", (uintptr_t)&a31_usbphy_conf }, > >> { "allwinner,sun7i-a20-usb-phy", (uintptr_t)&a20_usbphy_conf }, > >> + { "allwinner,sun8i-a83t-usb-phy", (uintptr_t)&a83t_usbphy_conf }, > >> { "allwinner,sun8i-h3-usb-phy", (uintptr_t)&h3_usbphy_conf }, > >> { "allwinner,sun50i-a64-usb-phy", (uintptr_t)&a64_usbphy_conf }, > >> { NULL, 0 } > >> > >> The SATA is why there are 3 USB phys for the BPI-M3 > >> instead of 2. > >> > >> The root filesystem is on: > >> > >> da0: Fixed Direct Access SPC-4 SCSI device > >> da0: Serial Number > >> da0: 40.000MB/s transfers > >> da0: 228936MB (468862128 512 byte sectors) > >> da0: quirks=0x2 > >> > >> > >> One new thing is: > >> > >> 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 > >> > >> I've not figured out what those messages are > >> about yet. > >> > >> There is also: > >> > >> real memory = 2147483648 (2048 MB) > >> avail memory = 2089332736 (1992 MB) > >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >> > >> vs. > >> > >> cpulist0: on ofwbus0 > >> cpu0: on cpulist0 > >> cpufreq_dt0: on cpu0 > >> cpu1: on cpulist0 > >> cpu2: on cpulist0 > >> cpu3: on cpulist0 > >> cpu4: on cpulist0 > >> cpufreq_dt1: on cpu4 > >> cpufreq_dt1: no regulator for cpu@100 > >> device_attach: cpufreq_dt1 attach returned 6 > >> cpu5: on cpulist0 > >> cpu6: on cpulist0 > >> cpu7: on cpulist0 > >> > >> My understanding is: only the first cluster > >> of 4 cores is supposed to be active/used > >> and the 2nd cluster is supposed to not > >> be in active use. I'm not sure that the > >> 2nd cluster is being handled as intended, > >> or what the intended details are. But > >> top does show only 4. > >> > >> An old thing is still true: > >> > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00008018 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> a10_mmc1: error rint: 0x00000100 > >> mmcsd1: 8GB at mmc1 52.0MHz/8bit/65535-block > >> mmcsd1boot0: 4MB partion 1 at mmcsd1 > >> mmcsd1boot1: 4MB partion 2 at mmcsd1 > >> mmcsd1rpmb: 524kB partion 3 at mmcsd1 > >> > >> > >> FYI: > >> > >> # uname -apKU > >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 1200051 1200051 > >> > >> > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > >> > >> > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 24 11:52:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 259FEE4A592 for ; Tue, 24 Oct 2017 11:52:13 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E37E38074F for ; Tue, 24 Oct 2017 11:52:12 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1e6xkg-0052GM-Be; Tue, 24 Oct 2017 13:52:10 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: Hans Petter Selasky cc: freebsd-arm@freebsd.org Subject: Re: rpi3 - changing MAC address of ue0 between GENERIC and GENERIC-NODEBUG kernels In-reply-to: <057df05d-9f0f-3cfd-516b-deb0444894b5@selasky.org> References: <057df05d-9f0f-3cfd-516b-deb0444894b5@selasky.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 2017 13:52:10 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 11:52:13 -0000 Hello, Hans Petter Selasky wrote: > Hi, > > I believe this topic has been discussed before. Try searching for this > thread "How to change MAC address on RPI-B?" on this list first. > > --HPS after reading the thread I think it does not cover the topic exactly. The creator of that thread liked to change the MAC address form the hardware/firmware given to a different one. Which was fixed during the thread. In this case, the hardware/firmware given MAC changes without user interaction but with a (each?) new kernel. As diffusae wrote during the named thread: > The MAC address isn't stored anywhere. It is generated from a > combination of the MAC range (b8:27:eb) and the last three bytes of > the serial number. The shown serial number of the board does not change. An so the MAC for ue0 should not. Especially it should start with the fixed range. Ralf From owner-freebsd-arm@freebsd.org Tue Oct 24 13:07:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D421E4C72A for ; Tue, 24 Oct 2017 13:07:53 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 14F3C82BA9 for ; Tue, 24 Oct 2017 13:07:53 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id t69so15615965wmt.2 for ; Tue, 24 Oct 2017 06:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=WhkSGmTpN+BqfXmBrWMaSciH2BQtwUEEITuhHqXzXd0=; b=F6T0soH23fbKzQmDxiWV+ezG7Bf0sbyYqyGelSETXi8UwPkbvmymys6jy7RTZkvt1K mVYFCKR5us630ze+nDTM9v4Zf8InAvxlGMCqHOBfLCWp7jBst7i2gnv6zIYFUEOKGxlD Du0mdzN//b7bfa4xRECvKpgufQH7P25cnOQ9i/Ssf4Tb0K5khfJ3EkfD1wodFqnXnzPK RvYCW10Bg5edKs5UCj3ptlBdmYrGsvu8YmfduF3cFfaX/MIqUCIblG4uBmJ5MDgtVGaD PB34YIeD5CFUvY0H6pKv4uteXEujaUEzhN3P3ed4967E806ODSJgbjVcrtbDcDtB+iHe VRFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:cc:to; bh=WhkSGmTpN+BqfXmBrWMaSciH2BQtwUEEITuhHqXzXd0=; b=L3E124k4Bkr/+VYAn3uIHDBzu8CfSMB0lw4Dt4vF2U8VroSJ6+p1nB0GkPLRP2K7DQ 1RlpwFjZWFO3+Y2Us7fjTegrczxjtUEnJwoGQZv3Q/WLlfDdGtNe8ZN357wLcadhwW0l 8lauLrfCYocCvjBJTTOmHQiP0ral6jzzIJyAplih7Usw/BSUAn6kLKNj2IPeN7w539SN Wxekt2GcKx0dEwdtgzsUNCYUjZpewQR50od6vmkpPBimSxn6ZezJqY+3TwYKN/f1TO13 UaY2GJoDqd0/1VtP4pbPbBWxqMyl1ABM4qE+JnVIF85Ts1fh4/tC0DDIR1dQ1hpSBjIY BGmg== X-Gm-Message-State: AMCzsaWHfQEAMXofkdS106BKK1MEgQWi3tRZIbV00gWzMMOypq1t+zw5 O/a33ExpcxGVZqjuvnxFlNkWS2Uf X-Google-Smtp-Source: ABhQp+RwXHBp0n5Y0oa589UO5f2bl4I5ZJSyLopTJJpZgY1fk7aFNuIjJ59NUcAQOIGNjXV5utfFZg== X-Received: by 10.28.54.154 with SMTP id y26mr8947094wmh.15.1508850471368; Tue, 24 Oct 2017 06:07:51 -0700 (PDT) Received: from [192.168.1.79] (lns-bzn-40-82-251-149-119.adsl.proxad.net. [82.251.149.119]) by smtp.gmail.com with ESMTPSA id n138sm332538wmd.3.2017.10.24.06.07.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 06:07:50 -0700 (PDT) From: Sylvain Garrigues Mime-Version: 1.0 (1.0) Date: Tue, 24 Oct 2017 15:07:49 +0200 Subject: Re: rpi3 - changing MAC address of ue0 between GENERIC and GENERIC-NODEBUG kernels Message-Id: Cc: freebsd-arm@freebsd.org To: Ralf Wenk X-Mailer: iPhone Mail (15A432) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:07:53 -0000 Hello, > Le 24 oct. 2017 =C3=A0 09:33, Ralf Wenk a =C3=A9= crit : >=20 > the MAC address of the ue0 interface on my > rpi 3 is changing=20 In the RPI case, the MAC address as seen by FreeBSD is read by the if_smc ke= rnel driver from the mac-address or the local-mac-address property of the bo= ot dtb (see code in sys/dev/usb/net/if_smc.c). Otherwise it is indeed set to= a random value during boot.=20 Obviously the stock DTB (either upstream ones or FreeBSD ones) don=E2=80=99t= know the MAC address, so the actual and real HW MAC address is initialized b= y the rpi firmware in the node pointed to by the =E2=80=9Cethernet=E2=80=9D a= lias in the dtb.=20 There were changes a few months ago both in upstream DTBs and firmware relat= ed about this: see for instance https://github.com/raspberrypi/firmware/issu= es/846 and https://github.com/raspberrypi/firmware/commit/23047785b7414111cb= 7cb80aa9d0042c99fae437 You may want to try to download / compile more recent versions of firmware /= DTB / u-boot than the 2017.01 from ports and check if they solved this issu= e. Sylvain= From owner-freebsd-arm@freebsd.org Tue Oct 24 13:25:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 624C2E4CD40 for ; Tue, 24 Oct 2017 13:25:13 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 29CCB834F6 for ; Tue, 24 Oct 2017 13:25:12 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3yLvC45FfDzsnj Received: from restart.be (norquay.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3yLvC45FfDzsnj for ; Tue, 24 Oct 2017 15:25:04 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v9ODP113003847 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 24 Oct 2017 15:25:03 +0200 (CEST) (envelope-from hlh@restart.be) To: freebsd-arm From: Henri Hennebert Subject: PINE64 - 12.0-CURRENT r324563 - problem with zfs_load="YES" in /boot/loader.conf Message-ID: Date: Tue, 24 Oct 2017 15:25:01 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:25:13 -0000 Hello, When I try to boot 12.0-CURRENT r324563 and put zfs_load="YES" opensolaris_load="YES" in /boot/loader.conf.local so that I can use a root on zfs, the kernel don't boot at all and all freeze after the message: Booting... Using DTB provided by EFI at 0x48000000. If I comment out those 2 lines, I can boot on the mmc card. Then I run `zpool list` to load zfs and opensolaris modules and with the trick: /bin/kenv vfs.root.mountfrom="zfs:rpool/ROOT/default" /sbin/reboot -r I boot with my root on zfs Henri From owner-freebsd-arm@freebsd.org Tue Oct 24 18:34: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 1CEB7E558D5 for ; Tue, 24 Oct 2017 18:34:16 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 A68A76BA00 for ; Tue, 24 Oct 2017 18:34:15 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id 78so15305206wmb.1 for ; Tue, 24 Oct 2017 11:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8rj1DY1am2u9DDS/BmsEiiLepGS0HxwltswYm+amE20=; b=BDnJVqtI7AoANtx0xiNzM5AoKRBuccvGGbXX78YDvBjI5Qz2qJo1jgnIYbp4nLT/h7 OQ9aM9Eq+h9JyYvEnLCjeHVt3mXhHTkbTAwwzVL43VsrrdcEdwCaJhfVz/TuHN4mmlYG t35wQIDvGp3O5zMSkMhaj15VO49yUnXQ24B/gtxKLuMOekfINd+zL6Wj1KirWBiJQLCn OKwVoRQyRe6IlRIGzectV3ZplJsTSBAp8kJoWu0Q3/qYcQDgAPsUOJZFBpdwrFRhZtvg t+MYSC5mSgIPihQ3YRR66lXaIbrJFvgw49d4JRPWCDy6dta1b4mE3sgX8F6ZklhtSUF9 IT5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8rj1DY1am2u9DDS/BmsEiiLepGS0HxwltswYm+amE20=; b=YlGhzq/bbD6IXZ+Pv6peuvMMcVR/PBB9QzNdZOMipPFsYawqqW3bR5jsxEJJVR9clx UF5CU8VM1A8vfBlAq5DFkKORxnj0AtvUprcVNQEAUOw/N2gjNLz0Iz+18qzxswvjt+JT EFWrhxanaksC0agbH60dtyy3adRXO5iz4NBQ8z6zi34+ajviVPwIRGeKnI+4fYXdpdOE xw+dWPWvvQN6Ruz0GJ7z76gFA3+qlYzRyVZBT/s/orMtgNHFIp9zjlAMlMCQC5duBEb+ MTHa0SvKH7c8NGROzlA6Q4XY000b9jLcB4Nr/QXbRfzrQWnuCPMDR3iguIP4tYol5Sgz +ZDQ== X-Gm-Message-State: AMCzsaVcmPHTQBQf3BUBfBjQHCre1MxmRYxVuaGJ5yBJJKmF/esL9m+f KBmGrNm6gWPlf2kJVLciN/P89Pdtg2q+u1eObqtTvUn2 X-Google-Smtp-Source: ABhQp+Sau079F3tqZRGCHig8/ABLH7SBCSdpadjg0CAM4yffeNeW0xRx89xz23D59Y8KhNV/qR0Ct1bAf+lEw87+Yww= X-Received: by 10.28.111.203 with SMTP id c72mr9899374wmi.42.1508870053889; Tue, 24 Oct 2017 11:34:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Tue, 24 Oct 2017 11:34:13 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Tue, 24 Oct 2017 21:34:13 +0300 Message-ID: Subject: Re: Any AVILA / CAMBRIA users? To: Warner Losh Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 18:34:16 -0000 2017-10-23 22:22 GMT+03:00 Warner Losh : > Is anybody still using the IXP425 systems on FreeBSD? Do you expect to run > FreeBSD 12 on them? > > I'm asking because it seems support for them is dangerously decayed and > likely wouldn't work. These are old systems, EOLd back in 2009. There's > issues with the boot loader, and it's unclear if a kernel for these boards > would still work (the boards have only 64MB of RAM, which puts them at the > extreme low end of what can run FreeBSD without expert tuning of the > kernel). A couple of years ago, I know we had one user, but I'm not sure > that he's still using the board. The niche market for these boards was > wifi, but the standard have evolved since then and there's no relevant > hardware available for an upgrade. Isn't the Linksys NSLU2 also using the ixp425? From owner-freebsd-arm@freebsd.org Tue Oct 24 18:42: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 E5842E55B68 for ; Tue, 24 Oct 2017 18:42:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 A6CCA6BDB7 for ; Tue, 24 Oct 2017 18:42:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id l196so11232109itl.4 for ; Tue, 24 Oct 2017 11:42:42 -0700 (PDT) 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=TvfeQGzQkQIu2bh0o51G2BM7TkgTr4wJD/XDNK4ljSE=; b=2GtzOT5s+aSH5h4K5P0yY5TWatJz5jR1isu6xy1iih7HZXaEXQe2zMsFtLpjwxLm/S 1HtQWo440Jj3eBjlyVTYWkCdIxk3q9CWdgWICAYn0YDKXsVo88K64ogGoZdGshMkwEdd FssLcShxCy3TCfVDjqMhYSOMIR3QhOSeLhVOWFYUXbApMPQ+oeAyzJoZY58vQhLnt/Yx OqtoWk4GCW6s7OQOJYQS973Sx0ua/96w9EMBz51vLGB26eVfRBnwO32DvnkHg3VdVj86 1vd/R0gHihlPhoybVUivfEq/uoQ5u3eTo0Pp55SajG0DUUYjMRYy6qA2sUmE8W/jUOD/ jmtA== 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=TvfeQGzQkQIu2bh0o51G2BM7TkgTr4wJD/XDNK4ljSE=; b=A3B7IoUtaLla0+3puRh7vGdWD+Rgdq+mgaGXEAQfzy0GrxAhP7DwLrBBR2MWequsgh B1GOfM7jKgNpP1UyE//aN0dNYPy/2OGKicW6eUZu/nc7dO41iZ5QvuvnPgXyMgA4pQgJ 1Iidnqqt2vjrtIeTXJUSZwqmtBq5iziVk9VCDdLgFzC+jdmJFX7rSy4KC5em6xvXjU8O EaARZDmZ8E0wzxWOhW6QOlT3HpOY+W/QKYTyhuz/yoikO+ffe/EmbxqVIa/Bmqq6BQYB Q0PhOZrMojYP1aH6fwc/ExawRKOJIT7cg4U3LecEFYK7hlAO1d56HaX0pM937ArzuduB mVfA== X-Gm-Message-State: AMCzsaXNU9Qflt1yavqlJSbARkk4w0B7mr/wO6mDbOcdz6obkRo9uuYE 9C+cdx2H4jqUZiCWG1F7AOmkYo9shhzpgLQN/UZg5w== X-Google-Smtp-Source: ABhQp+QpXqz0hsI7eSwYhYrTtXNBPBX3Iw04e7wVd5RruNKXH3wdxu2IwyalZ6NGY10TYKrgq9/QToYJNuC6zi+g5Kg= X-Received: by 10.36.64.145 with SMTP id n139mr15501612ita.115.1508870562020; Tue, 24 Oct 2017 11:42:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Tue, 24 Oct 2017 11:42:41 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:e136:19f5:a7c3:fff2] In-Reply-To: References: From: Warner Losh Date: Tue, 24 Oct 2017 12:42:41 -0600 X-Google-Sender-Auth: gk5yWWbVk68PuODButbLNWLUV_U Message-ID: Subject: Re: Any AVILA / CAMBRIA users? To: =?UTF-8?Q?Eddy_Petri=C8=99or?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 18:42:43 -0000 On Tue, Oct 24, 2017 at 12:34 PM, Eddy Petri=C8=99or wrote: > 2017-10-23 22:22 GMT+03:00 Warner Losh : > > Is anybody still using the IXP425 systems on FreeBSD? Do you expect to > run > > FreeBSD 12 on them? > > > > I'm asking because it seems support for them is dangerously decayed and > > likely wouldn't work. These are old systems, EOLd back in 2009. There's > > issues with the boot loader, and it's unclear if a kernel for these > boards > > would still work (the boards have only 64MB of RAM, which puts them at > the > > extreme low end of what can run FreeBSD without expert tuning of the > > kernel). A couple of years ago, I know we had one user, but I'm not sur= e > > that he's still using the board. The niche market for these boards was > > wifi, but the standard have evolved since then and there's no relevant > > hardware available for an upgrade. > > Isn't the Linksys NSLU2 also using the ixp425? > It is. Are you using one? Warner From owner-freebsd-arm@freebsd.org Tue Oct 24 20:34:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B306EE57E7B for ; Tue, 24 Oct 2017 20:34:38 +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 A121E6FB7D for ; Tue, 24 Oct 2017 20:34:38 +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 v9OKYc2J068219 for ; Tue, 24 Oct 2017 20:34:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223229] arm64 pre-build environment (kernel-toolchain) does not provide stdint.h Date: Tue, 24 Oct 2017 20:34:38 +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 Some People X-Bugzilla-Who: bugs.freebsd.asc@schwarzes.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:34:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223229 Bug ID: 223229 Summary: arm64 pre-build environment (kernel-toolchain) does not provide stdint.h Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bugs.freebsd.asc@schwarzes.net "make buildkernel" fails, because the temporary build environment does not provide a stdint.h. cc -target aarch64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/PINE64-ASC/opt_global.h -I. -I/usr/src/sys -fno-common -fPIC -I/usr/obj/usr/src/sys/PINE64-ASC -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-comp= are -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -std=3Diso9899:1999 -Werror -march=3Darmv8-a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: /usr/lib/clang/5.0.0/include/arm_neon.h:31:10: fatal error: 'stdint.h' file= not found #include ^~~~~~~~~~ 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/sys/modules/armv8crypto *** Error code 1 Stop. make[3]: stopped in /usr/src/sys/modules *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/PINE64-ASC *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src root@pinelot:/usr/src # ls -l /usr/obj/usr/src/tmp/usr/lib/clang/5.0.0/include/stdint.h ls: /usr/obj/usr/src/tmp/usr/lib/clang/5.0.0/include/stdint.h: No such file= or directory root@pinelot:/usr/src # uname -a FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r324720:= Thu Oct 19 09:37:31 UTC 2017=20=20=20=20 root@pinelot.schwarzes.net:/usr/obj/usr/src/sys/PINE64-ASC arm64 root@pinelot:/usr/src # svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 324948 Node Kind: directory Schedule: normal Last Changed Author: ae Last Changed Rev: 324947 Last Changed Date: 2017-10-24 10:39:05 +0200 (Tue, 24 Oct 2017) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Oct 24 21:31:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24DDAE2F236 for ; Tue, 24 Oct 2017 21:31:39 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (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 4CD7E71B7F; Tue, 24 Oct 2017 21:31:37 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=D/PK7hO7ZuIFONIqwxzQDI4Se2advmCG0GbmOGwU91Q=; b=AMhtSPZDi96KT+V6oJGPtJ/UMP iLVuTQiQS3RBonjfXuJyiWvunujpYURGII3M+0u0n4SLyJzcf75uI/3+Q42bxd8/DQPCp8R6WY7pT ctyalCI0zF8504vs+AA3M/PekCE0LcKPg7HW9tvONz7Z+jhBjBSzXcZS1ca12rZ8DkMCW1EppV8tL 9qS6DlFqJgc/58ihlItBRT+pHuuN6TAJHbuhOLZEjPoikQpWZ4bH3U4kUroyZmja7Ylwciyc0WxFn cFmAFdlUCPvH5PkZ1fpM9ZahNkoCSN8iDOt78l4UmdHMgcU48lrgbfaL51hibJQhHCiercOSkyO2D TZreys8w==; Received: from [136.62.171.86] (port=63679 helo=[192.168.1.159]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1e76nH-0003rV-IF; Tue, 24 Oct 2017 17:31:27 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Bug 223229] arm64 pre-build environment (kernel-toolchain) does not provide stdint.h From: Jon Brawn In-Reply-To: Date: Tue, 24 Oct 2017 16:31:26 -0500 Cc: freebsd-arm@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: bugzilla-noreply@freebsd.org X-Mailer: Apple Mail (2.3273) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:31:39 -0000 > On Oct 24, 2017, at 3:34 PM, bugzilla-noreply@freebsd.org wrote: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223229 >=20 > Bug ID: 223229 > Summary: arm64 pre-build environment (kernel-toolchain) does > not provide stdint.h > Product: Base System > Version: CURRENT > Hardware: arm64 > OS: Any > Status: New > Severity: Affects Some People > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: bugs.freebsd.asc@schwarzes.net >=20 > "make buildkernel" fails, because the temporary build environment does = not > provide a stdint.h. Do a =E2=80=98buildworld=E2=80=99 first. I fell over this a few days = ago. >=20 > cc -target aarch64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing = -Werror > -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/PINE64-ASC/opt_global.h -I. -I/usr/src/sys = -fno-common > -fPIC -I/usr/obj/usr/src/sys/PINE64-ASC -ffixed-x18 -ffreestanding = -fwrapv > -fstack-protector -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ = -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality > -Wno-error-unused-function -Wno-error-pointer-sign > -Wno-error-shift-negative-value -Wno-error-address-of-packed-member > -std=3Diso9899:1999 -Werror -march=3Darmv8-a+crypto > /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c > In file included from = /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > /usr/lib/clang/5.0.0/include/arm_neon.h:31:10: fatal error: 'stdint.h' = file not > found > #include > ^~~~~~~~~~ > 1 error generated. > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/src/sys/modules/armv8crypto > *** Error code 1 >=20 > Stop. > make[3]: stopped in /usr/src/sys/modules > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/obj/usr/src/sys/PINE64-ASC > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src >=20 >=20 > root@pinelot:/usr/src # ls -l > /usr/obj/usr/src/tmp/usr/lib/clang/5.0.0/include/stdint.h > ls: /usr/obj/usr/src/tmp/usr/lib/clang/5.0.0/include/stdint.h: No such = file or > directory >=20 >=20 > root@pinelot:/usr/src # uname -a > FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #2 = r324720: Thu > Oct 19 09:37:31 UTC 2017 =20 > root@pinelot.schwarzes.net:/usr/obj/usr/src/sys/PINE64-ASC arm64 >=20 > root@pinelot:/usr/src # svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 324948 > Node Kind: directory > Schedule: normal > Last Changed Author: ae > Last Changed Rev: 324947 > Last Changed Date: 2017-10-24 10:39:05 +0200 (Tue, 24 Oct 2017) >=20 > --=20 > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > 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" >=20 From owner-freebsd-arm@freebsd.org Tue Oct 24 21:44: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 9C2CDE2F90D for ; Tue, 24 Oct 2017 21:44:21 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34FB47248D for ; Tue, 24 Oct 2017 21:44:21 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id z55so16007654wrz.1 for ; Tue, 24 Oct 2017 14:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJq3sEj++Tqv8b1IFNq8FDR0fZzFGwYN0z+pdtgiNdY=; b=Ma/N17lDF/Ph7u2jG0V/Anr88064sN6eG3V6a/n6qiSfJdYz5R2pcZ7I2bdOe76WKt AmZU9Uhxs7HGV9qC4wCSPidnHnKvMyiFd1wUeIv7Ur0YI5riG0ptzfKa9OQKBHAf3kMU 3UZ6VNcWbnOA24z9xxr0iQCIDsEnAmOgULpYWDDftF5DpKKdyz5GPoWQ8j2Tf39LyF99 U4l8GFCl+MLaFU7IcNxVnOLkdAxR31GfxPkOHXNSRSh2RKbGi4x+H12pI5LL/Tb4XkLF +QEltPFHID7fc7hRlXd2G/P65jnFqNMI0u/WZM9Mms+HCML/xZqOYHdJ5ntEwYMuPCdu QY8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dJq3sEj++Tqv8b1IFNq8FDR0fZzFGwYN0z+pdtgiNdY=; b=DxExSmHk/X0piHsC3EzxrpqH1NYAR6smlmEUTVAuvkHVX++wsUPJ+2qvdD0eWkui3W N5YPjSyJlRILMttxyBqNwD+38m0vrEEzMIm6JfIhCVys33f2qBfkyJMV7FCzj1XA5PUr xDlzOk0Lq5yFM6yJmwPe4oafo1nv7MlC3b0v84S5klu4Q8Kh9T09giZ3WjRqEz9eIbww f1t9D4b+SW+ZbyZpXYq2ZiEkOLWtpcO3M3FnDC82xSS5zzVXkzAqIRQQGdxAQx8FxXpQ n55UAC68R496srQU586JPQVeANHZtgRcueXIqYBHDHrWE994v149USysYFJth37FgtRe SAkA== X-Gm-Message-State: AMCzsaUj4jy82CeqD4Kgc1p/8vLvh1cD7qBXNUQz4f/O/vukIv88QqWR yFLQWM5bDHpCevxeMqnAeyf4/Kf1zGM2jkQNPJPHIw== X-Google-Smtp-Source: ABhQp+RQnfVWcrxlKE59VPnUH2Zb7AoOl3mflB/JNQnQxDipJYiKAK6aEZfl5CoWwDyypsFzW8+i55De3RPtEF+2u2I= X-Received: by 10.223.165.7 with SMTP id i7mr36304wrb.155.1508881458608; Tue, 24 Oct 2017 14:44:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Tue, 24 Oct 2017 14:44:17 -0700 (PDT) Received: by 10.223.173.129 with HTTP; Tue, 24 Oct 2017 14:44:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Wed, 25 Oct 2017 00:44:17 +0300 Message-ID: Subject: Re: Any AVILA / CAMBRIA users? To: Warner Losh Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:44:21 -0000 Eddy Petri=C8=99or Pe 24 oct. 2017 9:42 PM, "Warner Losh" a scris: On Tue, Oct 24, 2017 at 12:34 PM, Eddy Petri=C8=99or wrote: > 2017-10-23 22:22 GMT+03:00 Warner Losh : > > Is anybody still using the IXP425 systems on FreeBSD? Do you expect to > run > > FreeBSD 12 on them? > > > > I'm asking because it seems support for them is dangerously decayed and > > likely wouldn't work. These are old systems, EOLd back in 2009. There's > > issues with the boot loader, and it's unclear if a kernel for these > boards > > would still work (the boards have only 64MB of RAM, which puts them at > the > > extreme low end of what can run FreeBSD without expert tuning of the > > kernel). A couple of years ago, I know we had one user, but I'm not sur= e > > that he's still using the board. The niche market for these boards was > > wifi, but the standard have evolved since then and there's no relevant > > hardware available for an upgrade. > > Isn't the Linksys NSLU2 also using the ixp425? > It is. Are you using one? No, I am not. Although I own 2 of them, I failed to find useful usages for them since they are extremely low powered. On the other hand, removing ixp425 support would kill nslu2 support, right? Btw, NetBSD should have support for nslu2, but needs manual interaction for booting, even for net booting. I tried this some time ago. Does FreeBSD have the same problem, or is FreeBSD small enough to fit in the internal flash instead of the stock linux kernel partition? From owner-freebsd-arm@freebsd.org Tue Oct 24 22:17: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 3282DE30496 for ; Tue, 24 Oct 2017 22:17:59 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B09B7733DB for ; Tue, 24 Oct 2017 22:17:58 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1e76sq-0000Lt-1R; Tue, 24 Oct 2017 14:37:12 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v9OLbAkm001356; Tue, 24 Oct 2017 14:37:10 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 24 Oct 2017 14:37:10 -0700 From: Oleksandr Tymoshenko To: Jon Brawn Cc: freebsd-arm@FreeBSD.org Subject: Re: [Bug 223229] arm64 pre-build environment (kernel-toolchain) does not provide stdint.h Message-ID: <20171024213710.GA1318@bluezbox.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Jon Brawn (jon@brawn.org) wrote: > > > On Oct 24, 2017, at 3:34 PM, bugzilla-noreply@freebsd.org wrote: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223229 > > > > Bug ID: 223229 > > Summary: arm64 pre-build environment (kernel-toolchain) does > > not provide stdint.h > > Product: Base System > > Version: CURRENT > > Hardware: arm64 > > OS: Any > > Status: New > > Severity: Affects Some People > > Priority: --- > > Component: arm > > Assignee: freebsd-arm@FreeBSD.org > > Reporter: bugs.freebsd.asc@schwarzes.net > > > > "make buildkernel" fails, because the temporary build environment does not > > provide a stdint.h. > > Do a ‘buildworld’ first. I fell over this a few days ago. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 22:17:59 -0000 Jon Brawn (jon@brawn.org) wrote: > > > On Oct 24, 2017, at 3:34 PM, bugzilla-noreply@freebsd.org wrote: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223229 > > > > Bug ID: 223229 > > Summary: arm64 pre-build environment (kernel-toolchain) does > > not provide stdint.h > > Product: Base System > > Version: CURRENT > > Hardware: arm64 > > OS: Any > > Status: New > > Severity: Affects Some People > > Priority: --- > > Component: arm > > Assignee: freebsd-arm@FreeBSD.org > > Reporter: bugs.freebsd.asc@schwarzes.net > > > > "make buildkernel" fails, because the temporary build environment does not > > provide a stdint.h. > > Do a ‘buildworld’ first. I fell over this a few days ago. Hi Jon, Unlike GNATS system bugzilla does not receive responses via email. If you'd like to leave comment to bug author, please register/login to Bugzilla interface https://bugs.freebsd.org/bugzilla/ and post it there. -- gonzo From owner-freebsd-arm@freebsd.org Wed Oct 25 05:35:28 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 B2507E3F138 for ; Wed, 25 Oct 2017 05:35:28 +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 A03BD81D59 for ; Wed, 25 Oct 2017 05:35:28 +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 v9P5ZS0m005783 for ; Wed, 25 Oct 2017 05:35:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223229] arm64 pre-build environment (kernel-toolchain) does not provide stdint.h Date: Wed, 25 Oct 2017 05:35:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed 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 Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 05:35:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223229 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |DUPLICATE --- Comment #2 from Mark Linimon --- *** This bug has been marked as a duplicate of bug 220125 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Oct 25 21:03:56 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 EB547E543F0 for ; Wed, 25 Oct 2017 21:03:56 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5E8382253 for ; Wed, 25 Oct 2017 21:03:56 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1e7Sq4-00158a-Hs; Wed, 25 Oct 2017 22:03:48 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: Sylvain Garrigues cc: freebsd-arm@freebsd.org Subject: Re: rpi3 - changing MAC address of ue0 between GENERIC and GENERIC-NODEBUG kernels In-reply-to: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Oct 2017 23:03:48 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 21:03:57 -0000 Hello, Sylvain Garrigues wrote: > Hello, >=20 > > Le 24 oct. 2017 =E0 09:33, Ralf Wenk a = =E9crit : > >=20 > > the MAC address of the ue0 interface on my > > rpi 3 is changing=20 >=20 > In the RPI case, the MAC address as seen by FreeBSD is read by the > if_smc kernel driver from the mac-address or the local-mac-address > property of the boot dtb (see code in sys/dev/usb/net/if_smc.c). > Otherwise it is indeed set to a random value during boot.=20 >=20 > Obviously the stock DTB (either upstream ones or FreeBSD ones) don’t > know the MAC address, so the actual and real HW MAC address is > initialized by the rpi firmware in the node pointed to by the > “ethernet†alias in the dtb.=20 oh. I had the expectation =22when it works as expected for an RPI B and a B+ it will/should also work for an RPI 3=22. > There were changes a few months ago both in upstream DTBs and firmware > related about this: see for instance > https://github.com/raspberrypi/firmware/issues/846 and > https://github.com/raspberrypi/firmware/commit/23047785b7414111cb7cb80a= a9d0042c99fae437 >=20 > You may want to try to download / compile more recent versions of > firmware / DTB / u-boot than the 2017.01 from ports and check if > they solved this issue. >=20 > Sylvain OK, so I will try the current raspbian first to get the hopefully constant MAC address for my board from there. After that I will try the newer versions step by step. Thank you. Ralf From owner-freebsd-arm@freebsd.org Thu Oct 26 00:23:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BA58E57541 for ; Thu, 26 Oct 2017 00:23:15 +0000 (UTC) (envelope-from bounces+6307625-b7a4-freebsd-arm=freebsd.org@sendgrid.net) Received: from o16824577x209.outbound-mail.sendgrid.net (o16824577x209.outbound-mail.sendgrid.net [168.245.77.209]) (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 B7E133076 for ; Thu, 26 Oct 2017 00:23:14 +0000 (UTC) (envelope-from bounces+6307625-b7a4-freebsd-arm=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.net; h=content-type:from:mime-version:reply-to:subject:to; s=smtpapi; bh=NUvs0MNh/LhhzKmzGml+w5rfqZU=; b=PCjJku5uvR5rlt68r20iupr+QS6qI Hn1ZKa/8ZlyAmvmTkcty9nfT9sFrzN6B6eMDeiKWVVgJSiEBEtl3MiN1Nd2xpmFX tX5cN8Y5FJwASOZodyWV05ZyDQtc2SLM3FLdp0cahXNdIDXJBJJ7OEm8FuMHNZ9A lfKdea+IcwAg1k= Date: Thu, 26 Oct 2017 00:23:13 +0000 (UTC) From: "Renew" Mime-Version: 1.0 Reply-to: netflix@billingporblem.com Subject: Sorry to say goodbye To: freebsd-arm@freebsd.org Message-ID: X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ/rV5oGMz4+ZVTdCT99I5wXuuR8WUWrykgPn3oFaheLLz703iMLTczqmZw XiPNMn8JWiuZ5x/6uGxMrRQCrqfCDa2wiM3O6EYOJb6iR69dY29/Y34Acwcmf2oFulAXt+8GsTY0LG kx9Xp/Oh+afFzX4oeX8zHlgJBP5xTB+aUirXdziy8tBSvT6UkqTgjtejzf07nLFIo4fKlHVYWr1W/t c= X-SG-ID: Z2FxZazunBjVeNuNdzHDqrF8mxuCpi0krmont6YQrP0uomiF4eFFUxMqaLyJIp6zOqoqfNtumn//fD 5OXzZGTpJuSfAkoYpdKF9Qq8enfZJI8eJjdZ8IDAO+kMe2VcCvxeQUlK9jDgWqiL0egXJzyMaLWYxZ MF6Ag58Nem01JOw= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 00:23:15 -0000 =E2=80=8B =E2=80=8B We're having some trouble with your current billing information. We'll try again, but in the meantime you may want to update your payment de= tails. Renew Now http://northgujaratmarket.com/job/upload/Netflix-zebi/Netflix-zeb= i/nf/ Failure to complete the validation process will result in a suspension of y= our netflix membership. We take every step needed to automatically validate our users, unfortunately in this case we were unable to verify your details. The process will only take a couple of minutes and will allow us to maintain our high standard of account security. Netflix Support Team This message was mailed automatically by Netflix during routine security ch= ecks. We are not completely satisfied with your account information and required you to update your account to continue using our services unit= errupted. =E2=80=8B http://sigre.com/unscribe.php =E2=80=8B= From owner-freebsd-arm@freebsd.org Thu Oct 26 06:09: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 49E7DE3EED6 for ; Thu, 26 Oct 2017 06:09:09 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh505-vm1.bullet.mail.kks.yahoo.co.jp (nh505-vm1.bullet.mail.kks.yahoo.co.jp [183.79.57.103]) by mx1.freebsd.org (Postfix) with SMTP id BDEC16DAFD for ; Thu, 26 Oct 2017 06:09:08 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.140] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 26 Oct 2017 06:07:24 -0000 Received: from [183.79.100.137] by t503.bullet.mail.kks.yahoo.co.jp with NNFMP; 26 Oct 2017 06:07:24 -0000 Received: from [127.0.0.1] by omp506.mail.kks.yahoo.co.jp with NNFMP; 26 Oct 2017 06:07:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 657951.51376.bm@omp506.mail.kks.yahoo.co.jp Received: (qmail 30159 invoked by uid 60001); 26 Oct 2017 06:07:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1508998044; bh=pfnSctNUwkyb/LGYw1l24PT9oAhG5TO01Z0dSDiM8yE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aMUsn8koG+8Lc0iWXNgu0KnqvErc7lQaonIdgnVVTCDmqY3lqbW4vybombL7Gxd22arIvdjRMKz5k0KZNPo+ohvN+9Rn68211e1v9KkbcybNldMcDLpk05xoYDdSJ1I5b4zluLp8sXPuBJOJWofyPPoeD8nUmAuMRQayERFPp5k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=To7r7PZ4XvMYbShY3tIqDp+YC0wFinlOQoPwbl+R4ocbwizbP7maKhU6MMlNzxfVyZmxdwELzPYiWaw0Hmz38chk2Q+o80SLUoUpNCcuZzKC+VU0AcrDfjRuUOqOjmFnafpDTydyoz9zkvRpCctgicqOnfMg7SRELvnfFBvjVsw=; Message-ID: <439621.15010.qm@web101705.mail.ssk.yahoo.co.jp> X-YMail-OSG: IcKXaI8VM1lRFn7EW3he7ihj_Vb1vFjmWr3WktZzM59AJ_5tQ02UQ_Q._KXKMnC.VkCgSiNEfCwcXVTX.cwzKUbaKzUcBdMV7Juaa5pfqflRVyXOHlLp2sai3EeebKuarXaGrEspCXU4Hm2RhO9F.IXyUrK.5PJ7r1lP7uwiMBtxBEDaBuikRFckH1gOBnVw1esrZTzW4fwiqlsguO8Idai9gDPoLDvI3llwGNjOqUI31ijFxCUMvwiPjQyHzNcaiUoY0fI8i8ZDZ_VouNgdYIG7u5ep_chDxVt_85wtv3IiXp9tMoQcK02nXw4lY_2DCzwKaTLS9GBpev8g0O2omTraSRaZsEXhPLVYHcgM0NGNqlxNCRsUlM5RbsG2wo6lgxh7JOeeVsj5L25Lk6J7k_aPL4yMuduhRdN1yCN.T7KbDsW_GDAt0pNKXUeOhcbIwVJklbLd8NZl_PR8lzYSFsulClEmNU0OLpiqL0dlxDvfKWf103ZZqa8WLJ7w72UJu0dzvKy.rIJzUJ7XTko.RvTv4Y0JZQZqCwUaIaLLtE1c427WCr5MfXUnUfl0ebi2xBt7mAXAuBl89DZLjDPyGV3JyIWNd7DpZcBrKTQ8dFs- Received: from [61.23.25.155] by web101705.mail.ssk.yahoo.co.jp via HTTP; Thu, 26 Oct 2017 15:07:24 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: x5D_dAkVM1lBWQE39kqWXFySpBdHUegs2XEDj0nMDlZxd4dTPxUNkfpCkWT_slCAn_j8kOWKHA.9d.bORsuDo56nzdezSqSOPnCyAt4ohYNuq2SzQlEBia2pTbIhm0sk.XsJ Date: Thu, 26 Oct 2017 15:07:24 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: build error armv5t by gcc To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 06:09:09 -0000 Hi=0A=0AI still have hang up problem on armv5t. I back to gcc because of cl= ang build is take a long time.=0A=0AI have build error to armv5t(RT1310) by= gcc.=0A=0AHow to fix this ?=A0=0A=0Acc -isystem /storage/home/hiroki/zorg/= obj//storage/home/hiroki/zorg/ZRouter/tmp/=0A/arm.arm/storage/home/hiroki/f= reebsd/tmp/usr/include -L/storage/home/hiroki/zorg=0A/obj//storage/home/hir= oki/zorg/ZRouter/tmp//arm.arm/storage/home/hiroki/freebsd/=0Atmp/usr/lib -B= /storage/home/hiroki/zorg/obj//storage/home/hiroki/zorg/ZRouter/tm=0Ap//arm= .arm/storage/home/hiroki/freebsd/tmp/usr/lib --sysroot=3D/storage/home/hiro= k=0Ai/zorg/obj//storage/home/hiroki/zorg/ZRouter/tmp//arm.arm/storage/home/= hiroki/fr=0Aeebsd/tmp -B/storage/home/hiroki/zorg/obj//storage/home/hiroki/= zorg/ZRouter/tmp/=0A/arm.arm/storage/home/hiroki/freebsd/tmp/usr/bin=A0 -O = -pipe =A0 -fpic -fvisibility=3D=0Ahidden -DVISIBILITY_HIDDEN -I/storage/hom= e/hiroki/freebsd/contrib/libcxxrt -DEMI=0AT_SYNC_ATOMICS -g -MD=A0 -MF.depe= nd.gcc_personality_v0.o -MTgcc_personality_v0.o -=0Astd=3Dgnu99 -Wsystem-he= aders -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer=0A-sign =A0 =A0= -c /storage/home/hiroki/freebsd/contrib/compiler-rt/lib/builtins/gcc_p=0Ae= rsonality_v0.c -o gcc_personality_v0.o=0AIn file included from /storage/hom= e/hiroki/freebsd/contrib/compiler-rt/lib/built=0Ains/gcc_personality_v0.c:2= 4:=0A/storage/home/hiroki/freebsd/contrib/compiler-rt/lib/builtins/unwind-e= habi-helpe=0Ars.h:42: error: redefinition of typedef '_Unwind_State'=0A/sto= rage/home/hiroki/freebsd/contrib/libcxxrt/unwind-arm.h:41: error: previous = d=0Aeclaration of '_Unwind_State' was here=0A=0ATemporary I comment up this= error. Then build complete.=A0=0A=0AHiroki Mori From owner-freebsd-arm@freebsd.org Thu Oct 26 07:29: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 2DFF5E4065E for ; Thu, 26 Oct 2017 07:29:12 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 2F8E96F86C for ; Thu, 26 Oct 2017 07:29:11 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id g11so1533578vkd.13 for ; Thu, 26 Oct 2017 00:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=w4x/mCiWTO3TG67QIhKHI0glxlsweM7yOILlfvdRUjg=; b=HifkHrw9suJj92TmN0E++oFY4Z55qPsVsRbmFszaWpNYlF0kpvRdNyvGbujiKsUYkA S1Mr53aa7AjT1meGECJnmpHMqlkFv7svQxzvyFkvEkZYk8fX7ZXa+/qjoR7phRf7s41D n4uWYO7+a/DP1d4SGalbB0JAFevNDP2SYL2OEfJy0IyFZcaUr/LBoYt0kcMe2HaCMpAp sKmQ1yNDIXXrfxQNY6fqyVgJxQbcLw6tYhGhAFXxl9ZoJCpEJFg0Hxpe2l+Vi5uhW7ol GsfKxHfzw1nCrLnoJg4+lIfJt31rrKAwJJD7XmNqsM+C3qzMcTqKFHKEyakbfQRjNN0Z y+Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=w4x/mCiWTO3TG67QIhKHI0glxlsweM7yOILlfvdRUjg=; b=IopUlup7R9DU1+4ZV1bPsgtCi5K+eMRcjkn3NI3QPrjpa3La8OAV7col7t4FC3+HMz j1aZ1LKXSzZKIlTk9DCMb/Sm200y3jM4463PDPoMp1w2FW4t4dzn9hgc9jEiIEVDOXPd Y+bJ1Qlxsz5w3i9HudcDR05I0aWKj6BWvviYMvmHisPHELeET1BGW1GQL01dwUh4GCEH Dur9C+kT4br6AMLKRk7aAfNtSZFGWHlyH+7X2Bj7nDGkBXHv6sECzx6O9JX+X5ZipdHb CbftOkQDlQEJAmnJV+F6Nioz+3Uuqof34W4mbipfwUPRJAN3AgvBciBgcl5n4vjTiFh5 mEDw== X-Gm-Message-State: AMCzsaXDlKWotkpjwu692knshKnRjoy3POQ7dvOT6IS+b3T0Jge2Ddhp dGVsnlNZsu/4h/VvM4PExIfixHi4FK2VFWuKzhV7AQ== X-Google-Smtp-Source: ABhQp+TYuAICQy5xl+gWpGh4HkZQxiYI8ltPbMlWqFk1Q6tyjZwrPPo/KY1p26OjgEXX/1N6YXDswrcFPAkMCqv6PrE= X-Received: by 10.31.58.2 with SMTP id h2mr3150348vka.194.1509002949864; Thu, 26 Oct 2017 00:29:09 -0700 (PDT) MIME-Version: 1.0 References: <439621.15010.qm@web101705.mail.ssk.yahoo.co.jp> In-Reply-To: <439621.15010.qm@web101705.mail.ssk.yahoo.co.jp> From: Tom Vijlbrief Date: Thu, 26 Oct 2017 07:28:59 +0000 Message-ID: Subject: Pending Pine64 ethernet fix To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:29:12 -0000 Can someone with commit bits please have a look at this 3 month old bugreport and apply or reject the proposed patch? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 From owner-freebsd-arm@freebsd.org Thu Oct 26 07:40:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5962FE40A96 for ; Thu, 26 Oct 2017 07:40:27 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 204976FD79 for ; Thu, 26 Oct 2017 07:40:26 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3yMzSL6RJ5zskY Received: from restart.be (norquay.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3yMzSL6RJ5zskY for ; Thu, 26 Oct 2017 09:40:18 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v9Q7eHVX007757 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 26 Oct 2017 09:40:18 +0200 (CEST) (envelope-from hlh@restart.be) To: freebsd-arm From: Henri Hennebert Subject: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time Message-ID: Date: Thu, 26 Oct 2017 09:40:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:40:27 -0000 Hello, After a upgrade from r320599 to r324563, ntpd can't keep time for long. After one hour, the clock run too fast. [root@norquay ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +ssh2.ulyssis.st 193.79.237.14 2 u 43 256 377 13.135 -178952 178956. +fetchmail.media 193.171.23.163 2 u 256 256 377 40.510 -0.081 243875. *2001:67c:360:1: 85.114.26.194 2 u 234 256 377 74.274 2.201 253082. [root@norquay ~]# date Thu Oct 26 09:38:53 CEST 2017 [root@norquay ~]# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 193.190.253.212 193.79.237.14 2 u 76 256 377 13.135 -178952 178956. 91.206.8.70 193.171.23.163 2 u 29 256 377 40.703 -178956 178956. 2001:67c:360:1: 85.114.26.194 2 u 2 256 377 74.274 2.201 286968. [root@norquay ~]# service ntpd stop Stopping ntpd. Waiting for PIDS: 7002. [root@norquay ~]# ntpdate 193.190.253.212 26 Oct 09:33:41 ntpdate[7737]: step time server 193.190.253.212 offset -357.908698 sec [root@norquay ~]# service ntpd start Starting ntpd. [root@norquay ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +213.189.188.3.i 193.190.230.65 2 u 67 64 37 13.565 -0.043 1.154 +time.srv.ualber 172.30.248.10 2 u 64 64 37 134.653 -0.426 0.722 *manager-vlan87. 195.111.98.17 2 u 6 64 77 38.907 0.547 0.634 Henri From owner-freebsd-arm@freebsd.org Thu Oct 26 08:44:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52F33E42625 for ; Thu, 26 Oct 2017 08:44:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-123.reflexion.net [208.70.210.123]) (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 100ED71A8A for ; Thu, 26 Oct 2017 08:44:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14991 invoked from network); 26 Oct 2017 04:44:12 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Oct 2017 04:44:12 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 26 Oct 2017 00:44:12 -0400 (EDT) Received: (qmail 4836 invoked from network); 26 Oct 2017 04:44:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Oct 2017 04:44:12 -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 6A30AEC7848; Wed, 25 Oct 2017 21:44:11 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen [Lucky it worked? sc->pmu[off] usage?] Date: Wed, 25 Oct 2017 21:44:10 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 08:44:14 -0000 [It looks like I got the naming wrong for pmu0 and pmu1 vs. pmu1 and pmu2, despite things appearing to operate?] On 2017-Oct-23, at 8:43 PM, Mark Millard wrote: > . . . > The changes: >=20 > # svnlite diff /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (revision 324743) > +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) > @@ -179,6 +179,9 @@ > reg =3D <0x01c19400 0x2c>, > <0x01c1a800 0x4>, > <0x01c1b800 0x4>; > + reg-names =3D "phy_ctrl", > + "pmu0", > + "pmu1"; > clocks =3D <&usb_clk 8>, > <&usb_clk 9>, > <&usb_clk 10>, I found linux 4.14 drafts of: /arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts and the files that are included from there, indirections included. The: /arch/arm/boot/dts/sun8i-a83t.dtsi that has the analogous content has: usbphy: phy@1c19400 { compatible =3D "allwinner,sun8i-a83t-usb-phy"; reg =3D <0x01c19400 0x10>, <0x01c1a800 0x14>, <0x01c1b800 0x14>; reg-names =3D "phy_ctrl", "pmu1", "pmu2"; In the FreeBSD head code: /usr/src/sys/arm/allwinner/aw_usbphy.c the pmu naming differences would change which sc->pmu[off] examples end up with bus_alloc_resource_any return values assigned: /* Get regulators */ for (off =3D 0; off < sc->phy_conf->num_phys; off++) { snprintf(pname, sizeof(pname), "usb%d_vbus-supply", = off); if (regulator_get_by_ofw_property(dev, 0, pname, ®) = =3D=3D 0) sc->reg[off] =3D reg; =20 snprintf(pname, sizeof(pname), "pmu%d", off); if (ofw_bus_find_string_index(node, "reg-names", pname, &rid) !=3D 0) continue; =20 sc->pmu[off] =3D bus_alloc_resource_any(dev, = SYS_RES_MEMORY, &rid, RF_ACTIVE); if (sc->pmu[off] =3D=3D NULL) { device_printf(dev, "Cannot allocate = resource\n"); return (ENXIO); } } With what I had it was off=3D=3D0 and off=3D=3D1 but with what the linux 4.14 draft material has it would be off=3D=3D1 and off=3D2 . Either way, exactly 2 of the 3 phys have sc->pmu[off] assigned by the above code, it just varies which ones. It may have been very lucky for me that things seemed to be working. Of the two *.dsti files and the sys/arm/allwinner/aw_usbphy.c file I have no clue what should be different. I'd expect to guess my a83t.dtsi edit --but then why do things seem to be working? Side note: There is also the difference above: reg =3D <0x01c19400 0x2c>, <0x01c1a800 0x4>, <0x01c1b800 0x4>; vs. reg =3D <0x01c19400 0x10>, <0x01c1a800 0x14>, <0x01c1b800 0x14>; whatever that means. > . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Oct 26 10:53:22 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 29AC0E45A94 for ; Thu, 26 Oct 2017 10:53:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-120.reflexion.net [208.70.210.120]) (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 CCFE875793 for ; Thu, 26 Oct 2017 10:53:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27809 invoked from network); 26 Oct 2017 08:06:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Oct 2017 08:06:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 26 Oct 2017 04:06:40 -0400 (EDT) Received: (qmail 32183 invoked from network); 26 Oct 2017 08:06:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Oct 2017 08:06:40 -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 A4574EC7A6E; Thu, 26 Oct 2017 01:06:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: Date: Thu, 26 Oct 2017 01:06:38 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> References: To: Henri Hennebert X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 10:53:22 -0000 On 2017-Oct-26, at 12:40 AM, Henri Hennebert wrote: > After a upgrade from r320599 to r324563, ntpd can't keep time for = long. > After one hour, the clock run too fast. I'm running: # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm64 = aarch64 1200051 1200051 Top shows: /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift It has been up for 3 days and date shows what I'd expect (local time). Also: # ntpq -p=20 remote refid st t when poll reach delay offset = jitter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 +96.226.123.195 128.138.141.172 2 u 486 512 377 53.512 -0.639 = 0.795 +clock.xmission. 128.138.141.172 2 u 75 512 377 43.109 -0.005 = 1.301 *chl.la 127.67.113.92 2 u 272 512 177 29.258 0.091 = 1.667 +mirror1.sjc02.s 162.213.2.253 2 u 44 512 377 28.404 -0.632 = 2.297 -mdnworldwide.co 216.218.254.202 2 u 95 1024 377 68.184 -3.070 = 1.488 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Oct 26 14:57: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 B9A37E4B7C1 for ; Thu, 26 Oct 2017 14:57:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D99980E7C for ; Thu, 26 Oct 2017 14:57:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 167f99d8-ba5e-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 167f99d8-ba5e-11e7-a938-4f970e858fdb; Thu, 26 Oct 2017 14:58:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9QEvp4t001201; Thu, 26 Oct 2017 08:57:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509029871.56824.49.camel@freebsd.org> Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Ian Lepore To: Mark Millard , Henri Hennebert Cc: freebsd-arm Date: Thu, 26 Oct 2017 08:57:51 -0600 In-Reply-To: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:57:59 -0000 On Thu, 2017-10-26 at 01:06 -0700, Mark Millard wrote: > On 2017-Oct-26, at 12:40 AM, Henri Hennebert wrote: > > > > > After a upgrade from r320599 to r324563, ntpd can't keep time for long. > > After one hour, the clock run too fast. > I'm running: > > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT  r324743M  arm64 aarch64 1200051 1200051 > > Top shows: > > /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift > > It has been up for 3 days and date shows > what I'd expect (local time). Also: > > # ntpq -p  >      remote           refid      st t when poll reach   delay   offset  jitter > ============================================================================== >  0.freebsd.pool. .POOL.          16 p    -   64    0    0.000    0.000   0.000 > +96.226.123.195  128.138.141.172  2 u  486  512  377   53.512   -0.639   0.795 > +clock.xmission. 128.138.141.172  2 u   75  512  377   43.109   -0.005   1.301 > *chl.la          127.67.113.92    2 u  272  512  177   29.258    0.091   1.667 > +mirror1.sjc02.s 162.213.2.253    2 u   44  512  377   28.404   -0.632   2.297 > -mdnworldwide.co 216.218.254.202  2 u   95 1024  377   68.184   -3.070   1.488 > > What is in your /var/db/ntpd.drift file on that system? -- Ian From owner-freebsd-arm@freebsd.org Thu Oct 26 17:55:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE95CE4FA9A for ; Thu, 26 Oct 2017 17:55:45 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B3BD03A45; Thu, 26 Oct 2017 17:55:45 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=ian@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3yNF6R2QgCzrnR Received: from restart.be (norquay.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3yNF6R2QgCzrnR; Thu, 26 Oct 2017 19:55:42 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v9QHtfbl028699 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 26 Oct 2017 19:55:42 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: Ian Lepore , Mark Millard Cc: freebsd-arm References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> From: Henri Hennebert Message-ID: <617f14dc-33ca-9afe-7b9c-328fcb46bca2@restart.be> Date: Thu, 26 Oct 2017 19:55:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509029871.56824.49.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:55:46 -0000 On 10/26/2017 16:57, Ian Lepore wrote: > On Thu, 2017-10-26 at 01:06 -0700, Mark Millard wrote: >> On 2017-Oct-26, at 12:40 AM, Henri Hennebert wrote: >> >>> >>> After a upgrade from r320599 to r324563, ntpd can't keep time for long. >>> After one hour, the clock run too fast. >> I'm running: >> >> # uname -apKU >> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT  r324743M  arm64 aarch64 1200051 1200051 >> >> Top shows: >> >> /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift >> >> It has been up for 3 days and date shows >> what I'd expect (local time). Also: >> >> # ntpq -p >>      remote           refid      st t when poll reach   delay   offset  jitter >> ============================================================================== >>  0.freebsd.pool. .POOL.          16 p    -   64    0    0.000    0.000   0.000 >> +96.226.123.195  128.138.141.172  2 u  486  512  377   53.512   -0.639   0.795 >> +clock.xmission. 128.138.141.172  2 u   75  512  377   43.109   -0.005   1.301 >> *chl.la          127.67.113.92    2 u  272  512  177   29.258    0.091   1.667 >> +mirror1.sjc02.s 162.213.2.253    2 u   44  512  377   28.404   -0.632   2.297 >> -mdnworldwide.co 216.218.254.202  2 u   95 1024  377   68.184   -3.070   1.488 >> >> > > What is in your /var/db/ntpd.drift file on that system? > [root@norquay ~]# cat /var/db/ntp.drift 29.760 To create it, after this problem I stop ntpd, remove /var/db/ntp.drift and restart ntpd. Henri From owner-freebsd-arm@freebsd.org Thu Oct 26 21:54: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 8B98EE53E48 for ; Thu, 26 Oct 2017 21:54:21 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 547CC6B0F8 for ; Thu, 26 Oct 2017 21:54:20 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1e7q6O-003EMk-40; Thu, 26 Oct 2017 22:54:12 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: Sylvain Garrigues cc: freebsd-arm@freebsd.org Subject: Re: rpi3 - changing MAC address of ue0 between GENERIC and GENERIC-NODEBUG kernels In-reply-to: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Oct 2017 23:54:11 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 21:54:21 -0000 Hello, I wrote: > Sylvain Garrigues wrote: > =5B...=5D > >=20 > > You may want to try to download / compile more recent versions of > > firmware / DTB / u-boot than the 2017.01 from ports and check if > > they solved this issue. > >=20 > > Sylvain >=20 > OK, so I will try the current raspbian first to get the hopefully > constant MAC address for my board from there. After that I will try > the newer versions step by step. After replacing bootcode.bin, fixup*.dat and start*.elf with the raspbian versions from 2017-08-11, three FreeBSD kernel from mid October to Monday used the same MAC address as raspbian. Starting with the expected b8:27:eb. I did not touch u-boot.bin. A FreeBSD kernel from July showed a totally different MAC address. Thanks again. Ralf From owner-freebsd-arm@freebsd.org Thu Oct 26 22:51: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 03443E54BF3 for ; Thu, 26 Oct 2017 22:51:37 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter06.peak.org (filter06.peak.org [69.59.194.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD7E86CAFB for ; Thu, 26 Oct 2017 22:51:36 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter06.peak.org ({0c47b2c3-829a-4f18-b445-de68be8d048d}) via TCP (outbound) with ESMTPS id 20171026225134032_0000 for ; Thu, 26 Oct 2017 15:51:34 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id 93D414C6C8 for ; Thu, 26 Oct 2017 15:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 793544C6AF for ; Thu, 26 Oct 2017 15:51:28 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AlqpWJ-Wie24 for ; Thu, 26 Oct 2017 15:51:28 -0700 (PDT) Received: from mailproxy-lb-05.peak.org (mailproxy-lb-05.peak.org [207.55.17.95]) by zmail-mta02.peak.org (Postfix) with ESMTP id 4181B4C6C8 for ; Thu, 26 Oct 2017 15:51:28 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1e7qzm-000FXN-RA for freebsd-arm@freebsd.org; Thu, 26 Oct 2017 15:51:26 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Make packages for armv7 makes armv6 packages X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 26 Oct 2017 15:51:26 -0700 Message-ID: <86lgjxo74h.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 22:51:37 -0000 I have a 12.0-CURRENT RPI2 system that I have been updating with packages that I build on my amd64 desktop system. I just tried building armv7 packages to see if the system could be upgraded that way. I did a buildworld and buildkernel for armv7 and everything worked properly. I then did a make packages for armv7 and it referenced the files created by the armv7 build, but then built armv6 packages. The 'pkg info -F' data showed armv6 architecture, and they were placed in the FreeBSD:12.0:armv6 repo directory. I don't think I did anything wrong, and the commands I used were: make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 buildworld buildkernel make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 packages I checked the typescript file and the only reference to armv6 was the line where it reports it is creating the the repository in .../FreeBSD:12:armv6/... at the end. Does anybody have any suggestions on what I am missing, or are the packages not implemented yet for armv7? I have upgraded it several times before this conversion to armv7, so I think my procedure is basically correct. The svn revision I used for this was r325018, which was the latest at this time. Thanks for any ideas on this. -- Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Thu Oct 26 22:55:56 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 CEA99E54E82 for ; Thu, 26 Oct 2017 22:55:56 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CEC16D1B9 for ; Thu, 26 Oct 2017 22:55:55 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ce4e9d7f-baa0-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id ce4e9d7f-baa0-11e7-a893-25625093991c; Thu, 26 Oct 2017 22:55:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9QMth0l002785; Thu, 26 Oct 2017 16:55:43 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509058543.56824.61.camel@freebsd.org> Subject: Re: Make packages for armv7 makes armv6 packages From: Ian Lepore To: Carl Johnson , freebsd-arm@freebsd.org Date: Thu, 26 Oct 2017 16:55:43 -0600 In-Reply-To: <86lgjxo74h.fsf@elm.localnet> References: <86lgjxo74h.fsf@elm.localnet> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 22:55:56 -0000 On Thu, 2017-10-26 at 15:51 -0700, Carl Johnson wrote: > I have a 12.0-CURRENT RPI2 system that I have been updating with > packages that I build on my amd64 desktop system.  I just tried building > armv7 packages to see if the system could be upgraded that way.  I did a > buildworld and buildkernel for armv7 and everything worked properly.  I > then did a make packages for armv7 and it referenced the files created > by the armv7 build, but then built armv6 packages.  The 'pkg info -F' > data showed armv6 architecture, and they were placed in the > FreeBSD:12.0:armv6 repo directory.   I don't think I did anything wrong, > and the commands I used were: > >   make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 buildworld buildkernel >   make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 packages >    > I checked the typescript file and the only reference to armv6 was the > line where it reports it is creating the the repository in > .../FreeBSD:12:armv6/... at the end. > > Does anybody have any suggestions on what I am missing, or are the > packages not implemented yet for armv7?  I have upgraded it several > times before this conversion to armv7, so I think my procedure is > basically correct.  The svn revision I used for this was r325018, which > was the latest at this time. > > Thanks for any ideas on this. I think the problem is that pkg itself hasn't been updated to know about armv7.  If you apply this patch to ports-mgmt/pkg https://bz-attachments.freebsd.org/attachment.cgi?id=187008 then I think it should create armv7 packages for you. -- Ian From owner-freebsd-arm@freebsd.org Fri Oct 27 03:42:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69879E5AAB9 for ; Fri, 27 Oct 2017 03:42:07 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter06.peak.org (filter06.peak.org [69.59.194.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 447B3750C7 for ; Fri, 27 Oct 2017 03:42:06 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter06.peak.org ({0c47b2c3-829a-4f18-b445-de68be8d048d}) via TCP (outbound) with ESMTPS id 20171027034204167_0000 for ; Thu, 26 Oct 2017 20:42:04 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id A6E584CA57 for ; Thu, 26 Oct 2017 20:41:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 8E16C4CA88 for ; Thu, 26 Oct 2017 20:41:58 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aF9tCSM6qMPX for ; Thu, 26 Oct 2017 20:41:58 -0700 (PDT) Received: from mailproxy-lb-05.peak.org (mailproxy-lb-05.peak.org [207.55.17.95]) by zmail-mta02.peak.org (Postfix) with ESMTP id 58D034CA57 for ; Thu, 26 Oct 2017 20:41:58 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1e7vWv-000Fk2-04 for freebsd-arm@freebsd.org; Thu, 26 Oct 2017 20:41:57 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Re: Make packages for armv7 makes armv6 packages References: <86lgjxo74h.fsf@elm.localnet> <1509058543.56824.61.camel@freebsd.org> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 26 Oct 2017 20:41:56 -0700 In-Reply-To: <1509058543.56824.61.camel@freebsd.org> (Ian Lepore's message of "Thu, 26 Oct 2017 16:55:43 -0600") Message-ID: <86h8ulntob.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 03:42:07 -0000 Ian Lepore writes: > On Thu, 2017-10-26 at 15:51 -0700, Carl Johnson wrote: >> I have a 12.0-CURRENT RPI2 system that I have been updating with >> packages that I build on my amd64 desktop system.=C2=A0=C2=A0I just trie= d building >> armv7 packages to see if the system could be upgraded that way.=C2=A0=C2= =A0I did a >> buildworld and buildkernel for armv7 and everything worked properly.=C2= =A0=C2=A0I >> then did a make packages for armv7 and it referenced the files created >> by the armv7 build, but then built armv6 packages.=C2=A0=C2=A0The 'pkg i= nfo -F' >> data showed armv6 architecture, and they were placed in the >> FreeBSD:12.0:armv6 repo directory.=C2=A0=C2=A0=C2=A0I don't think I did = anything wrong, >> and the commands I used were: >>=20 >> =C2=A0 make -j4 KERNCONF=3DRPI2 TARGET=3Darm TARGET_ARCH=3Darmv7 buildwo= rld buildkernel >> =C2=A0 make -j4 KERNCONF=3DRPI2 TARGET=3Darm TARGET_ARCH=3Darmv7 packages >> =C2=A0=C2=A0 >> I checked the typescript file and the only reference to armv6 was the >> line where it reports it is creating the the repository in >> .../FreeBSD:12:armv6/... at the end. >>=20 >> Does anybody have any suggestions on what I am missing, or are the >> packages not implemented yet for armv7?=C2=A0=C2=A0I have upgraded it se= veral >> times before this conversion to armv7, so I think my procedure is >> basically correct.=C2=A0=C2=A0The svn revision I used for this was r3250= 18, which >> was the latest at this time. >>=20 >> Thanks for any ideas on this. > > I think the problem is that pkg itself hasn't been updated to know > about armv7. =C2=A0If you apply this patch to ports-mgmt/pkg > > https://bz-attachments.freebsd.org/attachment.cgi?id=3D187008 > > then I think it should create armv7 packages for you. Thanks, but what is supposed to handle that file? I see two patches in there, but I don't know what the other lines are supposed to do. --=20 Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Fri Oct 27 06:23: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 C84CCE5D215; Fri, 27 Oct 2017 06:23:31 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 606C57D5A4; Fri, 27 Oct 2017 06:23:31 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id r79so5159864wrb.13; Thu, 26 Oct 2017 23:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=rKwo2TBsUoMdMiyC6Q1LiaE5m1I+8pszWjLAGLtc1SA=; b=Ln1obPrHc6LLvwzvRtg/DekDXNkGGM88qoW9MRniMq+ywzGYYaemt7i/Eo31rJ4Uyx O4ihRwAM6rm/v97BLo5uHUPuoXQSP2jlkrxvQmJ7+7j8N8FB3z6+s70lpkz5cK/l0SUm fQo6OZuYGWjUAjE30dBnuR4XuQV/wnrbHde9tISuGdrxbJkbR/S7qUgslDtCofJ1l/Ds SWSLbRkxunWrH9LPUzc3XMmbkHcblZxyP/K6TK+ePoCTGVZRPp9tlC1e+MpdTkUIPmwc y5D0YLXKZpz+vSc0Ff0QyrtZyC2/n+9cVad95OeZW7OPgPxUy7dpk3M81n7pHnGZTroc N66A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=rKwo2TBsUoMdMiyC6Q1LiaE5m1I+8pszWjLAGLtc1SA=; b=HO/z40kVxcwST2eFpFr8rMqZVVTurrmlBJyse/WF9GByjgEIWwDlne8DODtH7yaxL7 9/ltwQRVI3ecu91J23gNcX5NlXi86z+43u4BYhpQHcxBUxHIGINgGr0Gs3UH7OQiWs6S IDco+DGexBIGB3iEzG0rNbZY1+21eEaeuCnjlvxSmkYszo2e2uPlyaz1+LkRctvHQRtT eRLWoR8L+w1IdYsx3G31J1INpitIym2dpheKA3va22x3QiBJUBP3ozH0G17LULyVZ9zi Nt3YUB+3fNfE57sU+yG+jPPP1lFAsRZKcn7BdLV4bkC+q9lhgOGa02P1i0kENih5foSS Fpkw== X-Gm-Message-State: AMCzsaUx1uZCePkgU3Qc9DVG29I7TeJRFJPRJQyNeMJSZsOAQ92cMaOu Lol6Sx1oqN3gC9lniiXu1MQRaf5z1fXo5hGKHW+AFnuw X-Google-Smtp-Source: ABhQp+Q6uSVJ13d+EXAP/N1INvDB5eFiB32AgiDtCrwuwAMpi45MTki97aW0FMANEf2B6OZm9h+XSVD54OsJEgOzZiE= X-Received: by 10.223.176.14 with SMTP id f14mr7030451wra.129.1509085409639; Thu, 26 Oct 2017 23:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Thu, 26 Oct 2017 23:23:29 -0700 (PDT) From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Fri, 27 Oct 2017 09:23:29 +0300 Message-ID: Subject: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? To: freebsd-toolchain@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 06:23:31 -0000 Hello, I am trying to make the FreeBSD code base build from a Linux host and found this bit which defines BUILD_TRIPLE in a way which to my untrained eyes look like overengineering. .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} =3D= =3D "") TARGET_ABI=3D -gnueabihf .elif ${TARGET_ARCH:Marm*} TARGET_ABI=3D -gnueabi .else TARGET_ABI=3D .endif VENDOR=3D unknown OS_VERSION=3D freebsd12.0 TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TA= RGET_ABI} BUILD_TRIPLE?=3D ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} To support a Linux host I made these changes that is using 'cc -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if it shouldn't be OK for building on a FreeBSD host .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} =3D= =3D "") TARGET_ABI=3D -gnueabihf .elif ${TARGET_ARCH:Marm*} TARGET_ABI=3D -gnueabi .else TARGET_ABI=3D .endif VENDOR=3D unknown OS_VERSION=3D freebsd12.0 +BUILD_OS!=3D uname -s + TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TA= RGET_ABI} +.if ${BUILD_OS} =3D=3D FreeBSD BUILD_TRIPLE?=3D ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} +.else +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} +.endif What do you think, should the code be instead: .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} =3D= =3D "") TARGET_ABI=3D -gnueabihf .elif ${TARGET_ARCH:Marm*} TARGET_ABI=3D -gnueabi .else TARGET_ABI=3D .endif VENDOR=3D unknown OS_VERSION=3D freebsd12.0 TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TA= RGET_ABI} +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} --=20 Eddy Petri=C8=99or From owner-freebsd-arm@freebsd.org Fri Oct 27 10:40:34 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 6C89CE3FC4B for ; Fri, 27 Oct 2017 10:40:34 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward102j.mail.yandex.net (forward102j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 108718432D for ; Fri, 27 Oct 2017 10:40:33 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback2j.mail.yandex.net (mxback2j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10b]) by forward102j.mail.yandex.net (Yandex) with ESMTP id 513FF5607F5E for ; Fri, 27 Oct 2017 13:40:19 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback2j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id CoTURXnKVW-eJpqo6T1; Fri, 27 Oct 2017 13:40:19 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1509100819; bh=5i+puGBNFkAbJkIg+8Z34fn0iKLZ5raLSR+MQIY/ZJQ=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=A5UcAstxtyGBzTkjhfQ5I4x0w+oJohtqYJoFeET3ZIqnfr7xG4l4FO93y+1azo9rh PjDYziUzXCMVD2CUzvg6HRquSm8YUtM48ovfRmmOYJObQpek8nYb1vHdVnjMaPsIBe a0MQFj2oLXAA4XJXXUNtLsiFdub6YtCEWjVnOqPw= Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id BUTBsYlsFy-eIwqln9P; Fri, 27 Oct 2017 13:40:18 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1509100818; bh=5i+puGBNFkAbJkIg+8Z34fn0iKLZ5raLSR+MQIY/ZJQ=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=Ccn+H+VXhfxY8F1VTp5f5GwIcafl46fV+81NXhpa7v0jWrgM/PmNyGH7K/nuz4UFX pSMp4dsJh40/4cpuHXNbbdV9jEw6msvX5gFUy1G6YyW2+ihoezLdK74OgWRcfc6mSg ADz8NPI5IegEsvFRCT/YJUrerHOBrET3X8ye76gA= Authentication-Results: smtp3p.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: Make packages for armv7 makes armv6 packages To: freebsd-arm@freebsd.org References: <86lgjxo74h.fsf@elm.localnet> <1509058543.56824.61.camel@freebsd.org> <86h8ulntob.fsf@elm.localnet> From: Boris Samorodov Message-ID: <308eeb60-6cbe-5dbd-f287-fb70b621999a@passap.ru> Date: Fri, 27 Oct 2017 13:40:18 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <86h8ulntob.fsf@elm.localnet> Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 10:40:34 -0000 27.10.2017 06:41, Carl Johnson пишет: > Ian Lepore writes: > >> On Thu, 2017-10-26 at 15:51 -0700, Carl Johnson wrote: >>> I have a 12.0-CURRENT RPI2 system that I have been updating with >>> packages that I build on my amd64 desktop system.  I just tried building >>> armv7 packages to see if the system could be upgraded that way.  I did a >>> buildworld and buildkernel for armv7 and everything worked properly.  I >>> then did a make packages for armv7 and it referenced the files created >>> by the armv7 build, but then built armv6 packages.  The 'pkg info -F' >>> data showed armv6 architecture, and they were placed in the >>> FreeBSD:12.0:armv6 repo directory.   I don't think I did anything wrong, >>> and the commands I used were: >>> >>>   make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 buildworld buildkernel >>>   make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 packages >>>    >>> I checked the typescript file and the only reference to armv6 was the >>> line where it reports it is creating the the repository in >>> .../FreeBSD:12:armv6/... at the end. >>> >>> Does anybody have any suggestions on what I am missing, or are the >>> packages not implemented yet for armv7?  I have upgraded it several >>> times before this conversion to armv7, so I think my procedure is >>> basically correct.  The svn revision I used for this was r325018, which >>> was the latest at this time. >>> >>> Thanks for any ideas on this. >> >> I think the problem is that pkg itself hasn't been updated to know >> about armv7.  If you apply this patch to ports-mgmt/pkg >> >> https://bz-attachments.freebsd.org/attachment.cgi?id=187008 >> >> then I think it should create armv7 packages for you. > > Thanks, but what is supposed to handle that file? I see two patches in > there, but I don't know what the other lines are supposed to do. % cd /usr/ports/ports-mgmt/pkg % patch -p0 < _this_patch_file_ Then build and install pkg. HTH -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@freebsd.org Fri Oct 27 13:46:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11F4FE45782 for ; Fri, 27 Oct 2017 13:46:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-123.reflexion.net [208.70.210.123]) (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 CBE4965DAA for ; Fri, 27 Oct 2017 13:46:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18444 invoked from network); 27 Oct 2017 08:19:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Oct 2017 08:19:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 27 Oct 2017 04:19:36 -0400 (EDT) Received: (qmail 14140 invoked from network); 27 Oct 2017 08:19:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Oct 2017 08:19:35 -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 2FD1AEC7C1F; Fri, 27 Oct 2017 01:19:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Fri, 27 Oct 2017 01:19:34 -0700 Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> References: To: =?utf-8?Q?Eddy_Petri=C8=99or?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:46:24 -0000 On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or = wrote: > I am trying to make the FreeBSD code base build from a Linux host and > found this bit which defines BUILD_TRIPLE in a way which to my > untrained eyes look like overengineering. >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 I'm using a context where armv[67]* would now likely be in use above, in fact the context is from an armv7 build, no longer armv6 . > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > BUILD_TRIPLE?=3D > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >=20 >=20 > To support a Linux host I made these changes that is using 'cc > -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if > it shouldn't be OK for building on a FreeBSD host Using an arm FreeBSD head -r324743 context as an example. . . For reference: # grep BUILD_ARCH Makefile* Makefile.inc1:BUILD_ARCH!=3D uname -p Makefile.inc1:.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} # uname -ap FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 # uname -m arm # uname -p armv7 (A little endian, hard float context by default.) Compare that to some Linux distributions: (extractions from an old exchange) On a Digi CCWiMX53 som (someone else sent this) (buildroot busybox): # uname -m armv7l # uname -p unknown I booted Ubuntu Mate on a BPI-M3 and tried: $ uname -p armv7l $ uname -ap Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux (Unfortunately I did not record -m for that back then but it matched -p results --from memory.) I tried another linux on the BPI-M3: gentoo . # uname -p ARMv7 Processor rev 5 (v7l) # uname -pa Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 = UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux # uname -m armv7l [After looking into the details my preliminary guess seemed to be correct: the only dependable uname output among -m -p -i was for -m for linux. The uname.c code used varies from distribution to distribution and that changed the other options' results.] Back to the armv7 FreeBSD head -r324743 context. . . # cc -dumpmachine armv7-unknown-freebsd12.0-gnueabihf Compare that to the results of: ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} Note that on FreeBSD itself on that machine BUILD_ARCH would historically not have the "-gnueabihf" suffix for such a host. Would the build tolerate it? # cc --version 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: /usr/bin Note the "armv7" for what Linux might instead have something like "armv7l" for a little endian, hard-float context. Would this matter? Would the build tolerate a armv7l (or other such) in BUILD_ARCH? > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 > +BUILD_OS!=3D uname -s > + >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > +.if ${BUILD_OS} =3D=3D FreeBSD > BUILD_TRIPLE?=3D > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} > +.else > +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine > +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} > +.endif Keeping the historical BUILD_ARCH content for FreeBSD hosts might be important. But for non-FreeBSD hosts, such as a Linux distribution, might other mismatches with FreeBSD conventions matter? (See earlier above.) Also: What of using alternative compilers (${CC} vs. cc in classic notations, may be ${HOST_CC} or some such here because multiple compilers can be involved)? Would "cc" always exist and be appropriate? In fact on FreeBSD it is possible to buildworld buildkernel using a non-system compiler, such as via the devel/powerpc64-gcc port, even on a powerpc64 system. (This allows a modern build instead of what gcc 4.2.1 is limited to since lang does not sufficiently yet.) For that context: # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine powerpc64-unknown-freebsd12.0 # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for = powerpc64) 6.3.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. > What do you think, should the code be instead: >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine > +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} I'd expect that the historical BUILD_ARCH content for a FreeBSD host should be kept instead of ending up with things like "-gnueabihf" tacked on sometimes. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Oct 27 15:28:36 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 5D023E48887 for ; Fri, 27 Oct 2017 15:28:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40E576A6C9 for ; Fri, 27 Oct 2017 15:28:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 38ae404a-bb2b-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 38ae404a-bb2b-11e7-b50b-53dc5ecda239; Fri, 27 Oct 2017 15:26:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9RFRS4G004410; Fri, 27 Oct 2017 09:27:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509118047.56824.69.camel@freebsd.org> Subject: Re: Make packages for armv7 makes armv6 packages From: Ian Lepore To: Carl Johnson , freebsd-arm@freebsd.org Date: Fri, 27 Oct 2017 09:27:27 -0600 In-Reply-To: <86h8ulntob.fsf@elm.localnet> References: <86lgjxo74h.fsf@elm.localnet> <1509058543.56824.61.camel@freebsd.org> <86h8ulntob.fsf@elm.localnet> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 15:28:36 -0000 On Thu, 2017-10-26 at 20:41 -0700, Carl Johnson wrote: > Ian Lepore writes: > > > > > On Thu, 2017-10-26 at 15:51 -0700, Carl Johnson wrote: > > > > > > I have a 12.0-CURRENT RPI2 system that I have been updating with > > > packages that I build on my amd64 desktop system.  I just tried building > > > armv7 packages to see if the system could be upgraded that way.  I did a > > > buildworld and buildkernel for armv7 and everything worked properly.  I > > > then did a make packages for armv7 and it referenced the files created > > > by the armv7 build, but then built armv6 packages.  The 'pkg info -F' > > > data showed armv6 architecture, and they were placed in the > > > FreeBSD:12.0:armv6 repo directory.   I don't think I did anything wrong, > > > and the commands I used were: > > > > > >   make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 buildworld buildkernel > > >   make -j4 KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 packages > > >    > > > I checked the typescript file and the only reference to armv6 was the > > > line where it reports it is creating the the repository in > > > .../FreeBSD:12:armv6/... at the end. > > > > > > Does anybody have any suggestions on what I am missing, or are the > > > packages not implemented yet for armv7?  I have upgraded it several > > > times before this conversion to armv7, so I think my procedure is > > > basically correct.  The svn revision I used for this was r325018, which > > > was the latest at this time. > > > > > > Thanks for any ideas on this. > > I think the problem is that pkg itself hasn't been updated to know > > about armv7.  If you apply this patch to ports-mgmt/pkg > > > > https://bz-attachments.freebsd.org/attachment.cgi?id=187008 > > > > then I think it should create armv7 packages for you. > Thanks, but what is supposed to handle that file?  I see two patches in > there, but I don't know what the other lines are supposed to do. > The extra stuff is subversion properties that are only important if the changes are committed.  The standard patch(1) will ignore that extra stuff, so you can just apply the patches as Boris showed in his reply. -- Ian From owner-freebsd-arm@freebsd.org Fri Oct 27 15:56:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 343FEE4AA76 for ; Fri, 27 Oct 2017 15:56:51 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter06.peak.org (filter06.peak.org [69.59.194.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1C66D99E for ; Fri, 27 Oct 2017 15:56:50 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter06.peak.org ({0c47b2c3-829a-4f18-b445-de68be8d048d}) via TCP (outbound) with ESMTPS id 20171027155647717_0000 for ; Fri, 27 Oct 2017 08:56:47 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id A07744CCDA for ; Fri, 27 Oct 2017 08:56:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 80C984C4CC for ; Fri, 27 Oct 2017 08:56:42 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BDZIvFR3Dv21 for ; Fri, 27 Oct 2017 08:56:42 -0700 (PDT) Received: from mailproxy-lb-05.peak.org (mailproxy-lb-05.peak.org [207.55.17.95]) by zmail-mta02.peak.org (Postfix) with ESMTP id 4C84A4CDA6 for ; Fri, 27 Oct 2017 08:56:42 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1e86zx-0002Ba-4a for freebsd-arm@freebsd.org; Fri, 27 Oct 2017 08:56:41 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Re: Make packages for armv7 makes armv6 packages References: <86lgjxo74h.fsf@elm.localnet> <1509058543.56824.61.camel@freebsd.org> <86h8ulntob.fsf@elm.localnet> <1509118047.56824.69.camel@freebsd.org> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 27 Oct 2017 08:56:41 -0700 In-Reply-To: <1509118047.56824.69.camel@freebsd.org> (Ian Lepore's message of "Fri, 27 Oct 2017 09:27:27 -0600") Message-ID: <868tfwoa86.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 15:56:51 -0000 Ian Lepore writes: > On Thu, 2017-10-26 at 20:41 -0700, Carl Johnson wrote: >> Ian Lepore writes: >> > I think the problem is that pkg itself hasn't been updated to know >> > about armv7. =C2=A0If you apply this patch to ports-mgmt/pkg >> >=20 >> > https://bz-attachments.freebsd.org/attachment.cgi?id=3D187008 >> >=20 >> > then I think it should create armv7 packages for you. >> Thanks, but what is supposed to handle that file?=C2=A0=C2=A0I see two p= atches in >> there, but I don't know what the other lines are supposed to do. >>=20 > > The extra stuff is subversion properties that are only important if the > changes are committed. =C2=A0The standard patch(1) will ignore that extra > stuff, so you can just apply the patches as Boris showed in his reply. Thanks, I didn't realize how much patch would ignore. I will try that today, and then see if I can upgrade to armv7 that way. --=20 Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Fri Oct 27 22:10: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 BFA62E51E4B; Fri, 27 Oct 2017 22:10:44 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53BE47D04B; Fri, 27 Oct 2017 22:10:44 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id 15so7379298wrb.5; Fri, 27 Oct 2017 15:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lrTBgziPwdngYtbvIzI07s3ktWFij2n5T8R8Mr4+zmU=; b=YGuFZtKT+EkgGdtfi+rHCptyjSudhqX7ZEw8M0/hILII7aBgEXp9Gtd4bKo9Emd74z Osk3FHb+ON8YJd75pYlAcFbG67Evm3n6HUEyywRsqrssxvzsp7TBlNb58UifdrrWqnaR pCwHFwMLWVt+LDH+wjx5o7+To81O+QosRZPyey+uI8wtELBhkzZsrGWt2d6rlSwigd5A pEm4adPKVT9Mh8dqhRgj5T/5tT8Al22fhH+FKmxJQwj6r3TY1O99Eil8JxuD4+sTT8MY 43+Wgay565fZMcq8RXpl9cE9zFr9UPn7TJAQgR6ljuciHJVveHoX1ThMdc6JCwga85MB iBFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lrTBgziPwdngYtbvIzI07s3ktWFij2n5T8R8Mr4+zmU=; b=sYnjB8pRqMvbeEK9mskBBwIm+QWXVi6fib5muk8PdyaM1G1OCgCIxDl82D0haST+EW kMvHvWmR5pORNa1w+3D6HMSWvQLM7qtLhBVM/kpH0zJrnqIEuuIOG/NdOf408EddlKmd fGm78BfFUWcRFH2P/5srutgH983dAs6zMyU9EbAGSay8uZUD+YegtHwyIDAsEffBESrp JgBolGhUjCC7wPDmMCqty5vKsbIpmVNhG5uYfvBPaM/NsWz2juzvLBjkd6veLM0RFOY4 YhjjY5hc7qgvBJG4SY/z79I9LqquRHyh+wLTVNZVXeQFszz7PLH5HJ3lDO8/kCtfTBFv 0GNw== X-Gm-Message-State: AMCzsaWcXcyoevFj34GtNUJ/viyvbqcYrpBQYFOOkvjbZLTzqdIV0Q7a ZPwnVn/R2QbCZQEC87RwOHxn9pB4japou6ryo6lhKXr/ X-Google-Smtp-Source: ABhQp+SbuOaxbaQh8/HbWkgGB2DYKrJcrqZj7Xcnw+kM7mgn9tOTi/sC9dGiJjjq1rX5A7e0c6i0Q4nh8Erns4Kds5s= X-Received: by 10.223.198.6 with SMTP id n6mr1391754wrg.200.1509142242794; Fri, 27 Oct 2017 15:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Fri, 27 Oct 2017 15:10:41 -0700 (PDT) In-Reply-To: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> References: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Sat, 28 Oct 2017 01:10:41 +0300 Message-ID: Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 22:10:44 -0000 2017-10-27 11:19 GMT+03:00 Mark Millard : > On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or = wrote: > >> I am trying to make the FreeBSD code base build from a Linux host and >> found this bit which defines BUILD_TRIPLE in a way which to my >> untrained eyes look like overengineering. >> >> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") >> TARGET_ABI=3D -gnueabihf >> .elif ${TARGET_ARCH:Marm*} >> TARGET_ABI=3D -gnueabi >> .else >> TARGET_ABI=3D >> .endif >> VENDOR=3D unknown >> OS_VERSION=3D freebsd12.0 > > I'm using a context where armv[67]* would now > likely be in use above, in fact the context is > from an armv7 build, no longer armv6 . I am kind of confused by this part since I expect the BUILD architecture would not be that often and arm system. Maybe in my wish to provide some context, I added too much and sabotaged my own question :) >> TARGET_TRIPLE?=3D >> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}$= {TARGET_ABI} >> BUILD_TRIPLE?=3D >> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >> >> >> To support a Linux host I made these changes that is using 'cc >> -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if >> it shouldn't be OK for building on a FreeBSD host > > Using an arm FreeBSD head -r324743 context as an example. . . > > For reference: > > # grep BUILD_ARCH Makefile* > Makefile.inc1:BUILD_ARCH!=3D uname -p > Makefile.inc1:.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} > > > # uname -ap > FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 [..] > [After looking into the details my preliminary > guess seemed to be correct: the only dependable > uname output among -m -p -i was for -m for linux. > The uname.c code used varies from distribution > to distribution and that changed the other > options' results.] I am not that concerned about this aspect in the context of my proposal, especially since NetBSD's build.sh takes better care of this on the host side: https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316b= /build.sh#L486 > Back to the armv7 FreeBSD head -r324743 context. . . > > # cc -dumpmachine > armv7-unknown-freebsd12.0-gnueabihf > > Compare that to the results of: > > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} > > Note that on FreeBSD itself on that machine BUILD_ARCH > would historically not have the "-gnueabihf" suffix for > such a host. Would the build tolerate it? Why would a FreeBSD host compiler report the triple with -gnueabi suffix? OOTH, if we're talking about using clang, the exact triple reported by the actual toolchain would be used in the clang/llvm compilation to define -DLLVM_HOST_TRIPLE with the exact value that makes sense for the host triple, which seems the right choice anyway, at least to me. > # cc --version > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLV= M 5.0.0svn) > Target: armv7-unknown-freebsd12.0-gnueabihf > Thread model: posix > InstalledDir: /usr/bin > > Note the "armv7" for what Linux might instead have > something like "armv7l" for a little endian, hard-float > context. Would this matter? Would the build tolerate a > armv7l (or other such) in BUILD_ARCH? My point exactly, gcc and clang are supposed to behave identically from an interface PoV, so I expect the BUILD_TRIPLE gotten via -dumpmachine to be identical between them. >> +.if ${BUILD_OS} =3D=3D FreeBSD >> BUILD_TRIPLE?=3D >> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >> +.else >> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine >> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} >> +.endif > > Keeping the historical BUILD_ARCH content for FreeBSD > hosts might be important. I was only wondering about BUILD_TRIPLE in the context of llvm building. > But for non-FreeBSD hosts, such as a Linux distribution, > might other mismatches with FreeBSD conventions > matter? (See earlier above.) If we're on a Linux host the BUILD_TRIPLE should be the one approrpiate for the linux host, not the FreeBSD. If your point is that I will have to take such things into account for the cross building from Linux, I am aware of that, but that's not that important now since I am still stuck in the bootstrap phase for the cross compiler (linux host, freebsd target). > Also: What of using alternative compilers (${CC} vs. > cc in classic notations, may be ${HOST_CC} or some such > here because multiple compilers can be involved)? Would > "cc" always exist and be appropriate? That's why I said "host 'cc -dumpmachine'". I didn't care much for now for all sorts of checks or corrections such as using HOST_CC, I was just curious if the idea of using the '-dumpmachine' output to define the BUILD_TRIPLE. > In fact on FreeBSD it is possible to buildworld > buildkernel using a non-system compiler, such as > via the devel/powerpc64-gcc port, even on a > powerpc64 system. (This allows a modern build > instead of what gcc 4.2.1 is limited to since > lang does not sufficiently yet.) For that > context: > > # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine > powerpc64-unknown-freebsd12.0 yes, and the HOST_CC or whatever mechanism was chosen to select the host toolchain would have to pick the desired cc. But from what I can see here, the BUILD_TRIPLE would be correct for FreeBSD if using -dumpmachine. > # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version > powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for powerpc64= ) 6.3.0 > I'd expect that the historical BUILD_ARCH content > for a FreeBSD host should be kept instead of ending > up with things like "-gnueabihf" tacked on sometimes. Are you saying that based on BUILD_TRIPLE there is some later BUILD_ARCH definition? That sounds wrong. --=20 Eddy Petri=C8=99or From owner-freebsd-arm@freebsd.org Fri Oct 27 23:06: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 B279DE52C47 for ; Fri, 27 Oct 2017 23:06:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-106.reflexion.net [208.70.210.106]) (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 724547E42E for ; Fri, 27 Oct 2017 23:06:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21654 invoked from network); 27 Oct 2017 23:06:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Oct 2017 23:06:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 27 Oct 2017 19:06:24 -0400 (EDT) Received: (qmail 19027 invoked from network); 27 Oct 2017 23:06:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Oct 2017 23:06:23 -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 317FDEC8A28; Fri, 27 Oct 2017 16:06:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Fri, 27 Oct 2017 16:06:21 -0700 Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6BB7719D-6228-467E-ACA6-F849D290F9C4@dsl-only.net> References: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> To: =?utf-8?Q?Eddy_Petri=C8=99or?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 23:06:31 -0000 On 2017-Oct-27, at 3:10 PM, Eddy Petri=C8=99or wrote: > 2017-10-27 11:19 GMT+03:00 Mark Millard : >> On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or wrote: >>=20 >>> I am trying to make the FreeBSD code base build from a Linux host = and >>> found this bit which defines BUILD_TRIPLE in a way which to my >>> untrained eyes look like overengineering. >>>=20 >>> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || = ${CPUTYPE:M*soft*} =3D=3D "") >>> TARGET_ABI=3D -gnueabihf >>> .elif ${TARGET_ARCH:Marm*} >>> TARGET_ABI=3D -gnueabi >>> .else >>> TARGET_ABI=3D >>> .endif >>> VENDOR=3D unknown >>> OS_VERSION=3D freebsd12.0 >>=20 >> I'm using a context where armv[67]* would now >> likely be in use above, in fact the context is >> from an armv7 build, no longer armv6 . >=20 > I am kind of confused by this part since I expect the BUILD > architecture would not be that often and arm system. Maybe in my wish > to provide some context, I added too much and sabotaged my own > question :) I took your notes/questions/suggestions not as local workarounds based on your local context but as changes to FreeBSD materials themselves in order to more directly support bootstrapping and building from Linux in general. Looks like I got that wrong so most of my notes are not of much use to you. Sorry for the noise. >>> TARGET_TRIPLE?=3D >>> = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} >>> BUILD_TRIPLE?=3D >>> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>>=20 >>>=20 >>> To support a Linux host I made these changes that is using 'cc >>> -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if >>> it shouldn't be OK for building on a FreeBSD host >>=20 >> Using an arm FreeBSD head -r324743 context as an example. . . >>=20 >> For reference: >>=20 >> # grep BUILD_ARCH Makefile* >> Makefile.inc1:BUILD_ARCH!=3D uname -p >> Makefile.inc1:.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} >>=20 >>=20 >> # uname -ap >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 > [..] >> [After looking into the details my preliminary >> guess seemed to be correct: the only dependable >> uname output among -m -p -i was for -m for linux. >> The uname.c code used varies from distribution >> to distribution and that changed the other >> options' results.] >=20 > I am not that concerned about this aspect in the context of my > proposal, especially since NetBSD's build.sh takes better care of this > on the host side: > = https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316= b/build.sh#L486 >=20 >> Back to the armv7 FreeBSD head -r324743 context. . . >>=20 >> # cc -dumpmachine >> armv7-unknown-freebsd12.0-gnueabihf >>=20 >> Compare that to the results of: >>=20 >> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>=20 >> Note that on FreeBSD itself on that machine BUILD_ARCH >> would historically not have the "-gnueabihf" suffix for >> such a host. Would the build tolerate it? >=20 > Why would a FreeBSD host compiler report the triple with -gnueabi = suffix? > OOTH, if we're talking about using clang, the exact triple reported by > the actual toolchain would be used in the clang/llvm compilation to > define -DLLVM_HOST_TRIPLE with the exact value that makes sense for > the host triple, which seems the right choice anyway, at least to me. My example is what it does produce at the end: -gnueabihf Part of the reason is likely that FreeBSD allows building a soft-float based FreeBSD instead (still called armv7 ). hard-float based is just the default. The -dumpmachine output needs to indicate the distinction somehow. They choose to be explicit even in the default case (default from a FreeBSD point of view). This should apply to clang and to gcc for targeting FreeBSD. >> # cc --version >> 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: /usr/bin >>=20 >> Note the "armv7" for what Linux might instead have >> something like "armv7l" for a little endian, hard-float >> context. Would this matter? Would the build tolerate a >> armv7l (or other such) in BUILD_ARCH? >=20 > My point exactly, gcc and clang are supposed to behave identically > from an interface PoV, so I expect the BUILD_TRIPLE gotten via > -dumpmachine to be identical between them. >=20 >>> +.if ${BUILD_OS} =3D=3D FreeBSD >>> BUILD_TRIPLE?=3D >>> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>> +.else >>> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine >>> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} >>> +.endif >>=20 >> Keeping the historical BUILD_ARCH content for FreeBSD >> hosts might be important. >=20 > I was only wondering about BUILD_TRIPLE in the context of llvm = building. >=20 >> But for non-FreeBSD hosts, such as a Linux distribution, >> might other mismatches with FreeBSD conventions >> matter? (See earlier above.) >=20 > If we're on a Linux host the BUILD_TRIPLE should be the one > approrpiate for the linux host, not the FreeBSD. > If your point is that I will have to take such things into account for > the cross building from Linux, I am aware of that, but that's not that > important now since I am still stuck in the bootstrap phase for the > cross compiler (linux host, freebsd target). >=20 >> Also: What of using alternative compilers (${CC} vs. >> cc in classic notations, may be ${HOST_CC} or some such >> here because multiple compilers can be involved)? Would >> "cc" always exist and be appropriate? >=20 > That's why I said "host 'cc -dumpmachine'". I didn't care much for now > for all sorts of checks or corrections such as using HOST_CC, I was > just curious if the idea of using the '-dumpmachine' output to define > the BUILD_TRIPLE. >=20 >> In fact on FreeBSD it is possible to buildworld >> buildkernel using a non-system compiler, such as >> via the devel/powerpc64-gcc port, even on a >> powerpc64 system. (This allows a modern build >> instead of what gcc 4.2.1 is limited to since >> lang does not sufficiently yet.) For that >> context: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine >> powerpc64-unknown-freebsd12.0 >=20 > yes, and the HOST_CC or whatever mechanism was chosen to select the > host toolchain would have to pick the desired cc. >=20 > But from what I can see here, the BUILD_TRIPLE would be correct for > FreeBSD if using -dumpmachine. >=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version >> powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for = powerpc64) 6.3.0 >=20 >> I'd expect that the historical BUILD_ARCH content >> for a FreeBSD host should be kept instead of ending >> up with things like "-gnueabihf" tacked on sometimes. >=20 > Are you saying that based on BUILD_TRIPLE there is some later > BUILD_ARCH definition? That sounds wrong. FreeBSD's original materials constructs BUILD_TRIPLE from BUILD_ARCH. That means that they agree, with BUILD_ARCH (from uname -p) leading the way. Your change no longer has this property: uname -p and cc -dumpmachine need not match (for the part of -dumpmachine output that may or may not be a match vs. the part that never matches). uname -p output did not have a stable definition across Linux distributions in my past experiments. uname -m might be a closer match by content to FreeBSD's uname -p. uname -m was stable in my little bit of experimentation. You might need a local workaround for BUILD_ARCH as well. Again: I misread the scope of the intended usage of the potential changes. So, I missed your interests. Mostly just ignore my original message. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Oct 28 03:46: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 A4A7BE5ACDF for ; Sat, 28 Oct 2017 03:46:10 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter01.peak.org (filter01.peak.org [207.55.16.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.peak.org", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C5F52477 for ; Sat, 28 Oct 2017 03:46:09 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter01.peak.org ({e1c81c21-e4c4-4528-aa90-7a27869c545a}) via TCP (outbound) with ESMTPS id 20171028034603289_0000 for ; Fri, 27 Oct 2017 20:46:03 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id B977E4C46A for ; Fri, 27 Oct 2017 20:45:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 9FD844D13D for ; Fri, 27 Oct 2017 20:45:59 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PkIw2sVLO8tD for ; Fri, 27 Oct 2017 20:45:59 -0700 (PDT) Received: from mailproxy-lb-06.peak.org (mailproxy-lb-06.peak.org [207.55.17.96]) by zmail-mta02.peak.org (Postfix) with ESMTP id 682C14C46A for ; Fri, 27 Oct 2017 20:45:59 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1e8I4L-0009yz-SJ for freebsd-arm@freebsd.org; Fri, 27 Oct 2017 20:45:57 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Re: Make packages for armv7 makes armv6 packages References: <86lgjxo74h.fsf@elm.localnet> <1509058543.56824.61.camel@freebsd.org> <86h8ulntob.fsf@elm.localnet> <1509118047.56824.69.camel@freebsd.org> <868tfwoa86.fsf@elm.localnet> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 27 Oct 2017 20:45:57 -0700 In-Reply-To: <868tfwoa86.fsf@elm.localnet> (Carl Johnson's message of "Fri, 27 Oct 2017 08:56:41 -0700") Message-ID: <861slonde2.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 03:46:10 -0000 Carl Johnson writes: > Ian Lepore writes: > >> On Thu, 2017-10-26 at 20:41 -0700, Carl Johnson wrote: >>> Ian Lepore writes: >>> > I think the problem is that pkg itself hasn't been updated to know >>> > about armv7. =C2=A0If you apply this patch to ports-mgmt/pkg >>> >=20 >>> > https://bz-attachments.freebsd.org/attachment.cgi?id=3D187008 >>> >=20 >>> > then I think it should create armv7 packages for you. >>> Thanks, but what is supposed to handle that file?=C2=A0=C2=A0I see two = patches in >>> there, but I don't know what the other lines are supposed to do. >>>=20 >> >> The extra stuff is subversion properties that are only important if the >> changes are committed. =C2=A0The standard patch(1) will ignore that extra >> stuff, so you can just apply the patches as Boris showed in his reply. > > Thanks, I didn't realize how much patch would ignore. I will try that > today, and then see if I can upgrade to armv7 that way. I patched pkg and used that to build the packages, and this time it did build for armv7. The attempt to upgrade from armv6 to armv7 did not go so well. I installed the new kernel and rebooted and everything worked fine. I then installed everything else and rebooted, but this time it reported that init had died and then dropped into ddb. I haven't figured out anything else, but chroot from another RPi2 with 11.1-RELEASE shows that init was installed properly from the package. This was just an experiment, so I didn't really lose anything important. --=20 Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Sat Oct 28 11:12: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 44299E3F5ED; Sat, 28 Oct 2017 11:12:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DABD56C561; Sat, 28 Oct 2017 11:12:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5d71:227a:7bb3:8fe3] (unknown [IPv6:2001:470:7a58:0:5d71:227a:7bb3:8fe3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1BB16FAED; Sat, 28 Oct 2017 13:12:07 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? Date: Sat, 28 Oct 2017 13:11:59 +0200 In-Reply-To: Cc: freebsd-toolchain@freebsd.org, freebsd-arm@freebsd.org To: =?utf-8?Q?Eddy_Petri=C8=99or?= References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 11:12:16 -0000 --Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 27 Oct 2017, at 08:23, Eddy Petri=C8=99or = wrote: >=20 > I am trying to make the FreeBSD code base build from a Linux host and > found this bit which defines BUILD_TRIPLE in a way which to my > untrained eyes look like overengineering. >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > BUILD_TRIPLE?=3D > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} I don't see much overengineering here? :) We simply trust BUILD_ARCH, as it is passed in by the top-level Makefile.inc1. This is how most of these down-level Makefiles work. Running all kinds of commands to figure out architectures and the like should be avoided in such Makefiles. > To support a Linux host I made these changes that is using 'cc > -dumpmachine' to get the correct BUILD_TRIPLE, Unfortunately, this is the wrong option to do so. The gcc manual says: -dumpmachine Print the compiler=E2=80=99s target machine (for example, = =E2=80=98i686-pc-linux-gnu=E2=80=99) -and don=E2=80=99t do anything else. E.g, it prints the *target* tripe, not the build triple. > but I am wondering if > it shouldn't be OK for building on a FreeBSD host >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 > +BUILD_OS!=3D uname -s > + Again, this should be set by the top-level Makefiles, not in this one. >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > +.if ${BUILD_OS} =3D=3D FreeBSD > BUILD_TRIPLE?=3D > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} > +.else > +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine > +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} > +.endif >=20 > What do you think, should the code be instead: >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine > +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} No, this is definitely incorrect, as stated above. -Dimitry --Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWfRl/wAKCRCwXqMKLiCW o8fKAJ9cFTHTwp5Xa5nkDxxiefnU9mgmhACgiunmA7tOZhsUH2EPq4GNJQ5Ruqc= =9N23 -----END PGP SIGNATURE----- --Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3-- From owner-freebsd-arm@freebsd.org Sat Oct 28 15:31: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 0F8A1E4621C for ; Sat, 28 Oct 2017 15:31:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-156.reflexion.net [208.70.210.156]) (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 C7A55726ED for ; Sat, 28 Oct 2017 15:31:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1949 invoked from network); 28 Oct 2017 14:31:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Oct 2017 14:31:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 28 Oct 2017 10:31:34 -0400 (EDT) Received: (qmail 12211 invoked from network); 28 Oct 2017 14:31:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Oct 2017 14:31:34 -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 CB080EC8676; Sat, 28 Oct 2017 07:31:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Sat, 28 Oct 2017 07:31:33 -0700 Cc: =?utf-8?Q?Eddy_Petri=C8=99or?= , freebsd-arm , freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> References: To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 15:31:42 -0000 On 2017-Oct-28, at 4:11 AM, Dimitry Andric wrote: > On 27 Oct 2017, at 08:23, Eddy Petri=C8=99or wrote: >>=20 >> I am trying to make the FreeBSD code base build from a Linux host and >> found this bit which defines BUILD_TRIPLE in a way which to my >> untrained eyes look like overengineering. >>=20 >> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || = ${CPUTYPE:M*soft*} =3D=3D "") >> TARGET_ABI=3D -gnueabihf >> .elif ${TARGET_ARCH:Marm*} >> TARGET_ABI=3D -gnueabi >> .else >> TARGET_ABI=3D >> .endif >> VENDOR=3D unknown >> OS_VERSION=3D freebsd12.0 >>=20 >> TARGET_TRIPLE?=3D >> = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} >> BUILD_TRIPLE?=3D >> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >=20 > I don't see much overengineering here? :) We simply trust BUILD_ARCH, > as it is passed in by the top-level Makefile.inc1. This is how most = of > these down-level Makefiles work. Running all kinds of commands to > figure out architectures and the like should be avoided in such > Makefiles. >=20 >> To support a Linux host I made these changes that is using 'cc >> -dumpmachine' to get the correct BUILD_TRIPLE, >=20 > Unfortunately, this is the wrong option to do so. The gcc manual = says: >=20 > -dumpmachine > Print the compiler=E2=80=99s target machine (for example, = =E2=80=98i686-pc-linux-gnu=E2=80=99) > -and don=E2=80=99t do anything else. Yep --and it is even more complicated: gcc vs. clang are sometimes different for the target listed. . . For example -m32 for amd64 changes the clang result: # clang -dumpmachine x86_64-unknown-freebsd12.0 # clang -dumpmachine -m32 i386-unknown-freebsd12.0 But it does not change the gcc result: (I happen to have only gcc7 around.) # gcc7 -dumpmachine -m32 x86_64-portbld-freebsd12.0 # gcc7 -dumpmachine=20 x86_64-portbld-freebsd12.0 (powerpc64 vs. powerpc is the same for the -m32 handling for -dumpmachine .) > E.g, it prints the *target* tripe, not the build triple. My guess is that Eddy was depending on plain cc being a "self hosting" (target=3Dbuild) type of compiler command in his intended environment(s). Various linux distributions patch uname and its -p code (for example). Even for the same kernel being in use, giving different textual results. -m seemed more stable in my limited testing. Everyplace that uses uname probably needs to be reviewed for a possible re-work. BUILD_ARCH and its use is an example. >> but I am wondering if >> it shouldn't be OK for building on a FreeBSD host >>=20 >> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || = ${CPUTYPE:M*soft*} =3D=3D "") >> TARGET_ABI=3D -gnueabihf >> .elif ${TARGET_ARCH:Marm*} >> TARGET_ABI=3D -gnueabi >> .else >> TARGET_ABI=3D >> .endif >> VENDOR=3D unknown >> OS_VERSION=3D freebsd12.0 >> +BUILD_OS!=3D uname -s >> + >=20 > Again, this should be set by the top-level Makefiles, not in this one. >=20 >>=20 >> TARGET_TRIPLE?=3D >> = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} >> +.if ${BUILD_OS} =3D=3D FreeBSD >> BUILD_TRIPLE?=3D >> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >> +.else >> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine >> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} >> +.endif >>=20 >> What do you think, should the code be instead: >>=20 >> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || = ${CPUTYPE:M*soft*} =3D=3D "") >> TARGET_ABI=3D -gnueabihf >> .elif ${TARGET_ARCH:Marm*} >> TARGET_ABI=3D -gnueabi >> .else >> TARGET_ABI=3D >> .endif >> VENDOR=3D unknown >> OS_VERSION=3D freebsd12.0 >>=20 >> TARGET_TRIPLE?=3D >> = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} >> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine >> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} >=20 > No, this is definitely incorrect, as stated above. It certainly would not be appropriate for general use on FreeBSD: more of a local workaround for an odd context, not a general solution. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Oct 28 16:59: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 9D09EE48067 for ; Sat, 28 Oct 2017 16:59:58 +0000 (UTC) (envelope-from alex.m@youritcrowd.com) Received: from atlant.youritcrowd.com (atlant.youritcrowd.com [IPv6:2a02:2658:101c::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5699174E9F for ; Sat, 28 Oct 2017 16:59:58 +0000 (UTC) (envelope-from alex.m@youritcrowd.com) Received: from localhost (localhost [127.0.0.1]) by atlant.youritcrowd.com (Postfix) with ESMTP id 7CF3E41BD62F for ; Sat, 28 Oct 2017 19:59:56 +0300 (EEST) X-Virus-Scanned: amavisd-new at youritcrowd.com Received: from atlant.youritcrowd.com ([127.0.0.1]) by localhost (atlant.youritcrowd.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dxpq17MoPYoT for ; Sat, 28 Oct 2017 19:59:53 +0300 (EEST) Received: from [IPv6:2a01:d0:d969:0:59f6:62e8:8bfa:340c] (unknown [IPv6:2a01:d0:d969:0:59f6:62e8:8bfa:340c]) by atlant.youritcrowd.com (Postfix) with ESMTPSA id 6DBF6411CB08 for ; Sat, 28 Oct 2017 19:59:53 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=youritcrowd.com; s=default; t=1509209993; bh=V3lUy+pmIAqDB+5C3+0VFafbN4ULrCayswr877su6O4=; h=To:From:Subject:Date; b=ZpGWA3bYSZsueVtCn7cieVCuMjhNxQzx1hOSYXMtoGGA0djxsGhxRVyMo33XKFVEF TOj+awWnIr/0bbm2St0w6BJEnbepKeo5kPXHdOveBf3Vl3qhzgJBHehhS+4eu46td4 CqiqcWyDhHQojUP3wMxxXDakgggXyVDkjlTRNYYY= To: freebsd-arm@freebsd.org From: Alexander Magliovany Subject: BPI-R2 FreeBSD support Message-ID: Date: Sat, 28 Oct 2017 19:59:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7L7u0068SpGIemjMcHKRACACJJl95V7px" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:59:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7L7u0068SpGIemjMcHKRACACJJl95V7px Content-Type: multipart/mixed; boundary="pMoHDXhcLq79b0hU7JbMhib0NgKlSm9Pj"; protected-headers="v1" From: Alexander Magliovany To: freebsd-arm@freebsd.org Message-ID: Subject: BPI-R2 FreeBSD support --pMoHDXhcLq79b0hU7JbMhib0NgKlSm9Pj Content-Type: multipart/mixed; boundary="------------7D790CBA65E93A83A0C132A2" Content-Language: ru This is a multi-part message in MIME format. --------------7D790CBA65E93A83A0C132A2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! There is another new interesting board came in. It's called Bananapi-R2[1= ] Seems like it based on completely new SoC MT7623N from Mediatek. Is it real to port FreeBSD there? Or it's just a waste of time? [1] http://www.banana-pi.org/r2.html --=20 -- Alexander Magliovany Your IT Crowd --------------7D790CBA65E93A83A0C132A2-- --pMoHDXhcLq79b0hU7JbMhib0NgKlSm9Pj-- --7L7u0068SpGIemjMcHKRACACJJl95V7px Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZ9Ld+AAoJECCVgXC2fr3o0WsH/3ukb5SaVCB8mWt9rX3vT5Bt FHKu/bWc5sRCXasplre1XSW7P93nDUOirN+/g5A0Z3+sUi4fwrWog9om33iGoFpA i2RK23MeifhW+tEhTjHbxU9tysFb7o2/3n4JDIXIP+IxSpEvkXrydD3SJoqyuLKu oS+4eok5KUUkDsKUfRTxMDdeXyQuE0jdaTJpvw7h0dE2GeI+NqYJkQO6JGiY46G9 RNAAw7tlB0vaE6ou/86jV3mSvJYIFuR7qf3XGS+IpLjAWfzkU6jUMuvqExQe7+fP /zkNaWs0C2BiLYyKKhtZ+mHsBqKNcUDNM1ChfnGjCLVQwV+6t1mVhLk252SWubc= =hul8 -----END PGP SIGNATURE----- --7L7u0068SpGIemjMcHKRACACJJl95V7px--