Tritium ALL-H3-CC-H5 Allwinner SoC - ALL-H3-CC-H5v1.1a - boot, mmc, and other issues with debian

Hello,

I apologize in advance if I placed this in the wrong thread/catagory.

Recently I purchased 4 Tritium ALL-H3-CC-H5 Allwinner SoC systems from LoveRPI. I also purchased the recommended microSD cards from that supplier and I have experienced a lot of issues. I also purchased the recommended power adapter which is rated for 5V @ 3A.

I downloaded the recommended SD card imager application from LibreComputer website as well as the recommended debian distro.

Found here:
Information

I downloaded the files, installed the imager, wrote the image to the 4 SSD cards and experienced the following types of issues:

Issues:

  • failing to boot
    - the red power (board) LED would come on, the orange and green ethernet LEDs come on and stay on (I have learned since that this is probably the device going into FEL mode)
    - sometimes I could push the U-Boot button and the OS will load, other times it won’t
    - after doing work on the units I can reboot them and then the boot issues will occur
    - doing a poweroff would cause odd issues from services not shutting down to the board locking up
    - I would press CTRL+ALT+DEL several times to force a reboot and the system would still hang
    - after this the system would apparently go into FEL mode, I would take the SD card out, put in my main system and mount the partitions and the boot partition would have errors (“partition not cleanly unmounted”, which makes sense), I would fix the error, put the card back in the units and sometimes they would boot and sometimes they would not

  • random MMC errors
    - I would get fs errors that the system couldn’t write to the journal or that journaling failed (the image formats the root partition as btrfs)
    - I would also get SoC mmc errors “sunxi-mmc 1c11000.mmc: data error, sending stop command sunxi-mmc 1c11000.mmc: send stop command failed”

I presumed these issues were related to the quality of the MicroSD cards so I went out and purchased new cards that are from a name brand and rated for C10, U3, A2, v30 hoping that it would resolve the issue.

I used the imager to write debian to the SDcard, plugged in, powered on a unit, and same issue. Red LED/FEL mode/ no booting.

I then switched to Armbian on the new cards. Booting the cards from a fresh write is working well. Rebooting working well. Executing poweroff, turning the device off and on again is working. I simulated a power failure and the system did not go into FEL mode but the unit also seems to have failed to boot. Red and green board LEDs are on, orange and green ethernet LEDs are on solid (no ethernet cable connected), and the blue “disk activity” LED not illuminating all. Usually when you power up the blue LED will very quickly flash and after a few moments the orange and green ethernet LEDs will turn off, then the system will begin to boot and the blue LED will flash constantly of course.

FYI I downloaded the recommended armbian for my units from the armbian website.

UPDATE: I pulled the SD card out, powered on and the blue LED flashed, and the unit entered FEL mode, then I turned the unit off, reinserted the SD card, turned it on, and noted that the blue LED did very quick flash again and the unit went into “boot mode” (red+green board leds on, ethernet orange+green ethernet on) but it has been hanging there for 5 minutes or so. I have tried this with the keyboard connected and disconnected, with the ethernet connected and disconnected, and with the monitor connected and disconnected all combinations there within. Same result. After a simulated power outage the unit does not correctly attempt to boot.

Based on my experience so far if you are looking at purchasing the ALL-H3-CC-H5 (the SoC supports hardware crypto which is why chose it) I would advise to stay away and after more reading with Allwinner SoC’s I am tempted to say stay aware form allwinner altogether.

update: I will change my criticism to say if you use Armbian on these boards and remember to set the bootflag on the root partition you will be fine.

-grendel

edit: fixed some grammar issues I noticed immediately after I hit post lol

edit and update: I just noticed that the orange and green ethernet LEDs flash when the unit detects the OS is going to actually boot into it. I just tested an Armbian image on another SD card and took note of this fact and verified on the failing card that when it fails to boot the LEDs do not flash. The flash happens within 2 seconds of applying power.

Good news perhaps.

I just mounted the SD card that was failing to boot into my main system and fdisk showed that the root partition for Armbian (btw, the Armbian image does not utilize a EFI partition) was not marked for boot. So I flagged it for booting, sync’d the disk, and put it back in the unit and that unit ran fsck and is up and running.

I will simulate another power failure. I hope this is not a fluke.

OMG. It wasn’t a fluke. I turned off the unit (the power adapter I have is switched) and the unit came back on.

So maybe it was just an oddity that after first boot the armbian partition’s boot flag gets removed? I am not sure–after 2 power cuts and the unit recovering I call it a success.

Another poster asked a question and deleted it before I could respond as I was typing up my other messages.

The general idea of the question was:
How fast did the imager application write the data to the SD card because they noted on theirs it was writing at 10Mibi/s and it turned out that was an issue for them.

The recommended debian imager app reported it wrote the image at 30 to 40 Mibi/s.

The recommended Armbian imager does not report the speed. However the Armbian image I am using, uncompressed, is approximate 2Gibi. It writes the image in 4m37s…Doing some quick maths 2048Mibi / 277 seconds equals 7.4 Mibi/s.

I just loaded up another card, booted the unit and in fact, upon first boot the boot flag is removed.

grendel@tritium-h5:~$ sudo fdisk -l /dev/mmcblk0
[sudo] password for grendel:
Disk /dev/mmcblk0: 59.23 GiB, 63596134400 bytes, 124211200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x91ab3a62

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 122945536 122937345 58.6G 83 Linux

VS my other system I was doing all the testing on, where I manually set the boot flag:
grendel@warehouse:~$ sudo fdisk -l /dev/mmcblk0
[sudo] password for grendel:
Disk /dev/mmcblk0: 59.23 GiB, 63596134400 bytes, 124211200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x91ab3a62

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 8192 122945536 122937345 58.6G 83 Linux

VS a freshly written Armbian SD card (plugged in via USB adapter):
grendel@warehouse:~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 59.23 GiB, 63596134400 bytes, 124211200 sectors
Disk model: USB3.0 CRW -SD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x91ab3a62

Device Boot Start End Sectors Size Id Type
/dev/sdb1 8192 4079615 4071424 1.9G 83 Linux

^^^ For some reason this boots the first time no issue though and continues to work through reboots until you cut power.