• 0

Armbian Buster on CubieTruck - Endless boot loop


1 1


Hi All

I am not able to run Armbian Buster from the Downloads page (https://www.armbian.com/cubietruck/) on the CT board.


Other images run fine, including:

- Armbian_5.65_Cubietruck_Debian_stretch_next_4.14.78 (from archive)
- Armbian_5.65_Cubietruck_Ubuntu_bionic_next_4.14.78 (from archive)

- openwrt-19.07.7-sunxi-cortexa7-sun7i-a20-cubietruck-squashfs-sdcard.img.gz (from OpenWrt downloads site)

The problem is that it endlessly reboots after resetting the CPU. The output from the serial port is shown below.

I can interrupt the Autoboot and get to the Uboot console ok. The output from printenv is also shown below.


Any suggestions as to what might be the problem would be greatly appreciated.

If anyone has this set up working, a copy of the printenv output would be great to compare.


Thanks in advance for any help.





U-Boot SPL 2021.04-armbian (May 06 2021 - 17:01:36 +0000)
DRAM: 2048 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1

U-Boot 2021.04-armbian (May 06 2021 - 17:01:36 +0000) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubietruck
I2C:   ready
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c12000: 1
Loading Environment from FAT... Card did not respond to voltage select! : -110
Setting up a 1024x768 vga console (overscan 0x0)
In:    serial
Out:   vga
Err:   vga
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@1c50000, eth1: usb_ether
230454 bytes read in 14 ms (15.7 MiB/s)
starting USB...
Bus usb@1c14000: USB EHCI 1.00
Bus usb@1c14400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
Bus usb@1c1c400: USB OHCI 1.0
scanning bus usb@1c14000 for devices... 1 USB Device(s) found
scanning bus usb@1c14400 for devices... 1 USB Device(s) found
scanning bus usb@1c1c000 for devices... 1 USB Device(s) found
scanning bus usb@1c1c400 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3967 bytes read in 2 ms (1.9 MiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
154 bytes read in 2 ms (75.2 KiB/s)
9931076 bytes read in 546 ms (17.3 MiB/s)
7973464 bytes read in 439 ms (17.3 MiB/s)
Found mainline kernel configuration
43983 bytes read in 6 ms (7 MiB/s)
5532 bytes read in 4 ms (1.3 MiB/s)
Applying kernel provided DT fixup script (sun7i-a20-fixup.scr)
## Executing script at 45000000
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    9931012 Bytes = 9.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
EHCI failed to shut down host controller.
data abort
pc : [<bef89cec>]       lr : [<00000011>]
reloc pc : [<4a013cec>]       lr : [<8b08a011>]
sp : baf4aa18  ip : bfd00000     fp : befdd678
r10: 00000020  r9 : baf55ec0     r8 : befea28c
r7 : 6c616972  r6 : 00000010     r5 : 275b15ca  r4 : baf9ac50
r3 : baf9ac58  r2 : baf9ac48     r1 : baf9d320  r0 : 00000019
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32 (T)
Code: d005 f027 0501 441d (686d) 07ed
Resetting CPU ...

resetting ...





=> version
U-Boot 2021.04-armbian (May 06 2021 - 17:01:36 +0000) Allwinner Technology

arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025
GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))

=> printenv
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_targets=fel mmc_auto scsi0 usb0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=setenv devtype dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_fel=if test -n ${fel_booted} && test -n ${fel_scriptaddr}; then echo '(FEL boot)'; source ${fel_scriptaddr}; fi
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_mmc_auto=if test ${mmc_bootdev} -eq 1; then run bootcmd_mmc1; run bootcmd_mmc0; elif test ${mmc_bootdev} -eq 0; then run bootcmd_mmc0; run bootcmd_mmc1; fi
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_scsi0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
dfu_alt_info_ram=kernel ram 0x42000000 0x1000000;fdt ram 0x43000000 0x100000;ramdisk ram 0x43300000 0x4000000
distro_bootcmd=scsi_need_init=; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadsplash= for prefix in ${boot_prefixes}; do if test -e mmc 0 ${prefix}boot.bmp; then load mmc 0 ${splashimage} ${prefix}boot.bmp; bmp d ${splashimage}; fi; done
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
preboot=run loadsplash; usb start
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scsi_boot=run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

Environment size: 5201/131068 bytes




Link to post
Share on other sites

8 answers to this question

Recommended Posts

  • 0
4 hours ago, tgillett said:

Any suggestions as to what might be the problem would be greatly appreciated.

Probable cause is that one of the files (dtb, image, ramdisk) are overlapping which means same kernel version (that is smaller) boots, while a bit more features not. Problem is known for months, but our resources are only a tiny fraction needed to keep up with problems that pops up.

If you find out right numbers / fix the problem (for everyone) https://docs.armbian.com/Process_Contribute/


Before you start, check self created image (https://github.com/armbian) - perhaps its already fixed.

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

Hi Igor

Thanks very much for your response.
This is my first day working with Armbian so it is still something of a learning curve.


I took your advice and set up the build environment and built images for CT with combinations of Current and Legacy versions of the software for Buster and Focal as supported by the tool.

None of these versions would boot correctly, failing in the same manner as the version on the Download page for CT: "Armbian_21.05.1_Cubietruck_buster_current_5.10.34_xfce_desktop"

These images all have "U-Boot 2021.04" in common.  (U-Boot 2021.04-armbian (May 06 2021 - 17:01:36 +0000))


I don't know how to proceed further with debugging, in particular checking for file sizes as you suggested.
I have looked through the documentation Developer Guide / Building Armbian and User Configurations, and through
the build files system, but it is not obvious where this information might be, or how to re-configure.
Obviously I am missing something basic...  


I also explored the archive software a little more.
The most recent version I could find there was:  Armbian_21.02.3_Cubietruck_focal_current_5.10.21
dated March 2021.  This software booted correctly, with "U-Boot 2020.10-armbian"


I also tested several earlier versions with U-Boot 2019.04 and 2019.01 and they also booted correctly.

So I thought it might be worth looking at the environment settings for the different U-Boot versions.


Looking through the printenv output for the two recent versions of U-Boot, there are not a lot of obvious
differences in address settings.
One difference I noticed is the value of the "fdtcontroladdr" setting, as shown below, but I don't know
if it is telling us anything useful.


U-Boot 2020.10
fdtcontroladdr=baf4ddf0    ###

U-Boot 2021.04
fdtcontroladdr=baf4bd80    ###


I am happy to spend some more time on debugging if I can get some pointers in the right direction.



Link to post
Share on other sites

  • 0
27 minutes ago, tgillett said:

So I thought it might be worth looking at the environment settings for the different U-Boot versions

I doubt that has changed, but possible. There are some default values, but we overwrite those with our boot script: https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd Here you could experiment with values. Each time you edit /boot/boot.cmd you need to convert it to boots.scr https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd#L92 You can also override number by editing /boot/armbianEnv.txt which is plain text file.

I am not sure my prediction stands. Its just a hunch worth working on. And this problem is not directly related to Armbian (tools) so you will not find any documentation on this topics there. Perhaps here https://linux-sunxi.org/U-Boot or within u-boot documentation in the code or by looking into the code. That's how our world looks like ...

Link to post
Share on other sites

  • 0

There are more ways:

1. Wait for our next release, when images are rebuild, tested and fixed for other possible problems




2. Easy DIY - build your custom image by using our build tools. Workaround is already applied there




3. Harder DIY


Clone boot loader, find instructions for changing it and apply to the image from download section / your not very well working system on your SD card.


We also provide nightly images, but u-boot is not rebuilt each time - we use the one we have build before. A task is open on this topic, just time to code and test that needs to happen.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


1 1