Banana-pi m3 boot issues


(massimo ales) #1

Hi everyone. I had downloaded ubuntu image for m3 and it’s unable to reach starting mask like https://www.youtube.com/watch?v=5BAZauZ253c. What have I to think? An Hardware problem or software one? I see everytime a dump of hexa… Please help me? Or can someone give me another link to an image. The same happens with other operating system. Max


Android image for BPI-M1 is broken
(massimo ales) #2

I add. I cannot access by ssh and i cannot see the adress. sometimes after a while it shout off by itself. max


#3

Currently they provide only corrupted download images for the M3: BPI-M3 new image:bpi-m3-ubuntu15.04 image beta 1.0 update

It can’t work. :joy:

And since they refuse to provide SHA1/MD5 sums you can not even check whether the image is corrupted or not: How to burn android image to BPI-M3 EMMC

Also funny: Even if you tell them that they provide corrupted downloads nothing happens: http://www.bananapi.com/index.php/forum/adroid/1376-bpi-m2-new-image-android-4-4-v4-1-was-released?start=12

They simply don’t care whether you bought a paperweight (SBC without useable software) or an SBC (with useable software)


#4

Even more funny: Have a look at the commit log: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master

They did simply nothing the last 2 months (only releasing “beta” images through broken download links), then they release an Android image 2 days ago and YESTERDAY they started fixing bugs. 8 commits fixing important stuff like BT voltage, touchscreen and camera fixes.

Don’t expect that any of the already available OS images is close to being useable (fortunately the downloads are broken so you can’t even give it a try). I’m still LMAO :joy: :joy: :joy:


(Terry Simons) #5

I was able to boot my M3 off of the 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img file but I had issued decompressing it with OS X’s built in compression tool. I had to use Stuffit Expander to get the image to properly decompress.

I also had issues with HDMI. I had to use an FTDI console cable, but was able to boot up and login.


#6

[quote=“terrymisu, post:5, topic:772”] I was able to boot my M3 off of the 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img file[/quote]

Which one? Did you realise that they provide two different images with the same name? This “Raspbian” image exists in a version from 2015-11-21 and in another one from 2015-12-08. Both provided without version number and under the same link. The former not containing many essential fixes and the latter maybe.

Why does nobody cares about this?

I’ve told them many times: EVERY image they provide here is somewhat corrupted. Neither OS X decompress tool nor unzip accept them. At least they provide NOW MD5 checksums but only for some and not all images. It’s useless to complain, it will be as bad as with the M2 half a year ago…


(Terry Simons) #7

I provided the exact filename that I used - 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img.zip

I don’t think so. I suspect that the problem is that the version of whatever tool they’re using is much newer than what’s in OS X, and possibly whatever tools you’re using. Here’s why:

Brighid:Downloads terry$ unzip 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img.zip Archive: 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img.zip skipping: 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img need PK compat. v4.5 (can do v2.1)

It LOOKS to me like the zip tools in OS X can only support PK v2.1, but whatever the Banana Pi folks used requires v4.5 to decompress. The OS X graphical tools, and probably other tools probably don’t actually throw an error or useful dialog for this, but the command line version of unzip on OS X tells you about the mismatch.

Once I saw that, I tried Stuffit Expander, and everything worked fine. The resulting image mounts in OS X, and I’m able to use dd to write it to an SD card. The SD card boots fine on the Banana Pi, and I suspect the same would be true for the other images they posted.

I don’t think the images are corrupted at all. I think your zip tools are ignoring the version requirements and forcing an “unzip” that results in a corrupted file, but I suspect the zip archive itself is perfectly fine, and would decompress properly with the correct tool(s).


(Terry Simons) #8

Brighid:Downloads terry$ md5 2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img.zip MD5 (2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img.zip) = 966dcbdcd1e6965dedba4805753fc31c


#9

Rely on ditto.

Fine, that means that you’re using the image from 2015-12-08. Everything clear now?

They threw together an OS image sometimes in November that doesn’t contain the latest fixes. Then they realised that and released an update of this image 2 weeks later. They don’t increment a version number, they previsouly not even supplied a checksum to check download integrity, they just rerelease an OS image with a lot of fixed bugs with the exact same name as two weeks ago (and all they did was to replace the first few MB on the image, something that would be possible from within the running image – an UPGRADE mechanism – but they refuse to implement this)

Users that used the image from back then won’t even realize that they should update. But the funnny thing is: They can’t update because the moronic development attempt prevents that. They would have to reflash the update image. They still don’t implement an upgrade routine. But it’s useless to complain and useless to discuss.

The manufacturer doesn’t care about these issues and users also don’t care. So everbody happy here.

BTW: I used “The Unarchiver” last week as I do now. Back then all three available Linux images were definitely corrupted: http://linux-sunxi.org/User:Tkaiser#Manufacturer.27s_OS_images

If SinoVoip would care they would provide OS images with a minimal download size: Just a few easy steps that every responsible vendor automates: http://www.cnx-software.com/2015/10/13/how-to-reduce-sd-card-firmware-images-download-size/

But they don’t care about this, they just want to create the impression of activity. Every OS image here is the same horrible Android bootloader stuff combined with a rootfs they found somewhere. But since users don’t care and are happy with this crap…


(Terry Simons) #10

Cool. With the instructions I provided you should be able to get a bootable SD card. Happy hacking.


(Terry Simons) #11

By the way, the MD5 of the successfully decompressed image is:

Brighid:~ terry$ md5 ~/Downloads/2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img MD5 (/Users/terry/Downloads/2015-11-21-raspbian-jessie-lite-bpi-m3-sd-emmc.img) = 3358a332dd36f740fd6e5b39550e1ee1


#12

Ok, SinoVoip is totally right. They don’t have to care about software/support since users also don’t care.

They can sell every shit they want as long as it’s called Banana.

FYI: http://forum.armbian.com/index.php/topic/474-quick-review-of-banana-pi-m3/

I have an own OS image that runs faster than every provided here since I rebuilt the whole stuff with a more recent GCC and better settings. I can use 1-Wire, you can’t (SinoVoip forgot to activate it). I can upgrade my image everytime I want, you can’t since the magic happens not inside the rootfs but inside the first sectors of SD-card/eMMC where u-boot and kernel/ramdisk live:

root@BPiM3:/tmp# file -s boot.img 
boot.img: Android bootimg, kernel (0x40008000), ramdisk (0x41000000), page size: 2048

root@BPiM3:/tmp# python split_boot_img.py -i boot.img -o parts
Creating directory: parts
kernel size: 12838404
Base (hex): 0x40000000
ramdisk size: 3146144
second size: 0
page size: 2048
product name:  a83t
cmdline:  
File parts/zImage written (length=12838404).
File parts/ramdisk.gz written (length=3146144).

I can boot from USB (adjusting sunxi-pack/chips/sun8iw6p1/configs//env.cfg*), you can’t. And so on… happy suffering.

It’s not about that I’m able to do this (everyone is able to do that who’s willing to dig into Allwinner’s SDK/BSP). It’s about that SinoVoip doesn’t care, provides only crap and users seem to be happy with that.


#13

Mate, while I’m sure we all agree with many of the issues you’ve raised in your many postings, I really don’t understand why you feel the need to wrap all your writings in such revolting attitude. If you’ve got issues, then write about them, but what’s the point in behaving like a total douche bag? What are you hoping to achieve?

Posting comments telling people you know about a certain issue with a particular release but that you’re not going to tell anyone what it is… it’s just pathetic. Real troll behaviour.

The only conclusion I can draw is that you’ve got some hidden axe to grind with these guys that has nothing to do with what you’re discussing here. If not, then how about you save the attitude for somewhere else, and either offer helpful suggestions, or don’t?

L.


(Bruce) #14

Although I agree with you in regard to the attitude, I am willing to look past it and write in support of @tkaiser. Not only has he consistently helped other forum members with their problems but he has also provided reliable and useful information for all users of the forum.

I for one would rather have his input, than to not have it.


#15

@tkaiser: I actually agree. You’ve got the point. Unfortuantely I dind’t do a poroper research and already considering sending this whole thing back as it is… I am not willing to waste any more of my life time with finding and fixing bugs… Regards!