It worked perfectly well for me though. I’ll give you the file hashes for my download so you can compare.
SHA-1 : BADC0C74F4184124BD5970414F329A1875B5B138 MD5 : BC13D33DEE6047B06DA827F78EA9656C
Thx, but since you claim SHA1 and MD5 are the same, that’s useless. And it’s the manufacturer’s job to provide checksums together with their downloads. There’s no excuse for refraining from. But even that doesn’t help since they’re able to provide checksums with a corrupted image and simply don’t care: Android image for BPI-M1 is broken
Apart from that: Why should I use their image? I’ve an Ubuntu 15.10 image already (it’s really easy to combine any rootfs with bootloader, kernel and hardware initialisation for the M3) and my image contains all the recent fixes (2 more from today) already: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master
I automated that (easy, just let the first sectors of eMMC/SD-card being overwritten after you rebuilt the BSP) since otherwise it’s impossible to test software progress for the M3. Taking this into account it’s totally moronic that they released a few OS images the last days since these do NOT contain the necessary fixes from their Github repo.
But if you read how ‘devs’ that send commits to this Github repo deal with questions then it’s questionable if you want to use any software from them: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/4
The SHA-1 was fine, it looks like I didn’t copy paste the MD5 correctly and I didn’t notice it. I’ll fix that right away.
And how do the checksums of the extracted image look like? I’ve
MD5: b5df9b49bdf702a5da0daf74f1daf544 SHA1: 917843010adb54bc01496aa778174602e5913ab9
My checksums of the extracted image are:
MD5: b5df9b49bdf702a5da0daf74f1daf544 SHA1: 917843010adb54bc01496aa778174602e5913ab9
They seem to match with yours
Mine also match. I wonder why my board booted then if yours wouldn’t.
I’m a bit of a Linux newbie so I wouldn’t know how to assemble my own image. I wouldn’t mind trying that with Raspbian though.
Is there a suitable guidance how to build our own image and integrate the latest changes from git? Or can you please provide us a short tutorial how you did this?
I won’t give it a try again since it’s useless. I’ve already set up a working environment to further test with (the A83T is somewhat interesting since some stuff can be read out not available on other SoCs)
Don’t do it since Raspbian consists of slow ARMv6 code. It’s not even worth a try. But basically it’s just that: Choose any ARMv7 OS image you find that contains 2 partitions, build SinoVoip’s BSP (as usual the most important information is missing: this has to be done on a x86_64 machine) and you end up with two directories of importance:
- output/BPI_M3_1080P
- linux-sunxi/output/lib
The contents of these 2 dirs built this morning and including the 2 most recent fixes you’ll find here: http://kaiser-edv.de/tmp/TgVgxb/
And after unpacking BPI_M3_1080P.tar.7z, it’s just
dd if=BPI_M3_1080P/pack/boot0_sdcard.fex of=/dev/mmcblk0 bs=1k seek=8
dd if=BPI_M3_1080P/pack/u-boot.fex of=/dev/mmcblk0 bs=1k seek=19096
dd if=BPI_M3_1080P/pack/boot-resource.fex of=/dev/mmcblk0 bs=1k seek=36864
dd if=BPI_M3_1080P/pack/env.fex of=/dev/mmcblk0 bs=1k seek=69632
dd if=BPI_M3_1080P/kernel/boot.img of=/dev/mmcblk0 bs=1k seek=86016
cd / && tar xzf "`${OLDPWD}`/lib.tgz" && shutdown -r now
to get most recent kernel, bootloader and hardware initialisation. I automated this through a script that rebuilds the BSP in a virtual x64 machine running Ubuntu, fetches the archives and then replaces the stuff on the BPi-M3 followed by a reboot. That’s the only way to get the most recent fixes unless SinoVoip does it right: Providing an apt repository at least for their Debian based images, package the above stuff as .debs and do the overwriting of the first sectors as a package postinstall routine. As an example how Armbian does it: https://github.com/igorpecovnik/lib/blob/second/common.sh#L52-L71
If SinoVoip would care they would provide something like that since otherwise you’re forced to reflash the whole image if you want the latest fixes when they release a new image in a few weeks (or do the stuff outlined above manually). It’s even necessary to do this if you just want to change the display resolution. It’s unbelievable that they don’t care because we’ve told them already so many times that they should care about user experience. But they seem to not care at all except of selling hardware.
EDIT: SinoVoip now provides now /usr/bin/bpi-bootsel to be able to choose between a few bootloader/initialisation combinations. So you can switch display resolutions but are still cut-off from updates. This stuff has to work online. It’s nearly 2016 and not 1999 any more…
It’s basically what I just described (and this is what I did and what worked for me). If you have a working rootfs it should also be possible to include that into the BSP and let it build a whole image.
But I prefer to replace the sectors of my image since the image’s contents are work in progress. I’m doing some research on dfvs/cpufreq settings as already mentioned: https://groups.google.com/d/msg/linux-sunxi/CXx2MzMuujU/Y75MZpbpCwAJ
If you do the whole stuff not from within the running image then you’ve to replace /dev/mmcblk0p1 with either mountpoint of the SD-card or the path to the image. On OS X I used prior to ‘full automatisation’ this manual approach:
bash-3.2# cat update-sd-card.sh
#!/bin/bash
MyDisk=$1
if [ "$(id -u)" != "0" ]; then
echo "This script must be executed as root. Exiting" >&2
exit 1
fi
case ${MyDisk} in
disk*)
:
;;
*)
exit 1
;;
esac
ssh $buildhost "/var/git/M3/BPI-M3-bsp/build-stuff.sh"
rm -rf BPI_M3_1080P
rsync -a $buildhost:/var/git/M3/BPI-M3-bsp/output/BPI_M3_1080P .
diskutil unmountDisk ${MyDisk} || exit 1
if [ ! -f BPI_M3_1080P/pack/boot0_sdcard.fex ]; then
echo "Can't find the archive's contents. Giving up." >&2
exit 1
fi
dd if=BPI_M3_1080P/pack/boot0_sdcard.fex of=/dev/r${MyDisk} bs=1k seek=8
dd if=BPI_M3_1080P/pack/u-boot.fex of=/dev/r${MyDisk} bs=1k seek=19096
dd if=BPI_M3_1080P/pack/boot-resource.fex of=/dev/r${MyDisk} bs=1k seek=36864
dd if=BPI_M3_1080P/pack/env.fex of=/dev/r${MyDisk} bs=1k seek=69632
dd if=BPI_M3_1080P/kernel/boot.img of=/dev/r${MyDisk} bs=1k seek=86016
sleep 0.2
diskutil eject ${MyDisk}
But since I also had to replace /lib/modules I chose to fully automate it from within the running image. It’s fire and forget
How to put this image on emmc? is there any flasher tool that i can try?
our RD at allwinner and coworker with allwinner RD , we will try let Linux image same as android image ,and use PhoenixSuit tooling .to burn.
now ,only support dd to do this work.
You mean from SD to EMMC using dd to transfer the linux image?
Yeah, I don’t think I know enough Linux to follow that.
1 Like
In case you’re using this image could anyone of you please provide the output of
type $(which bpi-bootsel)
And in case it’s a shell script dump the contents to an online pasteboard service to get a clue what this tool does?
curl -F 'sprunge=<-' http://sprunge.us <$(which bpi-bootsel)
You get then an URL containing your paste and can share this here.
Ok, I thought one more time: Let’s give it a try. Booting into my image and transferring your image we’re talking here about to eMMC:
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 | gzip -c" | gunzip -c | dd of=/dev/mmcblk1
Is this the right sequence? @sinovoip, is it really that hard to write clear instructions?
At least I’ve had the chance to look at bpi-bootsel myself: It seems you picked up the idea to overwrite the 1st sectors to choose different display resolutions. At least a first step in the right direction. But the archives you provide are missing your latest fixes already:
root@BPiM3:/mnt/emmc/usr/lib/u-boot/bananapi/bpi-m3# ls -la
total 56056
drwxr-xr-x 2 root root 4096 Dec 3 02:43 .
drwxr-xr-x 4 root root 4096 Oct 22 10:04 ..
-rw-r--r-- 1 root root 9622875 Dec 2 02:30 BPI_M3_1080P.img.gz
-rw-r--r-- 1 root root 9532171 Dec 2 02:30 BPI_M3_720P.img.gz
-rw-r--r-- 1 root root 9532229 Dec 2 02:30 BPI_M3_LCD7.img.gz
-rw-r--r-- 1 root root 9622879 Dec 2 02:30 BPI_M3_USB_1080P.img.gz
-rw-r--r-- 1 root root 9532174 Dec 2 02:30 BPI_M3_USB_720P.img.gz
-rw-r--r-- 1 root root 9532237 Dec 2 02:30 BPI_M3_USB_LCD7.img.gz
This is useless given the state of your fixes: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master (the last 5 are already NOT included). Fortunately my update method outlined above also works with your image running now from eMMC.
Is it right that you are now running from emmc? What does the ‘| gzip -c" | gunzip -c |’ do? In my opinion it compresses and directly uncompresses the image… I will get my BPI M3 this evening and i will try your update method mentioned above.
Yes, I flashed SinoVoip’s 15.10 image this way. I downloaded it on OS X and transferred it through the network using a gzip pipe to compress the data. It failed the first 3 times until I realized that’s something going wrong. I had to lower the maximum cpu clockspeed to be able to realibly write to eMMC (!!!). Just opened another Github issue: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/5 (I assume they will close it without taking notice as usual).
At the moment I set
echo interactive >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1008000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
in /etc/rc.local. Will later have a look whether I can provoce eMMC corruption when clocking higher again.
The first part compresses the image on OS X and the 2nd uncompressed it on Linux.
First impressions: This bug is still unresolved even with SinoVoip’s own image: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/3 (already closed since ‘hey, why fixing a bug if you can simply ignore the bug report?!’). Compare with
root@bananapi:/usr/lib# cat /proc/loadavg
1.00 1.45 1.69 1/350 27033
And I had already many throttling situations – you can try
dmesg | grep -i Budget
in a terminal to get a clue. With my image this stopped after applying a heatsink and some finetuning. More to come…
LOL, I found another silly (and very very very well known) bug the image contains. But I won’t tell now. It’s too funny.
Everyone here running this image should report back in 2 days how sluggish the system behaves when it was running all the time. They installed the most useless and crappy piece of software by default 
I tried this on an Ubuntu 14.04 x86 VM with latest updates. I installed gcc and make and cloned the git repository. But when ich execute the build script it exits with the following message: “make: *** [kernel] Error 2” Do i need further packages? Or is the latest git clone broken?
I am successfully installed Debian Jessie into emmc flash using dd command. But still under observation on stability of OS distribution