tgillett

@Werner Thanks.

@Werner Thanks. I have updated my master and built new images for the CubieTruck and for OPi PC+. The new CT image worked but not the OPi PC+ image. Is it possible that the fix has not been applied to OPi PC+ / H3 as yet, or is the fix inherently common to all Allwinner 32bit devices?

I have tried the image for Buster from the Download page for OrangePi PC Plus, and also built new images from current Git repo. In all cases the device bootloops when it tries to start the kernel. The image from the OrangePi website works ok. This looks like a similar issue as experienced recently with CubieTruck and BananaPi A20 boards (https://armbian.atlassian.net/browse/AR-749) which was fixed with a workaround (https://github.com/armbian/build/pull/2963) Is it possibly the same / similar underlying problem?

I updated my build environment and made a new build for CubieTruck using Buster minimal. Booted the board multiple times and works every time. Thanks for your help.

Hi Igor Thanks for the update. I would like to test this solution on CubieTruck board. What do I need to do to get an updated image please? Thanks Terry

Thanks, I'll take a further look.

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 fdt_addr_r=0x43000000 fdtcontroladdr=baf4ddf0 ### fdtfile=sun7i-a20-cubietruck.dtb fileaddr=66000000 filesize=38436 U-Boot 2021.04 fdt_addr_r=0x43000000 fdtcontroladdr=baf4bd80 ### fdtfile=sun7i-a20-cubietruck.dtb fileaddr=66000000 filesize=38436 I am happy to spend some more time on debugging if I can get some pointers in the right direction. Regards Terry

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. T