BPI-M3 booted via a variant of head -r324743 with an external ECHI USB root file system: what I changed to have it happen

Mark Millard markmi at dsl-only.net
Tue Oct 24 10:03:29 UTC 2017


[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.

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.


===
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>



More information about the freebsd-arm mailing list