All Activity

This stream auto-updates     

  1. Today
  2. I don't know if I can help to solve this problem, but I can try. I want compile the kernel 5.07 because it's working on orangePi3, an then compile again the last 5.1.3 comparing with previous, in order to found the problem and share here the possible solution. I think that it's only a kernel module that create the bug.
  3. OT Igor, where i can get/buy some Cups for coffee like these? Markus
  4. Well, then I would say: Le Potato
  5. mostly its better to use a USB-WiFi Dongle - specially on OrangePi - for me the worst WiFi Chips onboard.
  6. I was unable to find many reviews about the K1 plus but I will definitely look into it.. What is your experience regarding on board wifi on these boards (orange, banana or nano) in general? Reliable? Or better off with a usb dongle?
  7. a good start - I think - would be the NanoPi K1 Plus has - 64bit SoC (well supported H5-CPU - also cool running) - 2GB of RAM - WiFi - HDMI (but no 4K) Wth 1GB of RAM there is also the OrangePi PC2 - but no WiFi
  8. I have a local OpenVPN server on Banan Pi M1, with latest armbian. I tried to replace with OrangePi3 but current results is disappointing iperf3 results on Banana Pi M1 OpenVPN server Connecting to host, port 5201 [ 4] local port 46250 connected to port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.69 MBytes 14.1 Mbits/sec [ 4] 1.00-2.00 sec 1.81 MBytes 15.1 Mbits/sec [ 4] 2.00-3.00 sec 2.43 MBytes 20.4 Mbits/sec [ 4] 3.00-4.00 sec 681 KBytes 5.58 Mbits/sec [ 4] 4.00-5.00 sec 1.99 MBytes 16.7 Mbits/sec [ 4] 5.00-6.00 sec 1.33 MBytes 11.2 Mbits/sec [ 4] 6.00-7.00 sec 1.55 MBytes 13.0 Mbits/sec [ 4] 7.00-8.00 sec 1.62 MBytes 13.6 Mbits/sec [ 4] 8.00-9.00 sec 1.33 MBytes 11.2 Mbits/sec [ 4] 9.00-10.00 sec 1.76 MBytes 14.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 16.2 MBytes 13.6 Mbits/sec sender [ 4] 0.00-10.00 sec 15.7 MBytes 13.2 Mbits/sec receiver iperf3 results on Orange Pi 3 OpenVPN server Connecting to host, port 5201 [ 4] local port 41583 connected to port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 621 KBytes 5.09 Mbits/sec [ 4] 1.00-2.00 sec 868 KBytes 7.11 Mbits/sec [ 4] 2.00-3.00 sec 1.18 MBytes 9.89 Mbits/sec [ 4] 3.00-4.00 sec 1.16 MBytes 9.75 Mbits/sec [ 4] 4.00-5.00 sec 1.02 MBytes 8.53 Mbits/sec [ 4] 5.00-6.00 sec 966 KBytes 7.92 Mbits/sec [ 4] 6.00-7.00 sec 726 KBytes 5.95 Mbits/sec [ 4] 7.00-8.00 sec 676 KBytes 5.54 Mbits/sec [ 4] 8.00-9.00 sec 2.58 MBytes 21.7 Mbits/sec [ 4] 9.00-10.00 sec 4.78 MBytes 40.1 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec sender [ 4] 0.00-10.00 sec 14.0 MBytes 11.7 Mbits/sec receiver As you can see, connection via OPi3 is slower, but more than that, it is unstabe and fluctuating from 5-8 MBit/s to 40 MBit/s What can I tune to improve openvpn connectivity?
  9. Hi, The OrangePI Plus 2 has 2 video output : HDMI and composite. I wander if it would be possible to use independantly these output : My goal is to have a media player on the HDMI (Kodi ?) and, at the same time, the composite image used to display my smarthome dashboard ? Thanks Laurent
  10. Ok I thought I was on the debian image but it was ubuntu. So sorry for this.
  11. Uploaded a new version of multi-start activation to the site (n2_autoscript).
  12. Our defaults. I recently re-add adjusted conf, but it will remain disabled by default.
  13. OK, so maybe its a wierd combination of hardware/software incompatibilities. I can live with slowness I get now, since its much faster than when I first started. I will try to play with network setup to see if I can improve something. I really dont want to run FAs kernel just tried it to compare, to see if its a HW or OS problem. Thats why I'm here asking for help. Thanks for now! I will update here if I find a solution, for knowledge.
  14. Not with this board/kernel combo. We have a policy to not help users trying to use development/preview builds for real. Why? They are full of problems, not just the one you found and we simply don't have resources dealing with boards and you finding problems on boards and seeking help. Over and over again. It is not possible. We will not pay for months of time lost for /dev/null and you also don't. We would need to waste hundreds of hours every day to catch up while only telling you this: If you seek for a solution in development areas stop doing ... what you are planing to do. If you plan to learn something and you don't care much about the problem you have, then proceed. If you are willing and capable to help, welcome.
  15. yes finally it worked (with jemp script, maybe with tocgen also not tested yet...) you have to write the keys only little endian instead big endian
  16. Hello guys, I'm new to SBCs in general and would like to start tinkering around a bit. But am not able to find a central resource with reviews and such. So have decided to ask the question here (moderators please feel free to move the thread around) I am looking for a SBC in the 30 to 35 or upto 40$ price range with a bare minimum of the following : 1. 64bit SoC 2. Atleast 1 GB RAM (pref 2 GB) 3. Wifi on board (or are wifi dongles a better option?) 4. 1080p out by hdmi.. Preferably 4k.. I read enough to understand that manufacturers other than Raspberry are not great with OS support or optimisation.. So I am looking for something that runs Armbian well or will run it well enough in the coming months (Had my eyes on the Orange Pi3 but I read about a lot of issues with H6 boards with compatibility and heating?)..
  17. After installation, /etc/apt/apt.conf.d/50unattended-upgrades is empty. What is the proper origins to automatically install at least security patches?
  18. ... or nightly builds. It will soon be pushed to stable repository since there seems to be no reports on problems. Here
  19. Hi, I've tried the same for a while with TBS5580 (dvb-s2/t2/etc usb card) for tinkerboard running ambrian kernel 4.4.y I've used TBS github repo for V4L drives which seems has extra TBS open source drivers added to V4L, but straight building and loading modules did not work - I've got kernel panic containing [ 13.721533] PC is at dvb_usb_fe_wakeup+0x20/0x60 [dvb_usb] [ 13.723656] LR is at dvb_frontend_init+0x28/0x74 [dvb_core] etc. It seems that since 4.4 there were changes in dvb-core and/or dvb-usb making just separately compiled driver modules sometimes not working for older kernels. Therefore in kernel config CONFIG_MEDIA_SUPPORT=y should be CONFIG_MEDIA_SUPPORT=m to support dvb-core as a module rather than "build-in". This allows replacing the "original" dvb-core.ko with dvb-core.ko build fom V4L pack, otherwise there will be a conflict. So you may need to compile kernel (unless CONFIG_MEDIA_SUPPORT is already set to "m" for your board and you already have "stock" dvb-core module) Also (note that this is relevant for my experience, but may apply to you): - there were changes in Kconfig language and "imply" used in one of Kconfigs in /drivers/media does not allow using make menuconfig (for rockchip's 4.4 at least), so I just replaced "imply HWMON" with "select HWMON" in that Kconfig, anyway that driver required higher kernel version - backports patch 4.4 is not needed for rockchip's 4.4 - building the driver it patches will break, so either deselect that driver or comment out the patch in backports.txt with # - I would be careful using make install since it will remove all original media modules including vendor specific, but would manually copy/replace only needed ones and run depmod thereafter PS: I've used ambrian build in VM for kernel, but build V4L on tinkerboard itself to avoid thinking on cross compilation
  20. Unlikely, but possible that some values in the NIC driver are not fine tuned due to hw quality issues (not an Armbian problem) - similar did happened on some boards. There is nothing in the logs, I am not able to reproduce and there are no other reports ... there is little to go on with. Something with your network? It could be just bad cabling? Change them. But you are fine with overall low quality kernel which is hard to rebuild and (will not/never did) receive no security nor functional update? And you are fine that Dietpi, which adds no value to hardware functionality, is spying on you OOB? And with series of security holes that are made in the conversion to something? People are running Kubernetes/Docker clusters with this board running Armbian. Fire3 is most appropriate (best bang/$) and no one ever reported network sluggishness.
  21. I forgot to write in the first message about eMMC that I always create partitions with an offset of 4M. New test results. Added files to the images to install the system in eMMC. Checked the Armbian installation with kernel 4.9. Everything was installed and when you restart properly run system from eMMC. Further an interesting outcome. The system startup from USB stopped working. Running from SD card works. When installed on eMMC, only system files were copied, u-boot did not copy. When clean the first 4M for eMMC, start with USB again earned. Now I have collected new images with the addition of the installation script in eMMC and a new option to activate multi-boot (changed the order of polling MMC), now the order of polling boot such 1. USB 2. SD card 3. eMMC. This ensures that the external system starts from USB\SD if there is a breakage with the start-up from eMMC.
  22. This patch is included in -next already? I can test it with BananaPi M1. ::edit commit messages seems to confirm it is in -next. Bleh, more like in -dev. I need more coffee... ::edit2 4.9.38 (next), only one test made. fs: btrfs random random kB reclen write rewrite read reread read write 102400 4 3951 5919 14107 14547 1337 4955 102400 16 9908 14394 17473 32988 3338 10818 102400 512 26440 27888 62459 73201 31875 30057 102400 1024 26543 29481 61408 74973 36113 28225 102400 16384 30315 34723 57029 109099 103228 38344 5.1.0-sunxi #5.86 SMP Mon May 13 21:11:09 CEST 2019 armv7l GNU/Linux (3 tests made) fs: btrfs random random kB reclen write rewrite read reread read write 102400 4 6056 7318 19250 19427 1376 4393 102400 16 16210 16483 42932 45765 5118 16473 102400 512 57882 44149 58178 69361 38018 61066 102400 1024 49587 55798 51267 78644 45696 63254 102400 16384 30345 66470 64869 82639 80843 58395 random random kB reclen write rewrite read reread read write 102400 4 5115 5813 18911 17605 1259 5124 102400 16 16791 20273 18971 38345 4750 13755 102400 512 36974 56462 62740 80449 33872 62893 102400 1024 44808 34004 51920 83809 43962 66327 102400 16384 57777 47181 44560 78107 79185 53640 random random kB reclen write rewrite read reread read write 102400 4 4989 6186 16698 16474 1138 3173 102400 16 11646 10015 38828 42461 4455 15354 102400 512 47299 49030 57053 82134 29582 61737 102400 1024 45468 35288 58417 81450 32958 64807 102400 16384 55345 65883 78657 99487 104514 56825 This was made on 1TB spinning rust: Device Model: ST1000LM035-1RK172 User Capacity: 1,000,204,886,016 bytes [1.00 TB]
  23. OK, so here are my findings: I was able to use a previous version of Armbian. Then I went back to the newer version and it worked! But, there is a difference: Last time, I did all the connection to NanoPi using a Windows laptop, directly connected to the NanoPi. This tine I was using an older Linux netbook, also directly connected to the NanoPi (ethernet cable). I am suspecting this has has to do with the ethernet speed, as my older Netbook has a slower 100mbps NIC, and my laptop has a 1000mbps NIC. I then connected it again to my newer laptop and the sluggish response was back. So I played a bit with the NIC speed, and as I lowered it, the responsiveness was better, but still not perfect. Lastly, I connected it to my 1000mbps switch, and while it is usuable, it is sluggish to respond: For example, when running ´htop´ on an idle system, the uptime sometime freezes, jumping 2-5 seconds. As I mentioned before, all this behaviour didn't happen with other images I tried. I suspect that maybe there is a wrong configuration of NIC on Armbian (at least on last version, I haven't had the time to go back again to earlier version and test it again connected to the switch). Maybe it has to do with tx offloading like I read some other board have problems with? Armbian monitor logs are here: BTW: The memory chips are NOT from the problematic numbers. Thanks for your help!
  24. Yesterday
  25. OK after a long and painful investigation with pine64 and other people doing distributions for them + members of the community, the problem is that by default the memory runs "full" speed which is way above specs, as it should be running at 800 MHz max. We need the dmc driver and being able to setup the max clock for the memory to run these boards in good conditions.
  26. It should be possible to use a SPI CAN module, as long as you can get the SPI interface enabled and the kernel driver loaded. I imagine you'll need to do something with the device tree to enable it. I don't know if the default kernel has the mcp2515 driver built in though. You may need to compile your own kernel module or kernel. Edit: I see Igor has already posted how to enable SPI
  1. Load more activity