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
The one from september? If so you miss all the very important fixes here: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master
The distribution used is completely irrelevant, everything important happens in kernel, u-boot and hardware initialisation (and does not live in the rootfs but in the first sectors of SD card or eMMC)
Please have a look at
ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS | grep irqbalance
from time to time
Maybe. You should keep in mind that the quality of this ‘BSP’ normally is for internal use only. I would never release such a crappy bunch of scripts. But that’s all what you get from Allwinner and unless you spend a huge amount of time to fix this you should better expect that it’s not working.
I use it on the same machine where my Armbian build system is up and running. It’s “Ubuntu 14.04.3 LTS” and Armbian does it right and installs the stuff that’s missing on its own: https://github.com/igorpecovnik/lib/blob/second/main.sh
I installed the packages mentioned in the script: aptly device-tree-compiler pv bc lzop zip binfmt-support bison build-essential ccache debootstrap flex gawk gcc-arm-linux-gnueabihf lvm2 qemu-user-static u-boot-tools uuid-dev zlib1g-dev unzip libusb-1.0-0-dev parted pkg-config expect gcc-arm-linux-gnueabi libncurses5-dev whiptail debian-keyring debian-archive-keyring ntpdate
But still the same error. I discovered an other more specific error:
LD security/built-in.o CC arch/arm/mach-sunxi/pm/standby/…/mem_tmstmp.o CC block/elevator.o CC fs/fifo.o CC arch/arm/mach-sunxi/pm/standby/…/mem_hwspinlock.o CC mm/truncate.o CC arch/arm/mach-sunxi/pm/standby/…/mem_clk.o CC fs/dcache.o CC fs/inode.o CC arch/arm/kernel/topology.o CC crypto/algboss.o arch/arm/mach-sunxi/pm/standby/gen_check_code: 1: arch/arm/mach-sunxi/pm/standby/gen_check_code: Syntax error: end of file unexpected (expecting “)”) make[4]: *** [arch/arm/mach-sunxi/pm/standby/resume1.code] Error 2 make[3]: *** [arch/arm/mach-sunxi/pm/standby/standby.code] Error 2 make[2]: *** [arch/arm/mach-sunxi/pm] Error 2 make[1]: *** [arch/arm/mach-sunxi] Error 2 make[1]: *** Waiting for unfinished jobs… CC block/blk-core.o CC arch/arm/kernel/io.o CC mm/vmscan.o CC kernel/user.o CC block/blk-tag.o AS arch/arm/kernel/debug.o CC arch/arm/kernel/early_printk.o CC crypto/testmgr.o CC kernel/signal.o
Any suggestions?
your build environment is 32-bit or 64-bit?
Switch to a x86_64 installation. A quick google search suggested this as the solution. Here I use “Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-53-generic x86_64)” and everything work’s flawlessly unless you try to switch to a more recent Linaro toolchain.
It’s Ubuntu 14.04 32 bit VM.
Could you please provide a list of packages or a tutorial how to set up the build environment?
The packages should be installed if necessary by build.sh – compare with
for example.
And such a ‘tutorial’ has to be part of Readme.md. It’s just a bad joke not providing these essential informations and let the user run into missing package problems or choosing the wrong architecture to build the stuff.
I could now compile successfully the bsp. I set up a fresh Ubuntu 14.04.3 x86_64 VM with installed updates. I had to enable the i386 architecture for my 64 bit System:
dpkg --add-architecture i386
then i had to update the local repo index and install severel i386 librarys which the build tools need:
apt-get update
apt-get install git make libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 lib32ncurses5 lib32bz2-1.0 gcc u-boot-tools
After this i cloned the git repository and compiled it by invoking ./build.sh
mkdir /root/bpi-m3-bsp/
cd /root/bpi-m3-bsp/
git clone https://github.com/BPI-SINOVOIP/BPI-M3-bsp.git
cd BPI-M3-bsp
./build.sh
Now after answering the questions the compilation process began and finished sucessfully for me.
Why did you use this lib folder and not the suggested from SINOVIP download/BPI_M3_1080P/lib/? I saw there is an additional folder called firmware.
Exactly and that’s the only difference:
diff -r download/BPI_M3_1080P/lib linux-sunxi/output/lib
Only in linux-sunxi/output/lib: firmware
I thought maybe the firmware folder contains stuff like BLOBs necessary to get Wi-Fi/BT working. Don’t know since never tested.
Hi,
I just tried the Ubuntu Mate image and got it running but only with standard HDMI connection to my TV. It’s not possible to see a video image if I use a HMDI to DVI connector attached to my LCD-monitor. So I wanted to play around with the script.bin (bin2fex, edit fex-file, fex2bin), but: there is no script.bin! I took a look at the first partition of SD-card:
bananapi boot.scr fixup_db.dat overlays
bcm2708-rpi-b.dtb cmdline.txt fixup_x.dat start_cd.elf
bcm2708-rpi-b-plus.dtb config.txt FSCK0000.REC start_db.elf
bcm2708-rpi-cm.dtb COPYING.linux kernel7.img start.elf
bcm2709-rpi-2-b.dtb fixup_cd.dat kernel.img start_x.elf
bootcode.bin fixup.dat LICENCE.broadcom
The output of boot.scr is also not very helpy for me:
fatload ${devtype} ${devnum}:${bootpart} 0x46000000 bananapi/uImage
fatload ${devtype} ${devnum}:${bootpart} 0x49000000 bananapi/${fdtfile}
setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rw rootwait panic=10 ${extra}
env set fdt_high ffffffff
bootm 0x46000000 - 0x49000000
Where is the script.bin located?
By the way, I previously owned a cubietruck and thought the procedure for modifying the configuration would be the same.