Building latest u-boot for colibri vf61

Hi,

I’m trying to build the latest u-boot from source but fails to boot on it.

I have picked a recent gcc (gcc-linaro-7.3.1-2018.05-i686_arm-linux-gnueabihf.tar.xz).
I get master from u-boot repo (99431c1c21685fe63d46b6eac995b78ce9adce0a).

I’m doing:
make colibri_vf_config
make all

If I try to load the generated u-boot-dtb.imx via recovery mode, the board doesn’t boot at all (no message).
With older versions (2018.05), I’m able to load it from recovery mode and it seems to run fine.
If I try to flash version 2018.05 using update_uboot command, the board doesn’t boot after a reset.

Is there any additional steps need to boot on latest u-boot?

Regards

Am I right in the assumption that by latest U-Boot you are talking about mainline U-Boot? Why exactly would you not want to use one of our BSP version’s U-Boots? Please also note our support strategy. Concerning mainline U-Boot you may also ask on the relevant mailing list for help.

I still got some issue with UBI in U-Boot and so I also ask some help on u-boot mainline side. I want to check the behavior with latest mainline u-boot (that seems to support vf61) to see if my issue is still present before deeper investigations. Seeing that latest u-boot fails to boot, u-boot team redirect me to Toradex to fix the boot issue

I still got some issue with UBI in U-Boot and so I also ask some help on u-boot mainline side
What is your Issue?

Seeing that latest u-boot fails to boot, u-boot team redirect me to Toradex to fix the boot issue.

As @marcel.tx wrote, for the mainline you should use the mailing list for help. Who exactly directed you to Toradex?

On the u-boot mainline IRC channel, Marex tell me to contact Marcel to get a quick feedback on the latest u-boot booting issue.

It’s just that some EFI morons implemented another useless protocol which consumes another 12K of precious space finally tripping the magic barrier of 512K available consecutive SRAM! Easiest is to just disable that crap. Alternatively one may either boot via SPL to RAM or use a custom linker file taking the non-consecutive SRAM into account.

Thanks for clarifications,

Is there an easy way to remove that useless code with a flag?

Sure, just add # CONFIG_EFI_LOADER is not set e.g. like we have in downstream to resp. config file here.

Thanks, after the update of colibri_vf_defconfig , I’m able to boot on mainline u-boot via Recovery mode. However if I flash it using run update_uboot, it fails to boot (no console output after resetting …).

At that time I will focus on my main problem with UBI u-boot environment on Toradex u-boot version (2016.11): link text.
If I can’t make it work with your help, I will check again with mainline u-boot.

Thanks again for your support

Note that for NAND booting you will need u-boot-nand.imx (see here) which there is no target for in mainline. Have a look here. Or just do something along those lines:

sudo dd bs=1024 count=1 if=/dev/zero of=u-boot-nand.imx
sudo bash -c 'cat u-boot.imx >> u-boot-nand.imx'

Perfect, a mainline u-boot boots properly now!

Thanks for the feedback. Is your UBI Issue also solved?

No, I’m still waiting some feedback from your side on the other thread.

Ok, we are working on this issue and will answer in the other thread.