Active threads

Showing topics posted in for the last 365 days.

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: 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. 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/
  7. 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:
  8. 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.
  9. 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).
  10. Yesterday
  11. 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 : DEV : 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 ...
  12. 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 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.
  13. If one is running a DNS server for the LAN/WLAN - probably better to keep it on the wire
  14. 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 ...
  15. thexman

    SSH doesn't work on Orange Pi Zero

    I finally upgraded to the mainline Kernel Linux pan 4.19.13-sunxi #5.70 SMP Sat Jan 12 15:43:21 CET 2019 armv7l armv7l armv7l GNU/Linux like described here and the issue is now also gone for me even with systemd-229-4ubuntu21.15 However I have now an issue with the service systemd-modules-load.service loaded failed failed Load Kernel Modules which won't start I don't know what the culprit of the issue is and what effects it has.
  16. The system is fine, cpuinfo shows 4 cores of 0xc0f and 4 of 0xc07 0xc07 is a Cortex-A7 and 0xc0f is a Cortex-A15 What version of htop is it?
  17. Clearfog wasn't receiving any updates in last update beside upstream fixes. There were some adjustments to the mvebu-next kernel for Helios4 purposes by @gprovost I doubt they could be behind those troubles.
  18. martinayotte

    Improve 'Support over Forum' situation

    I don't have any ...
  19. klamath123

    Armbian for Amlogic S802/S812

    tried but fails see
  20. TonyMac32

    RockPi 4b 'board bring up'

    They closed the original and have not resubmitted anything since Sent from my Pixel using Tapatalk
  21. martinayotte

    Baudrate supported by RK3399

    I don't think it is worth the effort, what would be the gain ? ...
  22. martinayotte

    testers wanted Testers wanted: sunxi Device Tree overlays

    As I said in the other thread, it is not the kernel that manage those DT parameters, it is u-boot responsible to load them, so, we need to see in early u-boot log (before kernel started) if the fixup.scr apply succeeded or not . You need USB-TTL Serial dongle to watch those early logs ...
  23. Kernel 4.19.y for Odroid XU4 is not yet well polished. Use stock 4.14.y until then - switch it simple via armbian-config -> system -> alternative kernels and choose latest 4.14.y
  24. Edit: Uh i guess it should be in the "Development" section instead ... but I can't find how to move the topic :s Hellow, thank you very much for all the work achieved by the Armbian project. I am using Armbian to build images (using ) that I provide to users, with custom packagers installed via userpatches and it works pretty well ! However, the whole "kernel compiling" thing is quite mysterious to me and I don't really understand it. My questions are : - I am confused by the whole "default", "next" and "dev" terminology ? I am guessing this is some sort of stable / testing / unstable, but not sure ... Is using "next" okay ? Is "next" less stable than "default" ? - Most of the building time is spent compiling the kernel image. I am guessing that this is needed at some point, because boards have specificities and the kernel must be patched to handle each of them correctly (?). But for my use case, I am not really interested in compiling the kernel myself, I would rather use the stuff already available in Armbian's repo ( directly. So : is there any way I could disable the build of the kernel and just use "official" builds when building my images ? That in fact goes beyond just the kernel I believed, as I saw some packages like "armbian-firmware" are flagged as "local". Sorry if these questions are already addressed somewhere obvious ... I've been trying to find answers to those elsewhere but couldn't find anything :/ Cheers !
  25. jeanrhum

    Home assistant

    Hi, I'm also using home-assistant since about 2 years I think on a tv-box with an armbian image from balbes (5.37 and legacy kernel). I used the virtualenv method and not hassio. The problem with hassio, is that I didn't manage to install it with docker on an arm64 system, but I didn't search too much. For mqtt and mosquitto, you just have to give the url of the server that can be local. There is also a mqtt server integrated in home-assistant.
  26. balbes150

    Armbian for Amlogic S9xxx kernel 4.1x (>= ver 5.55)

    Update 5.71 . Please note that there are no big changes in these images, for those who already have the system running do not need to update.
  27. petatester

    RK3288 Media Script (TinkerBoard)

    stress -c 4 output is: stress: info: [2841] dispatching hogs: 4cpu, 0 io, 0 vm, 0hdd I stopped it after few minutes because it wasn't printing anything else. Or should i leave 10/15min? PS: With Big Buck Bunny 1920x1080p60 offline ( mpv works great. So looks like only fails with urls. For browser i switched to firefox.
  28. Frostbyte

    Asus Tinkerboard

    Sorry if this has been posted before. Today I took the liberty and upgraded to 18.04.1 LTS via do-release-upgrade. I'm noticing that /var/log almost immediately fills up by the journal, no matter how many times I delete it (I know you're not supposed to delete the filesystem journal) Reaching 100% usage on /var/log causes a multitude of problematic behaviors (i.e. apt-get breaks) user@TinkerBoard:/var/log$ df -h Filesystem Size Used Avail Use% Mounted on udev 1000M 0 1000M 0% /dev tmpfs 201M 16M 186M 8% /run /dev/mmcblk0p1 29G 6.4G 23G 23% / tmpfs 1004M 0 1004M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1004M 0 1004M 0% /sys/fs/cgroup tmpfs 1004M 4.0K 1004M 1% /tmp /dev/zram0 49M 48M 0 100% /var/log tmpfs 201M 0 201M 0% /run/user/1000 user@TinkerBoard:/var/log$ du -hsc /var/log/journal 48M /var/log/journal 48M total Changing the SystemMaxFileSize value (i.e. to 30M) on /etc/systemd/journald.conf does not make the journaling system obey - it still fills up (even after a reboot).
  1. Load more activity