Piv Klit

  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Piv Klit reacted to milanos in SOLVED - Orange pi R1 can use to bridge mode ?   
    thanks my friend
    It's work for me
  2. Like
    Piv Klit got a reaction from pfeerick in Web page(s) redesign   
    1. How about a uploader top100 to motivate users to share bandwith with torrents ? and that way limit your bandwith use on your servers ? (if it´s a problem)
  3. Like
    Piv Klit reacted to tkaiser in Orange Pi R1   
    If that's true then this is a clear indication to better stay away from this at all (since 4.13 is already EOL this means he doesn't take care about the kernel part at all and now only thinks about an upgrade to please concerned users). More thoughts here BTW: https://www.cnx-software.com/2017/11/30/zeroshell-firewall-router-linux-distribution-works-on-x86-hardware-raspberry-pi-23-some-orange-pi-boards/#comments
  4. Like
    Piv Klit reacted to Igor in Web page(s) redesign   
    I had a meeting today and all except last two posts, since not existing at the time, were checked. In general, I was more or less presentation our pain with existing ideas how to solve this and that. Wordpress stays since they are familiar and since the problem is not there. Data will go into temp database (from GitHub config files as it comes now) that any possible search/filtering is possible, used or not. UX redesign has top priority than graphics tuneup and then backstage improvements. Estimated due ... hardly this year. Rather slow and good.
    Now waiting for the first prototype, then arguing further.
  5. Like
    Piv Klit reacted to tkaiser in Orange Pi R1   
    This whole stuff looks interesting. My only concern is the rather outdated kernels they use (for Raspberry Pi it's 4.4.50 and for the Oranges 3.4.113 -- at least I don't like to run stuff that matters with that outdated kernels)
    Sorry, but when this OPi R1 is used correctly (as a little routing device without peripherals attached) it should be almost impossible to underpower this thing even with crappy USB cables and crappy phone chargers. I tested 2 years ago with undervolting an Orange Pi PC: still booted at 4.4V but then of course both HDMI and USB peripherals got in trouble (since way below the specs: HDMI allows for 4.8V – 5.3V and USB for 4.75V - 5.25V) while the camera was still working.
    On the R1 without HDMI and USB consumers that need 4.8V minimum (without USB peripherals also minimal consumption which helps with voltage drops) and most if not all components on board 3.3V max it shouldn't really matter how crappy you power the board. We got OPi Zero with reasonable settings below 700mW (mW and not mA) so depending on how much the RTL8152 consumes I would still assume that we're talking here about less than 2.5W peak consumption (too lazy and uninterested to measure myself)
  6. Like
    Piv Klit got a reaction from guidol in Orange Pi R1   
    Oh well, we are all mad in here

    Here is my expandable IoT backend with 4 Zeros, 1 R1 and a C.H.I.P.
    Going to be expanded with some new ZeroPlus. Why ? For fun . 

    And yes openwrt is in the planing with the R1 so I can run them all away from my "private" network.

  7. Like
    Piv Klit reacted to tkaiser in Orange Pi R1   
    Today something called 'zeroshell updated:2017-11-23' appeared on Orange Pi R1 download page: http://www.orangepi.org/downloadresources/
    Curious I downloaded the image and had a look (still keen on either correct schematics or a correct hardware description. There's an additional led on this board next to the USB Ethernet MagJack and I still hope we can use a GPIO to toggle powering of the RTL8152 Ethernet chip in case it hangs).
    Guess what a surprise seeing that they use our work and rely on legacy kernel (IMO 'a bit' challenging for something with security in mind):
    root@orangepizero:/mnt/sda1# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT | grep sda sda 14.9G ├─sda4 ext4 2.1G /mnt/sda4 ├─sda2 iso9660 640M /mnt/sda2 ├─sda3 iso9660 640M /mnt/sda3 └─sda1 vfat 319M /mnt/sda1 root@orangepizero:/mnt/sda1# bin2fex OPIZERO.bin | grep corekeep fexc-bin: OPIZERO.bin: version: 1.2 fexc-bin: OPIZERO.bin: size: 35384 (84 sections), header value: 35384 [corekeeper] corekeeper_enabled = 1 root@orangepizero:/mnt/sda1# cat boot-slot.cmd setenv machid 1029 setenv bootm_boot_mode sec fatload mmc 0:1 0x500 slot.scr source 0x500 setenv bootargs ${CONSOLE} root=HD=${HD} rootwait panic=10 panic=10 loglevel=0 ${PARAMETERS} fatload mmc 0:1 0x43000000 OPIZERO.bin fatload mmc 0:1 0x48000000 ${SLOT}/${KERNEL}/vmlinuz-OPIZERO bootz 0x48000000 root@orangepizero:/mnt/sda1# cat slot setenv SLOT 1 setenv HD ZS-7D1C9C63_3.8.1A_1 setenv KERNEL 3.4.113-ARM-ZS setenv CONSOLE console=ttyS0,115200n8 setenv PARAMETERS quiet root@orangepizero:/mnt/sda4/_DB.001/LOG/2017/Nov/16/zeroshell# cat Administration Nov 16 20:50:12 zeroshell Administration: SUCCESS: System successfully started with Linux kernel 3.4.113-ARM-ZS and ZeroShell 3.8.1A  
  8. Like
    Piv Klit reacted to guidol in Orange Pi R1   
    I dont know how good the R1 is set up for the small Non-NAS-Expansionboard (2x USB, Audio/Composite Video), BUT the NAS-Board doenst seem to be made with the R1 in Mind.
    I ordered the NAS-Board for the Zero for using ist wit the R1. But it came without the metall spacer and screws
    Just putting it together without the spacers did show that a electric component will collide with one of the ethernet ports
    (see the red arrow in the picture)
    So I had to get some distance between the Orange Pi Zero R1 and the NAS-Expansionboard..
    Lucky me - I had some spare parts from 2 Acrylic OPi Zero cases laying around with some higher spacers and matching screws.
    To get more distance I used connector-extensions from/for an Arduino. Normally the Arduino has 8 pins + 6 pins - but I had to cut the 6 pin extension so fit the 5 pin width and I had to shorten the pins of the Arduino-Extensions to fit the hight of the spacers from the Acrylic case.
    For the bottom I also did use one of the Acrylic plates as foot-stand
    So this may be the first (and may be at this time the only) Orange Pi R1 with the NAS-Expansionboard "on the world"
    With the armbian-image I used before the USB-Ports on the Expansionboard do work (didnt checked by now the other ports):
    Linux opi-zero-r1 4.13.14-sunxi #12 SMP Sun Nov 19 10:35:41 CET 2017 armv7l GNU/Linux root@opi-zero-r1:~# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 058f:9380 Alcor Micro Corp. Flash Drive Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 03f0:5307 Hewlett-Packard v165w Stick Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 0bda:8152 Realtek Semiconductor Corp. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub  

  9. Like
    Piv Klit reacted to Igor in Orange Pi R1   
    Debian Jessie and Ubuntu Xenial with 3.4.113 (stable) Debian Stretch with 4.13.14 (nightly testing) 
    Bootlogs: http://sprunge.us/TZIQ
    Running AP: wlan0 IEEE 802.11bgn ESSID:"ARMBIAN" Nickname:"<WIFI@REALTEK>" Mode:Master Frequency:2.432 GHz Access Point: 08:EA:40:7C:02:B1 Bit Rate:150 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0  
  10. Like
    Piv Klit reacted to tkaiser in Orange Pi Zero Plus / H5 Chip   
    Doesn't matter, that's what the '### Installed packages' entry is for
    Since I don't understand what's happening on your installation I don't think so. You're running off eMMC, there's no SD card present, the boot environment doesn't look right and there's an older nand-sata-install.log lying around. I would need to understand this first...
  11. Like
    Piv Klit reacted to guidol in CAN I USE ORANGE PI PLUS 2 images(OS) on ORANGE PI PLUS 2E   
    As far as I can see the only difference is that the SATA Port is missing on the Plus 2E model.
    So you could try the Plus 2 images - I think it could only give a error message because of the missing SATA-Port (Controller?)
    BUT for armbian there are -  by this time - 2 different download-pages available 
  12. Like
    Piv Klit reacted to Igor in Orange Pi Zero Plus / H5 Chip   
    And updated wifi driver with fixed MAC address is coming later on to beta repository. 
  13. Like
    Piv Klit reacted to tkaiser in Orange Pi Zero Plus / H5 Chip   
    Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
    So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
    Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
    So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.
  14. Like
    Piv Klit reacted to lanefu in For helping people on other forums -- Orange PI FAQ   
    All really great points, Zador.    Honestly it was meant to be a bit tongue-in-cheek, but I tend view all the non-raspberry development boards as something for more advanced users.   
    The Raspberry eco-system is just hard to beat for newer users.   I recognize the price is a important consideration for new people as well, which is probably how many start off with allwinner-based stuff
  15. Like
    Piv Klit reacted to Icenowy in Orange Pi R1   
    P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)
  16. Like
    Piv Klit reacted to hazardsneon in Static IP setup, SSH connection but no internet   
    I haven't tried to use the browser because I disconnected the keyboard, mouse and monitor but I am now able to updgrade!
    I commented the source line now I can run "sudo apt-get upgrade" and I am now up to date.  I was not able to do this before commenting the line.
    Thanks for the help!!
    On to troubleshooting my other issues.
  17. Like
    Piv Klit reacted to tkaiser in Banana Pi Zero   
    Man, that's soooooooooo annoying. Do you know how much time it needs to support this M2 Zero IF SinoVoip would care about providing correct information? Less than an hour. It's just importing a CORRECT hardware description and then doing some MINOR adjustments. That's how it works
    Get correct hardware description from board vendor adopt/improve settings test, test, test provide general support if Armbian supports the board Step 1 is the problem. We NEVER got correct information, usually we get bogus information for whatever reasons (you call it business strategy while I would call it stupidity/ignorance) and it's the same with Zero AGAIN. If I have to ask someone who personally called me an asshole already, refuses to update publicly available information and also ensures that's there's only BS instead of technical documentation available then:
    why should a developer deal with this stuff? why should a community like Armbian think about step 4 above? If the vendor's business model is targeting only clueless consumers who do not even care about basic product descriptions being correct (even the PHYSICAL DIMENSIONS, still not fixed in their 'technical documentation') while at the same time being tricked into believing they would buy something compatible to Raspberry Pi Zero (SOFTWARE COMPATIBILITY) then why should a community like Armbian want to support these consumers and the vendor?
    Even if this M2 Zero isn't useful for any of my own use cases (anyone ever thought about WHY we Armbians spend our SPARE TIME on which devices?) I would've long added https://github.com/armbian/build/blob/master/config/boards/bananapim2zero.csc and https://github.com/armbian/build/blob/master/config/fex/bananapim2zero.fex to the build system since it's easy and fun. But impossible with SinoVoip since they refuse to provide step 1 above and even actively hinder community to support their products.
    Nothing will change until this company starts to realize that they need to replace their copy&paste monkey responsible for this gitbook mess with a technical writer and that they have to provide CORRECT hardware descriptions early and in an easily accessible way (push the stuff to github at one location, correct mistakes as soon as you're aware of it). And even then it's highly questionable why Armbian as community should start to officially support devices that are designed to trick consumers into believing full Raspberry Pi compatibility where there is none.
    BTW: I really don't know why I have to repeat this now again (especially since you call this boring). It's so OBVIOUS what's wrong with the company's behaviour and it's also obvious that they don't want to change this. It's still just a waste of time (the board I lost most of my time with in the past was the Zero's bigger sibling M2+, everything related to SinoVoip providing INCORRECT hardware information/description -- whether on purpose or caused by stupidity/ignorance doesn't really matter any more).
  18. Like
    Piv Klit reacted to guidol in Orange Pi R1   
    You're welcome! - if there is a thing in my possibilities i will try to help. 
    But Iam glad that you and the others here could help me to get my different PIs running smoothly
    Also to you: Thank you for your fast support! Many Users of the Orange Pi or H2(+)/H3 and H5 Boards will also thank you!

    The only little catch with nmtui - I got sometimes is the subnet.
    If you only insert a static IP in nmtui it will automatically add the subnet /32 ( = LOCKUP  )
    For a FAQ it would be nice to declare that the most users will have to add a /24 ( after the IP to get the
    communication working. (onlly IP-address of the Pi and not at the Gateway-/DNS-IP)
    For my OPi R1 I had to ifconfig down the USB Ethernet (the port near the TTL-serial (RX,TX,GND) and wlan0
    to get a a SSH-connect (or deactivate the connection via nmtui).
    The real eth0-Ethernetport is near the WiFi-Chip 8189ETV and the 13-pin-row and named Wired Connection 2 (at install time)
    PS: The OPi R1 Legacy Image is running much cooler on the R1 as the Opi Zero Image!
  19. Like
    Piv Klit reacted to Simon in Orange Pi Zero Plus 2 H5 OTG, Bluetooth and CSI   
    Thanks for your replies. A litte more progress by installing the debian OS from orangepi.org  (debian_jessie_zeroplus2_H5_V0_2.rar). This version enables the micro USB OTG (host mode) for use with USB hub, mouse and keyboard, WIFI worked immediately from the desktop setup. Unfortunately, bluetooth seems non-existent on this version. Having read the Armbian details on the AP6212A WIFI and bluetooth combo chip, I'm assuming the AP6212A firmware files are pretty much standard regardless of which OS is running? I don't see the firmware files even exist in the /lib/firmware/ folder for the above OS. To get bluetooth and bluetooth Low Energy working, is it a matter of configuration settings to enable the AP6212A's bluetooth function? I realize of course, the above OS is not Armbian, thought it may help with the micro USB OTG (host) setup in the Armbian OS. Any ideas on how bluetooth can be enabled, followed by bluetooth Low Energy function/setup? Thanks again....
  20. Like
    Piv Klit reacted to Igor in hostapd on orange pi light realtek driver   
    Yes, it looks armbian-config is not completely resilient to other changes ... it used to work but now it doesn't anymore. 

    Now you have to proceed manual way. temporally workaround:

    apt install hostapd cd /etc/network ln -sf interfaces.hostapd interfaces systemctl disable network-manager sed -i "s/^DAEMON_CONF=.*/DAEMON_CONF=\/etc\/hostapd.conf/" /etc/init.d/hostapd  reboot You will see: ARMBIAN / 12345678 ... Configure /etc/hostapd.conf
    Edit: it looks like this problem is affected only to Orange Pi Zero.
  21. Like
    Piv Klit reacted to tkaiser in H3 board buyer's guide   
    H2+/H3/H5 boards overview (2017/03 update)
    Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
    I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
    While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
    CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
    In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
    NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
    NAS category (only due to Gigabit Ethernet available):
    Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
    NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
    Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
    The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!  
    And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
    Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur).  Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
    Hope that helps
    Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.
  22. Like
    Piv Klit reacted to tkaiser in H3 board buyer's guide   
    Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
      Mainline kernel:   The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from kernel.org. For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far.    In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public)   BSP kernel:   So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices).   Allwinner's 1st BSP kernel variant:   Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on phoronix.com for various H3 based Orange Pi boards)   Loboris' kernel:   The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking.   Yann Dirrson's fork:   When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis.   1st Armbian legacy kernel:   Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings)   Alwinner's 2nd BSP kernel variant:   When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes.    2nd Armbian legacy kernel:   So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot.   Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default(currently exactly 112 rather large patches that add support for various hardware, new features, many fixes)   The SinoVoip experience:   While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board.   Further improvements:   In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards)   Summary:   Now a short overview about kernel situation combined with thermal/performance settings: Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example) Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)
  23. Like
    Piv Klit reacted to Richard Fortuna in Orange Pi Zero H5 Boots but no wifi   
    Oh, now THIS is bizarre!
    So, I told you I got it working with the reflash. Well, that was temporary. After transferring back to the EMMC, I opened /etc/network/interfaces to configure my network. I uncommented the line "iface wlan0 inet dhcp" and rebooted. wlan0 was gone! I opened interfaces and re-commented that line, then rebooted...and poof! It was back!
    I copied the ap6212 firmware over the brcm firmware like @martinayotte suggested, but wlan0 still is gone.
    So....I commented out the entire interfaces file except for the lo lines at the end and tried configuring the wireless using nmtui. That worked! 
    Bizarro-world. Any idea of what could CAUSE that?
  24. Like
    Piv Klit reacted to Richard Fortuna in Orange Pi Zero H5 Boots but no wifi   
    @DEHN.IO Thank you! Re-flashing to that release worked like a charm! wlan0 is back! I'll save a copy off of those firmware files like you suggest, @martinayotte, just in case I need them later. I'm sure I'll break something else later!
  25. Like
    Piv Klit got a reaction from Richard Fortuna in Orange Pi Zero H5 Boots but no wifi   
    If you do an apt-get upgrade you loose the wifi, the image called Armbian_5.27.170601_Orangepizeroplus2-h5_Ubuntu_xenial_dev_4.11.1 works fine and I have it running on EMMC for 19.8 hours and getting close to 250.000 MQTT calls without problems. I used a cheap serial board called CJMCU CP2102 MICRO USB to UART TTL from aliexpress to connect to the board through PUTTY

    And I'm powering it up with GPIO 4 (5volt) and GPIO 6 (Ground)