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