5 dead BPI-M3 after one year of inactivity

Banana Pi SBCs design BPI-M3(A83T/R18)
1

Dear All,

some years ago ( maybe almost 3 years ) I bought 5 Banana-Pi M3. They were running successfully all over the time. A little bit more than a year ago I replaced these M3 by M64 based on the fact that M64 is a little bit more powerful than M3. I shutdown the M3 and put them into a box. Yesterday I tried to boot one and I had to realize that all 5 of them are dead.

I did everything what came in my mind. I replaced the USB power supply, I replaced the cable. I wrote the SD card with a new image, I took also the old image, I wrote to a brand new SD card. Also tried the USB OTG plug for power instead the power jack I used always. But no way to bring it up.

It always the same. When I power on all 3 LEDs are going on. First the red, than the other two. On the serial console I can watch the boot process. And after about 4.5 seconds the LEDs are dark, the the console hangs. It’s not always at the same boot step. See below. Measuring the current it shows 0 mA power consumption. So it switched off itself. Only unplug/plug from/to power will repeat the boot process until it hangs again. When I hit the return key to stop autoboot I get a prompt and this stays forever.

In my opinion some electronic parts died during this time of inactivity. I also tried to keep it powered on over night. From the old days I know that this big fat condensators died if not used over years. But obviously something similar happened to the M3.

Any ideas what I can do ? Maybe some diagnostics at the boot prompt ? Or did someone else have a similar issue ? I am quite sure if I would run the M3 all the time it would still work.

Kind regards Hans

-- 
    [    4.480048] [mmc]: sdc2 set ios: clk 400000Hz bm PP pm ON vdd 3.3V width 1 timing LEGACY(SDR12) dt B
    [    4.495953] ------------audio_hmic_irq----------[mmc]: *** sunxi_mci_dump_errinfo(L824): smc 2 err, cmd 52,  RTO !!
    [    4.501678] [mmc]: *** sunxi_mci_dump_errinfo(L824): smc 2 err, cmd 52,  RTO !!
    [    4.501705] [mmc]: sdc2 set ios: clk 400000Hz bm PP pm ON vdd 3.3V width 1 timing LEGACY(SDR12) dt B
1 Like
2

Hello, I don’t own a M3 but AFAIK, If you can are getting to the boot screen using UART and reaching the uboot cmd interface there seem to be no problem with the Hardware.

Can you type printenv in uboot command and share the log. Maybe someone with M3 and M3 uboot knowledge can help you with it.

Also have you tried updating the official firmware to the last one from this Link? I assume it must be old firmware with new OS config, as a lot have changed in the uboot.

3

Hello spikerguy,

many thanks coming back to my posting. Below the result of “printenv”. And yes, we tried an image from this link you provided.

I am not sure if a working uboot prompt is really indicating there is no hardware issue. Maybe the boot process of OS is trying to initialize some i/o which wasn’t needed till now.

Kind regards Hans

sunxi#printenv 

board=bpi-m3

boot_fastboot=fastboot

boot_normal=if run checkemmc; then setenv partition 2; fi; if run loadbootenv; then echo Loaded environment from ${bootenv}; env import -t ${scriptaddr} ${filesize}; fi; if test -n "${uenvcmd}"; then echo Running uenvcmd ...; run uenvcmd; fi; sunxi_flash read 40007800 boot;boota 40007800 boot;

boot_recovery=sunxi_flash read 40007800 recovery;boota 40007800 recovery

bootcmd=run setargs_mmc boot_normal

bootdelay=3

bootenv=uEnv.txt

bpi=bananapi

bpiver=1

checkemmc=fatinfo $device 2

chip=a83t

console=ttyS0,115200

device=mmc

enforcing=1

fastboot_key_value_max=0x8

fastboot_key_value_min=0x2

fb_console=tty1

filesize=2A3036

init=/init

kernel=uImage

loadbootenv=fatload $device $partition $scriptaddr ${bpi}/${board}/${service}/${bootenv} || fatload $device $partition $scriptaddr ${bootenv}

loglevel=8

mmc_root=/dev/mmcblk0p2 rootwait

nand_root=/dev/system

panicarg=panic=10

partition=0

partitions=boot-res@mmcblk0p2:env@mmcblk0p5:boot@mmcblk0p6:rootfs@mmcblk0p7:klog@mmcblk0p8:UDISK@mmcblk0p1

recovery_key_value_max=0x13

recovery_key_value_min=0x10

script=script.bin

scriptaddr=0x44000000

service=linux

setargs_mmc=setenv bootargs enforcing=${enforcing} console=${console} console=${fb_console} root=${mmc_root} init=${init} vmalloc=384M ion_cma_list="120m,176m,512m" loglevel=${loglevel} partitions=${partitions} bootmenutimeout=10 datadev=mmcblk1p2

setargs_nand=setenv bootargs enforcing=${enforcing} console=${console} console=${fb_console} root=${nand_root} init=${init} vmalloc=384M ion_cma_list="120m,176m,512m" loglevel=${loglevel} partitions=${partitions}

stderr=serial

stdin=serial

stdout=serial

sunxi_hardware=sun8i

sunxi_serial=00000000000000000000

Environment size: 1775/131068 bytes
1 Like
4

Yes you’re right. I think someone from the BPI team should look into the log and help you with it.

1 Like