Date: Tue, 24 Oct 2017 03:03:25 -0700 From: Mark Millard <markmi@dsl-only.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> 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: <C3462FE1-9FFC-43CD-B09C-27A78A9513A3@dsl-only.net> In-Reply-To: <20171024105014.cd2012898a602408ee605183@bidouilliste.com> References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <C9F6BF5E-28DB-4569-B71E-EDE2A042FC78@dsl-only.net> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <B3F39A7C-339B-4072-9E41-A3F9DA1F590B@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <BF09EA6D-6DE8-4138-AD92-8836DFF28620@dsl-only.net> <06B9A4AD-EA28-41A8-91B9-FE368EF622FE@dsl-only.net> <68CB464E-6FC6-4CB9-963B-9E7A683041EB@dsl-only.net> <EC0D967B-B466-4CE2-83E6-4BAA7724A07D@dsl-only.net> <17D6B79E-F7AF-4395-B8A2-2CE9A5157ABF@dsl-only.net> <20171024105014.cd2012898a602408ee605183@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 <manu@bidouilliste.com> = 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 <markmi@dsl-only.net> 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: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number <NOT-SHOWN> >> da0: 40.000MB/s transfers >> da0: 228936MB (468862128 512 byte sectors) >> da0: quirks=3D0x2<NO_6_BYTE> >>=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: <Open Firmware CPU Group> on ofwbus0 >> cpu0: <Open Firmware CPU> on cpulist0 >> cpufreq_dt0: <Generic cpufreq driver> on cpu0 >> cpu1: <Open Firmware CPU> on cpulist0 >> cpu2: <Open Firmware CPU> on cpulist0 >> cpu3: <Open Firmware CPU> on cpulist0 >> cpu4: <Open Firmware CPU> on cpulist0 >> cpufreq_dt1: <Generic cpufreq driver> on cpu4 >> cpufreq_dt1: no regulator for cpu@100 >> device_attach: cpufreq_dt1 attach returned 6 >> cpu5: <Open Firmware CPU> on cpulist0 >> cpu6: <Open Firmware CPU> on cpulist0 >> cpu7: <Open Firmware CPU> 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 <MMCHC 8WPD3R 0.0 SN E7C6641B MFG 01/2016 by 21 0x0000> = 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 <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C3462FE1-9FFC-43CD-B09C-27A78A9513A3>