tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
GPU/Mali has nothing to do with video -- GPU is just 2D/3D acceleration.
Forget about playing youtube stuff and something like this. Your best bet is to follow these instructions: http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect&goto=findpost&ptid=723&pid=7286&fromuid=29411
Should work with A20 too.
-
Running Android you are able to use GPU/VPU with HW acceleration and the ARM cores aren't used that much. Unfortunately linux is a different story and you'll come across users that really like to benefit from the 'quad-core A53 at 1.2GHz' since you advertise this as an SBC. Then you probably realise the difference (Allwinner SoCs aren't fast but cheap. Since the A64 is said to be able to be clocked up to 1.2 GHz I would suspect it's rather slow compared to other A53 designs and produced in an inefficient
28nm40nm process)Regarding benchmarks: They're all wrong. A good starting point when it's only about CPU performance is http://slideshare.net/brendangregg
But in your situation there's something special: Since you focus on Android CPU performance doesn't matter that much. It's GPU/VPU performance and the former definitely sucks (Mali400MP2 -- old and slow). But most people won't realise that since they focus on irrelevant metrics like "64 bit is twice as much as 32 bit" or "2 GB RAM is twice as much as 1 GB" or "15$ is less than $16" even if they can't tell how that really affects their use cases. You're lucky guys
But in case you really want to provide a good 'Linux experience' there's a lot to do.
-
BTW: I read through your FAQ on kickstarter and I hope this is just marketing chitchat: "4Kx2Kp30 H.265 decode, and 1080p60 H.264 high-profile encode and decode" have nothing to do with the GPU but are provided by Allwinner's video engine.
And you might be surprised how high power consumption might increase when settings are tweaked and how capable larger heatsinks used in tablets work in reality.
Do you made any real benchmarks already or just dubious 'MIPS'? In case you really use MIPS/MFLOPS (AKA the most useless benchmark ever invented) and compare with a PS3 and an AMD CPU it's questionable whether you understand the performance implications at all
-
Currently we requesting open source community to participate and help to bring up Linux BSP to Ubuntu. Please let us know if you are interested.
In what are you interested?
Paid consultancy to 'bring up Linux BSP to Ubuntu' (quite easy: simply fix the BSP you got from Allwinner here and there and add any Ubuntu rootfs you find somewhere on the net. Then you've fulfilled what 'the community' already expects: just another broken OS image for a new Allwinner SoC without 2D/3D acceleration and no HW accelerated video encoding/decoding)?
Or should the community do this job for free and hack together such an annoying OS image?
-
Small follow-up since now I'm really done with the device.
Today I soldered a barrel plug to the M3 since I had way too much sudden power-offs resulting in a corrupted SD card (only filesystem): http://forum.banana-pi.org/t/voltage-drops-on-dc-in/846 (note to myself: never ever buy any device that uses the crappy micro USB for DC-IN)
Using a sane DC-IN solution I was able to test a bit more and had to realize that it's not a bug but a feature that you're not able to clock the M3 constantly above 1.2 GHz since otherwise it would just power-off when using it in a 'normal way' (in my test scenario I had most of the times only Ethernet and a serial console connected): http://forum.banana-pi.org/t/bpi-m3-battery-charging-capability/848/12?u=tkaiser
Good news regarding kernel compatibility: Allwinner's 3.4.39 kernel for H3 (Orange Pi's) and A83T (the unfortunate next Banana) shares large portions of code (it seems everything that's not hardware related). So you're not totally lost (having to rely on SinoVoip) but can benefit from community's work. Today I 'stole' some of the enhancements H3 users made and applied them to the M3's BSP: http://pastebin.com/xvJ04Pi2 -- seems to work.
I added the stuff to the preliminary OS image I had to use last week to be able to test (all SinoVoip provided OS images broken more or less) where I also relied on the H3 community. Just have a look into the readme: http://kaiser-edv.de/tmp/2m8dxM/
-
If you experience heat problems, then drop the case. It will not work and heatsinks inside a small enclosure are pretty useless since heat dissipation will be prevented by the enclosure.
I made a few tests a year ago and came up with large enclosures that ensure enough airflow. Small enclosures won't work.
And I don't know whether these temperatures are critical or not. There are SoCs available (like the one used on LeMaker's barrel burst called Guitar) that exceed easily 100°C without problems. But I would try to get a clue whether you're in an overvoltage situation (hard to tell since I donated my M2 to the linux-sunxi community half a year ago and can't have a look myself). Unfortunately that's not that easy with mainline kernel (at least it's a lot more easy with older Allwinner kernels where you could start with something like 'find /sys -name "*volt*"')
-
Another update regarding software / OS images. In the meantime they released a few more images: http://www.banana-pi.org/download.html
As usual without MD5/SHA1 checksums so you can not check whether your download is corrupted or not. But even if they would provide checksums it won't help since SinoVoip simply doesn't give a sh*t about anything other than selling hardware. Numerous downloads are corrupted (see here or here or here) and they simply don't react even if customers complain multiple times.
At the moment they are also clueless how to flash a Linux image onto eMMC using FEL mode (this only works with the Android images using PhoenixSuit/LiveSuit) so in case you want to start a Linux image from the internal eMMC storage you would have to first flash it to an SD card, then boot from this card, then transfer the image using dd to /dev/mmcblk1. I did it through the network as follows:
ssh tk@macbookpro-tk "dd if=/Users/tk/Downloads/ubuntu-mate-15.10-desktop-armhf-raspberry-pi-2-bpi-m3-sd-emmc-20151203.img bs=4m" | dd of=/dev/mmcblk1
Three times dd quit unexpectedly while writing to eMMC, then I simply lowered the maximum cpufrequency down to 1008 MHz and it worked. Seems there's a bug when writing to eMMC so be prepared to experience filesystem corruptions if you're booting from eMMC. At least you can use eMMC this way, the M3 boots from there when no SD card is present.
I tried then their Ubuntu 15.10 image and had a laugh: They ship with enabled irqbalanced! It's a well known fact that irqbalancing doesn't work on ARM based SBCs and has a memory leak on platforms that lack PCI/PCIe. So be prepared that irqbalanced will eat up all your RAM over time and then the whole system has to be rebooted. It's completely weird to release an OS image for an ARM SBC with an enabled irqbalanced.
Now they ship also with a small script called bpi-bootsel (source here) which can be used to overwrite the 1st sectors of the boot media to change the display resolution (all their images based on Allwinner's 3.3/3.4 kernel for Banana Pi M2/M3 still lack support for script.bin!). In /usr/lib/u-boot/bananapi/ there exist 2 subdirs with a few handpicked archives to provide a few display configurations (details here). And while this is a small step in the right direction it also means they do it still wrong since they're continually fixing critical bugs for the M3 that should also be applied to the 1st sectors (there's where u-boot, hardware initialisation and a kernel image lives -- don't expect this stuff being easily accessible in /boot/).
In other words: The new OS images they provide now are already outdated and cut-off from important fixes they commit in the meantime to their BSP github repo.
Just a few words regarding the BSP: The initial Readme.md was just wrongly copy&paste from the Banana Pi M2 and of course misses the most important information: How to setup a build environment (details here).
Back to the OS images. I dropped Ubuntu 15.10 since I already have my own image upgraded (apt-get install update-manager-core && do-release-upgrade sometimes works as expected
). Then I tried their so called "Armbian 4.7" image: It's the same outdated u-boot/kernel stuff missing the last fixes combined with a crippled Armbian rootfs. Of course nearly all Armbian features don't work and it's not worth the time to further explore this crap. They did not even adjust the thermal read-outs or prevent kernel messages from spamming to console as it will happen from time to time when thermal throttling occurs -- see their own image below.
It seems it's as with the M2 half a year ago and as a Banana Pi M3 user you'll have to wait until the community jumps in and provides OS images that aren't that crappy. Close to unbelievable but unfortunately true.
-
Irqbalanced is on any SBC just a waste of ressources and the reason you either have to restart the daemon or the whole board from time to time. It simply does nothing except of wasting CPU ressources and eating up all your RAM over time.
Simply compare with the output of 'cat /proc/interrupts'
I had a good laugh when having a 1st look at SinoVoip's OS images for the Banana Pi M3: Of course it's enabled and will take a few days to completely use the 2GB of the board
Regarding H3: Mainlining efforts are quiet fast and I believe it will be useable for headless stuff in Q1/2016.
And regarding the 60°C on your M2: Since I do some research in this area at the moment, it would be interesting how your cpufreq settings are (which governor? performance or interactive?) I ask because all A31/A31s devices share these dvfs settings:
operating-points = < /* kHz uV */ 1008000 1200000 864000 1200000 720000 1100000 480000 1000000 >;200 mV more or less might make a difference regarding both temperature and consumption. And maybe further voltage decreases might help (but it would be time consuming to get there: http://linux-sunxi.org/Hardware_Reliability_Tests )
And it might be also interesting if a display is connected or not. At leat on A20, H3 and A83T the video engine will be completely shut down when no display is connected which leads to a difference in SoC temperature of ~4°C
-
Powering via micro USB is a desaster... with only LAN connected the board is booting by luck, with additionaly HDMI connected the board will not power up at all...
To be expexted. Most likely you ran into the usual undervoltage problems many/most USB cables suffer from. And the connector itself is simply crap. On top of that means powering through USB a different power scheme compared to DC-IN (the PMU of the M2 can be fed through LiPo battery, USB or DC-IN).
Regarding the C1: Maybe you ran just into the common irqbalanced problem (eating up all RAM and CPU and let the machine freeze after some times). And instead of pasting huge amounts of log messages into a forum you could use an online pasteboard service like pastebin.com or even more convenient:
dmesg | curl -F 'sprunge=<-' http://sprunge.us
Finally: a bit sad that I missed your post from a few days before. I would've recommended an Orange Pi Plus2 instead. The USB-to-SATA bridge is crap but twice as much RAM and onboard 8GB eMMC being much faster than the limited SDIO implementation on A31s. Also cheaper than the M2 (that contains an already discontinued SoC since it started shipping half a year ago)
-
Update 3 days later: SinoVoip's software/support is worse than ever before:
- They're still busy fixing essential things long after sales have started: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master
- They close Github issues without investigation: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/3
- They close Github issues without even reading/understanding them and answer pure nonsense to questions: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/4
- They provide a faked Armbian image: http://forum.banana-pi.org/t/bpi-m3-new-image-armbian-v4-70-30-11-2015-for-bpi-m3/
- Their own images don't boot: http://forum.banana-pi.org/t/bpi-m3-new-image-ubuntu-mate-15-10-for-bpi-m3-20151203/817
- Still no MD5/SHA1 checksums to verify download integrity. But it wouldn't help if there were any since even if they provide an MD5 hash, they upload corrupted images at the same time but don't care about. They simply don't give a sh*t about anything else than selling hardware.
If you buy any product from this vendor be prepared that software/support will be catastrophic.
-
A83T isn't supported since for this SoC there exists only an old Allwinner 3.4.39 kernel and it's not worth the efforts to provide full Armbian support since mainline kernel support for the SoC is just in very early stages.
Regarding A83T you might want to read http://forum.armbian.com/index.php/topic/474-quick-review-of-banana-pi-m3/
Regarding Mainlining Efforts search here for the SoCs you're interested in: http://linux-sunxi.org/Mainlining_Effort#Merged_into_4.4
Good news regarding R8: http://free-electrons.com/blog/free-electrons-chip-nextthing/
-
Overview
(Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time
)
EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source)
SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki.
This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC.
Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care
Getting Started:
The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off.
Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3).
To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show.
One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also).
First Showstoppers:
Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works.
But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin)
First Impressions:
Heat (dissipation):
The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you
have tocan't bring them back online manually the usual way since Allwinner's kernel doesn't allow so:echo 1 >/sys/devices/system/cpu/cpuX/online
Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds.
This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead:
CPU performance:
Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink).
Network throughput:
I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below):
BPi-M3 --> Client:
[ 4] 0.0-10.0 sec 671 MBytes 563 Mbits/sec [ 4] 0.0-10.0 sec 673 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 870 MBytes 729 Mbits/sec [ 4] 0.0-10.0 sec 672 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 675 MBytes 566 Mbits/sec
Client --> BPi-M3:[ 4] 0.0-10.0 sec 714 MBytes 599 Mbits/sec [ 5] 0.0-10.0 sec 876 MBytes 734 Mbits/sec [ 4] 0.0-10.0 sec 598 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 690 MBytes 578 Mbits/sec [ 4] 0.0-10.0 sec 604 MBytes 506 Mbits/sec
When I used longer test periods (-t 120) then the "Client --> BPi-M3" performance increased up to the theoretical limit: 940 Mbits/s. Then a second iperf thread jumped in, both utilising a single CPU core fully. And that's the problem: Networking is CPU bound, a single client-server connection will not exceed 500-600 Mbits/sec as it was the case when I started with A20 based boards 2 years ago. Since all we have now with the A83T is an outdated 3.4.39 kernel and since I/O bandwidth on the M3 is so low, I stopped here since it's way too boring to try to improve network throughput and also useless (disk access is so slow that it simply doesn't matter when Ethernet is limited to half of the theoretical GBit Ethernet speed... at least for me
)
Accessing disks:
Since there's a SATA connector on the board I gave it a try.
Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!).
I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable:
GL830 USB-to-SATA performance: 480 MHz: kB reclen write rewrite read reread 4096000 4 13529 13466 22393 22516 4096000 1024 13588 13411 22717 26115 1.8 GHz: 4096000 4 15090 15082 30968 30316 4096000 1024 15174 15131 30858 29441I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell.
I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM).
Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse:
GL/JM: kB reclen write rewrite read reread 4096000 4 17800 17140 14382 16807 4096000 1024 17741 17258 14493 14368 JM/ASM: 4096000 4 19307 18458 22855 26241 4096000 1024 19231 18518 21995 22362If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better.
SD-card and eMMC:
Just a quick check with the usual iozone settings running @ 1.8 GHz:
kB reclen write rewrite read reread eMMC: 4096000 4 26572 27014 59187 59239 4096000 1024 25875 26614 56587 56667 SD-card: 4096000 4 20483 20855 22473 22892 4096000 1024 20526 19948 22285 22660LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too.
EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s
Other issues:
- If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC
- Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue
- Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s)
- Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken)
Conclusion:
Still no idea what to do with such a device.
Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead).
Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one).
And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV
Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis.
But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important!
Armbian support:
Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly).
Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.
-
I found it quite interesting the Banana PI M3, however the block diagrams seems to show the SATA interface is connected to the USB bus. Has someone the experience of using it?
Now I can since my M3 arrived this noon: It's slow as hell: 13 MB/s write and 23 MB/s read. I will ask whether some Orange Pi Plus users made better experiences (uses also the GL830 but not behind the internal 4-port-USB hub) to confirm this disaster. With mainline kernel and a good USB enclosure you're more than twice as fast and being able to use SATA on A20 boards it's 3.5-10 times the performance (write/read).
-
Ok, i tried, but i think i's too much difficult for me. I believed that i coud.
I would like to have a system (with my OrangePI) like a media center (i.e. Kodi) but i can't. Maybe OrangePi PC is faster (or better)
Neither better nor faster. Just different and limited. There's an overclocker's forum that will tell you quite the opposite but it's not true unless you fry your device all the times.
If you want a media center, then the important stuff happens in different SoC regions than the CPU (HW accelerated video decoding --> VPU). Simply use Android and you're done. There this stuff works. You might also try out Igor's Ubuntu Trusty (desktop) image or this here: https://blog.eldajani.net/banana-pi-arch-linux-customized-distribution/(works on your A20 based Orange Pi since it's the same. The Orange Pi vendor claims he also designed the Banana Pi and in the meantime I believe it's true: http://web.archive.org/web/20151129140451/http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=663&extra=&page=2 )
-
Interesting. If you mind my asking, what do you have any idea if the orange pi 2 octa core is any good?
Pardon? As far as I know they have 4 devices:
3 shipping in different variations and a new one using the H64 (slow Cortex-A53 quad-core, but "64-bit" -- the overclocker crowd over there will love it)
- A20 based "Orange Pi" and "Orange Pi Mini"
- H3 based with external GBit Ethernet PHY using a crappy USB-to-SATA bridge and an internal USB hub limiting performance
- H3 based relying on the internal 100 Mb/s Ethernet PHY (the Orange Pi PC the only interesting one since it features access to 4 USB ports)
- H64 based "Orange Pi 3" in development
All variants quite unimpressive except of the "OPi PC" due to its low price and the 4 available USB ports. I've to wait until my 2nd OPi PC arrives together with a camera module and then I'll write a review here.
Update: A new H3 model -- Orange Pi One -- has been announced: http://www.cnx-software.com/2015/11/26/raspberry-pi-zero-is-a-5-board-based-on-broadcom-bcm2835-processor/#comment-504411-- I hope they do not save Ethernet port and camera connector.
-
Not working as expected: http://forum.banana-pi.org/t/is-sata-working-on-any-of-the-m3-images/776
The GL830 USB-to-SATA bridge used there is the worst choice ever (slow, crappy,
obviously with a 2 TB limitation). SinoVoip sends me a review sample and I'll report here soon: https://nolp.dhl.de/nextt-online-public/set_identcodes.do?idc=7214605425BTW: I started already with a wiki page for this weird device: http://linux-sunxi.org/Banana_Pi_M3
-
The orange pi mini is shown prominently on the downloads page, yet this thread suggests it's not supported.
Nope, Xunlong designed a few A20 boards (Banana Pi, Lamobo R1, Orange Pi and Orange Pi Mini). These are fully supported by Armbian due to its SoC and the state of software support for the SoC.
Then they started with H3 boards that are all more or less the same, the OPi PC being the first interesting one (since the H3 is made for dirt-cheap systems without that much additional components on the PCB and the OPi PC being the 1st such a design -- all other H3 based Orange Pi are bloated with additional components). We won't have Armbian support for H3 designs anytime soon. Unless mainline kernel support for H3 improves it's just a waste of efforts.
In case you own already a H3 board beware that the root cause of all stability issues is most likely not the old Allwinner 3.4.39 kernel used now but insane overvolting/overclocking by the manufacturer (see post #26 here) instead. That also applies to thermal problems, that can be easily fixed the same way.
-
"Enclosure" is a DHT11 and "Ambient" a DS18B20. And you will need to adjust the templates a bit since I monitor a lot of stuff there:
-
Basically I need proper binary able to read from gpio pins and I want to record/show values from this sensor on Rpi Monitor.
LOL, I've not realized that you're already using RPi-Monitor. In case you use my sunxi addons it would be easy to replace the temperature daemon (/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh) with this extended version where you might want to disable some stuff (eg. querying external weather stations via HTTP to also monitor your town's temperature and exact parsing of /proc/stat to get an idea what's really going on -- average load is so misleading): http://pastebin.com/U08kPTxt
I start the daemon as such through an init script:
root@lamobo:~# cat /etc/init.d/sunxi-tempd #!/bin/sh ### BEGIN INIT INFO # Provides: sunxi-tempd # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: RPi-Monitor sunxi-temp helper # Description: Sunxi-temp helper for daemon for RPi self monitoring daemon ### END INIT INFO # Source function library. . /lib/lsb/init-functions DAEMON="/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh" PIDFILE="/var/run/sunxi-tempd.pid" [ -x $DAEMON ] || exit 0 checkroot(){ if [ "$(id -u)" != "0" ]; then echo "This script must be run as root" exit 1 fi } start() { touch $PIDFILE for pid in $(cat $PIDFILE); do if ( kill -0 $pid > /dev/null 2>&1 ); then echo "Sunxi-temp helper is already running."; status; return 0; fi done; log_daemon_msg "Starting Sunxi-temp helper for RPi-Monitor" "sunxi-tempd" nice -n 19 $DAEMON $PIDFILE & status=$? log_end_msg $status } stop() { touch $PIDFILE log_daemon_msg "Stopping Sunxi-temp helper RPi-Monitor" "sunxi-tempd" for pid in $(cat $PIDFILE); do kill -15 $pid > /dev/null 2>&1 done status=$? log_end_msg $status rm $PIDFILE } restart() { stop sleep 2 start } status(){ echo -n "Sunxi-temp helper RPi-Monitor status: " if [ ! -f $PIDFILE ]; then echo "Not running" exit 0 fi for pid in $(cat $PIDFILE); do kill -0 $pid > /dev/null 2>&1 && echo -n "[ \033[1;32mok\033[0m ]" || echo -n "[\033[31mFAIL\033[0m]"; done; echo } checkroot case "$1" in start) start ;; stop) stop ;; status) status ;; restart) restart ;; *) echo "Usage: $0 {start|stop|restart|status}" ;; esac exit 0But it should also work if you just start it from /etc/rc.local -- then uncomment the last line. You need the first 2 lines to query the DHT11:
echo 'Humidity = 300 % Temperature = 300 °C' >/var/log/enclosure.log /usr/local/bin/dht11 >>/var/log/enclosure.log & # /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &
My /etc/rpimonitor/data.conf looks like on this system:
include=/etc/rpimonitor/template/version.conf include=/etc/rpimonitor/template/uptime.conf include=/etc/rpimonitor/template/pispy.conf include=/etc/rpimonitor/template/memory.conf include=/etc/rpimonitor/template/swap.conf # include=/etc/rpimonitor/template/sdcard.conf include=/etc/rpimonitor/template/lamobo-disks.conf include=/etc/rpimonitor/template/network.conf
All that's necessary (including the /usr/local/bin/dht11 binary) you'll find here: http://kaiser-edv.de/downloads/sunxi-temp-daemon-with-dht11.tgz
-
Three more things to add regarding 1-Wire:
- It has been recommended to me to buy an I2C-to-1Wire bridge like 1 Wire Pi to protect the board from ESD damage and to have easier access to sensors: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=8312&pid=40322
- Worth a look: OWFS
- Here a user has shown a solution to use 1-Wire reliably over longer distances.
-
Where do you have your sensors, only in the indoors, or do you have sensors for outdoors too? How much are they good/sensitive?
I use one inside a Lamobo R1's enclosure where measuring humidity makes absolutely no sense at all
This was just sort of a test run between DHT11 and DS18B20 regarding temperature (the latter won -- see post 20 in this thread), it's important to always take ambient temperature into account when doing thermal measurements (eg. how behaves a SoC when you adjust dvfs tables). And since the DHT11 was already inside, I left it there to measure internal enclosure temperatures.
I would better ask in another place (without knowing where, but I asked another community member to contribute here) since it seems the knowledge we collect here is more software/server centric. And I would also have a look how to query the sensor (dealing with eg. DHT11/DHT22 is timing critical and I get a lot of read-out errors and had to write a filter script to drop erroneous values).
All stuff that applies to RPi or any other SBC combined with sensors will fortunately apply to the ARM boards we use too. It's just a matter of settings sometimes, eg. https://github.com/igorpecovnik/lib/issues/125
-
I used both zador's attempt with DHT22 and a more simple approach I found here (both requiring WiringPi) for DHT11. But since I had the need to continually write to a logfile that has been parsed by another process (RPi-Monitor) I had to made an adjustment: adding "fflush(stdout);": http://pastebin.com/j1ec3Aqx
Just follow LeMaker's instructions and ensure that dht11.c is lying next to the WiringBP folder.
-
being served from a 250Gb 2.5" inch SATA drive.
Ah, one thing I forgot to mention: The older the disks the more they often consume (applies especially to peak current needed at disk spin-up). And you might also end up with the LCC problem (LCC --> load cycle count): many 'green' 2.5" HDDs suffer from this problem when running with linux: the drive's firmware parks the drive's heads every few seconds in a landing zone just to let the kernel unramp them a few seconds later.
Be prepared to install both smartmontools and hdparm and watch/adjust the relevant parameters (preventing increasing LCC counters and sane spin-down timeouts). If your disk doesn't support automatic spindown, it's time to give hdd-spindown.sh a try: https://github.com/lynix?tab=repositories
With Armbian it's easy to put the rootfs on a connected SATA disk. But unless it's an SSD I normaly refuse to do so and stay with the rootfs on SD-card with Igor's default settings (check /etc/fstab for details) and put only 'application data' on disk. With this setup I manage high spindown times since the disk only runs when really needed.
-
As for using a RPi, I threw that idea out when I realised that all Disk I/O, Network traffic and any other USB peripherals would be through a single USB port
Of course. That's the main disadvantage of any RPi (I tried to point out this architectural difference in the linux-sunxi wiki already)
But one of the many advantages of any RPi is the ability to do HW accelerated video encoding/decoding on the VideoCore VPU. We use a couple of RPi B+ as surveillance cameras (being able to do also a lot of other things since while recording video and sending the encoded h.264 stream through the network CPU utilisation doesn't exceed 10% even when using the slow B+ clocked at 700MHz):
FYI: Armbian running on A31s based Banana Pi M2
in Allwinner sunxi
Posted
First: Forget about the marketing stuff from Imagination. It's true what they tell but that's not related to your problem (since they're talking only about GPU stuff that applies to gamers running Android).
Then how do you measure temperatures? Are you able to read-out an internal sensor?
And it would be still interesting how your cpufreq settings look like: