Date: Wed, 2 Aug 2017 14:34:37 -0700 From: Mark Millard <markmi@dsl-only.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head? Message-ID: <D614120A-8987-4990-AE6D-9EBB9F04E76C@dsl-only.net> In-Reply-To: <20170802210607.dc92b751dcc23f3ddaea5144@bidouilliste.com> References: <F43B3C72-4370-4A02-B921-A2AD6082699D@dsl-only.net> <20170802210607.dc92b751dcc23f3ddaea5144@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Aug-2, at 12:06 PM, Emmanuel Vadot <manu at bidouilliste.com> = wrote: > On Tue, 1 Aug 2017 14:03:23 -0700 > Mark Millard <markmi at dsl-only.net> wrote: >=20 >> [I historically use a ufs USB SSD for a (head) root file >> system on a Pine64+ 2GB and a RPI3. Thus the question >> below.] >>=20 >> Context for question (note the "USB not working for now" >> in the Log Message): >>=20 >>> Revision 320612 >>>=20 >>> Author: >>> manu >>> Date: >>> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago) >>> Changed paths: >>> 5 >>> Log Message: >>> allwinner: Add A64 ccung support >>>=20 >>> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux = switched >>> to ccu-ng >>> This commit adds the necessary bits to boot on pine64 with latest = DTS from >>> upstream. >>> USB is not working for now and some node aren't present in the DTS = (like the >>> PMU, Power Management Unit). >>>=20 >>> Tested on: Pine64 > . . . >>=20 >> The questions: >>=20 >> Does anyone have a general idea that they can report for >> what/when to expect for the return of USB support for >> Pine64+ 2GB, RPI3, and the like A64 based contexts? >=20 > I'm the only one who could have an idea (for Pine64) and I don't know. Both parts are good to know. And it confirms that I've not read the wrong content into the note. >> Should I just ignore updating the Pine64+ 2GB and RPI3 for >> a few months more? (Because I do self-hosted builds on them >> I want the USB file system to be used for such activity.) >=20 > You can do whatever you want, either ignore or help. Long term having learned to "get USB going again" for A64 would be good. But I really do not expect someone to deal with my learning curve. (I've never done anything remotely analogous.) I'm not aware of a combination of self-study materials that would get me there either (or close to there). I'm afraid that bootstrapping me into "get USB going again" for A64 might well take more time than the direct effort to do it would take. Still if you can identify some way that I'd likely be of help for the issue (or other issues that would help clear the way for this one) that would be great. Feel free to point me at things to read or otherwise study. Side notes on my FreeBSD activities so far: I've been able to identify very narrow specific points in preexisting code such as the sp_el0 usage with interrupts enabled in the fork_trampoline for aarch64 that was fixed once noticed. In other cases I've just provided evidence that helped prompt someone that knew what they were doing to identify an underlying issue, such as loss of "dirty bits for removing PROT_WRITE on arm64". These were examples of backtracking from odd behavior that was observed, sometimes intermittent behavior. Classically my FreeBSD activities have been tied to finding and reporting issues for clang targeting powerpc64 and powerpc, as well as finding some oddities somewhat analogous to finding the sp_el0 issue for aarch64 but in a powerpc-family context. (I started my FreeBSD activity with old PowerMacs and only later dealt with other TARGET_ARCH's as well.) I maintain bootable/usable freeBSD environments (head based) for (mostly clang based in modern times, even for the powerpc-family): amd64 (also used for cross buildworld buildkernel) powerpc64 powerpc aarch64 (specifically: cortex-a53 examples) armv6 (specifically: cortext-a7 examples, so armv7) The variety helps make sure that my activities do not accidentally mess up building bootable systems for other FreeBSD contexts. But I've limited that coverage to environments for which I (sometimes) have access to native-hardware. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D614120A-8987-4990-AE6D-9EBB9F04E76C>