HI Saut_Daniel: We do M1 and M2 in different ways. Maybe you can see this for reference.
They simply rely on Allwinner’s SDK for the M2 and use an U-Boot from 2011 which does not support script.bin. So no easy way to fix errors in hardware initialisation, support a different LCD and so on.
They could use a newer U-Boot version which supports script.bin but they don’t want to. You should also have a look at http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested (there’s outlined how you can use the M2 with mainline kernel. If you rely on Armbian you could use also Ubuntu Trusty with Kernel 4.1 this way)
1 Like
You power the board wrong. And since the BPi people don’t create a FAQ and link to it this has to be posted over and over again: http://linux-sunxi.org/Banana_Pi_M2#Powering_the_board
Regarding your idea to get the most stable OS if you set on an Ubuntu system with kernel 3.3 and U-Boot from 2011… well, that’s questionable 
It’s really weird that you provide different OS images for simple stuff like different video outputs (HDMI vs. LVDS LCD).
All you would’ve to do is to provide a simple tool that overwrites a few blocks at the beginning of the SD card where U-Boot with the precompiled sysconfig_fex lives. But instead of providing such a tool that could be used on all your OS images relying on kernel 3.3 and the aging U-Boot from 2011 you force people to start all over again when they just want to switch between HDMI and LCD? Are you kidding?
1 Like
HI Saut_Daniel: We do M1 and M2 in different ways. Maybe you can see this for reference. Building a Minimal System with BPI-M2
Well I download this image and then install it using sudo dd … ON the BPI-M2 If I do it that way it would have the script.fex? Somehow I doubt that. But going to try that
They simply rely on Allwinner’s SDK for the M2 and use an U-Boot from 2011 which does not support script.bin. So no easy way to fix errors in hardware initialisation, support a different LCD and so on.
They could use a newer U-Boot version which supports script.bin but they don’t want to. You should also have a look at http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested (there’s outlined how you can use the M2 with mainline kernel. If you rely on Armbian you could use also Ubuntu Trusty with Kernel 4.1 this
@tkaiser you mean there is no script.fex? But the bpi-m1+ have it so I thought it is just some sort of diffrent location.
yes, we have begin to development with kernel 4.1.x .
HI tkaiser:
We divided the images into HDMI and LVDS because we’d like the users to opt for their preferred display type. If you’d like to switch the resolution for BPI-M2 (LCD to HDMI), you may see http://forum.banana-pi.org/t/bpi-m2-how-to-do-bpi-m2-resolution/362for reference.
We’ve been working on this in kernel 4.1, the expected time to release will be in September. Please be following up with us.
I believe you still don’t get my point. Changing resolution or video output is essentially just overwriting a few KBs at the beginning of the SD card as you already outlined in https://github.com/BPI-SINOVOIP/BPI-M2-Configuration
You force users (that power their board using the USB OTG port and suffer from being able to use half of the USB ports since they don’t know better and search for script.bin since they don’t know better) to download stuff from github and do a risky dd operation themselves? While there are already images based on kernel 4.x in the wild where everything works totally different?
Why don’t you ship a small self-containing tool that
a) checks boundary conditions (which u-boot version and kernel is the user in question running? Is this a sun6i board or does someone try to trash his M1/M1+/M3 installation?)
b) does the right thing (overwriting SD card blocks when U-Boot 2011 and kernel 3.3 is used and otherwise adjusting the .dtb file)
With this approach you would also help users to use GPIO pins and GBit Ethernet with an older OS image and don’t want to start over again with a totally fresh image.
Whether script.bin works or not (and therefore exists or not) is not a question of the board but of the software used. And SinoVoip uses a totally outdated U-Boot version for their kernel 3.3 based OS images so there simply is no script.bin that you as the user could easily adopt to your needs using the sunxi tools bin2fex/fex2bin.
Dear tkaiser:
We truly appreciate your valuable advices, and we’ll be ameliorating as soon as we can. The BPI team will devote ourselves to a better user experience, and your kind advices will surely be a great inspiration to us to move on. 
Dear sinovolp I want to report some kind of bug. The touchscreen works flawlessly but on the bottom on the touch screen the touch screen doesn’t work. Is this the hardware or are there some kind of bug on the driver. The image i used is the the ubuntu one.
Best Regards.
1 Like
HI: Please try it .
sudo modprobe fft5x_ts.ko
“FATAL: Module fft5x_ts.ko not found.” The module is not found And shouldn’t that driver is for the bpi-m1+? I used the bpi-m2 one. And i need to add that it is the wrong pic
HI:
Please try again.
fft5x_ts.ko ==> ft5x_ts.ko
sudo modprobe ft5x_ts.ko
That is the correct pic.
And for the command the same thing happen FATAL: Module ft5x_ts.ko not found.
1 Like
HI: try it
cd /lib/modules/3.3.0-BPI-M2-Kernel/kernel/drivers/input/touchscreen sudo modprobe ft5x_ts.ko
1 Like
The modprobe command run without a problem but the bottom of the touchscreen still doesn’t work
fyi the upper part of the screen.
The touchscreen does work 
The bottom one doesn’t work 
Is this a case of hardware malfunction? Or is this a software malfunction. Could you just please show me that your touch screen on the bottom part is responding and working. So we could plan to order another touch screen
please wating ,we test it now.
Why does setting up the touchscreen, the bananapi, and booting it up takes such a long time? Does the lcd didn’t work?