Learnincurve

This is resolved now.  After reading https://www.raspberrypi.org/forums/viewtopic.php?t=216901 I created the following systemd service file:
 
Unit]
Description=unload the goodix driver ahead of reboots to allow it to properly load again when the system restarts
[Service]
ExecStop=/sbin/rmmod goodix
Type=oneshot
RemainAfterExit=true
[Install]
WantedBy=multi-user.target
 
System now comes up with working touchscreen every time:)                                                                                                                                                  ~                                                                                                                                                     ~                        

Hi,
 
Thanks to the hard work of your team, the Pine64-plus touchscreen now works great with the mainline kernel and legacy images are no longer listed in the download options, but it looks like some of the instructions at https://www.armbian.com/pine64/
are still referring to the "old way" of doing things:
 
ie:
Pine64’s own LCD with touchscreen support can simply be activated in /boot/armbianEnv.txt by setting pine64_lcd=on and adding gt9xxf_ts to /etc/modules followed by a reboot.
 
The LCD screen is now activated by manipulating the DT overlays, which can even be done from armbian-config - hardware, and the touchscreen module is now called "goodix".
 
 Please can someone find the time to update the instructions on the page?
 
BR.
 
 

:
 
Issue is finally fixed in (at least) nightly builds !
 
There is now a "pine64-7inch-lcd" overlay in /boot/dtb//allwinner/overlay
 
Just add
 
 "overlays=pine64-7inch-lcd"
 
to armbianEnv.txt and screen magically works.
 
A BIG thank you to the team for fixing this! Pine64 is now ready for mainline kernel goodness!
 

:
 
Issue is finally fixed in (at least) nightly builds !
 
There is now a "pine64-7inch-lcd" overlay in /boot/dtb//allwinner/overlay
 
Just add
 
 "overlays=pine64-7inch-lcd"
 
to armbianEnv.txt and screen magically works.
 
A BIG thank you to the team for fixing this! Pine64 is now ready for mainline kernel goodness!
 

I cheated and upgraded to nightly from the latest stable build, which you can do from the armbian-config  - System menu. Otherwise I see that all of https://minio.k-space.ee/armbian/ is unavailable at the moment.  The link will probably work again later.

I updated the system with the new dtb package and edited the tree again, this time without the feiyang panel.  Here are the the .dts snippets for dsi and d-phy:
             
  dsi@1ca0000 {                         compatible = "allwinner,sun50i-a64-mipi-dsi";                         reg = <0x1ca0000 0x1000>;                         interrupts = <0x00 0x59 0x04>;                         clocks = <0x02 0x1c>;                         resets = <0x02 0x05>;                         phys = <0x44>;                         phy-names = "dphy";                         status = "okay";                         #address-cells = <0x01>;                         #size-cells = <0x00>;                         phandle = <0x8d>;                         vcc-dsi-supply = <0x04>;                         port {                                 endpoint {                                         remote-endpoint = <0x45>;                                         phandle = <0x20>;                                 };                         };                 };                 d-phy@1ca1000 {                         compatible = "allwinner,sun50i-a64-mipi-dphy\0allwinner,sun6i-a31-mipi-dphy";                         reg = <0x1ca1000 0x1000>;                         clocks = <0x02 0x1c 0x02 0x71>;                         clock-names = "bus\0mod";                         resets = <0x02 0x05>;                         status = "okay";                         #phy-cells = <0x00>;                         phandle = <0x44>;                 };  
This time, dmesg is at least not displaying any mipi or dsi-related errors:
 
# dmesg | grep dsi
[    2.318045] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360)
~# dmesg | grep mipi
[    2.275838] vcc-mipi: Bringing 2900000uV into 3300000-3300000uV
 
so definitely closer.
 
Now I'm going to re-visit the thread and armbian documentation to see what needs to be done to enable.
 
 

Thanks @lex,
 
I currently only have headphones attached direct to my DAC (not even through a headphone amplifier) as the system is hooked up to a testbed at work
Thank you for the very interesting article!  I had rad a little about the problems of DSD, but haven't seen them presented in such an easily read way before.
 
My project, which started as an attempt to replace my ageing squeezebox touch, is turning (with the help of my colleague) into a potentially commercial venture. I say potentially, because we still have a lot of work to do and a lot of problems to solve, before we have a working prototype. For the moment, I just have pine screen on a stand, with basic touch-like functionality, running only slightly modified squeezelite/jivelite. The plan is to develop a new control interface and to make sure that we are passing through /or processing the original stream as authentically as possible.  That is the main reason for the interest in DSD, as format conversion is generally considered a bad thing, yet another conversion to PCM is best avoided.  The other reason is that if we ever plan to become commercial, we need to support as many DAC input technologies as possible, as some DACs only support native DSD, while some support DoP.
 
Some pics and very basic/poor video uploaded to my Google drive at  
https://drive.google.com/drive/folders/0B1XH4Yuu5-Nyc2luSEJzTTBmNEU
 
It doesn't give any impression of sound quality, but will show that the device exists and works (as far as it goes). 
 
There are various files in the lower folder, including a compressed, 32GB system image and there is also a folder containing kernels as I play with them.  The kernel in the image does not have the nrpacks fix applied.
 
Regarding kernel:
 
3.10 is a little early in terms of USB throughput (I have patched the Armbian kernel with an nrpacks fix from 3.13 described here), there have been significant changes to the alsa tree, especially regarding DSD. I'm not sure that any of this is sonically significant but it does mean that I am prevented from using some of the output options that are available in the latest squeezelite versions.
 
I wish I were up to doing the backporting work myself, but am not.  If anyone volunteers and needs a monkey for producing diffs or anything similarly dumb, I'd be happy to help and to test as far as my equipment allows.
 
The alternative is obviously to wait for the mainlining effort to catch up.  As of 4.10, I'm missing DSI (lcd) support, higer clock frequencies, IR and USB.. all pretty much show-stoppers, but I do know of and am vary grateful for the community working so hard to bring better mainline support to these allwinner chips., which represent fantastic hardware bang-for-the-buck, coupled with terrible driver support from the manufacturer.
 
 

Thanks @lex,
 
I currently only have headphones attached direct to my DAC (not even through a headphone amplifier) as the system is hooked up to a testbed at work
Thank you for the very interesting article!  I had rad a little about the problems of DSD, but haven't seen them presented in such an easily read way before.
 
My project, which started as an attempt to replace my ageing squeezebox touch, is turning (with the help of my colleague) into a potentially commercial venture. I say potentially, because we still have a lot of work to do and a lot of problems to solve, before we have a working prototype. For the moment, I just have pine screen on a stand, with basic touch-like functionality, running only slightly modified squeezelite/jivelite. The plan is to develop a new control interface and to make sure that we are passing through /or processing the original stream as authentically as possible.  That is the main reason for the interest in DSD, as format conversion is generally considered a bad thing, yet another conversion to PCM is best avoided.  The other reason is that if we ever plan to become commercial, we need to support as many DAC input technologies as possible, as some DACs only support native DSD, while some support DoP.
 
Some pics and very basic/poor video uploaded to my Google drive at  
https://drive.google.com/drive/folders/0B1XH4Yuu5-Nyc2luSEJzTTBmNEU
 
It doesn't give any impression of sound quality, but will show that the device exists and works (as far as it goes). 
 
There are various files in the lower folder, including a compressed, 32GB system image and there is also a folder containing kernels as I play with them.  The kernel in the image does not have the nrpacks fix applied.
 
Regarding kernel:
 
3.10 is a little early in terms of USB throughput (I have patched the Armbian kernel with an nrpacks fix from 3.13 described here), there have been significant changes to the alsa tree, especially regarding DSD. I'm not sure that any of this is sonically significant but it does mean that I am prevented from using some of the output options that are available in the latest squeezelite versions.
 
I wish I were up to doing the backporting work myself, but am not.  If anyone volunteers and needs a monkey for producing diffs or anything similarly dumb, I'd be happy to help and to test as far as my equipment allows.
 
The alternative is obviously to wait for the mainlining effort to catch up.  As of 4.10, I'm missing DSI (lcd) support, higer clock frequencies, IR and USB.. all pretty much show-stoppers, but I do know of and am vary grateful for the community working so hard to bring better mainline support to these allwinner chips., which represent fantastic hardware bang-for-the-buck, coupled with terrible driver support from the manufacturer.
 
 

Back to the main topic of the thread. I do now have a working (beta) pine64 / Armbian based system that can connect to a Logitech Media Server and output PCM streams up to 24/384.
 
I made a mistake regarding native DSD as this is not supported in kernel 3.10.  Squeezelite/alsa is silently converting to PCM (which still sounds pretty good).
 
I have a thread on the slimdevices forums if anyone is interested in a cheap, audiophile quality device feeding a USB dac.