BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen
Emmanuel Vadot
manu at bidouilliste.com
Tue Oct 24 11:12:36 UTC 2017
On Tue, 24 Oct 2017 03:03:25 -0700
Mark Millard <markmi at dsl-only.net> 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 <manu at bidouilliste.com> 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 <markmi at dsl-only.net> 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: <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=0x2<NO_6_BYTE>
> >>
> >>
> >> 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: <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 at 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
> >>
> >> 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 <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
> >>
> >>
> >> 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 at freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> >
> >
> > --
> > Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
--
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
More information about the freebsd-hackers
mailing list