January 21, 2026

Allwinner H5 chip - U-boot FIT buffer bug

After building U-boot from source for the OrangePi PC 2, we get the following message when we boot it up: 
U-Boot SPL 2026.01-rc3trebisky-00026-g31bf4a1c3087-dirty (Jan 20 2026 - 22:19:01 -0700)
DRAM: 1024 MiB
Trying to boot from MMC1
alloc space exhausted ptr 10fe00 limit 100000
Could not get FIT buffer of 1113088 bytes
	check CONFIG_SPL_SYS_MALLOC_F_LEN
I tried changing the value of CONFIG_SPL_SYS_MALLOC_F_LEN with no good results (see the prior page in this series) so now it is time to dig deeper.

I am happy to be able to search and find the message "Could not get FIT buffer of 1113088 bytes" coming from the file common/spl/spl_fit.c in the function spl_get_fit_load_buffer(). The size is suggestive. This is close to the final size of the U-boot executable itself.

So, what is a FIT?

FIT is "flat image tree". It is a file format that allows several things to be contained within it. For example the U-boot binary and the device tree could both be contained within a FIT file. It is entirely possible for just a single thing to be contained. The "mkimage" utility that comes with U-boot will pack things into a FIT file.
Some image sizes are: 
-rw-r--r-- 1 tom tom 1041584 Jan 20 22:20 u-boot.bin
-rw-r--r-- 1 tom tom 1145437 Jan 20 22:20 u-boot-sunxi-with-spl.bin

MALLOC config settings

Here is what I currently see in the .config file. 
CONFIG_SYS_MALLOC_LEN=0x4020000
CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x100000
CONFIG_SPL_SYS_MALLOC_F=y
CONFIG_SYS_MALLOC_F=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
# CONFIG_SPL_SYS_MALLOC_CLEAR_ON_INIT is not set
# CONFIG_SYS_MALLOC_DEFAULT_TO_INIT is not set
# CONFIG_SYS_MALLOC_BOOTPARAMS is not set
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
# CONFIG_SPL_SYS_MALLOC is not set
The error messages gives these values: 
0x10fe00 = 1,113,600
0x100000 = 1,048,576
And it announces it cannot get a buffer of 1113088 (0x10fc00) bytes.

Give this some thought

A likely target is to increase the size in this line: 
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x100000
I am guessing, but this is some kind of MALLOC related size that matches the 0x100000 limit given in the error message.

Another approach entirely is to reduce the size of the U-boot executable. In fact, it is my guess that this problem has arisen by slow growth (feature creep) in U-Boot. I would like to omit the USB boot features anyway, just to avoid the delays when I reset my system.

First though, I search for CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN in the U-boot source. It is only used in common/spl/spl.c and a key line is: 

gd->malloc_limit = CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN;
So let's try bumping this from 0x100000 to 0x200000 in
In other words, add this line to configs/orangepi_pc2_defconfig 
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200000
Then we rebuild U-boot as per the prior post in this series: 
cd /Projects/ARM-sources/
cd u-boot
export BL31="/Projects/ARM-sources/arm-trusted-firmware/build/sun50i_a64/release/bl31/bl31.elf"
export CROSS_COMPILE=aarch64-linux-gnu-
export LOCALVERSION="trebisky"
export SCP=/dev/null
make distclean
make clean
make orangepi_pc2_defconfig
make
cd ..
dd if=u-boot/u-boot-sunxi-with-spl.bin of=h5.img bs=1K seek=8 conv=notrunc
su
dd if=h5.img of=/dev/sdf
sync
exit
Now we just get this: 
U-Boot SPL 2026.01-rc3trebisky-00026-g31bf4a1c3087-dirty (Jan 21 2026 - 16:53:58 -0700)
DRAM: 1024 MiB
Trying to boot from MMC1
Too bad we don't have JTAG -- we could at least find out where the processor is running.

Get rid of USB

We look at the .config file to see what options are set that select USB.
These options are active: 
CONFIG_CMD_USB=y
CONFIG_USB_FUNCTION_FASTBOOT=y
CONFIG_FASTBOOT_USB_DEV=0
CONFIG_PHY_SUN4I_USB=y
CONFIG_INITIAL_USB_SCAN_DELAY=0
CONFIG_USB=y
CONFIG_DM_USB=y
# USB Host Controller Drivers
CONFIG_USB_HOST=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_OHCI_NEW=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_GENERIC=y
# MUSB Controller Driver
CONFIG_USB_MUSB_GADGET=y
CONFIG_USB_MUSB_SUNXI=y
CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT=y
CONFIG_USB_MUSB_PIO_ONLY=y
CONFIG_USB_MUSB_FIXED_CONFIGDATA=y
# USB peripherals
CONFIG_USB_STORAGE=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=1000
CONFIG_USB_KEYBOARD_FN_KEYS=y
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="Allwinner Technology"
CONFIG_USB_GADGET_VENDOR_NUM=0x1f3a
CONFIG_USB_GADGET_PRODUCT_NUM=0x1010
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_ETHER=y
CONFIG_USB_ETH_RNDIS=y
CONFIG_USBNET_DEV_ADDR="de:ad:be:ef:00:01"
CONFIG_USBNET_HOST_ADDR="de:ad:be:ef:00:00"
We comment out 3 USB related lines, and add three lines to configs/orangepi_pc2_defconfig: 
#CONFIG_USB_EHCI_HCD=y
#CONFIG_USB_OHCI_HCD=y
#CONFIG_USB_MUSB_GADGET=y
CONFIG_USB=n
CONFIG_DM_USB=n
CONFIG_USB_HOST=n
Then we rebuild and try to boot it. Again we get: 
U-Boot SPL 2026.01-rc3trebisky-00026-g31bf4a1c3087-dirty (Jan 21 2026 - 17:12:53 -0700)
DRAM: 1024 MiB
Trying to boot from MMC1
Now I start to wonder if something is wrong with the boot image.
What we should see is something like: 
U-Boot SPL 2020.04-armbian (Jun 03 2020 - 07:47:47 +0200)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.3(debug):ec29ce6-dirty
NOTICE:  BL31: Built : 07:47:38, Jun  3 2020
In other words, BL31 should get booted from MMC1 and start giving us messages. It is of course possible that there is something broken about BL31 and it is not talking to us.

Try a boot image from the johang collection

He says this was built 1-1-2026 and corresponds to U-Boot v2025.10 along with ATF V2.9.0. This image works fine! I get: 
U-Boot SPL 2025.10johang-dirty (Jan 01 2026 - 02:26:24 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.9(debug):v2.9.0
NOTICE:  BL31: Built : 02:26:14, Jan  1 2026
NOTICE:  BL31: Detected Allwinner H5 SoC (1718)
One thing to note is that this is U-boot 2025.10 whereas I have been working with 2026.01-rc3 I could go back and explicitly select the 2025.10 branch.
This could be done as follows. 
U_BOOT_GIT_URL_DEFAULT="https://source.denx.de/u-boot/u-boot.git/"
U_BOOT_GIT_REV="v2025.10"

if [ -n "${U_BOOT_GIT_REV}" ]
then
    git clone --depth 1 \
              --reference-if-able "${WORKDIR}/u-boot" \
              --branch "${U_BOOT_GIT_REV}" \
              "${U_BOOT_GIT_URL:-${U_BOOT_GIT_URL_DEFAULT}}" u-boot
The -n test checks if the length of the string is non-zero. The :- operator in A:-B uses the first A if it is set, the second B if not. The --reference-if-able will speed things up if there is already a copy on the local machine. So this boils down to: 
U_BOOT_GIT_URL_DEFAULT="https://source.denx.de/u-boot/u-boot.git/"
git clone --depth 1 --branch "v2025.10" ${U_BOOT_GIT_URL_DEFAULT u-boot
More on the next several pages.

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org