Tried your Google Drive link. You still provide no MD5/SHA1 checksums which is a sign that youâre not able to learn. How should your users confirm that they downloaded an uncorrupted image?
Booting stucks in early stage:
Itâs unbelievable. Iâve never seen a vendor being such a loser regarding software and support.
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
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
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?
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
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.
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
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).
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
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