#define MENDER_BOOTENV_SIZE 0x4000 is missing and value was inherited from config:
by config_mender_defines.h:
/* For sanity checks. /
/#define MENDER_BOOTENV_SIZE ${BOOTENV_SIZE} */ #define MENDER_BOOTENV_SIZE CONFIG_ENV_SIZE
Old:Symbol: ENV_SIZE [=0x20000]
│ Type : hex
│ Prompt: Environment Size
│ Location:
│ (1) -> Environment
│ Defined at board/theobroma-systems/lion_rk3368/Kconfig:15
│ Depends on: ARM [=y] && ARCH_ROCKCHIP [=n] && ROCKCHIP_RK3368 [=n] && TARGET_LION_RK3368 [=n]
Added this to defconfig: echo CONFIG_ENV_SIZE=0x4000 >> $(PKG_BUILD_DIR)/configs/nanopi_neo2_defconfig
New:Symbol: ENV_SIZE [=0x4000]
│ Type : hex
│ Prompt: Environment Size
│ Location:
│ (1) -> Environment
│ Defined at board/theobroma-systems/lion_rk3368/Kconfig:15
│ Depends on: ARM [=y] && ARCH_ROCKCHIP [=n] && ROCKCHIP_RK3368 [=n] && TARGET_LION_RK3368 [=n]
As a sanity check: uboot/.config contains “CONFIG_ENV_SIZE=0x4000”
The reason I am getting ENV_SIZE from uboot config is that I am trying to cover the entire sunxi family and avoid as many target specific files as I can.
Updated readme and config_mender_defines.h in tarball.
I have integrated your patches. Same link failures. Be aware that the failures happen AFTER passing the size test.
To see what I am seeing, trim some features, suggestions:
echo CONFIG_CMD_MISC=n >> (PKG_BUILD_DIR)/configs/nanopi_neo2_defconfig
echo CONFIG_VIDEO_BPP8=n >> (PKG_BUILD_DIR)/configs/nanopi_neo2_defconfig
echo CONFIG_VIDEO_BPP16=n >> (PKG_BUILD_DIR)/configs/nanopi_neo2_defconfig
echo CONFIG_CMD_LOADB=n >> (PKG_BUILD_DIR)/configs/nanopi_neo2_defconfig
echo CONFIG_CMD_LOADS=n >> $(PKG_BUILD_DIR)/configs/nanopi_neo2_defconfig
I tried @MarekBelisko patches as well, but the way I worked around the size limit was by changing in include/configs/sunxi-common.h:
/*
* This is actually (CONFIG_ENV_OFFSET -
* (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)), but the value will be used
* directly in a makefile, without the preprocessor expansion.
*/
#define CONFIG_BOARD_SIZE_LIMIT 0x7e000
to
/*
* This is actually (CONFIG_ENV_OFFSET -
* (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)), but the value will be used
* directly in a makefile, without the preprocessor expansion.
*/
#define CONFIG_BOARD_SIZE_LIMIT 0x37e000
It is safe to do this, because we have changed the ENV_OFFSET to 0x400000, and the limit is there to not overflow the U-boot binary to overlap with the ENV_OFFSET. The default value that they have in U-boot is silly low and that is why it is quite easy to hit it, but I guess it is hard to change in upstream because it would break functionality.
It compiled all the way now with my changes above.
I have been cleaning u-boot b4 each build. I have changed CONFIG_BOARD_SIZE_LIMIT as suggested by mirzak. The extra patch you provided just disables some of the features which I was already disabling, but prefer to keep, so I now pass the size test with no features disabled.
Still failing, same patches and config as you. That leaves two possibilities: toolchain and/or buildsystem state. So going to do a dirclean and complete rebuild, which takes several hours. Will advise.
export ARCH=aarch64
export CROSS_COMPILE=aarch64-linux-
git clone https://github.com/mirzak/u-boot-mender -b nanopi-neo2-2018.11
cd u-boot-mender
make nanopi_neo2_defconfig
make
My build from clean failed in same manner which leaves the openwrt toolchain as the likely culprit.
Thanks for you effort creating the git repo…
I will do this:
1 - alter my makefile to use the toolchain suggested, failing that
2 - The full monty, using your git repo
Since I am creating a Mender solution for openwrt (which they will not accept without full integration), if this interests you, I can setup to allow you to poke around my buildsystem, provide simple instructions, if I have your ssh public key.
Just remembered that u-boot is static, so no interaction with openwrt libraries, kernel (apart from loading), effectively standalone. So, I should be able to swap toolchain to build it, with no dire consequences.
In openwrt, swapped out toolchain (for u-boot) to use aarch64-linux- tools from bootlin.com. Failed with same link errors. Compiled without openwrt patches, using both OpenWrt, Mender recommended toolchains. Same link errors. Mender patches appear to take openwrt u-boot into uncharted territory.
My production schedule forces me to take the out of tree u-boot / flash script approach using bootlin tools and do proper openwrt / Mender integration at some point in the future (give up for now).
We are proceeding with Mender. When I am done, will provide you with scripts and files for the out of tree approach.
I have two issues / suggestions for your neo2 git repo:
The size patch (#define CONFIG_BOARD_SIZE_LIMIT 0x37e000) is missing, so fails on size.
Consider adding bl31.bin (secure boot) to repo
Mender integration is my highest priority task, so won’t take long.
I repeat my offer to provide access (your ssh key) to my build system, or support so you can replicate if you decide to pursue the link failures.
@rossbcan there must be something wrong with openwrt build system. Can you try to enable verbose build for u-boot if it is build with correct toolchain and share log. As we both have no issues with building out of tree there must be something in openwrt build system which change something and thus u-boot build fails.
I also suspect something in the OpenWRT environment is causing this, because the out-of-tree build works. This could mean that OpenWRT applies additional patches that might conflict with the Mender patches, or applies other compile flags that exposes something that you normally do not see or builds different targets.
So I would try to investigate the verbose build log of U-boot and compare to an out-of-tree build to compare as suggested by @MarekBelisko
I do not know much of the OpenWRT build system to be able more specific and ssh access to the environment would not do me much good either as the patches have been verified to work out-of-tree and also together with Yocto (though slightly different bootloader version).
I agree with your conclusion. Have enabled verbose and no obvious problems. As stated: my production schedule prohibits spending a lot of time of full Mender integration.
Here’s the verbose logs for both openwrt and bootlin toolchain builds:
As suspected there are patches that are applied by OpenWRT,
Applying ./patches/002-add-olimex-a13-som.patch using plaintext:
patching file configs/OLIMEX_A13_SOM_defconfig
Applying ./patches/003-add-theobroma-a31-pangolin.patch using plaintext:
patching file arch/arm/dts/Makefile
patching file arch/arm/dts/sun6i-a31.dtsi
patching file arch/arm/dts/sun6i-a31-pangolin.dts
patching file configs/pangolin_defconfig
patching file arch/arm/mach-sunxi/Kconfig
Applying ./patches/062-A20-improve-gmac-upload.patch using plaintext:
patching file configs/A20-OLinuXino-Lime2_defconfig
Applying ./patches/091-sun6i-sync-PLL1-multdiv-with-Boot1.patch using plaintext:
patching file arch/arm/mach-sunxi/clock_sun6i.c
Applying ./patches/093-sun6i-fix-PLL-LDO-voltselect.patch using plaintext:
patching file arch/arm/mach-sunxi/clock_sun6i.c
patching file arch/arm/include/asm/arch-sunxi/prcm.h
Applying ./patches/100-sun6i-alternate-on-UART2.patch using plaintext:
patching file arch/arm/include/asm/arch-sunxi/gpio.h
Applying ./patches/101-sun6i-support-console-on-UART2.patch using plaintext:
patching file arch/arm/mach-sunxi/board.c
patching file include/configs/sunxi-common.h
Applying ./patches/102-sunxi-make_CONS_INDEX-configurable.patch using plaintext:
patching file arch/arm/mach-sunxi/Kconfig
Applying ./patches/200-mkimage-check-environment-for-dtc-binary-location.patch using plaintext:
patching file tools/fit_image.c
Applying ./patches/210-sunxi-deactivate-binman.patch using plaintext:
patching file Makefile
patching file arch/arm/Kconfig
Applying ./patches/221-compatible-old-dtc.patch using plaintext:
patching file scripts/Kbuild.include
patching file scripts/Makefile.extrawarn
Applying ./patches/230-disable-axp209-on-a13-olinuxino.diff using plaintext:
patching file configs/A13-OLinuXino_defconfig
Applying ./patches/240-sun50i-h5-Orange-Pi-Zero-Plus-Fix-SdCard-detection.patch using plaintext:
patching file configs/orangepi_zero_plus_defconfig
So definitely some kind of conflict with above and the patches that are applied at the next stage (the mender patches)
Also based on the log it seems that the SPL build is failing, which could mean that one of the options enabled trough Mender might need a #ifndef CONFIG_SPL_BUILD guard.
If you can upload the OpenWRT patches (from above log) somewhere I could test this and probably would be re-producible in a out-of-tree build
I have built (both toolchains) without openwrt patches - same result. The Mender patches have been refreshed to apply properly after the openwrt patches.
