Jump to content

TonyMac32

Moderators
  • Posts

    2382
  • Joined

  • Last visited

Reputation Activity

  1. Like
    TonyMac32 got a reaction from Tido in Banana Pi R2   
    @chwe as long as it is not banana Aldi beer...   (There is Aldi here, it does quite well)
     
    There is an old saying, I feel it applies here:. "Fool me once, shame on you.  Fool me twice, shame on me."   I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed.  And that is with only one bad board, imagine 3,4,5?  "Same old story, same old song and dance".
     
     
     
     
  2. Like
    TonyMac32 got a reaction from JohnnyWednesday in Banana Pi R2   
    @chwe as long as it is not banana Aldi beer...   (There is Aldi here, it does quite well)
     
    There is an old saying, I feel it applies here:. "Fool me once, shame on you.  Fool me twice, shame on me."   I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed.  And that is with only one bad board, imagine 3,4,5?  "Same old story, same old song and dance".
     
     
     
     
  3. Like
    TonyMac32 reacted to Frostbyte in RK3328 Kernel   
    I've just finished writing my SHT31-D (I2C) Nagios plugin.
    As promised, it can be found here for anyone else interested.
  4. Like
    TonyMac32 reacted to nightseas in Add Support for RK3399 (2xA72+4xA53)   
    Thanks a lot for the hints.
     
    I chose the Marvell 64-bit patch instead of RK3288 to replace compressed zImage with the binary Image.
    https://github.com/armbian/build/blob/master/patch/kernel/mvebu64-default/packaging-4.x-with-postinstall-scripts.patch
     
    Now Armbian 5.32 (Ubuntu 16.04 Desktop) is successfully running on my board.
     
    I forked the repo and make my own commit to add the support for RK3399. You can find the changes to original repo here:
    https://github.com/nightseas/armbian-build/
     
    Know issues:
     1. No GPU or VPU pack installed for now;
     2. There's a binary tool from RK used to convert u-boot, which can't be packed into the u-boot deb because it's for x86_64. Means you can't update bootloader in a running Armbian.
     
    Next step will be GPU and VPU userspace lib porting. 
     
    Screenshot of desktop, with CPU, temperature, and frequency:

     
  5. Like
    TonyMac32 got a reaction from Tido in Tinker Board and the RPI 7" touchscreen   
    HID is now working, of course the touch input does not rotate with the screen (perfect compatibility with raspberry pi! )
     
    I can link to the Deb packages for the kernel/dtb if anyone wants to try them out, and if anyone with a MiQi can make sure they don't break anything before I push the patch to the repo.
  6. Like
    TonyMac32 got a reaction from chwe in ASUS Tinker Board   
    [update 12/2017 at bottom]
    Possibly late, but I would like to put everything we know in one place for anyone who might think of buying this board.
     

     
    Overview:
     
       This is a form factor and (mostly) I/O clone of the Raspberry Pi 3 with a much more powerful quad-core Cortex-A17 Rockchip rk3288.  It supports HDMI 2.0, has 2 GB RAM, Gigabit Ethernet, Wifi and BT on board, etc:  https://www.asus.com/us/Single-Board-Computer/Tinker-Board/
     
       As numerous other sites have covered all the typical performance metrics and extolled the power and so forth of this board, I'm going to go ahead and give you the less exciting information and the tradeoffs/problems.
     
    Mainline:
     
    Getting the mainline kernel to boot on this machine was pretty straightforward, mainline support for the hardware, including WiFi, makes for less patching and allows a lot of functionality from the mainline kernel without excessive patching.  That said, so far Bluetooth and squashing a reboot bug have not been successful (I'm under the impression the rk3288 was never truly intended to boot solely from external sdmmc devices)
     
    Important Hardware Considerations:
     
              Power Solution:  This board is equipped with a micro-USB connector as it's power input.  Micro-USB is only rated for 1.8 Amps, no matter how big the numbers on your power supply are.  It is entirely possible, even likely, that you will hang this board by plugging in peripherals to the USB 2 slots.  Micro-USB is a terrible method of providing power to a single board computer, and is the most serious problem with this device.  This device should be powered via the GPIO header using a filtered supply if you wish to have any semblance of stability.
     
              Heat:  The rk3288 is not a low-power chip, and the heat sink supplied (pictured above), is not adequate for any CPU-intensive activity, quickly throttling performance when it gets too hot. 
     
              USB throughput:  I have not empirically tested this, mostly because it is unnecessary.  For some reason the 4 USB 2.0 ports on the board are all routed through a single USB Hub as on the Raspberry Pi.  Not incredibly useful, other than not having to buy an external hub to make the one exposed USB port into 4.  (unless of course those devices use power, then you need a powered hub anyway)  In case you are wondering, there are 2 USB2 ports available on the SoC, however the dev team for this board decided to dedicate one to an "HD Audio codec" instead of using the dedicated I2S/PCM output to do that job.
     
              Undocumented pins:  The 4 pin header  next to the micro-USB power serve no documented purpose.  One pair is definitely the power button as references in the device tree for the board,  I've determined (and have seen others likewise verify) that the pins closest to the edge are the power button input. The other is not documented at all, and I've not wanted to tempt fate by shorting it out.
     
    Software/Support Considerations:
     
              The Documentation for this board is terrible.  Incomplete, non-existent, etc.  The Official ASUS image is a series of workarounds and, until release 1.6, was not properly available to the community.  Even then, development does not appear to be occurring publicly (if it is that means development has stopped).  Rockchip representatives (seemingly not the ones working on the Tinker Board) have at least come forward to provide some helpful hints concerning issues, but ASUS has been entirely silent. 
     
    My opinion after use/development:
     
              This is a very powerful board.  Unfortunately I had to build an adapter to power it over GPIO so it would run properly with any moderately demanding USB peripherals, I added a larger heat sink to stabilize the thermal situation, and am currently trying to find a way to get the board to reset properly without using what the Tinker Board source code itself labels a "HACK".  I can not recommend this board to a new buyer.  It's a shame, really, this board had every opportunity to be a really good solution. 
     
    If the prospective buyer wants nothing more than a 4K media player, there are other options that will serve that niche better, including a small mountain of inexpensive TV boxes.  This board is not ideal for a NAS due to the USB Hub (unless you want to test the limits of the SD card interface).  CPU intensive operations will throttle the device to under 1 GHz with the factory cooler, so without modification you are limited there. Powering peripherals through the board is simply not possible out of the box due to the Micro-USB power solution.  Powering through GPIO is the only sane option. Raspberry Pi compatibility is not absolute.  The GPIO libraries (WiringPi, etc) are not exact, some of the pins serve multiple purposes on the header, etc. This board may be adequate as a small kiosk linux desktop, it is fast enough to provide a snappy interface, and will fit in many of the available cases for the RPi.  I would still recommend GPIO power and probably improved cooling in case a lot of video/etc are needed.  
    [update]  I've been running the Tinker Board as a daily driver for over a week, powering it via micro USB with my normal peripherals (mouse/keybd, wireless active, touchscreen attached)  My findings are what would be expected:
     
    Power supplied to micro USB port:  5.25 volts 800 - 950 mA "normal" use Playing a Youtube Video (software render) this hits 1.7 Amps Voltage present at Tinker Board USB Host port:  4.7 Volts under "normal" use Playing a Youtube Video this drops to 4.2 Volts, meaning a > 1 Volt drop.  
    Now, you might be saying "I run my Tinker on micro USB all the time and don't have any issues"  You're right, and you're wrong all at once.
     
    The processor/RAM use much lower voltages provided by the RK808 PMIC, so the system doesn't fold up and crash when the input voltage gets too low.  HOWEVER, here is a snippet from my dmesg:
     
    What you're seeing here is my little wireless mouse receiver giving up the ghost because of voltage starvation.  More or less, when I get these voltage dips, anything that needs 5 volts (like USB peripherals, say that external HDD, webcam, card reader, mouse) shut down and/or could be damaged/corrupted.  I have not had a single system failure, however were I to be reading/writing external media (or running this off of a flash drive for some reason) I'd have experienced some real problems.
  7. Like
    TonyMac32 reacted to Myy in The VPU driver   
    Nice catch ! This might prove useful, yeah.
     
    Reading this document, I still don't understand why they're dead focused on having technology specific buffers, where all those techs use DMA buffers in the end though. At least internally.
     
    I'm currently looking at DRM PRIME and trying to understand if you can, as a user-space application, allocate a DMA buffer, pass it to something else (user-space or kernel-space) so that it writes some bitmap in it and then display the bitmap on the screen using DRM calls. If that can be done, I'm throwing out the DRM/ION part of the VPU driver and let the user-space app/MPP do the buffers allocation.
  8. Like
    TonyMac32 reacted to balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    Update images 20170803.
    Added support for remote control. To use it you need to add the correct file "remote.conf" in the /boot directory or /etc/amremote. By default, a part of the image includes several predefined files (in the /boot directory). To use it you need to rename one of the files in "remote.conf". Additionally uploaded the site to the directory the deb package "amremote.deb" , which can be installed in the old system (do not download the whole image). After installing this package you need to run service "amlogic-remotecfg" and add (rename) the correct file 'remote.conf".
  9. Like
    TonyMac32 got a reaction from StuxNet in 4k Output on the Tinkerboard?   
    The FAQ is totally incorrect, it is actually true 4K.  Their initial release used a "fake" 4k where it was up-scaled, why, honestly I don't know.  Now, the Legacy kernel works with 4k on my Samsung, however I am aware that some Acer products are... different.  I believe I saw a patch related to this, I can take a look.  The Next and Dev kernels do not yet have 4k support, I haven't rounded up everything needed, and the DRM system has gone through some changes since 4.4, so it's not a drop it in and go situation.
     
    their 4k video player is the QT based one found in the rockchip repo.
     
    @chwe I understand, I was actually outdoors repairing some masonry, I had to rebuild/replace some sections of a 70 year old wall.  Beautiful weather for it, and a good excuse to work with my hands.
     
  10. Like
    TonyMac32 got a reaction from StuxNet in Authentication token manipulation error   
    Are you a child in the schoolyard looking for ways to taunt someone, or are you an adult?  I understand being frustrated with an issue, but your lack of basic manners is unacceptable.
     
    As far as FS corruption: Win32DiskImager causes it.  It is a tool that is only used out of ignorance of superior options like Etcher.  Because of that, we do not support its use and automatically recommend the use of Etcher before we spend our time debugging issues that may simply be faulty SD card burning.  
     
    Other common problems: garbage/counterfeit SD cards, inadequate power supply, etc.  Read the documents you were given a link to.
  11. Like
    TonyMac32 reacted to Xalius in ROCK64   
    I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok.  Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet...
     
    Boot log: http://pastebin.ubuntu.com/25206030/
     
    I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...
  12. Like
    TonyMac32 got a reaction from tkaiser in The VPU driver   
    Awesome.  I'll patch this into the Dev image for anyone here that wants to experiment with the user space parts.
  13. Like
    TonyMac32 reacted to Kwiboo in The VPU driver   
    Cool, I will check how this VPU driver works with a 4.13 kernel on LibreELEC later this weekend.
     
    I would suggest testing the VPU driver and mpp using Rockchip's gstreamer plugins or possibly LongChair's mpv/ffmpeg.
    I don't know much about gstreamer but it seems to be what the Rockchip's developers use to test video decoding.
    Both mpv/plexmediaplayer and kodi use DRM/KMS, gbm version of libmali and a few kernel hacks on LibreELEC for smooth 1080p/4k video playback, they most likely need modifications to run on x11/wayland.
     
    For a version of ffmpeg that use mpp for decoding, see https://github.com/LongChair/FFmpeg/commits/rockchip or the rockchip-new branch.
    LongChair also have a mpv version for both those branches of ffmpeg at https://github.com/LongChair/mpv/commits/rockchip or the rockchip-new branch.
    I have a ffmpeg 3.1 backport at https://github.com/Kwiboo/FFmpeg/commits/rockchip-krypton and Kodi Krypton patches at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-krypton.
    The Kodi Leia patches in the rockchip-leia branch will be updated once we have achieved more stable playback on rk3328 devices using mpv and Kodi Krypton.
  14. Like
    TonyMac32 reacted to Myy in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  15. Like
    TonyMac32 reacted to chwe in Split Armbian in two branches with different names   
    I understand why you would love it cause your ferrari powered VW golf gets hammered quite often:
     
     
    keep fighting, if you solved all this issues there's nothing else which works properly on a RPi.  Maybe they come up with something like 'is the tinker able to play 8k hardware encoded video?'  If I have time on weekend, I may play a little bit my asus tinker and try to solve some of these issues (if the weather gets better I go sailing ).
  16. Like
    TonyMac32 reacted to bedalus in RK3328 Kernel   
    I would if I could, but I've no way to log into the device on the standard images as this is my only keyboard! Maybe they'd let me borrow one from work.
     
    I have to say thanks thanks for all your work and input in this thread. When I got this device I was unaware of armbian, and happened to discover it because you posted a link in the asus forum: https://tinkerboarding.co.uk/forum/thread-330.html
     
    I found armbian and its users so interesting I must have read this entire thread two or three times! If you follow the link above you can see how I followed your example with GPIO power and an uprated heatsink and was able to hacksaw a hole into my case and attach a little fan! You can even see my dongle
  17. Like
    TonyMac32 got a reaction from Myy in ASUS Tinker Board Reboot   
    *High-Five*
     
    I'm testing the 4.4 legacy kernel with the emergency patch, I added all the changes we made to it so as to protect the MiQi (And I think it's just smart).
     
    I'll be working on 4.13 later today to get Dev set up.
     
    I forgot to change the compatible line in the dts, so it didn't run the code.  Well, I guess that works.
  18. Like
    TonyMac32 got a reaction from Tido in ASUS Tinker Board Reboot   
    *Updated 7-23*
     
    ~~All kernels should be fixed at this point, Legacy, Next, and Dev.~~
     
    The ASUS Tinker Board has a big problem with rebooting properly, centered around the SD card power supplies.  Upon issuing a shutdown request, the kernel is turning everything off , including the vmmc regulator.  To make matters worse, vqmmc is set to 1.8 Volts if you use a UHS SD card, and the kernel is not switching it back to 3.3 volts before rebooting, which is required if the Rockchip boot ROM is to communicate with the device.  The result is a hung board in MaskROM mode.
     
    For the Default kernel (4.4), a patch was carried over from the vendor software (quite literally tagged as "HACK" which added a shutdown routine to the rk mmc driver.  It powers vmmc back up, switches vqmmc back to 3.3 volts, then delays for 20 uS or so.  It works on default.
    7-22:  Need to add fix for " echo b > /proc/sysrq-trigger "  ETA:  7-22 or 7-23 7-22:  Adding device check to make certain there are no complications with the MiQi.  Concurrent with sysrq fiq.  Complete and uploaded.  
    For Next/Dev kernels, however, it does not work.  I don't know the full system that well, so I can't comment as to why just yet.  It is also important to note that testing the patch on kernel 4.11/4.12 resulted in a MiQi crash on reboot, wheras I've had confirmed this doesn't appear to be an issue on 4.4.
    7-22: It was determined a day or so ago that the issue was the mmc not being powered down before the hack happened.  Now that is commanded.  7-22: Initial patch broke MiQi, myself and @Myy worked today on figuring it out, trading kernels and patches.  We thought it a good idea to use the device tree platform to discriminate.  Fix is now known, adapting patches and moving them from Dev to Next.  Implemented 7-23:  Rockchip-DEV is now kernel 4.13, reboot patch tested and works.  
    Any expertise in this area would be welcome, I'll update this post as things go on.
  19. Like
    TonyMac32 reacted to chwe in Improve 'Support over Forum' situation   
    I finally made a copy past monkey work out of it and posted it in the forum. So if people want to keep this 'white paper' idea alive we could still do it, but as long as there's not enough manpower i'll left it in the forum (doesn't make sense to hide it)
     
  20. Like
    TonyMac32 reacted to chwe in Powering through micro USB   
    Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
    Basics:
    It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

    The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

    Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
    Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
    How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

    Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

    Illustration 1: AWG print on cable
    Example:
    If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
    *this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
     
    Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

    Figure 2: Voltage drop of a copper cable at various thiknesses
    If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
     
    Case Study:
    Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

    Illustration 2: Setup vor measurement
    FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
    Table 1: Specification of the tested chargers

    Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
    Table 2: Tested micro USB cables

    Results:
    After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

    Figure 3: Voltage drop at delivered current of all chargers
    Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
    All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

    Figure 4: Voltage without load, with load and on output and @powerbank
    .
    Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
    Conclusion:
    What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

    Illustration 3: Recommended powersource
     
     
  21. Like
    TonyMac32 reacted to bedalus in RK3328 Kernel   
    I flashed the file from the download link above: Armbian_5.32.170724_Tinkerboard_Ubuntu_xenial_next_4.12.3_desktop.7z 
     
    After entering root/1234/etc and getting to the desktop, the first thing I tried was a reboot, and it successfully rebooted back to the desktop. I tried again from the newly rebooted desktop, and success again. 
  22. Like
    TonyMac32 reacted to Igor in RK3328 Kernel   
    NEXT nightly = 4.12.3, updated this morning.
    https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_desktop_nightly.7z
  23. Like
    TonyMac32 got a reaction from infinity in ROCK64   
    For Pi form factor boards I've been using a 25 x 50 mm aluminum heatsink available on Amazon, top left in image. 

  24. Like
    TonyMac32 got a reaction from lafalken in ASUS Tinker Board   
    [update 12/2017 at bottom]
    Possibly late, but I would like to put everything we know in one place for anyone who might think of buying this board.
     

     
    Overview:
     
       This is a form factor and (mostly) I/O clone of the Raspberry Pi 3 with a much more powerful quad-core Cortex-A17 Rockchip rk3288.  It supports HDMI 2.0, has 2 GB RAM, Gigabit Ethernet, Wifi and BT on board, etc:  https://www.asus.com/us/Single-Board-Computer/Tinker-Board/
     
       As numerous other sites have covered all the typical performance metrics and extolled the power and so forth of this board, I'm going to go ahead and give you the less exciting information and the tradeoffs/problems.
     
    Mainline:
     
    Getting the mainline kernel to boot on this machine was pretty straightforward, mainline support for the hardware, including WiFi, makes for less patching and allows a lot of functionality from the mainline kernel without excessive patching.  That said, so far Bluetooth and squashing a reboot bug have not been successful (I'm under the impression the rk3288 was never truly intended to boot solely from external sdmmc devices)
     
    Important Hardware Considerations:
     
              Power Solution:  This board is equipped with a micro-USB connector as it's power input.  Micro-USB is only rated for 1.8 Amps, no matter how big the numbers on your power supply are.  It is entirely possible, even likely, that you will hang this board by plugging in peripherals to the USB 2 slots.  Micro-USB is a terrible method of providing power to a single board computer, and is the most serious problem with this device.  This device should be powered via the GPIO header using a filtered supply if you wish to have any semblance of stability.
     
              Heat:  The rk3288 is not a low-power chip, and the heat sink supplied (pictured above), is not adequate for any CPU-intensive activity, quickly throttling performance when it gets too hot. 
     
              USB throughput:  I have not empirically tested this, mostly because it is unnecessary.  For some reason the 4 USB 2.0 ports on the board are all routed through a single USB Hub as on the Raspberry Pi.  Not incredibly useful, other than not having to buy an external hub to make the one exposed USB port into 4.  (unless of course those devices use power, then you need a powered hub anyway)  In case you are wondering, there are 2 USB2 ports available on the SoC, however the dev team for this board decided to dedicate one to an "HD Audio codec" instead of using the dedicated I2S/PCM output to do that job.
     
              Undocumented pins:  The 4 pin header  next to the micro-USB power serve no documented purpose.  One pair is definitely the power button as references in the device tree for the board,  I've determined (and have seen others likewise verify) that the pins closest to the edge are the power button input. The other is not documented at all, and I've not wanted to tempt fate by shorting it out.
     
    Software/Support Considerations:
     
              The Documentation for this board is terrible.  Incomplete, non-existent, etc.  The Official ASUS image is a series of workarounds and, until release 1.6, was not properly available to the community.  Even then, development does not appear to be occurring publicly (if it is that means development has stopped).  Rockchip representatives (seemingly not the ones working on the Tinker Board) have at least come forward to provide some helpful hints concerning issues, but ASUS has been entirely silent. 
     
    My opinion after use/development:
     
              This is a very powerful board.  Unfortunately I had to build an adapter to power it over GPIO so it would run properly with any moderately demanding USB peripherals, I added a larger heat sink to stabilize the thermal situation, and am currently trying to find a way to get the board to reset properly without using what the Tinker Board source code itself labels a "HACK".  I can not recommend this board to a new buyer.  It's a shame, really, this board had every opportunity to be a really good solution. 
     
    If the prospective buyer wants nothing more than a 4K media player, there are other options that will serve that niche better, including a small mountain of inexpensive TV boxes.  This board is not ideal for a NAS due to the USB Hub (unless you want to test the limits of the SD card interface).  CPU intensive operations will throttle the device to under 1 GHz with the factory cooler, so without modification you are limited there. Powering peripherals through the board is simply not possible out of the box due to the Micro-USB power solution.  Powering through GPIO is the only sane option. Raspberry Pi compatibility is not absolute.  The GPIO libraries (WiringPi, etc) are not exact, some of the pins serve multiple purposes on the header, etc. This board may be adequate as a small kiosk linux desktop, it is fast enough to provide a snappy interface, and will fit in many of the available cases for the RPi.  I would still recommend GPIO power and probably improved cooling in case a lot of video/etc are needed.  
    [update]  I've been running the Tinker Board as a daily driver for over a week, powering it via micro USB with my normal peripherals (mouse/keybd, wireless active, touchscreen attached)  My findings are what would be expected:
     
    Power supplied to micro USB port:  5.25 volts 800 - 950 mA "normal" use Playing a Youtube Video (software render) this hits 1.7 Amps Voltage present at Tinker Board USB Host port:  4.7 Volts under "normal" use Playing a Youtube Video this drops to 4.2 Volts, meaning a > 1 Volt drop.  
    Now, you might be saying "I run my Tinker on micro USB all the time and don't have any issues"  You're right, and you're wrong all at once.
     
    The processor/RAM use much lower voltages provided by the RK808 PMIC, so the system doesn't fold up and crash when the input voltage gets too low.  HOWEVER, here is a snippet from my dmesg:
     
    What you're seeing here is my little wireless mouse receiver giving up the ghost because of voltage starvation.  More or less, when I get these voltage dips, anything that needs 5 volts (like USB peripherals, say that external HDD, webcam, card reader, mouse) shut down and/or could be damaged/corrupted.  I have not had a single system failure, however were I to be reading/writing external media (or running this off of a flash drive for some reason) I'd have experienced some real problems.
  25. Like
    TonyMac32 got a reaction from lafalken in ASUS Tinker Board   
    I've been toying with the idea of designing a simple board and publishing the artwork/BOM for it, but if you look around, one for the raspberry pi should be available, look for DIN rail pi accessories, some of them have regulator hats.
     
    As far as filtered (I forgot to hit that point), I am referring to a capacitor/zener diode combo to protect against switching noise and over voltage. 
×
×
  • Create New...