All Activity

This stream auto-updates     

  1. Past hour
  2. Victor O
    well, its not a question, just reporting that I tried a couple of your images for the Jetson Nano and everything worked except for the fact that the display doesn't recover after turning the monitor off and on. It happens on my TV and my monitor. The question would be. Is there a quick fix? or could you help me add another mode to the xrandr? I noticed that when I shutdown the Jetson Nano, the display turns into textmode and I can see it again. So, I am thinking of making a script using xrandr to switch to a different display mode into order to reset the display.
  3. Today
  4. NicoD
    Hi all. I've made a new video where I compare the above boards. I show specs, performance and transfer speeds of everything. Here's the video. Here my gathered data. Benchmarks ---------- Khadas VIM3 | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench | glmark2 Ubuntu Bionic 1.80Ghz 2.21Ghz 13m22s 1582 2322 192FPS 12.90 http://ix.io/1P6F Ubuntu XFCE 1.80Ghz 2.21Ghz 12m43s 1586 2316 355FPS 12.90 http://ix.io/1PhE Armbian Bionic 1.80Ghz 2.11Ghz 11m48s 1610 2244 495FPS Armbian Bionic 1.80Ghz 2.21Ghz 11m28s 1613 2348 510FPS 12.85 http://ix.io/1PD2 Armbian Disco 1.80Ghz 2.21Ghz 11m11s http://ix.io/1PDR Armbian Buster 1.80Ghz 2.21Ghz 11m21s 1644 2374 590FPS 12.80 http://ix.io/1PEm RockPi 4B | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Debian Stretch64 1.51Ghz 2.02Ghz 21m44s 1340 1988 90FPS 8.79 http://ix.io/1Rrl Debian Stretch64 1.42Ghz 1.80Ghz 23m34s 1260 1789 90FPS 8.07 http://ix.io/1RrE 50 Armbian Disco 1.42Ghz 1.80Ghz 21m38s 1246 1811 254FPS 9.90 Armbian Bionic 1.42Ghz 1.80Ghz 22m19s 1247 1809 255FPS 9.55 http://ix.io/1Rz3 Armbian Bionic5.4.0RC4 75 NanoPi M4 | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Armbian Bionic 1.42Ghz 1.80Ghz 22m18s 1249 1813 250FPS 9.50 http://ix.io/1ORz Armbian Stretch 1.42Ghz 1.80Ghz 23m48s 1269 1789 7.97 http://ix.io/1ORY Armbian Buster 1.42Ghz 1.80Ghz 21m23s 1277 1816 290FPS 10.07 http://ix.io/1P6X Armbian Disco 1.42Ghz 1.80Ghz 20m34s 1252 1823 260FPS 9.95 http://ix.io/1PbD Odroid N2 | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Armbian Bionic 1.9Ghz 1.8Ghz 14m29s 1629 1891 Atomic Pi | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Ubuntu Disco 1.67Ghz 27m58s 1441 60FPS Storage ------- NanoPi M4 | Read | Write 32GB eMMC 180MB/s Samsung EVO SD-cardreader 68.1MB/s 20.6MB/s USB3-Sata 395.5MB/s 411.5MB/s Odroid N2 | Read | Write 32GB eMMV 151.4MB/s Samsung EVO SD-cardreader 61.9MB/s 14.2MB/s USB3-SATA 228.5MB/s 239.6MB/s Khadas VIM3 | Read | Write eMMC 16GB 165.9MB/s 60 MB/s SSD over USB3 286.1 MB/s 380.3 MB/s write SSD over USB2 : 40.2 MB/s Samsung EVO plus with on-board sd-reader : 10.2MB/s write 22.1MB/s read with USB3 sd-reader : 31.7MB/s write 88.6MB/s read RockPi4B | Read | Write On-board sd 23.9 MB/s 14.3 MB/s ssd over USB3 402.7 MB/s 406.2 MB/s write NVMe 730 MB/s 745.0 MB/s write 1GB 10GB 432MB/s
  5. belfastraven
    On further investigation, it looks like changes to ./compile.sh from a couple of weeks ago will look for a vagrant installation if vagrant is specified as the first parameters to compile.sh in the build directory and try to install it (and virtualbox) if it is not installed. Since it IS already installed on my machine, vagrant was brought up and the compilation proceded successfully (I build PineH64 with Dev kernel, desktop, buster) and then end by telling one to hit enter to halt the vagrant box, but would allow no further communication with the vagrant box. (I.e., I didn't want to halt it, I wanted to use it again) The way the build worked before, once the virtual box was up and one ssh'ed into it, one could do multiple compilations, logout and ssh back in, etc. I cannot figure out how to do that now. I would be happy to submit documentation changes if I could understand how this is all supposed to work, now. I know I ran into other changes on the parameters for building a few weeks earlier too. Id also be happy to test proposed build changes and match them to the documentation if that would help...
  6. t23
    Can anyone with 5.98 and HDMI audio please do this: "speaker-test -c 2" On both my x96 mini and KM8P the channels are reversed. Please tell me its not my head, haha.
  7. AlexP
    This is really ridiculous. I've made all the recommendations from the 2nd message - it still hung. So I've re-installed the system (was Bionic, now Buster). And it still deadly hangs. In addition to this Buster version queries ntp servers really often 3K queries per day (x4) to 0/1/2/3.debian.pool.ntp.org. But when I query timedatectl service, it says that ntp service is inactive... Have no ideas where it stems from: corrupted distributive, buggy SD card(despite it's a Sony UHS-I card), bad microcomputer.
  8. Lutz Fechner
    My Zero ver. 1.5 in the black case with the expansion board attached reports 50°C right after booting and settles at around 46°C shortly after. There is no heatsink on the SOC yet and load on the system is pretty low (only using it as OpenVPN Gateway). I can live with that temperatures as they seem to be stable over time so far.
  9. Lion Wang
    BPI-MT7615 802.11 ac wifi 4x4 dual-band PCIe module Mass production version,support BPI-R64 ,BPI-R2 http://forum.banana-pi.org/t/bpi-mt7615-802-11-ac-wifi-4x4-dual-band-pcie-module-mass-production-version/10037
  10. Igor
    Yes it is and its not going to be fixed.
  11. adogado
    Hello; I tried again, wifi connected wthout problems wpa-wpa2 network with nmcli. Connect to open network not working with nmcli. I think , problem is a driver problem. It was tested wth external wifi card and connect to open network ok. But orange pi wifi card not connect to open network. Thanks. --- [ 726.849024] wlan0: authenticate with 30:b5:c2:ee:be:a5 [ 726.849131] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 726.849148] ieee80211 phy0: Freq 2452 (wsm ch: 9). [ 726.849555] wlan0: send auth to 30:b5:c2:ee:be:a5 (try 1/3) [ 726.849798] wlan0: send auth to 30:b5:c2:ee:be:a5 (try 2/3) [ 726.849960] wlan0: send auth to 30:b5:c2:ee:be:a5 (try 3/3) [ 726.850580] wlan0: authentication with 30:b5:c2:ee:be:a5 timed out ---
  12. Igor
    We don't care about CSC configurations, right? Perhaps its most commonly used, Raspian on RPi, is one of many. Answer = "Just do it." I don't care about RPi, otherwise it would already be in. I am just saying that if someone provides a working CSC it will be there and its future will depends on random people.
  13. Igor
    This will only properly label the existing work done mainly by me in various branches. I started to develop some new feature, but perhaps more has to be fixed and rather make move to a new release. So "arm64", where most of the work and where naming is totally derailed from the actual work shell be renamed to new branch ... its an attempt to make it easy for others to join. If they have an interest, otherwise this will remain just my upgrade. But until nobody knows this is actually an upgrade, not just fixing one function, nobody even look into until its done. You can see what was already fixed, there are pleads what its nice to fix and perhaps some other have an idea to squeeze in some feature. Ideally this process shell be planned within Jira. This is not maintaining a separate LTS branch.
  14. funben
    Anyone ? Where to find driver for a FORESEE eMMC in armbian ? How to install it ?
  15. Tido
    IIRC, @tkaiser did some tests and it may be the best or the best-compromise to use this for ZRAM. it says slack&whatspp... isn't https://wire.com already doing that? They want to close the gap between rivaling provider or so AND get some money to do so.. fair enough.
  16. Tido
    did you now find a way to do it anyway, with as little people as armbian is?
  17. Tido
    it is not about the software, it is also about the people you attract and their expectation: Hmmm, but this works in raspbian, why not in armbian. Please fix it now.
  18. balbes150
    The question is not clear. Write details
  19. Igor
    Negative. It's Armbian based. @tkaiser made those images solo for this purpose. Perhaps one day someone will submit a CSC configuration, like https://github.com/armbian/build/pull/1542/files or https://github.com/armbian/build/pull/1480 ?
  20. Igor
    Yes. Then its better to stay on generic versioning since Armbian is already not exactly the same as Ubuntu. We put a kernel in the centre and attach userland on that. Also add Debian's. This default/next/dev or legacy/current/dev already tells a lot about support status and since kernel is the thing we have now LTS around 4.19 ... which is good for most, while Allwinner is better to upgrade to 5.3.y and ASAP to 5.4.y when its out ... To not confuse with Ubuntu, we have probably only one option left -> 2019.10.n ... next major version 2020.02.n ... n for bug fix releases. Is this clear enough? It is unrealistic to properly maintain an LTS version at this stage. When we agree on this, branches shell follow this naming - clean out older. Master have version 2019.10.n, development (arm64 at this point) becomes 2020.02 or whatever its appropriate. Goal is that its clear at once where things are getting developed. - branches shell not go too far apart. Merging must be possible all the time. - critical fixes goes to both branches - other branches are open temporally only for features development - if any of those processes can be automatised, task should be put to Jira and version tags shell be set for the future in Jira. Clear rules, protocol of changing and communicating to the users ... and clearing possible points of confusions anywhere possible.. Can we define into the last detail, what would that represent? If someone knows exactly what shell be done, its easy and I am sure more people will be able to help. If we focus to master (2019.10) and development (2020.02) and if I focus only on development, someone should take care of current master branch. Merge bug fixes, while leave features for 2020.02. They need to be well tested. beta.armbian.com is ofc attached to 2020.02. One of the must-do tasks for the maintainer of this branch: In case a pull request with the fix or feature comes to the master (2019.10) it has to be shared upstream, to development as well. Also one should pull critical things from the development without any special request.
  21. guidol
    OMV for Raspberry Pi should be based on Raspbian - which is actual based on debian (stretch or buster).
  22. TRS-80
    I just came across this article (for those interested in the freedom aspects, per the title): https://www.fsf.org/resources/hw/single-board-computers I still haven't been home yet to play with those ODROIDs nor the IP cameras I ordered back in August. See what I mean when I say I have no time? :)
  23. chwe
    if we have the same naming as ubuntu, people expect the same behavior (e.g. 20.04 being then a LTS version). I would consider being part of LTS on one kernel as long as we have a proper definition such a LTS "project" (e.g. features don't get back-ported, running boards more conservative to keep the maintenance coast lower). Without clear 'rules' what people can expect from a LTS-like build and what they can not, it doesn't make sense.
  24. chwe
    I'll guarantee that it will be sufficient.. We even let US citizens write our documentation.. Honestly.. A bunch of people (including me) are not native native english speaker (and writer) so we'll never have 'the perfect' documentation.. But it's not the marketings department here writing some fancy stuff for the next hot shit.. It's that others understand how to do it. So as long as others can follow the instruction after your writing everybody will be fine with it. And if it's understandable or not can be tested by letting someone build under vagrant who didn't build before. that's just the old text we had there as well.. (but there are rumors that even some devs here sometimes build on native hosts - shh.. it's still not recommended. ) https://github.com/armbian/build/commit/da028f1ca3b4fa073e866e6d1461832f85f0254c#diff-04c6e90faac2675aa89e2176d2eec7d8L13 we just don't have that branch anymore (dev branch of buildscript).
  25. belfastraven
    @Igor, @mother, I normally build with Vagrant, and things were working fine three weeks ago. I realize that the changes that were made two weeks ago moved some files that used to be in the "build" directory to have been moved to the "build/config/templates" directory. That is , for example, where the Vagrantfile is now. I just tried going to that directory and entering Vagrant up Vagrant ssh cd armbian ./compile.sh and the build has definitely started I am not sure whether this was the intent, that is, to have people build from the build/config/templates directory. Butdoing this right now this might solve Mother's initial issues. It looks to me like a lot of the changes made were actually for Docker, and I haven't yet had time to figure out whether the whole userpatches move has anything to do with Vagrant.
  26. devman
    I'd recommend keeping Kobol's option of the little clear window w/mounting holes on the front panel for the OLED status display.
  27. rmrfmlp
    Hi adodago, sorry for the late response: this may not end up being helpful, but in the past when supplicant files for WiFi connectivity haven't worked for me I've used 'nmtui' from Network Manager to do the initial connection legwork, and then extracted the correct values out of the nmtui config files later. In my experience it's been able to connect to all APs I've tried.
  1. Load more activity