This is a tricky part. There are
images available (
also here) to download where I have gone with the most recent ones to try as earlier this year and end of 2015 there was quite a a bit of negative feedback about bugs.
Ubuntu Mate 15.10 for BPI-M3 GPU PowerVR SGX544MP (20160317) is probably damaged/broken as I have tried writing it to the flash storage and it always failed to boot. On some occasions the file system was already corrupted and / could not be mounted on boot.
I have decided to go for
Debian Jessie 8.4 from above and flashed it to the on-board eMMC. I strongly recommend this (latest, as of now) OS image. No more SD cards!
At this point I have to say that I have been unable to install kodi on Debian Jessie after many days of trying. I figure that the gpu is still not properly supported.
Summary
There is continuous development and a new Ubuntu 16.04 LTS image should be coming out soon, stay tuned! Currently, support is quite low. I would only advise for developers and people who would like to tinker with an upcoming hardware.
Writing to the on-board eMMC storage
Let us leave SD cards behinds as this was one of my main motivations over buying a newer model of Raspberry Pi. I had to throw out and reinstall too many SD cards to start using them again. The Banana Pi M3 has a net of 7.3 GB on-board flash storage. To write an image to it, first you have to boot from an SD card. This is well explained in other tutorials, but the method is same in all cases,
- Download an .img file
- Find out what is the device number of the SD card /flash storage
- Write image with dd
So, respectively if you are on a Linux machine or already booted the banana Pi from an SD card,
lsblk
will list the devices you have. On your computer the SD card probably shows up as
/dev/sdb whereas if you are running the Banana Pi the internal storage will likely be
/dev/mmcblk0 and the SD card shows up as
/dev/mmcblk1.
I am pretty sure
mmcblk0 is the flash and
mmcblk1 the SD card by default on every board. To write a .img file to the flash storage you do as you normally would with an SD card,
sudo dd if=/debian-jessie-8.4.img of=/dev/mmcblk0 bs=1M
Where
if - input file, the img file you want to write
of -output file, in this case the internal storage
Once finished, you can run
lsblk again to confirm that partitions have been written. You should see something like on the image below.
 |
| Banana Pi with Debian 8.4. mmcblk0 stand for the internal storage whereas mmcblk1 shows an inserted SD card. p1 & p2 stand for partitions one and two, respectively. |
Note: You can specify a block size of 1-10 MB if you want for dd, but it is not necessary. Use e.g.
bs=1M at the end of the dd command.
Also, dd doesn't have any status indicator of the process. If it doesn't give you an error, it is running. Let it finish.
Warning: dd is dangerous, so make sure you are writing to the good partition with it, it can easily overwrite other data. I take no responsibility if you delete anything.
Expanding the file system
Sometimes the .img file you write to the SD card to eMMC storage is smaller than the actual storage space you have. However, in this case some of the space will be unrecognised and hence cannot be used until you expand the file system. You can do this directly from the Banana Pi while running, it will require one reboot. This will NOT delete any data from your SD card or the on-board eMMC storage.
Explanation:
What happens here is the following: The first partition mmcblk0
p1 is the boot partition and it occupies the first X sectors of the "disk". The second partition starts with the following sector and occupies some amount of sectors, however not until the last one. Hence part of the space is not "seen" by the device. Herein lies the problem. What we have to do is that we have to redefine this second partition and specify to last until the last sector on the disk. Essentially we have to delete the second partition (mmcnlk0p2) and recreate it, such that it starts immediately after the first partition (like before). However, this time we tell the OS to make the partition last until the end of the disk, that is the last sector. This process does not cause data loss as the partition is not formatted, only expanded to free space after the current sectors.
There is a nice tutorial on how to do this on
gleenders.blogspot.com. The steps you have to do to expand the on-board storage on the Banana Pi is pretty much the same,
- sudo fdisk -l
Check from the output which one is the eMMC storage. I assume here its /dev/mmcblk0
- sudo fdisk /dev/mmcblk0
- Press "p" to list partition table on the device. You will most likely see 2 partitions, with the second one being several GB in size. Remember the last sector of the first partition. The second one needs to be deleted, set to start right after the end of the first partition and last until the last sector.
- Press "d" to delete a partition and select the second one.
- Press "n" to create a new partition and choose "p" for primary". Specify the first sector of the partition starting right after the first partition (you should still see this information above in your terminal window). The last sector should be the last sector of the drive.
- Press "w" for writing the partition table
- Reboot your Banana Pi,
sudo shutdown -r now
- Log in via ssh and resize the partition finally with,
sudo resize2fs /dev/mmcblk0p2
Note: This does not delete any data from the drive, if done correctly.
Hardware
Power supply
Initially I have tried to power the board from a micro USB port, however this was unsatisfactory as it was unable to power a 2.5" HDD. Next, I have ordered a 5V 3A DC jack power supply, and this worked perfectly. I got a multi-adapter power supply for 16€ from
Amazon.de. It comes with plenty of adapters and I can re-use it later on for other projects if I need.
 |
| KFD universal network adapter, 5V 3A power supply that works well with the Banana Pi M3 (Also comes with a bunch of adapters, so can be used for other projects as well) |
Note: When you are buying a power supply, make sure you get the right adapter at the end! Refer to
BPi M3 DC Power Interface.
2.5" Hard Drives
At least using the latest Debian Jessie (8.4) hot plugging of HDDs is allowed (the raspberry Pi B reboots if you connect a HDD as it creates a power surge). Using my DC power jack cable I can have a
2 TB 2.5" Seagate HDD connected and powered via one of the USB ports. Of course, it can be connected and powered via the SATA connector as well.
Writing to the Hard Drive
Copying over via Gigabit Ethernet from my Linux laptop I got an average speed of 14.6 MB/s. This was roughly the same when copying from Windows as well.
 |
| Write speed to 2.5" Seagate HDD via Gigabit LAN connection. 14.6 MB/s |
 |
| Write speed to 2.5" Seagate HDD EncFS conatined via Gigabit LAN connection. 5.7 MB/s |
|
|
|
|
|
|
Reading from the Hard Drive
Again, copying to my laptop from the HDD via gigabit Ethernet connection resulted in read speeds close to that of the write speed, 13.3 MB/s. Interesting that it is lower than the write speed, I assume it is just some fluctuation and that it is the same, limited by the USB connection. The Read speed from the EncFS container was not severely affected, it was around 9 MB/s.
 |
| Read speed from 2.5" Seagate HDD via Gigabit LAN connection. 13.3 MB/s |
 |
| Read speed from 2.5" Seagate HDD EncFS conatner via Gigabit LAN connection. 8.7 MB/s |
Note: Possible hardware "bug" is that after powering down the board, the HDD is still powered on, whether it isconnected via the SATA or the USB port. Only way to power down the HDD is to disconnect it from the board. Furthermore, if the board is powered down, USB HDD is plugged it, even though the HDD powers up automatically, the board won't power up. The HDD has to be disconnected, the board started and finally the HDD can be plugged in again.
Encrypted Hard Drive
Connecting
the drive with the new power supply was easy and the BPi M3 recognized
it straight away. The two options I am still considering for encryption are,
- veracrypt (after Truecrypt has been discontinued)
I have managed to install the command line version of it to the BPi M3 without problem and could mount the 2 TB HDD. The write speed over Samba shares has spiked and then quickly dropped to 0 in all my tests and eventually got interrupted. This seemed like a dead end and I didn't test any further.
- EncFS
Can be set up relatively simply, however reduces the write speeds to the drive to 30% of the original.
Veracrypt,
as far as I know, offers a higher level of security than an EncFS, however EncFS scales pretty nicely with written data and I
wouldn't need to convert an entire 1.7 TB drive. (I have used a computer to do it over USB 3.0 and it took 14-15 hours) If anyone has managed to get decent speeds writing to a Veracrypt container, I would be happy to hear it!
Temperatures
The CPU can be clocked up to 1.8 GHz dynamically, depending on the load, whereas the minimum running frequency is 480 MHz. Of course, the higher the load on the CPU, the higher the frequency will be scaled by cpufreq and consequently it will get hotter.
The CPU gets pretty hot just by idling, so some sort of cooling is advised, if not compulsory. The idle temperature I got was around 53 degrees C. Temporarily I was using a small externally powered USB fan, but then decided to get a small heat sink from Amazon, which has proven to work well on my Raspberry Pi B previously. 14 x 14 mm heat sink fits perfectly on the CPU.
 |
| Banana Pi M3 board with a heat sink added on the CPU |
Passive cooling
With the small Aluminium heat sink the CPU's temperature started off at 40 C and then slowly rose to 52 C when idle. Running an apt-get update has ramped up this temperature to 57 C. Therefore, I'm planning on buying a small plastic case where I can fit the Banana Pi M3, a 2.5" HDD and also a cooling fan that can be powered with under 5 V (to reduce speed and collateral noise).
Heat sink of my choice (as visible on the picture above) is from
Amazon.de. The dimensions 14 x 14 mm fit the processor perfectly, so feel free to buy anything you deem fit.
Software solution
CPU scaling is a "soft" solution that can be applied and I also recommend this. The frequency of the cores can be scaled from 480 MHz to 1.8 GHz. However, if you want to run all 8 cores at 1.8 GHz, you need forced cooling (fan), otherwise cpufreq throttles back the frequency and perhaps also shuts off some cores.
With my heat sink and limiting the CPU frequency to 1 GHz, the CPU gets to 53 C during a simple apt-get upgrade.
Maxing out all the 8 cores, with my CPU cooler heat sink I got up to 67 C at 1 GHz. Since it was 2 a.m., I decided to put a fan nearby and set the maximum frequency to 1.6 GHz to speed up compiling. This has reached a steady temperature of 51 C, however I have to say this is not sustainable as the small USB fan I am using is annoyingly loud. With the same fan and process, at 1 GHz the CPU stabilizes at 40C. A moderate 1 GHz should be roughly the maximum one could use with some heat sink, without forced cooling. Without one, I would perhaps go as low as 700 MHz to avoid overheating. Operating with default settings and no heat sink or cooling, the CPU easily reaches 65 C where it gets throttled back.
 |
| Maxing out all 8 cores (set to 1.6 GHz) while compiling Kodi from source |
 |
| CPU at 1.6 GHz heats to 51 C when using heat sink and USB fan cooling maxing out all 8 cores |
My final setting is 1 GHz with just the heat sink, no fan. If the temperature gets to 65 C, the OS throttles the cores back. However, this only happens if all 8 cores are running at 100% e.g. when compiling stuff from source.
Is it worth to get a heat sink?
Well. What I have observed is that without the heat sink the CPU's temperature spikes within seconds over 60C when maxing out all cores. Compared to this, with heat sinks it has a larger thermal mass, and some additional heat transfer to the ambient air and therefore a more smooth heating up and cooling down. I would say it is a slight improvement, especially if only spikes happen on the CPU and not running continuously at 100%.
If the plan is to use a fan, I would say there is no need to spend money on such a small heat sink.
In general, getting a heat sink is most likely not needed at all. I would not buy it again, instead I would simply limit the CPU frequency and trust the device (since it should be built in such a way that it doesn't melt when I use it, right?).
Troubleshooting
There were some issues while installing and configuring, I hope my experience will help others resolve their problems quicker!
Welcome to Emergency mode!
If there is an entry in /etc/fstab that cannot be executed at boot, the boot from the flash storage will fail. E.g. if you define a HDD in /etc/fstab and then try to boot without it connected, the Banana pi won't boot. Commenting it out in fstab resolves the problem otherwise you are greeted with the "Welcome in emergency mode" message. (source)
As usual, if you have any questions, do not hesitate to ask. Also, if you have any cool project going on with the Banana Pi (and/or have managed to get Kodi running), I would be happy to hear it!
