34 34
Peba

Asus Tinkerboard

Recommended Posts

On 12/30/2018 at 8:14 PM, kngdmond said:

I'm having an issue with an 7" LCD touch screen and hoping someone might be able to give me some insight of where to look for a solution.  I've posted once before but at that time the LCD would not display at all but I've managed to get it to show up with mixed results. 

If I plug the HDMI into a tv, the display works fine.  Plugging into an LCD 7" made for an rPi the screen would be blue with no display.  I edited /boot/armbianEnx.txt and added:
extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/800x480.bin video=HDMI-A-1:800x480@60.  I know the is oddball, but that's the actual size of the display and by adding this line I was able to boot into Armbian with a working display on the 7" screen.  I did try setting the line to 640x480, 1280x720, and 1920x1080.  I'd get no display with those settings.  The only one that would show a display booting was 800x480.  I did go to github and added LCDshow config lines for the LCD7B to armbianEnv.txt.  After adding LCDshow config lines and rebooting, 640x480 still had no display, but 720p, and 1080p booted to a black screen.

What I can't figure out is, if I boot using 800x480 with the 7" LCD I get a display but it breaks anything using SDl.  I get an error saying lvl0: Error initializong SDL! No currently active connector found.
But if I plug in a tv, boot, anything using SDL works.  If I hot swap the HDMI from the tv to the 7" LCD, the display works including SDL.  But the moment you change menu items or anything that requires an interaction with SDL, the screen will go black.  If I hot swap the HDMI back to the tv, I see the SDL error No currently active connector found.  I tested hot swapping from the TV to the 7" with 720p and 1080p and was able to get a display with SDL but with the same results once I change a menu or did something that required interaction with SDL the screen would go black.  Although the screen would not go black using the 800x480, the display would remain on and just present the SDL error.

So my question is why does the LCD display work by hot swapping. I've searched Google to try to find a solution, a file to modify, etc and I come up empty handed.  Any ideas??

Thank you.

Can you please install my media script, and see if you can play with any of the GBM players in the same circumstances that sdl is failing? That would give us some more info about where the issue can be.

Share this post


Link to post
Share on other sites
On 12/30/2018 at 8:14 PM, kngdmond said:

I get an error saying lvl0: Error initializong SDL! No currently active connector found.

Looking for No currently active connector found on google tells that it is probably a message coming from kernel DRM.

Maybe the 7" LCD screen is not advertising itself correctly to the HDMI interface, or there's a bug in the DRM kernel code which prevents it working correctly.

 

I had to deal with a couple of Full-HD industrial panels (via DVI) and they usually refuse to display anything when they are not configured exactly with the resolution and refresh rate they expect.

I think this is a remote possibility, but supplying EDID manually may interfere somehow. You can read back EDID from the display using get-edit tool (see this for an example), at least you can understand if the display is advertising its modes correctly:

get-edid -b 5 | parse-edid

 

Edited by Tido
quote shorted for readability - please do that next time yourself, thank you

Share this post


Link to post
Share on other sites

Read the entire thread to find out how to see boot messages on HDMI, which were not appearing even if verbosity=7.

 

Turns out you need to specify console=tty0 in armbianEnv.txt instead of console=ttyS3...…..

Share this post


Link to post
Share on other sites

Sorry if this has been posted before.
Today I took the liberty and upgraded to 18.04.1 LTS via do-release-upgrade.
I'm noticing that /var/log almost immediately fills up by the journal, no matter how many times I delete it (I know you're not supposed to delete the filesystem journal)
Reaching 100% usage on /var/log causes a multitude of problematic behaviors (i.e. apt-get breaks)
 


user@TinkerBoard:/var/log$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev           1000M     0 1000M   0% /dev
tmpfs           201M   16M  186M   8% /run
/dev/mmcblk0p1   29G  6.4G   23G  23% /
tmpfs          1004M     0 1004M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs          1004M     0 1004M   0% /sys/fs/cgroup
tmpfs          1004M  4.0K 1004M   1% /tmp
/dev/zram0       49M   48M     0 100% /var/log
tmpfs           201M     0  201M   0% /run/user/1000


user@TinkerBoard:/var/log$ du -hsc /var/log/journal
48M     /var/log/journal
48M     total

 


Changing the SystemMaxFileSize value (i.e. to 30M) on /etc/systemd/journald.conf does not make the journaling system obey - it still fills up (even after a reboot).

 

Share this post


Link to post
Share on other sites

@JMCC @TonyMac32 Rockchip did it again :) 


Possible workaround but overlays doesn't work. (they don't work on images from download section anyway). What shell we do?

--- a/config/sources/rockchip.conf
+++ b/config/sources/rockchip.conf
@@ -22,7 +22,7 @@ SERIALCON=ttyS2
 case $BRANCH in
        default)
        KERNELSOURCE='https://github.com/rockchip-linux/kernel.git'
-       KERNELBRANCH='branch:release-4.4'
+       KERNELBRANCH='branch:stable-4.4-rk3288-linux'
        KERNELPATCHDIR='rockchip-default'
        KERNELDIR='linux-rockchip'

 

Share this post


Link to post
Share on other sites
6 hours ago, Igor said:

Rockchip did it again

Did you notice they created a new branch labeled as 'stable'? Maybe if we just switch to that branch, our problems will end. I cannot test now, though, because I will be away from home until next week.

 

[Edit]: Sorry, I'm on the go and rushed my answer, that was precisely what you suggested. There is another option, namely switching to ASUS.

Share this post


Link to post
Share on other sites

Switching to Asus is possible, but it will require some patching to make sure their fairly unique coding style doesn't break any other RK3288 board/box/etc. While I understand we're not required to keep things nice for other boards, I'd rather not leave a wake of destruction either. I'll take a look at it hopefully tonight.

(I'm not being overly critical of ASUS, it's their kernel for their device, they don't really need to give a damn about other people's hardware, so they can hack to their heart's content)

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites

I did some testing and switching to "stable-4.4-rk3288-linux" works - only 1-2-regulator-act8865-add-restart-handler-for-act8846.patch has to be disabled. But overlays are not there. Should they be at legacy kernel at all?

Share this post


Link to post
Share on other sites

Overlays were never rolled out on legacy I think, if we do roll them out what I'd recommend is making the switch to naming "rk3288-tinker.dtb", so that it won't break any older installs where u-boot is looking for "miniarm", because the dtb needs updated to have sane device tree support as we do it on other boards. That is what I had to roll out on Next when I added overlays there.

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites
On 1/15/2019 at 4:51 PM, Frostbyte said:

Sorry if this has been posted before.
Today I took the liberty and upgraded to 18.04.1 LTS via do-release-upgrade.
I'm noticing that /var/log almost immediately fills up by the journal, no matter how many times I delete it (I know you're not supposed to delete the filesystem journal)
Reaching 100% usage on /var/log causes a multitude of problematic behaviors (i.e. apt-get breaks)
 


user@TinkerBoard:/var/log$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev           1000M     0 1000M   0% /dev
tmpfs           201M   16M  186M   8% /run
/dev/mmcblk0p1   29G  6.4G   23G  23% /
tmpfs          1004M     0 1004M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs          1004M     0 1004M   0% /sys/fs/cgroup
tmpfs          1004M  4.0K 1004M   1% /tmp
/dev/zram0       49M   48M     0 100% /var/log
tmpfs           201M     0  201M   0% /run/user/1000


user@TinkerBoard:/var/log$ du -hsc /var/log/journal
48M     /var/log/journal
48M     total

 


Changing the SystemMaxFileSize value (i.e. to 30M) on /etc/systemd/journald.conf does not make the journaling system obey - it still fills up (even after a reboot).

 


No one? Or at least an image recommendation that's latest?

Share this post


Link to post
Share on other sites
16 minutes ago, Frostbyte said:

No one? Or at least an image recommendation that's latest?

You need to look first what is logged in this journal, because on most Armbian image journal is even turned off, not producing any /var/log/journal ...

Share this post


Link to post
Share on other sites
3 hours ago, martinayotte said:

You need to look first what is logged in this journal, because on most Armbian image journal is even turned off, not producing any /var/log/journal ...


Excuse me if I'm being ignorant at this point, but if the journal is supposed to be off in the first place, then do it's contents really matter at this point?

How can I turn it off if it's not obeying the configuration? Am I missing something? Do I have to turn it off somewhere else?
Also, I will need to do some RTFM before I'll be able to decipher the contents, any pointers will be most welcome.

Share this post


Link to post
Share on other sites
22 minutes ago, Frostbyte said:

any pointers will be most welcome.

How your /etc/systemd/journald.conf looks like ? Mine, on all my boards, everything is commented, so disabled ...

Even for myself, some RTFM is always good, we always have something to learn... Here are some reading : "man journald.conf" .

22 minutes ago, Frostbyte said:

then do it's contents really matter at this point?

Yes, it is matter : simply to know what is logged in this files to figure out who is using it, maybe a specific appllication. I can't verify on my side, since none are created ...

Share this post


Link to post
Share on other sites
7 minutes ago, martinayotte said:

How your /etc/systemd/journald.conf looks like ? Mine, on all my boards, everything is commented, so disabled ...

Even for myself, some RTFM is always good, we always have something to learn... Here are some reading : "man journald.conf" . 

Yes, it is matter : simply to know what is logged in this files to figure out who is using it, maybe a specific appllication. I can't verify on my side, since none are created ...


Everything is commented out here too, but from what I know - commented values are the default ones, unless manually overridden.
In the case of "Storage" it's comment reads "auto", thus means that it'll collect journals if it finds a /var/log/journal folder, otherwise it will do nothing.
The manual entry for journald.conf describes the configuration under /etc and I have already perused it.

I tried to stop journal collection by setting the Storage value to "volatile" and "none", each without success. After a reboot it will be filled to the brim again.
The odd thing here (at least for me) is that when I delete the contents of /var/log/journal but not the folder itself, journal collection will halt. So I have to do this every reboot or set up a crontab (too hacky of a solution for my liking).

The underlying folders and files appear to be random hexadecimal jibberish, how do we know where they originate from?

Also, I suppose I will ask this too:
We obviously run a risk if we turn the journal off and thankfully I have my device on a UPS.. but even these can go out during long outages.
I remember that the TinkerBoard survived plenty of power outages and crashes when I had it with the Xenial image, that one had it's journaling off by default, no?
I always keep backups; but I'd rather avoid accidentally/unwillingly tearing it a structurally superfluous new behind, as my reasoning to use them.

 

Share this post


Link to post
Share on other sites
13 minutes ago, Frostbyte said:

The underlying folders and files appear to be random hexadecimal jibberish, how do we know where they originate from?

So, sadly, we have no clues here ...

15 minutes ago, Frostbyte said:

We obviously run a risk if we turn the journal off

Maybe there is no other solution to do that workaround, except if you found the process that send those hexadecimal to the journal deamon ...

systemctl stop systemd-journald.service
systemctl disable systemd-journald.service

 

Share this post


Link to post
Share on other sites
1 minute ago, martinayotte said:

So, sadly, we have no clues here ...

Maybe there is no other solution to do that workaround, except if you found the process that send those hexadecimal to the journal deamon ...


systemctl stop systemd-journald.service
systemctl disable systemd-journald.service

 


I see, thank you for the insight so far. I'll see what I can do with it and hopefully I will have something to share back.

Share this post


Link to post
Share on other sites
1 hour ago, martinayotte said:

Euuh ??? So, something has been corrupted somehow ...

Maybe you are better to prepare new image from scratch ...


I guess that will give me the peace of mind that I need. Good thing I kept configuration backups!
Thank you for the assistance.

Share this post


Link to post
Share on other sites
On 1/28/2019 at 3:36 PM, Igor said:

I did some testing and switching to "stable-4.4-rk3288-linux" works - only 1-2-regulator-act8865-add-restart-handler-for-act8846.patch has to be disabled. But overlays are not there. Should they be at legacy kernel at all?

 

On 1/28/2019 at 3:47 PM, TonyMac32 said:

Overlays were never rolled out on legacy I think, if we do roll them out what I'd recommend is making the switch to naming "rk3288-tinker.dtb", so that it won't break any older installs where u-boot is looking for "miniarm", because the dtb needs updated to have sane device tree support as we do it on other boards. That is what I had to roll out on Next when I added overlays there.

Sent from my Pixel using Tapatalk
 

 

So, since RK started to create tags, I guess we can just use them and forget about the old problem of the default 4.4 kernel being a constant pain, right? It's also very comforting to see that they paid attention to our requests in that matter.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
34 34