TonyMac32

Members
  • Content Count

    1748
  • Joined

  • Last visited


Reputation Activity

  1. Like
    TonyMac32 got a reaction from sfx2000 in Pi-Factor power solution   
    the new one has 2, and a big inductor that looks like a small office building.  
     
    Yes, all of my components sit on the "top", other than the header to connect to the other board.  
     
     
    I've taken to using a hot plate with thick steel "heat diffuser" to keep the surface consistent, I don't get any charring that way, the only tricky part is removing boards to cool them acceptably, but I've more or less worked that out, and the hot plate was $25.  I will admit SMT is new for me (I hand soldered the boards in this thread, for instance), but so far I'm having decent success.
  2. Like
    TonyMac32 got a reaction from sfx2000 in Pi-Factor power solution   
    Some feedback from @chwe and some improvements on the protection circuitry:
     

     
    And for the record, electrical cleaner can/will dissolve your electrical connectors...   Also, lead-free solder is an angry and terrible thing.  ;-)
     
    I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...  
  3. Like
    TonyMac32 got a reaction from sfx2000 in Pi-Factor power solution   
    Some feedback from @chwe and some improvements on the protection circuitry:
     

     
    And for the record, electrical cleaner can/will dissolve your electrical connectors...   Also, lead-free solder is an angry and terrible thing.  ;-)
     
    I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...  
  4. Like
    TonyMac32 got a reaction from guidol in Official Asus Tinker Board Case   
    Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
     
    First off, same nice packaging the Tinker owners are familiar with:
                             
     
    The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
     
    The reason for the weight becomes immediately obvious when pulling the two halves apart:

    All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
     
    Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
    https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
     
    I can't verify (no hardware), but the holes are 85mm apart and threaded.
     
    Board fits nicely:
                                     
     
    Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
     

     
     
     
    My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.
  5. Like
    TonyMac32 got a reaction from guidol in Official Asus Tinker Board Case   
    Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
     
    First off, same nice packaging the Tinker owners are familiar with:
                             
     
    The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
     
    The reason for the weight becomes immediately obvious when pulling the two halves apart:

    All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
     
    Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
    https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
     
    I can't verify (no hardware), but the holes are 85mm apart and threaded.
     
    Board fits nicely:
                                     
     
    Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
     

     
     
     
    My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.
  6. Like
    TonyMac32 reacted to JMCC in Le Potato / C2 / K2 4.19 LTS testing thread   
    I fixed some u-boot bug, happening in boards with 1GB of RAM, that could not load u-boot. Here is the console log with the failure:
    Reference to the commit: https://github.com/armbian/build/commit/01571c0a4c6c3e7cdb1fec8c99465d8fc00c8c90
  7. Like
    TonyMac32 reacted to AdamD in tinkerboard S's bricked after 5.70 upgrade   
    you are my hero tonight.  my cluster is running again. i can go back to sleep now..
  8. Like
    TonyMac32 reacted to JMCC in RK3328 Media Script (Rock64, Renegade)   
    And, for last,  the first version of:
    The UN-official, UN-supported, UN-expected
    RK3328 MEDIA TESTING SCRIPT
     
    This is the first release of the RK3328 media testing script. The script provides a functionality similar to its RK3288/3399 equivalents, except for the OpenCL related stuff, which is not supported by the SoC. So it includes:
    Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 2.0 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with: Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
    Here is a more thorough documentation:
     
     
     
    >>> DOWNLOAD LINK <<<
     
    Prerequisites:
    You need a fresh Armbian Bionic desktop image with default kernel installed. 
     
    Instructions:
    Download the file above Untar it: tar xvf media-rk3328_*.txz cd media-script ./media-rk3328.sh  
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!
  9. Like
    TonyMac32 got a reaction from Myy in NanoPC T4   
    Yeah, VPU doesn't exist in mainline.  There are some patches for educational purposes out there, but nothing constituting a truly functional driver.  Mali needs patched in, similar to what @Myy does with RK3288.
  10. Like
    TonyMac32 got a reaction from chwe in Asus Tinkerboard   
    Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19.
     
    Notable changes include the use of device tree overlays.
  11. Like
    TonyMac32 got a reaction from chwe in Asus Tinkerboard   
    Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19.
     
    Notable changes include the use of device tree overlays.
  12. Like
    TonyMac32 got a reaction from kngdmond in Asus Tinkerboard   
    I'm afraid not.   :-/  I have an 800x400 hdmi, it's behavior is a bit different from a typical HDMI display, but as to why, I'm afraid I'm in the dark.
  13. Like
    TonyMac32 reacted to vlad59 in Home assistant   
    I'm using Home Assistant for more than one year and if you follow the armbian installation : use a Virtualenv !!!!! or you'll be facing very painful upgrades.
     
    I switched to docker images but that's the same spirit.
  14. Like
    TonyMac32 reacted to chwe in RockPi 4b 'board bring up'   
    you can start with testing: https://github.com/armbian/testings
    maybe not yet for the RockPi 4b but for other boards you have?
     
    google is a good helper which I quite often use.
     
    If you want to dive into this it might be worth to start with some basics in device tree. The kernel comes with docs, docs are great to understand what a *random devicetree node* does. Combine this stuff try to build images, get errors on building or that the DT doesn't work, use google (or ask here), build again and learn step by step.
     
    You need a virtual machine with ubuntu on it and some spare-time. You may file a few times until you get something working but that's fine. Happens to all of us.
  15. Like
    TonyMac32 got a reaction from Tido in RK3288 Media Script (TinkerBoard)   
    Wait, what? Not much faster? If you say at burning energy during operation, I agree; otherwise, I think every benchmark on the planet is against you. I have 2 Pi3's, I can't use them because they are slower than very nearly every other board I possess, they collect dust. My Pi2 serves to play music for me.

    Sent from my Pixel using Tapatalk


  16. Like
    TonyMac32 reacted to martinayotte in RockPi 4b 'board bring up'   
    With the SDIO changes for better strength done by @TonyMac32, it seems that the laggyness is gone !
  17. Like
    TonyMac32 reacted to zador.blood.stained in board support - general discussion / project aims   
    And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
     
    Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
     
    Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."
  18. Like
    TonyMac32 reacted to oleid in Le Potato Serial Getty on ttys0 starts, stops restarts   
    I renamed the link and rebooted, works fine for my odroidc2; no more spam in the journal.
     
    # cd /etc/systemd/system/getty.target.wants && mv serial-getty@ttyS0.service serial-getty@ttyAML0.service # ls -l [...] lrwxrwxrwx 1 root root 34 Sep 18 11:24 getty@tty1.service -> /lib/systemd/system/getty@.service lrwxrwxrwx 1 root root 41 Sep 18 16:38 serial-getty@ttyAML0.service -> /lib/systemd/system/serial-getty@.service  
  19. Like
    TonyMac32 got a reaction from Slackstick in Support of Raspberry Pi   
    Hola tauroblau,
     
        If possible please use English on the forums, it is quite helpful to everyone, since all told there are probably over 10 (low estimate) languages spoken by the various members.
     
    For the Pi there is no plan on supporting that family of boards.  They embody many of the things we point to as fundamental problems with basic board design (micro USB power, horrible I/O bandwidth, propagandist marketing, just plain wrong benchmarking, I could go on.  The 300 Mbps on the RPi will be significantly affected (negatively) by any other USB peripheral, like a storage drive.  I would recommend researching other boards and finding one with GbE for your needs, the RK3328 boards, RK3288 boards, etc.  They are pricier, but if you need the performance, you will have it.
  20. Like
    TonyMac32 got a reaction from guidol in run armbian on 64MB ram?   
    Aha!  I only turned up the V1.1 datasheet that does not specify the "G" variant.
  21. Like
    TonyMac32 got a reaction from NicoD in Ramblings and progress with the RK3399   
    I'm afraid not.  A few have some sort of "marker" to show what they are (a resistor somewhere tied to an ADC, and efuse value, etc), but they are as non-standard as the SoC's themselves.
     
     
    A lot of people feel this way, but it would require an agreement on a standard.  SPI flash or an eeprom drive cost some vendors will never sign up for, and create some problems when needing to upgrade the information stored on them (device tree bugs, bootloader fixes, etc)
     
    And projects like this one wouldn't have much to do either, the "big guys" would take over and you'd have the same basic options as PC, with others like us and Arch being "alternatives".  That said, there is a versatility of application to SBC's that does not exist with PC.  Few strap a PC to a bench with bare I/O monitoring things, that died with the parallel port.  So I think there will always be room.
     
    An FPGA that runs a RISC-V  powerful enough for linux isn't in my budget just yet, but it does look interesting.
  22. Like
    TonyMac32 got a reaction from NicoD in Ramblings and progress with the RK3399   
    That would be ideal, but some of these boards have... peculiarities that cause source code issues (Tinker has some gymnastics around reboot that require some ugly hacking of the sd/emmc driver that can break other RK3288 devices) or userspace issues (manually toggling IO's to reset BT adapters).  In general, though, you'll find that most of our images are the same for the same SoC, just with DTB/boot script differences for each particular layout, it's why on any board bringup you see us just manually swapping DTB's to see if it will work out of the box.
  23. Like
    TonyMac32 got a reaction from guidol in USB hub not working on OdroidC2   
    If the devices aren't plugged in on boot with 4.17+ the hub will go into a suspend state that can't be woken.  I've patched this in the 4.19 dev images by copying the solution for Rockchip (same IP block).  One of the upstream contributors submitted a nearly identical patch within a day of mine, so it will be fixed in the future.
  24. Like
    TonyMac32 reacted to rino in Le Potato / C2 / K2 4.19 LTS testing thread   
    On bionic 4.19.12-meson64 #5.67.181226:
    $ xrandr -d :0 -q
    Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 8192
    Composite-1 connected (normal left inverted right x axis y axis)
      720x576i      50.00  
      720x480i      59.94  
    HDMI-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm
      1920x1200     59.95*+   (yes)
      1920x1080     60.00  (yes)
      1600x1200     60.00  
      1680x1050     59.88   (yes)
      1280x1024     75.02    60.02  (HDMI only)
      1440x900      59.90  (yes)
      1280x960      60.00  
      1152x864      75.00  
      1024x768      75.03    70.07    60.00  
      832x624       74.55  
      800x600       72.19    75.00    60.32    56.25  
      640x480       75.00    72.81    66.67
     
    Legenda of test result:
    (yes) means that HDMI to HDMI and HDMI to DVI both work
    (HDMI only) means HDMI to HDMI works
    no () means that HDMI to HDMI and HDMI to DVI both don't work.
     
    PS
    To change resolution from UART console I used for example:
    $ xrandr -d :0 --output HDMI-1 --mode 1920x1080
     
  25. Like
    TonyMac32 reacted to rino in Le Potato / C2 / K2 4.19 LTS testing thread   
    Other test performed. I am starting to understand better the "HDMI to DVI" working/not working laziness problem:
     
    HDMI to DVI works BUT, just after the boot, I have to move the mouse to wake up the monitor and get the desktop (I usually interact with the SBC via the uart console).
     
    That's with the last:
    ARMBIAN 5.67.181221 nightly Ubuntu 18.04.1 LTS 4.19.11-meson64