Chili N

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.

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.

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.

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.

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?

@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, 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.

Yes Tido, I had been to that page but kept getting the "hwclock: Cannot access the Hardware Clock via any known method" message. I still can't see what was wrong but I'd tried it on a fresh install with cut and paste from the pages eventually too but couldn't stop this error. I ended up using DS1307 instructions from a Pi page. Where I am at the moment there are hundreds of DS1307 modules of different shapes and sizes, not a single one over $4. I've had to message companies in Quito for my next trip into the city about DS3231's ..... cheapest so far is $18 each. Mounts up when you could do with 25 of them The import process is a little crazy here. You can buy a $2 module from China, pay 40c tax on it but the processing/handling charge for each is $3.50. I just had a $110 charge from DHL for processing two $15 arduino shields.

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.

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.

Quick update: it seems the DS3231 works with the DS1307 (not the DS1302) kernel module and the kernel doesn't need recompiling for this (Stretch 4.14). I fitted the module to pins 1,3,5,7,9, mode-probed for the DS1307, and followed the instructions for a Pi3 and removing the fake-hwclock. There are a number of posts in different communities about leaving the fake-hwclock there and reconfiguring it so the Tinker will pick up NTP time normally and fall back on the RTC when there's no network connection. I didn't do this because I had already removed fake-hwclock according to other instructions and didn't have time to start over. However, I've got a cron job that just resyncs the RTC with NTP once a month. DS3231 seems hugely more accurate than DS1307 and the three modules I've got running so far have kept much better time. I've a single DS1307 running on a Pi3 and it's gained around 211 seconds over the last week. Of the Tinker's RTC's I've just checked one which has lost around 3 seconds.

Thank you Igor, project for me this afternoon. If I've got things working I'll see if I can make a clear walkthrough for others. Thanks again.

Hi guys, sorry, on with my second issue with the Asus Tinker Board and installing a DS3231 Real Time Clock module. I've tried following any instructions on the internet for Tinker Board use and a couple for the Raspberry Pi, from recompiling the kernel through to trying to edit boot files. I just cannot get this thing working so I've now got myself a fresh install of Armbian Stretch 4.14 and ready to go again. Can anybody provide a step-by-step installation for the Tinker Board and this module (I've been told the DS1307 is the same kernel module but for the life of me I cannot find any modules/.ko's available in Armbian)? Many thanks for any help or advice.

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.

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.