From owner-freebsd-hackers@freebsd.org Tue Oct 24 11:12:36 2017 Return-Path: Delivered-To: freebsd-hackers@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-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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