Uboot.org officially suppoorts BananaPI-M3 (v2016.05-rc1)
https://patchwork.ozlabs.org/patch/563980/
Download (v2016.05-rc1)
1 Like
O yes, kudos to Vishnu! One of the linux-sunxi devs that receives zero support from you and does all the work in his spare time to get support for A83T and BPi M3 upstream.
And now the most interesting question: By mentioning mainline u-boot support for M3 (still in an very early stage as can be seen above) do you announce that you will replace the horribly outdated u-boot 2011.09 you now use with 2016.05-rc1 soon?
Or is this just a PR stunt trying to take credits for someone else’s work?
What does M3 mainline u-boot support mean for your customers as long as you don’t adopt it? Simply nothing.
BTW: I prepared u-boot support for your product BPi M2+ one week ago: https://github.com/igorpecovnik/lib/commit/c25dd4ca08f7c0c584df011d62afb6e9a6634ed6
If you were a responsible vendor you would take our work (it’s open source) and submit our patches upstream so that you as the vendor starts the process of getting ‘offficial’ support for your very own hardware. But you do not even think about that. Only doing PR work instead 
So it will take months until you can announce magically appeared ‘official support’ for the M2+
1 Like
we also hope you can spent time to do this work with BPI-M2+ uboot and help us. you always good than us
1 Like
this is why we use ourself way to do image . we can update all newest code to our image soon . we do the base .so many user can do more on it ,and help us . more way is good than just one way .
Dear TK,
Why u angry about M3 supports latest uboot under ubuntu OS image? It’s not related about Armbian! Will Armbian support M3? If not, why u argue our M3 SW quality? You can open mind to tell us your intention to avoid wasting time on out of Armbian supporting models!
Nora
I’m not angry at all since in the meantime @sinovoip clarified that you want to get rid of the old u-boot you use now and rely on mainline u-boot
The above was just about giving credits to whom it belongs (Vishnu Patekar who did the real work together with a few others, as usual you just take and do not contribute back) and it was a hint that you don’t need to wait months to get ‘official’ u-boot support for the M2+ since you could already take my work (from the commit to Armbian) and submit these patches upstream. You could try to behave like a responsible vendor supporting his own products.
But what do you do instead? Never giving back to the community and currently violating the GPL. You provide the latest drivers/kernel for M2+ only as binary https://github.com/BPI-SINOVOIP/BPI-files/commit/6bfa724cb7abbcf71f975b1c9da89ca0c652d0cb (7 days old) while holding back the sources: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/ (14 days old)
Anyway it’s useless. You’re fiddling around with Allwinner sources, with community sources, stick stuff together without really testing it and don’t get even the idea why this could be wrong. Let’s stop
Well, you realized that I published a semi Armbian image last week that one of your customers used to create an Ubuntu 16.04 LTS image? BPI-M3 new image:bpi-m3 Ubuntu 16.04 Beta Mate
One showstopper for porting Armbian to M3 was missing mainline u-boot support. Now that 2016.05-rc1 is available we might look into it. I would suspect you as the vendor already tried out to boot the identical A83T, H8 and R58 using mainline u-boot? If this suceeds you know that you don’t need to believe Allwinner’s fairy tales since all what’s different between these SoCs is their ID that gets checked by Allwinner’s SDK/BSP code that is not needed any more now that we have mainline u-boot ready, isn’t it?
@sinovoip: This was a question waiting for an answer.
And may I add a suggestion? If you really wasted already your time playing around with different ‘SDK’ versions for A83T, H8 and R58 it would be great if you extrakt the small boot0 BLOBs for each board (as outlined here) and upload it to https://github.com/BPI-SINOVOIP/BPI-files since then there’s no need for your users to deal with different ‘SDK’ versions since it’s just the boot0 BLOB that needs to be replaced when you still rely on the aging BSP u-boot 2011.09.
yes ,we have use to boot all l A83T, H8 and R58 using mainline u-boot.
we also can boot A83T, H8 and R58 with old boot version , so we can boot the three board with android 5.1.1 , as you konw ,H8 not support android 5.1.1 now . but we only can do test ,can not public it . for allwinner NDA .
The only thing I know is that it’s like talking to a wall with @sinovoip. Of course does Android run on H8. There exists no fucking reason why an ‘operating system’ shouldn’t run on a SoC that is identical to its siblings.
I tried to tell you that all that’s different between the 3 SoCs is the SoC ID. I already posted instructions how to exchange the boot0 BLOBs. I already pointed out that since you can boot all 3 absolutely identical SoCs with mainline u-boot this is just marketing bullshit by Allwinner you still seem to believe (OMG, YOU’re the VENDOR. And you believe this BS! You talk to them in Chinese aren’t you?)
Here you can read how Android can be installed on a H8 device (it’s still just about exchanging the boot0 BLOB when you rely on the smelly 2011.09 u-boot from Allwinner to get your Android image run on H8, there’s exactly no need to believe random BS).
But you’re not lost: @BrianBeuken still believes in you! 
yes ,you can do more for this ,but we have many limited , for we need coworker with allwinner .
I said it a long time ago, and just chip ID limited .
yes ,cubieboard use just android 4.4, it is for H8 android SDK, so you need note ,we run android 5.1.1, it is not same . it is clear???
mainline uboot , we can use it under linux ,not on android.
yes ,you just know it is chip ID limited for those board, are you test how to fixed it by youself???
Great! Thx for the confirmation that Allwinner uses the chip IDs and encryption in their BSP code to artificially differentiate between different SoCs.
They produce one and the same SoC with 3 names, give them different IDs and the different business units decide how much support a single ID gets.
And that’s why they limit Android support for the H8 artificially to 4.4 and ‘allow’ A83T to be used with 5.1. So It’s all about marketing and artificially limiting what you can do as long as you have to rely on this BSP crap (and the very same seems to happen with A64, R18 and H64 at the moment where they release a 2.0 BSP ready for Marshmallow soon that also does not support every ARMv8 SoC).
One more reason to never use this BSP crap again.
So in other words: Everyone who wants to use your SBCs with Linux is not affected by this SDK/BSP bullshit. See you again in 2017 when mainline kernel support might be ready for A83T/H8/R58.
H8 is for BOX , and A83T for PAD, so android support version is not same.
and for linux ,allwinner also do many wrok on it . both with H8 and A83T. but they are for business, not think more about open source linux ,but we can base it to do open source.
now ,many user have begin to do this ,such as hans ,wens…thye all get free sample same as you. maybe have a good news soon.
also hope you can join , do the best you can do .we are on the right way. do something is better than nothing to do
@sinovoip
So where is the sun8i-a83t-sinovoip-bpi-m3.dtb ? 
U-Boot SPL 2016.05-rc3 (May 05 2016 - 17:24:23) DRAM: 2048 MiB Trying to boot from MMC1
U-Boot 2016.05-rc3 (May 05 2016 - 17:24:23 -0500) Allwinner Technology, Build: jenkins-github_Bootloader-Builder-375
CPU: Allwinner A83T (SUN8I 1673) Model: Allwinner A83T BananaPi M3 Board v1.2 DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 ***** Warning - bad CRC, using default environment**
In: serial Out: serial Err: serial Net: No ethernet found. starting USB… USB0: USB EHCI 1.00 USB1: No host cable detected: Port not available. scanning bus 0 for devices… 2 USB Device(s) found **Hit any key to stop autoboot: 2 ÿÿÿ 1 ÿÿÿ 0 ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1… Found U-Boot script /boot.scr reading /boot.scr 377 bytes read in 16 ms (22.5 KiB/s) ## Executing script at 43100000 reading bananapi/uImage 7876328 bytes read in 654 ms (11.5 MiB/s) reading bananapi/sun8i-a83t-sinovoip-bpi-m3.dtb **** Unable to read file bananapi/sun8i-a83t-sinovoip-bpi-m3.dtb **** ## Booting kernel from Legacy Image at 46000000 … ** Image Name: Linux-4.2.0-BPI-kernel+** ** Image Type: ARM Linux Kernel Image (uncompressed)** ** Data Size: 7876264 Bytes = 7.5 MiB** ** Load Address: 40008000** ** Entry Point: 40008000** ** Verifying Checksum … OK** ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree … … …
Great
you can test this image , it defaults is for BPI-R1, but you can use bpi-bootsel tooling let it working on BPI-M3 
here you can find : http://git.denx.de/?p=u-boot.git;a=tree;f=arch/arm/dts;h=9a0cd94e47aa028bfdb30c9b2de6cdd936c4be79;hb=HEAD
[U-Boot] [U-BOOT] [PATCH] net: Add EMAC driver for H3/A83T/A64