Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

[Mark Millard]

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:
> 
>> [I historically use a ufs USB SSD for a (head) root file
>> system on a Pine64+ 2GB and a RPI3. Thus the question
>> below.]
>> 
>> Context for question (note the "USB not working for now"
>> in the Log Message):
>> 
>>> Revision 320612
>>> 
>>> 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
>>> 
>>> 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).
>>> 
>>> Tested on: Pine64
> . . .
>> 
>> The questions:
>> 
>> 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?
> 
> 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.)
> 
> 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.

===
Mark Millard
markmi at dsl-only.net