u-boot binary too large on compile

baby Onioneer

I am trying to compile basic u-boot binaries using the configuration from here:
https://github.com/OnionIoT/u-boot/blob/master/configs/onion-omega2p_defconfig

I am able to succesfully compile the make but get a u-boot.bin much larger than expected. I get a u-boot.bin of 487 kb while most images i found from the Onion are arond 170 kb. Moreover the Onion has a 192kb max sixe for the bootloader so was wondering if anyone could help me in the right direction. Any help would be greatly appreciated

Here are the steps i took in Ubuntu 22.04.04

sudo apt-get update
sudo apt-get install build-essential libncurses5-dev bc gcc-multilib
Wget https://downloads.openwrt.org/releases/21.02.3/targets/ramips/mt76x8/openwrt-sdk-21.02.3-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64.tar.xz


tar -xvf openwrt-sdk-21.02.3-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64.tar.xz 
cd openwrt-sdk-21.02.3-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64

export STAGING_DIR=$(pwd)/staging_dir
export PATH=$PATH:$STAGING_DIR/toolchain-mipsel_24kc_gcc-8.4.0_musl/bin

export CROSS_COMPILE=mipsel-openwrt-linux-
git clone https://github.com/OnionIoT/u-boot.git
cd u-boot/
make onion-omega2p_defconfig
Make

crispyoz

@baby-Onioneer Just use these steps:

git clone https://github.com/OnionIoT/omega2-bootloader.git
cd omega2-bootloader
./setup_env.sh
make

You can check the repo for any other details you may need.

baby Onioneer

@crispyoz said in u-boot binary too large on compile:

git clone https://github.com/OnionIoT/omega2-bootloader.git

I did succesfully compile that one before but dont see a defconfig file for me to edit and play with, which is why I was using the other git repo. Am I incorrect there and there is a defconfig file I can edit? I found nothing from a find command.

crispyoz

@baby-Onioneer There's no defconfig I have seen in that repo. There a are stack of them for various devices under the main build system. Look in the <build root>/build-dir/hosts/<u-boot version>/configs. Nothing specific to the Omega2 there.

baby Onioneer

@crispyoz Thank

luz

@crispyoz I got here thanks to your hint in the GPIO44 question thread because to free GPIO44 from being switched to output I need to build my own bootloader.

Now I see that setup_env.sh as a first step unpacks a precompiled buildroot/toolchain for an x86 linux host. However I don't have such a thing, my platform is 64bit ARM.

But of course I do have a working mips toolchain built for 64bit ARM as part of the openwrt build. What is the reason to not use the openwrt build environment to build uboot and rather use that pre-packaged buildroot instead?

crispyoz

@luz An interesting question I asked myself when dealing with Omega2Pro flappy GPIO44 issue. I found I could modify the makefile to point to my standard buildroot, however I needed to install gcc-multilib and then it worked fine. I didn't investigate why, perhaps @Lazar-Demin knows.

luz

@crispyoz, @Lazar-Demin having cross-links between build environments, pre-built x86 binaries etc. feels a bit brittle to me, so what I would like to do is getting uboot for omega2 built as an openwrt package.

This is something that already exists (see package/boot/uboot-ramips) in openwrt for another MT76x8 target, the RAVPower RP-WD009.

So I copied that package to make an uboot-omega2 package and made it use my fork of omega2-bootloader (Once this builds, I'll kill the fork and make the needed changes a patchset in the uboot-omega2 package, but for now it's easier to work this way)

At the moment the build fails very early, because the openwrt u-boot.mk is made for the upstream u-boot sources whereas the omega2 version has forked off from 1.1.3 version from upstream about here and includes some static config that the standard build process is trying to generate.

Any help or pointers how to get that right are welcome, it's a bit of a mess right now

[Update hours later:] looks like a huge pain, nothing works as it should, down to C files giving errors because some 1000 fold-nested macros in io.h expand to invalid assembler instructions

{standard input}:2896: Error: operand 2 must be an immediate expression `lb $2,$4($2)'

somehow originating from assember generated from compilingdrivers/ohci-hcd.c:

#APP
 # 309 "/Volumes/CaseSens/openwrt-2/build_dir/target-mipsel_24kc_musl/uboot-omega2-plan44_p44dsbomega2/uboot-omega2-4.3.0.3/include/asm/io.h" 1
	lb	$2,$4($2)
 # 0 "" 2
$LVL204 = .
	.loc 3 309 1 view $LVU687
	.loc 3 309 1 is_stmt 0 view $LVU688
#NO_APP

crispyoz

@luz can you give me the steps you followed and on what OpenWrt release. I can see if I can find the issue, maybe two heads are better than one.

luz

@crispyoz ...maybe two heads are better than one.

certainly !

This is what I tried so far:

on OpenWrt 22.03.5
copied the existing uboot package from package/boot/uboot-ramips into my own package feed as plan44/uboot-omega2
modified the package makefile to pull sources from omega2-bootloader instead of u-boot upstream as in the original Makefile. You can find the changed version here on github.
Tried to make package/uboot-omega2/compile
Realized that one of the main difference between official upstream way to build uboot and the omega version is that the omega2-bootloader repo is pre-configured, i.e. it contains .config, autoconf.h etc. prebuilt so I must prevent running config.mk, see this change
Also I needed to disable the pre-built-toolchain in the uboot Makefile, see this change
The other commits on top of omega2-bootloader were other details I had to fix while trying to compile, some probably caused by my platform (macOS on ARM64).
At the moment, I also need to run
export CROSS_COMPILE=mipsel-openwrt-linux-
before calling make. Of course that should go into the package makefile later.

With this, the build runs through around 20 *.c files successfully and then stops in drivers/ohci-hcd.c with the aforementioned Error: operand 2 must be an immediate expression 'lb $2,$4($2)'problem.

In the meantime I found that this comes from the macros in io.h that are translating I/O port accesses (x86 architecture has separate I/O address space) into single-address space instructions like we have on the MT7688.

Most probably the problem is not in ohci-hcd.c nor in io.h, but in some parameter coming from the build environment, I guess… But I'm currently out of ideas of how to proceed...

I hoped that with OpenWrt natively providing a build environment for u-boot this would be relatively straightforward, but it seems quite the opposite right now

crispyoz

@luz take a look at my fork of your fork. The issue seems to be caused by the use of extern inline in io.h and bitops.h if you change them to static inline it fixes the assembler issue.

Once that's sorted there as some other stuff to fix but I haven't had time to look at this yet.

Lazar Demin

@luz said in u-boot binary too large on compile:

having cross-links between build environments, pre-built x86 binaries etc. feels a bit brittle to me, so what I would like to do is getting uboot for omega2 built as an openwrt package.

I agree, it is brittle. It was something we put in place back when x86 was the only game in town for desktop computing

We also noticed the OpenWRT build system has an option to build the bootloader, but haven't explored that path yet.

Like I mentioned in the Omega2S+ sys_led pin thread, we're contemplating moving to a more modern u-boot. I think this would give us more impact for the time spent.
And we could set it up to be less brittle from the get go.

@luz @crispyoz let me know your thoughts and if you're interested in collaborating on this!

crispyoz

@Lazar-Demin a lot of the issues I'm seeing are caused because of the build tools version gcc 3.4.2 (released 2004), which is 9 major release behind the current 12/13 (I'm using OWRT 23). The issue @luz posted is not so unexpected due to the many changes related to how extern and inline has been implemented/standardised in the last 20 years.

As time permits I'm working though some of the these issues, but keep wondering if as you mentioned it would be better to spend time moving to a modern u-boot. I wonder if we could move to the modern u-boot but patch it to reduce size, or is it better to wait for the Omega3