TonyMac32

Members
  • Content Count

    1741
  • Joined

  • Last visited

2 Followers

About TonyMac32

  • Rank
    Embedded member

Contact Methods

  • Website URL
    http://www.electricgraveyard.com

Profile Information

  • Gender
    Male
  • Location
    Michigan

Recent Profile Visitors

4088 profile views
  1. TonyMac32

    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.
  2. TonyMac32

    Odroid C2 general

    That I'm not sure of, and I'm also uncertain they were ever "real". I'd have to scour around in here and find what @wtarreau has to say on the matter, since Amlogic processors are under the command of the mighty M4 micro of doom with super-secret firmware. We have the same secret sauce blobs as the legacy u-boot, so it should be there.
  3. TonyMac32

    Odroid C2 general

    The Odroid blob is used for the C2, so it should be able to run up to it's maximum (15xx MHz)
  4. TonyMac32

    RockPi 4b 'board bring up'

    They closed the original and have not resubmitted anything since Sent from my Pixel using Tapatalk
  5. Ok. I'm just relating what I saw last night, changes that failed: -editing armbianEnv locked up after a few seconds at loading kernel. -symlink failed same as above -I forgot to pull the "boot from SD" jumper and it was booting ok after massive errors because of overlays and pulling the SD script after the eMMC one failed. Sent from my Pixel using Tapatalk
  6. @igor the solution that worked on mine was simply dropping the miniarm DTB into the directory and rebooting with the jumper off and the SD out. It sounds like that worked for the OP as well, I think it's safe to push the update. Sent from my Pixel using Tapatalk
  7. If you don't pull the SD card it will fall back to SD, reload the boot script from there, and boot. Probably how the issue escaped in the first place. Sent from my Pixel using Tapatalk
  8. I had to do it as root, then I sync'd and ejected
  9. no SD card in the slot, right? Otherwise I'll try to install a fresh 4.14 and repeat the process again and see what happens tomorrow my time (is 1:30 here, I have to sleep. ). If I can't reproduce it, then we will have to wait on your USB-UART adapter
  10. No, the armbianEnv.txt file overrides it. Maybe check to be sure the file has the right file listed.
  11. That looks the same, now, did you reboot it with the USB attached to the PC still (crazy question, but if I don't ask...) (This would get it stuck in UMS mode)
  12. I'll have to catch up on that. This worked on mine, but has not worked on @AdamD's I want to verify the boot comands/etc
  13. OK, show me what your boot.cmd file looks like.
  14. OK, don't edit anything, just copy this file into the "dtb" folder with the other device trees. @Igor I'll push this patch, basically creating this device tree for the older u-boot systems. rk3288-miniarm.dtb
  15. OK, mine is wanting to see "rk3288-miniarm.dtb" and can't find it. We had a symlink there, it must have gotten lost, but why that isn't angering the SD cards I'm not sure... if you edit /boot/armbianEnv.txt to read "fdt_file=rk3288-tinker.dtb" instead of "fdt_file=rk3288-miniarm.dtb" you are a step closer, but mine is hanging after a few seconds, can you verify that behavior? I am trying something else quickly. @Igor does u-boot not get updated on eMMC? My board is still listing the 2018.05 revision after the update