Chili N Posted May 29, 2018 Posted May 29, 2018 Hi all, I've got an application that runs from the terminal and with it failing to work on Tinker OS I've gone back to my default OS, Armbian, where it works faultless. However, everything worked great on my own 25" Philips monitor.... The Tinker Boards will be plugged into a number of 1440 x 900 60hz Samsung and LG HDMI monitors; the only screens available where I am. When using these screens I get a 2-3 pixel vertical purple line down the left of the screen and horrific 1 pixel high, long horizontal multi-coloured lines 'snowing' down the screen like old TV interference. The LG monitors consistently flicker on and off trying to change resolution. Neither Tinker OS or DietPi seem to have this problem but the app won't work with Tinker OS due to sound and networking problems and DietPi is missing a number of libraries, besides me never really getting accustomed to DietPi. So, if I'm booting directly to Armbian Stretch terminal (no X windows), how can I change the resolution and sync speeds, which I presume is the issue? On PC's I always changed the framebuffer settings in Grub but these boards don't use Grub. The app was previously Raspberry Pi based but I'm out in the sticks in Ecuador now and only have access to a batch of Tinker Boards, and some Chinese unnamed ones that I can't identify so trying other boards isn't an option. Big thanks in advance for anybody that can get this working. UPDATE: Just while I've been typing this I've tried booting Xenial into the desktop, changing the modeline for X and opening the app in terminal window but the app fails with a few errors to do with OpenGL/SDL or something.
TonyMac32 Posted May 29, 2018 Posted May 29, 2018 Could I have the link output by armbianmonitor -u ? Need to know things like kernel /etc
jock Posted May 29, 2018 Posted May 29, 2018 I got the same purple vertical line on the very left when using Armbian on my rk3288 tv-box with mainline kernel. I guess it is an HDMI driver problem because I don't remember it ever happened using the default kernel. In my case, turning off and on the monitor makes the purple line go away. Another power cycle makes it appear again, and so on... Now I'm running very latest mainline kernel (4.1.44) and the purple line seems to be gone, but I still get a minimally stretched framebuffer so that the monitor seems to be set in a non-native resolution. This is something I related to this other fact:
Chili N Posted May 29, 2018 Author Posted May 29, 2018 Sorry about the delay, armbianmonitor -u advised the diagnosis information was uploaded to: http://ix.io/1bK4 Restarting the monitor did indeed get rid of the purple line but only on the LG and Samsung monitors, it remains on my Philips monitor that I work from.
Chili N Posted June 10, 2018 Author Posted June 10, 2018 (edited) Quick update: I still can't find any way of changing resolution or refresh rates on the Tinker Board and Armbian. I've spent 10 days trying other distros and there is just so much not working (or libraries missing) I've ended dumping the Tinker Boards and now awaiting a batch of Raspberry Pi3 boards due in a few weeks. The Tinker Board seems to have been such a great prospect with good specs yet Asus have really dropped the ball on this one. Even Tinker OS is so fragile it can't be played with, not without something breaking. It kind of defeats the idea of a 'maker' board. I've noticed guys on the ROTT Facebook group have been trying to get RetroPie going with an Armbian base. A genuine Good Luck guys because nothing seems to work on this board as it should, or at least not taking advantage of the hardware it's built on. Edit: I just read this last post and realised it's come out a bit wrong.... my disappointment is with the Tinker Board, not with Armbian who have done a great job trying to get the Tinker working. It'd be excellent to have all of the hardware working as expected with the lightweight performance of Armbian but for me personally it feels like a waste of effort when other boards could benefit from the support. By the time the Tinker is working properly it will likely be average by SBC standards and have a lot of other better priced competition if it hasn't already. Edited June 10, 2018 by Chili N Change perception of my last post
chwe Posted June 11, 2018 Posted June 11, 2018 21 hours ago, Chili N said: By the time the Tinker is working properly it will likely be average by SBC standards and have a lot of other better priced competition if it hasn't already. depends on use-case.. There's always a better board.. but as you figured out, software has to be mature to benefit from the 'better board'.. And even when the kernel (4.4) has issues at the moment.. It's not that easy to find a board with a proper working VPU (kernel and user-space) yet. Not that rockchips user-space VPU stuff is 100% perfect.. but it works (sometimes. )... Cause all of my boards run headless, I can't give you any advice what might be important to tweek the HDMI output. There are always things which don't work as expected. Sometimes it is a easy task to bring up a feature/solve a bug.. Sometimes it's painful and you can't explain why it doesn't work (or at least I can't ) There are a bunch of recent changes in RKs kernelsource, in case you're still patient enough you might give it a try as soon as the kernel works somehow reliable..
Chili N Posted June 11, 2018 Author Posted June 11, 2018 38 minutes ago, chwe said: There are a bunch of recent changes in RKs kernelsource, in case you're still patient enough you might give it a try as soon as the kernel works somehow reliable.. I'd love to stay with the Tinker given the hardware. Unfortunately they were needed on a time-dependent project that I've joined and my patience doesn't get included in their budget The project itself is for a number of small community groups in Ecuador, and there wasn't much of a budget to begin with. The software had already been created by a group of UK students and was working fine, at the basic level with Raspberry Pi's but there weren't any Pi's available to the community groups here and Tinker Boards had already been supplied. An electronics shop in the closest city had a number of unbranded Chinese boards where I couldn't even read the CPU model or find a similar picture on the internet to identify them. The software communicates directly with the framebuffer, the only alternative was for a browser to be used but X and a browser sucks resources out of the boards and it would have been a fair amount of reprogramming. I've actually got a ROCK64 board with me too, and Armbian/Debian work fabulously on it, no flaws at all that I have found. I'm quite sure it's down to Asus' poor support of this board, and Tinker OS just being thrown together with a handful of their own drivers. I've tried starting with Tinker OS and stripping it down to just the bare essentials and stuff just breaks too easily.
chwe Posted June 11, 2018 Posted June 11, 2018 32 minutes ago, Chili N said: the only alternative was for a browser to be used but X and a browser sucks resources out of the boards and it would have been a fair amount of reprogramming. hmm I think this is solved 'partly' by @JMCC multimedia script which has some HW acceleration (even in chrome.. ) but reprogramming is a different story.. 34 minutes ago, Chili N said: The project itself is for a number of small community groups in Ecuador, and there wasn't much of a budget to begin with. The software had already been created by a group of UK students and was working fine, at the basic level with Raspberry Pi's but there weren't any Pi's available to the community groups here So, the (https://www.raspberrypi.org/about/) Quote The Raspberry Pi Foundation is a UK-based charity that works to put the power of digital making into the hands of people all over the world, so they are capable of understanding and shaping our increasingly digital world, able to solve the problems that matter to them, and equipped for the jobs of the future. doesn't deliver the Quote We provide low-cost, high-performance computers that people use to learn, solve problems and have fun. We provide outreach and education to help more people access computing and digital making. in regions where they claim to 'bring education to poor people'? You should write to their marketing people... 39 minutes ago, Chili N said: I'm quite sure it's down to Asus' poor support of this board, and Tinker OS just being thrown together with a handful of their own drivers. We don't use asus Kernel for the tinker (we only patch stuff partly in, when they're needed for some features.. e.g. DSI display) .. RK3288 kernel comes from RK and RK3328 kernel comes from ayufan (when you choose the default bsp kernel) his kernel is based on RKs kernel, it's obviously a different SoC with different drivers.. But you might have a look in his repo, looking if he did some adjustments there and hope that you find the 'magical bits' which do the trick..
JMCC Posted June 11, 2018 Posted June 11, 2018 1 hour ago, Chili N said: I'd love to stay with the Tinker given the hardware. Unfortunately they were needed on a time-dependent project that I've joined and my patience doesn't get included in their budget I recommend you to give a try to this image for the tinkerboard, and then run this script to install accelerated desktop support. This is about the best you can get from a SBC right now, way ahead Rpi. Of course, when the new kernel is ready, it can get better, but as I say, the stable image already provides a very good desktop experience. It won't take you more than 20 minutes to install the image and the script.
Chili N Posted June 11, 2018 Author Posted June 11, 2018 @JMCC, thank you. It appears I've got some kind of GPU acceleration via the script which will work directly to the framebuffer. However, I'm still unable to locate where or how to change the resolution of the HDMI output to 1440x900@60. On all the LG and Samsung monitors here I've still got flickering output and horizontal lines all the way down the screen. I had to disable booting to the desktop because I get a still cursor on the top left of the screen, whether on my work monitor or the project monitors.
jock Posted June 11, 2018 Posted June 11, 2018 1 hour ago, Chili N said: @JMCC, thank you. It appears I've got some kind of GPU acceleration via the script which will work directly to the framebuffer. However, I'm still unable to locate where or how to change the resolution of the HDMI output to 1440x900@60. On all the LG and Samsung monitors here I've still got flickering output and horizontal lines all the way down the screen. I had to disable booting to the desktop because I get a still cursor on the top left of the screen, whether on my work monitor or the project monitors. You should not get flickering or horizontal lines if you're using standard consumer-grade monitors. Industrial monitors have a fixed resolution and refresh rate (I've seen a couple of them in my life), but consumer monitors usually have their built-in scaler to adapt a non-native resolution. The quality of what you get is far worse than native, but indeed you should not get artifacts. Which version of armbian did you try? I experienced issues trying the variant with the legacy rockchip kernel (4.4) and to solve the problem I had to dig and manually change some bits in the device tree by hand. I opened an issue on github (https://github.com/rockchip-linux/kernel/issues/91) but I get no responses from the official team. By the way, that is not your specific case, because I see you're using the mainline kernel. Normally you should be able to grab the EDID configuration from the monitor installing the read-edid package and running: get-edid -b 5 -q | parse-edid The output is intersting because in theory you can create an xorg.conf file using this output to specify the resolution X.org should use. The output is something like this: Section "Monitor" Identifier "PL2390" ModelName "PL2390" VendorName "IVM" # Monitor Manufactured week 6 of 2016 # EDID version 1.3 # Digital Display DisplaySize 510 290 Gamma 2.20 Option "DPMS" "true" Horizsync 30-83 VertRefresh 55-76 # Maximum pixel clock is 170MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1440x900, 75Hz #Extension block found. Parsing... Modeline "Mode 13" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 2" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 6" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 9" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 10" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 11" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync Modeline "Mode 12" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 14" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Modeline "Mode 15" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync Option "PreferredMode" "Mode 13" EndSection Another hint: always use a good quality HDMI cable. There are cheap cables out which generate all sort of problems, mostly when the monitor is trying to send data back (EDID, but also CEC...)
chwe Posted June 11, 2018 Posted June 11, 2018 It might be possible to bring 1440 x 900 60hz natively with something like this one: https://github.com/arne48/armbian_build/blob/d7f73b341c3170c69bef5d2d1c86bf72c322ca30/patch/kernel/rockchip-next/0039_clk_pll.patch#L36 but his work is based on a patched vanilla 4.4 kernel (and a bit outdated) so things might be slightly different, and there are some bigger kernel issues at the moment.. Due to I don't have such a display and not much experience with 'HDMI hacking' you have to test it on your own.. Maybe until the RPis arrive? The 4.4 kernel had some recent changes which might let you run into other problems, so be aware of that.
Chili N Posted June 12, 2018 Author Posted June 12, 2018 @jock, most of the monitors are LG 20MP38's and a handful of 19.5" Samsungs. The native resolution of all of them is 1440x900@60hz. I've forced my Pi 3 with Raspbian to varying resolutions by setting config.txt and the monitors handle most modes. I've just discovered with the single HDMI to VGA adapter I've got that the picture comes up perfectly on VGA on the Tinker but it's at 800x600. I still can't change to any other resolution without booting into X and fiddling around. I've tried running the application software in a terminal in X and unfortunately coming up with errors. The real point is there should be an easy way to change the framebuffer resolution on the Tinker.
JMCC Posted June 12, 2018 Posted June 12, 2018 Have you tried to play with cvt and xrandr? More info here: https://wiki.archlinux.org/index.php/xrandr#Troubleshooting
Chili N Posted June 12, 2018 Author Posted June 12, 2018 3 hours ago, JMCC said: Have you tried to play with cvt and xrandr? More info here: https://wiki.archlinux.org/index.php/xrandr#Troubleshooting xrandr is for X and cvt just calculates the pixel clock rates. Let's take the Pi for example. In Raspbian you can change the resolution and refresh rate in config.txt. This works even booting into Raspbian Lite which has no X windows system at all. The software I've been given (custom screen communications software) either uses the framebuffer or DRM. I've tried to run the application inside of an X windows terminal and it exits with a bunch of errors. I'm a fairly competent coder but there's errors coming up that would just take too long to sort out. Now, I have been approached by the supervisor of the project in the last few hours who's asked me if I can stay on until Christmas and what the possibilities of trying to recreate the app are, to run within standard user interfaces. Again this is kind of bypassing the point that there is no way to change resolution on the Tinker Board in Armbian without using X. Even if the monitors worked without the lines, how do I set a framebuffer resolution or resolution for something DRM based?
JMCC Posted June 12, 2018 Posted June 12, 2018 31 minutes ago, Chili N said: xrandr is for X Sorry, since the quote that tagged my name talked about X, I didn't miss that you wanted framebuffer. I guess you have already tried this workaround, in case it works with Armbian. Also, in case your app is Qt-based, you can use accelerated GBM+KMS directly from the console to display, and that might eliminate the resolution/refresh rate problem you are experiencing. More info here.
zador.blood.stained Posted June 12, 2018 Posted June 12, 2018 If this driver has proper DRM/KMS stack implementation then it should be possible to force modes on the kernel command line, either with drm_kms_helper.edid_firmware= or with video= parameters. https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes
Chili N Posted June 12, 2018 Author Posted June 12, 2018 Thank you JMCC and zador, I'll try all four links tomorrow. I haven't found that workaround previously, in fact, I think I've just discovered a problem with searches where I'm based. Tinkerboarding.co.uk seems to use Google for it's site search, as I've now just logged in through a VPN in the UK and I'm getting a lot more results in the searches I'm making. Apologies to anybody that's got frustrated with thinking I'm not searching properly. Thanks again for the links, I will start on them in the morning.
JMCC Posted June 13, 2018 Posted June 13, 2018 18 hours ago, Chili N said: Thanks again for the links Start with Zador's suggestion, it's the easiest and most likely to fit your needs. In its simplest form, would be just putting this line in /boot/armbianEnv.txt extraargs=video=HDMI-A-1:1920x1200@60 of course, with your custom resolution and rate
Chili N Posted June 16, 2018 Author Posted June 16, 2018 Back again, and most likely successful. Unfortunately I hit another problem with the boards shortly after getting the workaround going that JMCC mentioned. That workaround finally let me change resolutions, though I still can't get it to 1440x900, I could get others running stable. It would need another thread to explain the other problem but in short, once I'd got the resolution changes working I made a copy for backup of the micro SD card, used Etcher to burn another card and it wouldn't boot. Tried another card (the one thing I have a healthy supply of) and it wouldn't boot. Tried making another copy of the image, and another card, and it wouldn't boot. Repeated the process on the Raspberry Pi and images copy no problems. Tried with dd on the Tinker, still won't boot. I used a fresh Armbian, and a fresh Tinker OS image on the three cards I had already used with the intention of just copying the files from the working card to the fresh image, imaged with Etcher, and none of the boards will boot. Fresh Raspbian on a Pi, same cards, no problems. Fresh card, fresh image (Armbian) on to a card and Tinker boots fine. Fresh image copy from working card to PC, image copy from PC to brand new card, Tinker doesn't boot. Clonezilla for Pi images, on to used cards works fine, even tried it on my single Odroid C2 board and it works fine. Tinker.... doesn't boot. So basically I can flash a completely clean Armbian, Tinker OS or DietPi on to a brand new micro SD card, but it won't take a reflashed card whether from a clean image or one of my own. Okay, wasn't so short :) Apologies, but somebody would ask me what the other problem was. I've 40 16GB Class 10 Sandisk Ultra Cards, 12 16GB Sandisk Extreme cards and 5 Kingston Class 10 (standard ones) cards. They are all genuine, and I've tried three different card readers. Power supplies are all 5V 4.2A and checked with Bitscope. These boards under several OS's just have so many problems - video, audio (the switching in Tinker OS is just crazy), wifi, bluetooth syncing, power supply; I can't see how anybody can make reliable use of them. Expect to find them on eBay UK sometime in July at a fairly budget price. so I can get this project some money back. Thank you folks that have tried to help in getting the video working. Seems the workaround could be the right way to go but I've run out of time on trying to get these boards working.
zador.blood.stained Posted June 16, 2018 Posted June 16, 2018 2 hours ago, Chili N said: ... I made a copy for backup of the micro SD card ... Fresh image copy from working card to PC, image copy from PC to brand new card ... How exactly did you copy the SD cards? Raspberry Pi and Raspbian distributions are a very rare instance where it is enough to simply clone the partitions or rsync to a prepared and mounted card, for most other SoCs you need to raw copy the whole card or reinstall the bootloader manually on new cards because it is not stored on a partition, and if you are using a filesystem level copy you have to adjust the UUID in two places.
Chili N Posted June 16, 2018 Author Posted June 16, 2018 2 hours ago, zador.blood.stained said: How exactly did you copy the SD cards? Raspberry Pi and Raspbian distributions are a very rare instance where it is enough to simply clone the partitions or rsync to a prepared and mounted card, for most other SoCs you need to raw copy the whole card or reinstall the bootloader manually on new cards because it is not stored on a partition, and if you are using a filesystem level copy you have to adjust the UUID in two places. The methods I have used: first attempted copy that failed: dd from one 16GB card to PC, Etcher to an identical model 16GB card. Second attempt dd both ends, another identical model card. Third attempt, Clonezilla, one USB card unit, one unit in a laptop. fresh download of Armbian, using Etcher, straight to new card worked. Same download, using Etcher to the first card I attempted to clone to, failed. Thought card was bad, tried with Raspbian image, Etcher, RPi3, worked. Exactly the same as above but with the second micro sd card that failed (with dd both directions), Tinker Board failed, RPi3 worked. Then tried a mixture of these methods with Tinker OS, Armbian, used cards, new cards, different Tinker Boards, choice of three different card reader/writers. Each time I've attempted a boot on a Tinker Board and it's failed, THEN tried to reflash the card the Tinker Board doesn't even bother to try reading the reflashed card. Ultimately, I tried a new card, flashed with Armbian. I let it boot, then shutdown and overwrote the files on the card (systemd rubbish etc) and copied the application over. This booted but the application wouldn't start. Reflashed the same card with Armbian to start again and it wouldn't boot. Same card again, reflashed (always with Etcher at this point) with Armbian for Odroid C2, and the C2 boots. The Raspberry Pi and the Odroid really don't care if the card is new, old, reflashed, fresh, Sandisk, Kingston, whatever, they boot every time around. I've tried with changes to the UUID and without but eventually all these different configurations were just taking too much time, especially considering the other problems I was already encountering. The cards are genuine. I bought them in blister packs from Ebuyer in the UK. One thing that I've just picked up on is this (purely for the sake of testing now): If I flash a clean image on to a new card and boot it successfully, then wipe the card, whether with Windows or Linux, then reflash the drive and try booting again on the Tinker it doesn't work.... and then if I run badblocks on the card I get some error about a magic number and a super-block. Bearing in mind I've a number of Tinker Boards here and I've tried 4 boards from two different (allegedly) suppliers, I still get the same problem. I can't check any more boards at the moment because badblocks is taking 4 hours to complete. I'm just waiting on a Raspberry Pi card to see if there's the same issue. I also tried to read the reflashed cards in Ubuntu to see if there is any corruption but they actually won't even mount, giving a number of possible errors instead.
chwe Posted June 17, 2018 Posted June 17, 2018 I think your goal is to install some dependencies you need and then dd them to multiple boards do get your system up and running? If that's the case? Did you think about https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script e.g. the way @tkaiser generates the OMV builds? Or a short one form Igor: https://github.com/igorpecovnik/iot/blob/master/userpatches/customize-image.sh this should IMO be the 'proper' soultion.
Chili N Posted June 17, 2018 Author Posted June 17, 2018 Quote I think your goal is to install some dependencies you need and then dd them to multiple boards do get your system up and running? I've dumped the Tinkers for now, but if I get time I'll start another thread about the micro SD cards, as this one was for the video sync/resolution problem. I came across the image copying problem just trying to make a backup of a card that I'd half-sorted the video on. dd'ing doesn't seem to work in any kind of way. Etcher has worked from the beginning with each brand new card I have used but as soon as I have used a card once, if I need to reflash the card using any tools, the Tinker no longer boots. It was more of a highlight of yet another problem, possibly/probably only with the boards I have here, and not every board made, but it has added to the list of issues with Tinker. Thing is there will be a few people willing to spend the time on solving these problems. I feel that the Tinker Board was released more as a hobby board that users could start attaching things to straight away but Asus really couldn't give a damn about supporting it. I've basically inherited the boards I have here to complete a project that was started and the expertise wasn't originally there to get it done. Even with the input from several professionals and the help from communities such as this one it's still beyond just being able to plug a board in and have an operating system and hardware working correctly. Even the early Orange Pi's were eventually workable and documentation/software for them was pretty dire. The organisation that bought these went with a brand name they recognised and the plus side that they were easily available. As it is, they've turned into a huge waste of limited funds, disappointment for young students and way too much wasted time and that's before they're even attached to anything.
TonyMac32 Posted June 19, 2018 Posted June 19, 2018 On 6/16/2018 at 9:15 PM, Chili N said: Etcher has worked from the beginning with each brand new card I have used but as soon as I have used a card once, if I need to reflash the card using any tools, the Tinker no longer boots. Whoa. I've burned a few of these SD cards 50 times or so with Etcher and never had that happen. Is this a Windows/linux/Mac host?
Recommended Posts