divode

  • Posts

    15
  • Joined

  • Last visited

Reputation Activity

  1. Like
    divode reacted to tkaiser in Quick review of Orange Pi PC   
    Unfortunately even 'branded' PSUs can start to burn so I would both try to reduce the count of PSUs used and always choose their location carefully to avoid flammable stuff around. That's one of the reasons why we choose passive PoE for a bunch of Orange Pi PC: Use one regulated quality 24V PSU and provide power through the 2 unused Ethernet cable pairs to the board where a step-down converter injects 5V through the GPIO pins.
     
    Regarding consumption it depends on the use case as you already said. As can be seen on page 1 of this thread (the review) you can limit maximum consumption to ~500mA pretty easily by using optimised dvfs/cpufreq settings.
     
    In normal useage scenarios it's not that easy to let the board consume more than 1500mA alone (given you use the sane Armbian settings and not the ones found in Orange Pi forums) but USB peripherals add to this when not being behind a powered hub so take this into account since then consumption might exceed 2.5A and you should better use a 3A/4A rated PSU that shows stable voltage.
     
    The most important thing regarding PSU amperage ratings is mostly misunderstood: Voltage drops when consumption increases (see this nice example and especially the footnote regarding Micro USB fortunately avoided with all Orange Pis). Most Orange Pi PC components work still if DC-IN drops to 4.5V but both HDMI and USB peripherals do not tolerate voltage drops below ~4.8V so get a PSU that can handle this.
     
    BTW: The best variant to run in all sorts of annoying troubles is to use both a crappy PSU and a crappy SD card. This will ensure the worst user experience ever
  2. Like
    divode reacted to tkaiser in Quick review of Orange Pi PC   
    It's possible to both overvolt the CPU and undervolt the board
     
    These are two different things. You define in the so called dvfs table a few operating points with a relationship between CPU clockspeed and voltage provided to the CPU cores. The basic principle is that you define the Vcore voltage as low as possible since this helps with consumption, temperatures and longevity. But the problem is that if you need higher clockspeeds you also have to increase the Vcore voltage to still let the chip run reliably.
     
    There exist some recommended values from Allwinner for every SoC ("Vcore not lower than 1.04V and not higher than 1.2V for example") and responsible vendors follow these advices. Most H3 devices (OTT boxes) come with a dvfs table only containing 2 operating points:
    1200 MHz @ 1.3V 1008 MHz @ 1.2V This is OK and leads to a Vcore voltage of 1.3V when clocked at 1008 MHz or above and 1.2V when running slower (most devices are configured to clock lower when idle and to increase clockspeeds only under full load -- and only then Vcore increases also). Xunlong then simply stayed with 2 operating points and increased both cpufreq and Vcore voltage (necessary to reach the 1.53 GHz they advertise as "1.6 GHz"):
    1536 MHz @ 1.5V 1200 MHz @ 1.3V That means the H3 is always volted with the maximum all other devices use (1.3V) and if clockspeeds exceed 1200 MHz even with 1.5V (0.1V above the recommended upper limit). And this overvolting is the root cause for all the thermal problems Orange Pi users experienced in the past. I tried to document the overvolting/overclocking history here.
     
    Regarding DC-IN it's something different. There you should supply 5V but since many USB cables are simply crap and micro USB has very tiny contacts you might run in undervoltage situations easily (DC-IN dropping below 4.6V or even lower). SoCs that are accompanied by a PMIC/PMU will be powered-off in such a situation by the PMU to prevent damage. The Orange Pi PC has no PMU but a few voltage regulators that might work even with 4.5V. But for connected USB peripherals or HDMI this is already way too low. Therefor the barrel plug the Orange Pi's are equipped with is an advantage compared to boards that use [micro] USB since you've to consider that DC-IN also has to provide power to external USB devices and other board components.
     
    And as you can see above it always depends. When you want to use the Orange Pi PC just as a headless server and let it run at 1.2 GHz with a sane dvfs table the whole board's consumption won't exceed 3.5W so 5V/1A would already be enough. In case you attach 4 bus-powered USB drives even 5V/3A won't suffice (you would've to study the schematics or simply try it out to get a clue where the limits are)
  3. Like
    divode reacted to tkaiser in Quick review of Orange Pi PC   
    This "up to 1.6 GHz" marketing chitchat is the source of all the heat problems the H3 is blamed for. But you can simply fix that by using better dvfs entries. In the meantime the linux-sunxi devs developed a dvfs table and thermal values (throttling and in case of emergency shutting CPU cores down) that work even without a heatsink in most situations.
     
    Every Raspberry Pi has just a single USB 2.0 connection to the outside. All USB ports and network have to share this: http://linux-sunxi.org/Sunxi_devices_as_NAS#Network.2Fstorage_not_blocking_each_other
     
    Given that we will see rather sooner than later the H3 being supported by mainline kernel (at least for the headless stuff you're talking about) the OPi PC might be worth a try (4 independent USB ports and also independent 100 Mbits/sec networking). Regarding encryption: Allwinner SoCs do contain a crypto engine called 'Security system' still being work in progress in mainline kernel: http://linux-sunxi.org/Mainlining_Effort#Major_drivers
     
    But even without that the H3 should outperform any RPi 2 in your setup due to better I/O and network bandwidth. The H3's integer performance when clocked at 1.2 GHz is also better than the BCM2836's (even when clocking the latter with 1.0 Ghz which should work flawlessly even without a heatsink).
     
    The RPi 2 is superiour in different areas due to driver support (both GPU and VPU) but as long as it's about integer performance and bandwidth (both I/O and network) the H3 wins. 
  4. Like
    divode reacted to tkaiser in Quick review of Orange Pi PC   
    Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong.
      The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning.   Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus').   The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub")   In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs).   The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably.   Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3). So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3. Igor started already to support the H3 based Orange Pis in Armbian-- see below.   Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki.   Getting started   To power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery)   In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!)   Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well)   On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair:     If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsink   Since we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI).    Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me.   I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!)   Consumption/temperatures in headless mode:   The OPi PC idles at 240-600MHz: 1.5W, 20°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC.   Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores:   240 MHz: not exceeding 2.0W, 25°C above ambient temperature 600 MHz: not exceeding 2.5W, 32°C above ambient temperature 1200 MHz: not exceeding 3.3W, 50°C above ambient temperature   2 CPU cores deactivated and testing again:   240 MHz: not exceeding 1.9W, 23°C above ambient temperature 600 MHz: not exceeding 2.1W, 29°C above ambient temperature 1200 MHz: not exceeding 2.8W, 40°C above ambient temperature   The multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense.   Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load: echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq   With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed.   Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago.   Camera module   Xunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module:     The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion.   Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3°C (clocked at 240-600 MHz)   For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy.   Other use cases   Regarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS   At the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely:   OpenELEC HW accelerated video decoding   RPi-Monitor   I adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums.   All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot:  cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.