Building Linux Kernel fails for Colibri VF50 in BSP5.0

Technical Support
, ,
1

Hi,

i followed the steps described here:

Set machine in local.conf to colibri-vf

Executed bitbake core-image-minimal

When all dependencies were build an error appears when the kernel is build.

ERROR: linux-toradex-4.4.217+gitAUTOINC+4a31b8a351+gitAUTOINC+4a31b8a351-r0 do_compile: oe_runmake failed
ERROR: linux-toradex-4.4.217+gitAUTOINC+4a31b8a351+gitAUTOINC+4a31b8a351-r0 do_compile: Execution of '/home/sebastian/OHP/yocto-trdx/build/tmp/work/colibri_vf-tdx-linux-gnueabi/linux-toradex/4.4.217+gitAUTOINC+4a31b8a351+gitAUTOINC+4a31b8a351-r0/temp/run.do_compile.914009' failed with exit code 1:
  CHK     include/config/kernel.release
  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  Using /home/sebastian/OHP/yocto-trdx/build/tmp/work-shared/colibri-vf/kernel-source as source for kernel
  CHK     scripts/mod/devicetable-offsets.h
make[3]: 'include/generated/mach-types.h' is up to date.
  CHK     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  CHK     include/generated/asm-offsets.h
  CALL    /home/sebastian/OHP/yocto-trdx/build/tmp/work-shared/colibri-vf/kernel-source/scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CHK     kernel/config_data.h
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  CHK     scripts/mod/devicetable-offsets.h
  DTC     arch/arm/boot/dts/vf500-colibri-eval-v3.dtb
./scripts/dtc/dtc: invalid option -- '@'
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv]
  -q, --quiet                
	Quiet: -q suppress warnings, -qq errors, -qqq all
  -I, --in-format <arg>      
	Input formats are:
		dts - device tree source text
		dtb - device tree blob
		fs  - /proc/device-tree style directory
  -o, --out <arg>            
	Output file
  -O, --out-format <arg>     
	Output formats are:
		dts - device tree source text
		dtb - device tree blob
		asm - assembler source
  -V, --out-version <arg>    
	Blob version to produce, defaults to 17 (for dtb and asm output)
  -d, --out-dependency <arg> 
	Output dependency file
  -R, --reserve <arg>        
	Make space for <number> reserve map entries (for dtb and asm output)
  -S, --space <arg>          
	Make the blob at least <bytes> long (extra space)
  -p, --pad <arg>            
	Add padding to the blob of <bytes> long (extra space)
  -b, --boot-cpu <arg>       
	Set the physical boot cpu
  -f, --force                
	Try to produce output even if the input tree has errors
  -i, --include <arg>        
	Add a path to search for include files
  -s, --sort                 
	Sort nodes and properties before outputting (useful for comparing trees)
  -H, --phandle <arg>        
	Valid phandle formats are:
		legacy - "linux,phandle" properties only
		epapr  - "phandle" properties only
		both   - Both "linux,phandle" and "phandle" properties
  -W, --warning <arg>        
	Enable/disable warnings (prefix with "no-")
  -E, --error <arg>          
	Enable/disable errors (prefix with "no-")
  -h, --help                 
	Print this help and exit
  -v, --version              
	Print version and exit

Error: unknown option
make[3]: *** [scripts/Makefile.lib:293: arch/arm/boot/dts/vf500-colibri-eval-v3.dtb] Error 1
make[2]: *** [arch/arm/Makefile:333: vf500-colibri-eval-v3.dtb] Error 2
make[1]: *** [Makefile:152: sub-make] Error 2
make: *** [Makefile:24: __sub-make] Error 2
WARNING: /home/sebastian/OHP/yocto-trdx/build/tmp/work/colibri_vf-tdx-linux-gnueabi/linux-toradex/4.4.217+gitAUTOINC+4a31b8a351+gitAUTOINC+4a31b8a351-r0/temp/run.do_compile.914009:1 exit 1 from 'exit 1'

ERROR: Logfile of failure stored in: /home/sebastian/OHP/yocto-trdx/build/tmp/work/colibri_vf-tdx-linux-gnueabi/linux-toradex/4.4.217+gitAUTOINC+4a31b8a351+gitAUTOINC+4a31b8a351-r0/temp/log.do_compile.914009

Any hints to use the BSP5.0 for Colibri VF50 Modules?

And we would also prepare to use a newer LTS Kernel like 5.4 instead of the 4.4.

Kind regards,
Sebastian

1 Like
2

Unfortunately, this is not supported. Why exactly would you prefer 5.4 LTS over 4.4 SLTS?

3

We’re starting a new version of our product, same hardware but different software. And just liked to use the kernel that has the longest support period and newest softwarepackages available.

Why isn’t it anymore supported? Toradex guarantees that hardware is available till 2028 and in 2021 now newer software is available?!

As an example in yocto rocko, which is base for the BSP2.8 only an ancient openssl1.0.2 is available. Also other software packages are outdated.

4

just liked to use the kernel that has the longest support period

I would suggest for you to research this topic first:

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

Which is why I asked my question about SLTS 4.4 vs. LTS 5.4.

Why isn’t it anymore supported?

We just do not officially support LTS 5.4 on Colibri VF50/VF61. However, you are welcome to try that yourself should you truly believe this is a superior variant.

As an example in yocto rocko

I was under the impression we talked about Linux kernel versions. However, now you talk about the Yocto Project. Anyway, while also not officially supported by us you may still run even very latest master thereof:

5

Thanks for informations about the SLTS Kernel. I wasn’t aware of that. And you’re right I brought two things together. Sorry for that.

So running a 4.4 kernel is also a valid option for us. But we also want to be able to run openssl in newer versions, because we plan to use TLS1.3 in some of out services running on the VF50 module.
Also updating all the other libraries and services sounded like a good idea.

Unfortunately using the latest master of meta-freescale-3rd party isn’t working also.

That was my first try - Starting from an official yocto release (dunfell) and adding the layers which were needed to have all the configurations for the VF50 module.

Here the u-boot do_install() tasks failed. With changes I posted in Is nand padding needed for U-Boot on Yocto 3.1 (dunfell) for Colibri VF50 / u-boot do_install returns error on u-boot-toradex_2020.07 - Technical Support - Toradex Community the u-boot build is running without any errors and u-boot is starting up on my VF50 module.

Also the kernel recipe needed a tweak to get the build running.

I changed meta-toradex-bsp-common/recipes-kernel/linux/linux-toradex_%.bbappend

export DTC_FLAGS = "-@"

to

#export DTC_FLAGS = "-@"

Having a working build in yocto without any errors it tried to start the kernel from u-boot but it gets stuck with “Starting kernel …”.

After that I tried the same with BSP5.0 which also resulted in the same problems. I tweaked the u-boot recipe and the kernel recipe.
Flashed u-boot to the VF50 and tried to start the linux kernel…

But starting the Kernel in u-boot hangs, again, at “Starting kernel …”

The command is used for starting the kernel is:

setenv bootargs console=tty1 console=ttyLP0,115200n8 root=/dev/mmcblk0p2 ro rootwait; load mmc 0:1 ${kernel_addr_r} zImage && load mmc 0:1 ${fdt_addr_r} vf500-colibri-eval-v3.dtb && bootz ${kernel_addr_r} - ${fdt_addr_r}

Can you give me a hint where I can continue my research to get kernel running in an newer yocto environment?

Maybe you have also another idea how to get the newer stuff (openssl a.s.o.) runnning in the older yocto environment from BSP2.8?

6

Hi @seho85

which kernel config did you use for VF? AFAIK Dunfell doesn’t include kernel config for VF. As well I think one of makefiles has to be patched for VF. See attached my working VF defconfig for 5.4 kernel and patch. Try without patch first, but as I remember it won’t build without that patch applied.

VF kernel defconfig
patch

7

Thank you for your answer.

I’ll give that a try and report back.

8

Thank you.

It’s good to know that there is openssl 1.1.1 implementation.

I’ll give that a try, but there are some other packages (vsftpd as example) that we were using that depends on the older open 1.0.2. I will just switch the yocto to use openssl 1.1.1 and see what recipes will fail on build.

Maybe there isn’t to many stuff to patch. But first i’ll try Edwards patch and defconfig with the 5.4er kernel and a newer yocto system.

9

Bsp 2.8b7 is based on the rocky branch of yotcto which include openssl 1.1.1d as marked here: OpenEmbedded Layer Index - openssl. Dunfell is not supported for Vybrid. You would need to backport the recipe from Dunfell to Rocko with taking account of all the dependencies needed for package you need to integrate. Toradex is only supporting rocko branch for Vybrid modules.

10

Yeah, sure. Let us know if the patch and the kernel 5.x has worked.

11

@Edward

I tried your defconf and the patch.

I can confirm that the 5.4er kernel is booting up. But get it starting I needed to use the older u-boot (U-Boot 2016.11-2.7.4).

The newer U-Boot 2020.07 fails with the kernel image. But that could be cause by my tweaks.

Boot 2020.07-5.3.0-devel+git.68f97c8d17f0 (Jun 24 2021 - 07:52:49 +0000)

CPU: Freescale Vybrid VF500 at 396 MHz
Reset cause: POWER ON RESET
DRAM:  128 MiB
NAND:  128 MiB
MMC:   FSL_SDHC: 0
Loading Environment from NAND... OK
In:    serial@40027000
Out:   serial@40027000
Err:   serial@40027000
Model: Toradex Colibri VF50 128MB IT V1.2B, Serial# 06555813
Net:   eth0: fec@400d1000
Hit any key to stop autoboot:  0 
Colibri VFxx # setenv bootargs console=tty1 console=ttyLP0,115200n8 root=/dev/mmcblk0p2 ro rootwait; load mmc 0:1 ${kernel_addr_r} zImage && load mmc 0:1 ${fdt_addr_r} vf500-colibri-eval-v3.dtb && bootz ${kernel_addr_r} - ${fdt_addr_r}
5448472 bytes read in 281 ms (18.5 MiB/s)
27966 bytes read in 14 ms (1.9 MiB/s)
Kernel image @ 0x81000000 [ 0x000000 - 0x532318 ]
## Flattened Device Tree blob at 82000000
   Booting using the fdt blob at 0x82000000
   Loading Device Tree to 8fff6000, end 8ffffd3d ... OK
   Updating MTD partitions...

Starting kernel ...

But I think thats another story :slight_smile:

Thank you very much for your help!

What bootloader/version are you using?

12

I would not recommend mixing and matching stuff like that. Anyway, I just did an OE-core master build and it all worked out just fine after just a few minor hacks like you already found them. The only remaining hiccup is the following being missing in U-Boot 2020.07 to get the latest Linux kernel 4.4.274 booted:

setenv fdt_high 0xffffffff

I guess, that used to be set here (;-p):

http://git.toradex.com/cgit/u-boot-toradex.git/tree/include/configs/colibri_vf.h?h=2016.11-toradex#n123

Please find attached the full log file.

We will push a few updates shortly so OE master may be built again without any hacks required…

13

I’m using U-Boot 2016.11.

Just tried @marcel.tx suggestion regarding missing setenv fdt_high 0xffffffff. Seems booting, but U-Boot 2020.07 seems missing important things. run setupdate hangs bootloader without SD card inserted, writebcb command is missing, perhaps more. 2016.11 doesn’t seem missing something really important to have. Does it?

14

5.4er kernel has worked with that patches from Edward.

15

I can confirm that missing part for booting the kernel was the

setenv fdt_high 0xffffffff

setting.

Adding this setting to the u-boot bootup sequence, the 4.4.217+g4a31b8a3519d kernel booted with u-boot-2020.07.

This is actual kernel version defined in meta-freescale-3rd party for linux-toradex_4.4.

I need to make more changes, dervice out own machine from colibri-vf, add some tweaks to the kernel source, tweaking the u-boot to match our needs. When tweak the kernel i also will update the kernel to 4.4.274.

Having all the stuff together the new yocto environment we were using will contain of:

yocto-dunfell
linux-toradex-4.4
and u-boot-2020.07

Maybe I try to backport the older u-boot to dunfell, but for now we will stick to u-boot-2020.07.

Again, thanks your help!

Kind regards,
Sebastian

16

Yes, I also noticed USB to just hang on U-Boot 2020.07. Well, as we do not officially support such a combination we never tested/validated this. Currently, we don’t have any immediate plans to work on any such. I would suggest for you to stay on U-Boot 2016.11 as that is what we fully tested/validated at one time. As for the Linux kernel and OpenEmbedded you could move to the latest 4.4.274 and OE master which gives you whatever latest stuff the open-source community supports.

17

BTW: The latest kernel.org 4.4.274 backport got merged now.

http://git.toradex.com/cgit/linux-toradex.git/log/?h=toradex_vf_4.4-next

More MRs are in review…

18

The Dunfell based BSP 5.x should build fine again for Colibri VF50/VF61 now with some recent fixes we merged:

http://git.toradex.com/cgit/meta-toradex-nxp.git/log/?h=dunfell-5.x.y

http://git.toradex.com/cgit/meta-toradex-bsp-common.git/log/?h=dunfell-5.x.y

http://git.toradex.com/cgit/meta-toradex-demos.git/log/?h=dunfell-5.x.y

This plus some more fixes will trickle down soon and should also allow building master again.

19

MR for meta-freescale-3rdparty submitted:

20

Thanks again for your effort.

I pulled all the changes and can confirm that changes are fixing the build problem.

As note: A merge of the changes into the dunfell branch in meta-freescale-3rd party was not performed. Changes were just in master branch.

For now I’m using the master branch, with a tweak of of the layer.conf.