All Activity

This stream auto-updates     

  1. Past hour
  2. wtarreau

    Odroid C2 general

    I understood as well that HK got their hands on the blob part and were able to figure the highest stable frequency they could use. I don't know how this blob is used but definitely without it you won't go above 1.5 GHz.
  3. Today
  4. JMCC

    [Development] RK3399 media script

    That is the problem, then. Well, there are two problems here: 1) RockPro64 uses a different kernel than the other RK3399 boards; and 2) I don't have a RockPro64 to test. So, in answer to your question, I can tell you that my preferred kernel for all other RK3399 boards is default 4.4.167, but it is because I was able to test and patch that kernel with the required features. It seems like that kernel version, on RockPro64, is not working, and there is not much I can do about it. I think we must consider the possibility of moving RockPro64 to standard RK3399, and then all problems would be solved. But we must make sure before that it is possible to do so without breaking other things.
  5. 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.
  6. Multi

    [Development] RK3399 media script

    OK, so changed to nightly and nothing happened same results, installed both 5.67 and 5.69 builds (stable builds available at armbian download page old and current) with no avail. noticed that both builds use kernel 4.4.167 even after changing to nightly and updating, upgrading, dist-upgrading nothing changed the Kernel, decided to do it manually and finally was able to change, selected 5.71 build that uses 4.20.0. Redid instructions and the observations are as follows 4.20.0 does play youtube and media at slightly faster speed (not better i mean like 1.25x) , mpv and chromium 32 played them at correct speed, can see ldspa working but there is no audio so ill blame that on the kernel, neither hdmi or 3.5mm socket have audio output, most likely kernel the culprit again, kodi desktop link does close x and when running command throws error, no longer breaking os so Im attaching error log. Since changing kernel did make a gr8 difference before I try all the builds to my hearts desire, Im wondering if you have a preferred build version that is better tailored to your script? Also neither before or after script install / before after updating and upgrading was /dev/mali available rp64@rockpro64:~$ ls -l /dev/mali ls: cannot access '/dev/mali': No such file or directory kodi_crashlog-20190116_023538.log
  7. ning

    Detecting HDMI status from CLI

    or if display driver is using DRM, maybe /sys/class/drm/ could help you. if display driver is framebuffer, no much info from /sys/class/graphics/
  8. ning

    Detecting HDMI status from CLI

    try xrandr ? or if you know how to use libdrm, you can write your own cmd.
  9. 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
  10. raksan

    Armbian for TV box rk3328

    @CarlosPiles thank you! Yeah, I'm very happy the internal Wifi is working. Anyway my box is Beelink A1, not MX-10. I didn't compile the whole kernel, I just compile the wifi driver for my box. Is your box has 8723bs driver? If so, it's already included in the image. You should play around dtb file, try to get your original dtb file from android, convert it to dts and compare the entry. I got it working that way. I hope you get wifi working too.
  11. Alternatively, you could use a usb to ethernet connector, this would give you network (my user build next works just fine and boots - I just did it today).
  12. Yesterday
  13. JMCC

    Odroid C2 general

    I'm not sure whether they correspond exactly with the number you set, but I can tell they mean a real higher clock speed. I tried with HK's image, and increasing the clock speed through that method causes an increase in hashes/sec with a CPU miner (like ~14.50 hash/s at 1512MHz, vs ~16.50 at 1752Mhz).
  14. martinayotte

    One wire DS18B20 on 4.19.13-sunxi

    No worries ! Anyway, I think I found something interesting about overlays fixup scripts ... But this means it will take time to fix and get new build done for download ... For WiFi brcmfmac, please, create a new thread to avoid mixing issues ... EDIT : fixes are there : NEXT : https://github.com/armbian/build/commit/592c8bd76b006c64564d88145c867f231e5e3791 DEV : https://github.com/armbian/build/commit/88317839596ef844b3899c027d008f2b5911b96e EDIT2 : BTW, this bug seems to be present since months until now for A10./A13/A20 but not for H3/H5/H6, probably just because there are not a lots of overlays users on those platforms, and we didn't get any feedback about it, probably present since more than 8 months ...
  15. 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.
  16. JMCC

    Odroid C2 general

    That's an improvement over S905X, for sure. But I guess the old settings for higher clock speeds (1.6, 1.75, etc. Ghz) in boot.ini were bound to legacy kernel or uboot, weren't they?
  17. technik007_cz

    One wire DS18B20 on 4.19.13-sunxi

    I carry on watching movie so I will be not accessible for change
  18. technik007_cz

    One wire DS18B20 on 4.19.13-sunxi

    ... and wifi is not accessible: [ 9.702977] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout [ 9.702998] brcmfmac: brcmf_bus_started: failed: -110 [ 9.703025] brcmfmac: brcmf_attach: dongle is not responding: err=-110 [ 9.719331] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
  19. technik007_cz

    One wire DS18B20 on 4.19.13-sunxi

    And here is output of /sys/kernel/debug/gpio from the "virgin" image: onewire stays on value 271 like @Emil posted
  20. sfx2000

    uBoot fun stuff... pepe2k

    Stumbled across this while working on something else not ARM related, but it's pretty cool - since Armbian is looking at devices that have eMMC, this might be useful https://github.com/pepe2k/u-boot_mod Short story - it's a uBoot with a micro web server that supports flashing images, including uBoot itself - basically it turns things into a bit of a fail-safe as long as uBoot can execute... (those playing with the fire that is uBoot, keep your UART connections handy) Do I have some security concerns - absolutely yes... but no different than the UEFI that is on many x86 boards these days.
  21. martinayotte

    One wire DS18B20 on 4.19.13-sunxi

    As you can see here, it is a bit better ... But those look bad and probably the issue ... I've never seen such error ... I will dig more this issue ...
  22. 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)
  23. technik007_cz

    One wire DS18B20 on 4.19.13-sunxi

    Yes, it was present. (I did not do any edit of that file and that image is about 2 weeks old.) Here is u-boot from image I downloaded few minutes ago. I made only one change, right after rootfstype=ext4 was added to armbianEnv.txt this: It is exactly same like in non working image with latest kernel.
  24. If one is running a DNS server for the LAN/WLAN - probably better to keep it on the wire
  25. Well - there's always OpenWRT, and the eBin is growing support there - and for a router oriented build - it's a good place to start Alternately - here's a blog/build using Arch with the eBin -- should be similar with Armbian... https://blog.tjll.net/building-my-perfect-router/ Netgate is going to do what they're going to do -- keep in mind that they did independently fund armv7a development for FreeBSD as part of pfSense support for the SG-1000 on Ti Sitara, and did a lot of work on mvebu for their coldfog based SG-3100 on Armada - so to protect their investment in freebsd, I kind of understand it... (and then there's the whole political mess with pfSense, OpnSense, and Monowall - a lot of butt hurts, bad feelings, big egos, etc... so I can see why pfSense/Netgate did what they did... I try to stay out of it, just looking in from the outside)
  26. martinayotte

    One wire DS18B20 on 4.19.13-sunxi

    Please, let isolate the issue : don't do any update/upgrade, simply check the u-boot on freshly burned image to see if you have same issue. And please, tell us if /boot/boot.scr was there in your previous attempt ...
  27. Welcome to ARMBIAN 5.71 user-built Ubuntu 18.04.1 LTS 4.9.138-rtd1295 System load: 1.15 1.02 0.73 Up time: 15 min Memory usage: 4 % of 1631MB IP: CPU temp: 46°C Usage of /: 6% of 15G It is somehow patchable, to be continued ...
  28. technik007_cz

    One wire DS18B20 on 4.19.13-sunxi

    I check our community website, downloaded and flashed latest stretch image for bananapi and during routine upgrade right after logging in and etc I found that image is not latest because it started downloading kernel packages.
  1. Load more activity