+- PINE64 (https://forum.pine64.org)
+-- Forum: PINE A64(+) (https://forum.pine64.org/forumdisplay.php?fid=4)
+--- Forum: Pine A64 Hardware, Accessories and POT (https://forum.pine64.org/forumdisplay.php?fid=32)
+---- Forum: LCD and Touch Panel (https://forum.pine64.org/forumdisplay.php?fid=37)
+---- Thread: Linux Support (/showthread.php?tid=1183)
RE: Linux Support - tkaiser - 09-19-2016
(05-26-2016, 11:45 PM)UnixOutlaw Wrote: I don't want to run Android to get touch-screen LCD support - I want to run "native" Linux.
With Allwinner BSP it has always just been tweaking of hardware config (formerly known as fex files, now device tree stuff): http://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/?view=getlastpost
It seems Allwinner chose to stay compatible to the old fex settings: http://linux-sunxi.org/Fex_Guide#disp_init_configuration (output type for example: 1 is still LCD while 3 is HDMI and so on)
So grab the .dts from ayufan's github repo, optionally adjust the settings to your needs (LCD+HDMI in different modes) and enjoy the LCD. Since an automatic detection in u-boot would be nice I asked ayufan whether he already looked into.
RE: Linux Support - tkaiser - 09-20-2016
BTW: When I looked into the first A64 SDK/BSP back in last Dec for obvious reasons display was set to LCD as default. I put the example fex file online back then: http://pastebin.com/26Q5tbXU (starting at line 408).
This SDK/BSP allowed defining stuff in the traditional way (fex file) and also as device tree (kernel 3.10). When longsleep started to work with BSP kernel coming from 'real' kernel sources he got rid off all the fex stuff immediately and defined everything solely in .dts -- since no LCD was available back then and since 'it just worked' he defined display settings to use HDMI. And since none of the linux-sunxi devs uses Pine64 with display connected (only to test out stuff asked by users here from time to time) nothing has changed over time. That's the whole story.
That Allwinner's BSP kernel can deal with LCD is a must since A64 is made for tablets. And today it's not a Android vs. Linux thing it was just ignorance (for different reasons) preventing the adoption of LCD settings from an Android image to Linux OS images.
It will become an Android vs. Linux thing as soon as we talk about Mainline u-boot/kernel since there display initialisation happens differently (or not at all ATM). But as long as all Linux images providing display output are based on Allwinner's BSP kernel (regardless whether patched up to 3.10.102 or not) using an LCD is just defining it in a configuration file (dual display config possible in different modes as known since years from other Allwinner implementations).
RE: Linux Support - apple4ever - 09-20-2016
(09-20-2016, 01:55 AM)tkaiser Wrote: BTW: When I looked into the first A64 SDK/BSP back in last Dec for obvious reasons display was set to LCD as default. I put the example fex file online back then: http://pastebin.com/26Q5tbXU (starting at line 408).
This SDK/BSP allowed defining stuff in the traditional way (fex file) and also as device tree (kernel 3.10). When longsleep started to work with BSP kernel coming from 'real' kernel sources he got rid off all the fex stuff immediately and defined everything solely in .dts -- since no LCD was available back then and since 'it just worked' he defined display settings to use HDMI. And since none of the linux-sunxi devs uses Pine64 with display connected (only to test out stuff asked by users here from time to time) nothing has changed over time. That's the whole story.
That Allwinner's BSP kernel can deal with LCD is a must since A64 is made for tablets. And today it's not a Android vs. Linux thing it was just ignorance (for different reasons) preventing the adoption of LCD settings from an Android image to Linux OS images.
It will become an Android vs. Linux thing as soon as we talk about Mainline u-boot/kernel since there display initialisation happens differently (or not at all ATM). But as long as all Linux images providing display output are based on Allwinner's BSP kernel (regardless whether patched up to 3.10.102 or not) using an LCD is just defining it in a configuration file (dual display config possible in different modes as known since years from other Allwinner implementations).
Thanks for the background. Is there a detailed step by step to getting the LCD working on Ubuntu? That would be really helpful.
RE: Linux Support - MarkHaysHarris777 - 09-20-2016
(09-20-2016, 07:25 AM)apple4ever Wrote:(09-20-2016, 01:55 AM)tkaiser Wrote: BTW: When I looked into the first A64 SDK/BSP back in last Dec for obvious reasons display was set to LCD as default. I put the example fex file online back then: http://pastebin.com/26Q5tbXU (starting at line 408).
This SDK/BSP allowed defining stuff in the traditional way (fex file) and also as device tree (kernel 3.10). When longsleep started to work with BSP kernel coming from 'real' kernel sources he got rid off all the fex stuff immediately and defined everything solely in .dts -- since no LCD was available back then and since 'it just worked' he defined display settings to use HDMI. And since none of the linux-sunxi devs uses Pine64 with display connected (only to test out stuff asked by users here from time to time) nothing has changed over time. That's the whole story.
That Allwinner's BSP kernel can deal with LCD is a must since A64 is made for tablets. And today it's not a Android vs. Linux thing it was just ignorance (for different reasons) preventing the adoption of LCD settings from an Android image to Linux OS images.
It will become an Android vs. Linux thing as soon as we talk about Mainline u-boot/kernel since there display initialisation happens differently (or not at all ATM). But as long as all Linux images providing display output are based on Allwinner's BSP kernel (regardless whether patched up to 3.10.102 or not) using an LCD is just defining it in a configuration file (dual display config possible in different modes as known since years from other Allwinner implementations).
Thanks for the background. Is there a detailed step by step to getting the LCD working on Ubuntu? That would be really helpful.
No there is not; which is the prime problem with so much surrounding the Allwinner SoC; no documentation.
Lennyraposo estimated two weeks to get the LCD working with gnu+linux on the PineA64; if its a dts thing he should have been able to say two hours-- and that would have been more than enough time. The problem is that noone yet knows the configuration ( except perhaps Allwinner ).
RE: Linux Support - tkaiser - 09-20-2016
(09-20-2016, 07:25 AM)apple4ever Wrote: Is there a detailed step by step to getting the LCD working on Ubuntu? That would be really helpful.
I can't provide one since currently I don't even have a Pine64+ around ('lost' mine when we started to nail the 'GbE issue' down). Only as advice: Look at the commits from Sep 11th: https://github.com/ayufan-pine64/device-pine64-common/commits/master
Basically it's just getting the compiled DT, putting it next to the other .dtb files (depends on the OS image in question) and then adjust uEnvt.txt (or boot.cmd with Armbian) to load the correct one when the board boots.
So given we would talk about Armbian it should suffice to do this (as root of course):
Code:
wget -O /boot/dtb/allwinner/sun50i-a64-lcd-pine64-plus.dtb https://raw.githubusercontent.com/ayufan-pine64/device-pine64-common/19545248d729d0ddf056d3bed85eeee4a238ffd5/bootloader/pine64/sun50i-a64-lcd-pine64-plus.dtb
sed -i '1isetenv fdtfile sun50i-a64-lcd-pine64-plus.dtb' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
rebootThis will store ayufan's .dtb in the right location, then patch the bootscript to use this afterwards. This won't work with the other OS images (and I really don't care about any of those except longsleep's!) and of course no guarantee whatsoever.
With Armbian and a board with working Ethernet not that much can go wrong since all you need to recover from any of the steps above is to SSH into your board, remove line 1 from /boot/boot.cmd, do the mkimage call again and reboot.
I'm curious whether the moderator who answered you also will start again censoring/deleting posts as he did a few weeks ago... IMO it's a shame that he's still enable to censor other posts!
EDIT: All of the above just gives you the framebuffer on the LCD instead of (or in parallel to) HDMI. But for the more advanced modes you would have to check the links above (especially linux-sunxi wiki). Don't expect that touch functionality works out of the box. And please don't ask me, I'm personally not interested in 'Desktop Linux' at all or connecting Pine64 to any display.
All the hot 'desktop' stuff now happens driven by some talented community members here: https://github.com/ayufan-pine64/linux-pine64/commits/master
So in case some talented Linux devs interested in 'Desktop Linux experience' are also here, that's the place to look at (and to 'port back' now that same kernel sources can be used -- Jon Smirl poked me a few weeks ago to look into that direction and I totally lost track, even forgot to answer him
)
RE: Linux Support - tkaiser - 09-20-2016
Seems touchscreen is also tweaking .dts: https://github.com/ayufan-pine64/device-pine64-common/pull/1
And also nice: just looked through some of the commits the Android guys did on top of longsleep's kernel just to realize that HDMI-CEC is taken from H3 and a quick search for the term and author's name later I was already back in Armbian forum: http://forum.armbian.com/index.php/topic/1407-wiphdmi-cec-driver-for-h3/
That's how open source collaboration should happen: in the open and without being blinkered
Now for better 'Linux Support' to happen only some more talented devs would be needed that are interested in 'Desktop Linux' also (I fear that does not apply to the usual linux-sunxi tinkerers active now)
RE: Linux Support - vintagewaffle - 10-26-2016
(09-20-2016, 09:33 AM)tkaiser Wrote: Seems touchscreen is also tweaking .dts: https://github.com/ayufan-pine64/device-pine64-common/pull/1
And also nice: just looked through some of the commits the Android guys did on top of longsleep's kernel just to realize that HDMI-CEC is taken from H3 and a quick search for the term and author's name later I was already back in Armbian forum: http://forum.armbian.com/index.php/topic/1407-wiphdmi-cec-driver-for-h3/
That's how open source collaboration should happen: in the open and without being blinkered
Now for better 'Linux Support' to happen only some more talented devs would be needed that are interested in 'Desktop Linux' also (I fear that does not apply to the usual linux-sunxi tinkerers active now)
The touch panel is slightly more than just dts tweaking, you also need to patch the panel driver and make sure it's compiled when building the kernel.
However once that is done, the touch panel works great, I have it running under armbian at the moment.
RE: Linux Support - HayseedGeek - 10-26-2016
(10-26-2016, 11:55 AM)vintagewaffle Wrote: The touch panel is slightly more than just dts tweaking, you also need to patch the panel driver and make sure it's compiled when building the kernel.
However once that is done, the touch panel works great, I have it running under armbian at the moment.
Help me out here because I'm a bit unsure what you are saying. I'm under the impression that Armbian is headless. How would the touch panel even be relevant in that environment?
RE: Linux Support - UnixOutlaw - 10-26-2016
I'd suggest vintagewaffle installed a GUI ontop of the legacy Armbian image... there's nothing stopping you from doing that - just requires a fair amount of tweaking that's all... Me? I run DietPI on one of my Pines (with Pine 7" display - in a Lego "playbox" enclosure), and the XFCE debian build on the other one...
Would be nice to find vintagewaffle's recipe for doing this - if there is a "recipe"...
RE: Linux Support - pfeerick - 10-26-2016
(10-26-2016, 06:09 PM)HayseedGeek Wrote:(10-26-2016, 11:55 AM)vintagewaffle Wrote: The touch panel is slightly more than just dts tweaking, you also need to patch the panel driver and make sure it's compiled when building the kernel.
However once that is done, the touch panel works great, I have it running under armbian at the moment.
Help me out here because I'm a bit unsure what you are saying. I'm under the impression that Armbian is headless. How would the touch panel even be relevant in that environment?
There is nothing stopping you running a DE/GUI on Armbian - in fact they documented the steps to install a simple desktop environment here. However, these are the generic instructions - the Pine64 specific stuff has been documented by tkaiser here.
And as far as relevance... it would be great to be have a information display with system load, uptime, network address, service status, etc... just one possibility...