Does the BPI-M3 have built in Li-Ion battery charging? I don’t have an M3 yet, so I’ve been reviewing the schematics. Given the BATSENSE an LOADSENSE on U2A (which I assume is the AXP813) it appears there is battery charging capability, but, I don’t see a BAT1 connector on the board.
Because you have to to make use of that to be able to use a battery. And when you change something there then it’s time to recompile the kernel or a so called BSP (the same applies to the OS images they provide: If you want them bug-free then spend a few hours/days in the net and fix it yourself). The stuff has to happen on a Linux installation somewhere else (but SinoVoip won’t tell you the requirements because they don’t care).
Got it. I have been working on custom builds of A20-OLinuXIno-LIME2-4GB for Linux and Android, I hope that experience will give me a head start on BPI-M3. I use a Vagrant based Ubuntu virtual machine with Oracle VirtualBox for a build environment. I could share the base box if that would help others.
@Tido I haven’t seen them yet, I’m assuming the information in the http://linux-sunxi.org/Banana_Pi_M3 page is correct. I hope my board will arrive today or tomorrow and I can find them.
If you look at page 3 of the M3 schematics there is a BAT1 listed. I wish the gerber files were available for the board.
I’ve seen them and already taken a picture a week ago:
It’s just an ugly SDK provided by Allwinner where SinoVoip started to fix some essential stuff just after sales started. They still provide OS images that do not contain the latest fixes so even simple hardware features won’t be available. The only OS image that contains all fixes might be the SuSE one from 6th Dec.: Look at the timeline: Commits · BPI-SINOVOIP/BPI-M3-bsp · GitHub
(and obviously my own image since I did a ‘git pull’ a few hours ago and fixed a few things later)
And the boot process is somewhat different, you can not simply exchange uImage or script.bin, you’ve to rebuild the whole BSP everytime something got fixed or you want to adjust minimal hardware initialisation stuff and the like.
Today I managed to compile the stuff with a more recent Linaro toolchain and also backported zsram into ‘their’ kernel (you can rely on nearly every generic kernel stuff for the H3 so always have an eye on loboris’ github repo and especially Siarhei’s)
Apart from that: For most use cases the M3 is slower than the M1 or the A20-OLinuXIno you already know.
Really?! I see your other posts on the A83T not being a true 8 core SOC, but, since the A20 is only a dual core and runs at 900MHz I was hoping the A83T would be much faster with 4 cores at 1.8GHz. I was also hoping the GPU on the A83T would be much faster.
Aside from the GPU and CPU speeds on-board BT and WiFi are also nice.
It has 2 clusters of Cortex-A7 cores that are used concurrently (only some softwares have problems with detection of the correct core count eg. ‘cpuburn-a7’ which detects only 4 cores).
The A83T gets quite hot therefore you need at least a good heatsink or even a fan to really benefit from the theoretical performance since otherwise throttling occurs. And if you adjust the thermal settings CPU cores might be shut down if it gets too hot. But for an old and boring A7 design the SoC is quite fast. You find some performance numbers in my review: http://forum.armbian.com/index.php/topic/474-quick-review-of-banana-pi-m3/
My problem is lack of I/O bandwidth. The A83T is made for tablets and features 2 USB ports and only one is used (internal USB hub and slooooooow USB-to-SATA bridge). The integer performance is useless, graphics performance not that good (only an old and boring PowerVR with 1 GPU core) and I/O and network performance suck. As do software/support.
SinoVoip does a really bad job regarding software (and nobody gets it why – they’ve been told so often which simple steps would improve the situation). For example: I just had a look at their Ubuntu 15.10 image. They ship with enabled irqbalanced. This piece of software is both completely useless (on ARM unless you use the fixed version) and contains a memory leak eating up all your RAM over time. It does only harm. And to do it right you would add something like this instead to /etc/rc.local:
If you just use a heatsink, then under full load the thermal throttling will jump in and you won’t exceed 1.2 GHz, often even falling back to 1008 MHz:
If you enhance heat dissipation either through a really large heatsink or a fan you’ll really get in trouble. Since with 1.2 GHz the SoC will run at 920mV. If you enhance cooling it will speed up and Vcore voltage will also increase further: 980mV and even up to 1080mV.
Under full load at 920mV the consumption is already between 5.5W and 6W – without a connected disk, USB peripherals and a display. When Vcore voltage increases consumption explodes:
And since SinoVoip chose to ship the M3 with the worst power connector ever (rated for 1.8A ~9W) your device will simply shutdown when you enhance cooling:
Therefore you might benefit only from peak performance (risking a sudden shut-off when you don’t solder wires or a power barrel and use 5V/3A) or end up with a device running with 8 cores at 1.2GHz (that’s four times the A20 running at 1.1 GHz – when clocked identical the single core performance of the older A20 is higher).
For your A20 Lime I’ve made templates and a daemon (necessary to query the temperatur sensor and disks) long before. All relevant informations (installing a “beta”) can be found in the aforementioned thread here.
Because you have to to make use of that to be able to use a battery. And when you change something there then it’s time to recompile the kernel or a so called BSP.
The stuff has to happen on a Linux installation somewhere
else
At least you can start the modlules
sudo modprobe wire
sudo modprobe sunxi-gpio
sudo modeprobe w1-sunxi gpio=3
to gpio=… the pin you want
sudo modeprobe w1-therm
The only thing who not work is the w1-gpio
if you find something out which can help say to me pls