topic LS1021A-IOT SDK and SD Card kernel version mismatch? in Layerscape

LS1021A-IOT SDK and SD Card kernel version mismatch?

justineno — Fri, 16 Sep 2016 00:25:48 GMT

I am attempting to build an out-of-tree kernel module against the LS1021A-IOT SDK (specifically, "LS1021A-IoT Rev B Gateway Reference Design SDK Source ISO") and load it on my platform, the LS1021A-IOT. This is not the Rev B board with Rev 2.0 silicon, i.e.,

>U-Boot SPL 2014.01Layerscape-SDK-V1.3+g50d6848 (Dec 01 2014 - 13:42:50)

>
>U-Boot 2014.01Layerscape-SDK-V1.3+g50d6848 (Dec 01 2014 - 13:42:50)

>CPU: Freescale LayerScape LS1021E, Version: 1.0, (0x87081110)

I built the module and tried to load it, which produced the following result:

>root@FSL:~/test# insmod ./test.ko
>[264884.711792] test: version magic '3.12.37-rt51+ls1 SMP mod_unload ARMv7 p2v8 ' should be '3.12.0+ SMP mod_unload ARMv7 p2v8 '
>insmod: ERROR: could not insert module ./test.ko: Invalid module format

Here are the steps I used to generate the module:

1. Installed SDK according to START_HERE.html on ISO

2. Built fsl-image-flash according to same

3. Rebuilt kernel image according to same (no changes)

4. Installed standalone toolchain according to same

5. Built hostprogs:

>cd /opt/sdk/Freescale-Linux-SDK-for-LS1021A-IOT-Rev2-v0.4-20150907-yocto.iso/build_ls1021aiot_release/tmp/work/ls1021aiot-fsl-linux-gnueabi/linux-ls1/3.12-r0/sysroot-destdir/usr/src/kernel

>make ARCH=arm CROSS_COMPILE=/opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/x86_64-fslsdk-linux/usr/bin/arm-fsl-linux-gnueabi/arm-fsl-linux-gnueabi- scripts

6. Built external module:

> cd ~/test

> make -C /opt/sdk/Freescale-Linux-SDK-for-LS1021A-IOT-Rev2-v0.4-20150907-yocto.iso/build_ls1021aiot_release/tmp/work/ls1021aiot-fsl-linux-gnueabi/linux-ls1/3.12-r0/sysroot-destdir/usr/src/kernel M=`pwd` modules

The module appears valid, but it will not load due to the version mismatch. Is there an SDK available which matches the original LS1021A-IOT? The only download I could find was the Rev B version listed above. Some of the other QorIQ SDKs appear to have Cortex-A7 support, but it's not clear if they target this board.

Thank You

Re: LS1021A-IOT SDK and SD Card kernel version mismatch?

Pavel — Tue, 20 Sep 2016 05:30:23 GMT

See the following page about toolchain installing:

https://freescale.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-B7570271-9B1B-461A-A242-753FA06755C4

Usually the following command sequence is used for test.c file compiling using toolchain:

source /opt/fsl-networking/QorIQ-SDK-V1.8/environment-setup-cortexa7hf-vfp-neon-fsl-linux-gnueabi

Testing of the path from previous command:

echo $PATH

Similar message you should see:

/opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/x86_64-fslsdk-linux/usr/bin:/opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/x86_64-fslsdk-linux/usr/bin/arm-fsl-linux-gnueabi:/opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/x86_64-fslsdk-linux/usr/bin:/opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/x86_64-fslsdk-linux/usr/bin/arm-fsl-linux-gnueabi:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Compile the test.c file:

$CC test.c -o test.elf

Look at the following page about module compiling:

https://freescale.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-738EAE8F-745B-43C6-8BC6-54C59B8AB5F5

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: LS1021A-IOT SDK and SD Card kernel version mismatch?

justineno — Thu, 22 Sep 2016 19:54:14 GMT

Hi Pavel,

Thank you for the response, but it doesn't really address the question. The fundamental issue is that the kernel version pre-installed on my SD card:

>root@FSL:~# uname -a
>Linux FSL 3.12.0+ #1 SMP Mon Dec 1 13:35:02 CST 2014 armv7l GNU/Linux

does not match with what's provided in the SDK:

>$ more Freescale-Linux-SDK-for-LS1021A-IOT-Rev2-v0.4-20150907-yocto.iso/meta-fsl-arm/recipes-kernel/linux/linux-ls1_3.12.bb
>...
>SRCREV = "aaa395f27e077f51c75c6aefc7bbec44732e9742"

>...

>$ cd Freescale-Linux-SDK-for-LS1021A-IOT-Rev2-v0.4-20150907-yocto.iso/sources/git2/sw-stash.freescale.net.scm.dnnpi.ls1-linux.git

>$ git show aaa395f27e077f51c75c6aefc7bbec44732e9742:Makefile
>VERSION = 3
>PATCHLEVEL = 12
>SUBLEVEL = 37

>...

Hence, 3.12.0 vs 3.12.37. Therefore, any kernel module built using the SDK cannot be loaded onto the system.

Anyway, to assist others, I've found a workaround for my issue:

>$ more Freescale-Linux-SDK-for-LS1021A-IOT-Rev2-v0.4-20150907-yocto.iso/meta-fsl-arm/recipes-kernel/linux/linux-ls1.inc

>...

>SRC_URI = "git://sw-stash.freescale.net/scm/dnnpi/ls1-linux.git;branch=LS1-SDK-Rev2.0;protocol=http"

>...

>$ cd Freescale-Linux-SDK-for-LS1021A-IOT-Rev2-v0.4-20150907-yocto.iso/sources/git2/sw-stash.freescale.net.scm.dnnpi.ls1-linux.git

>$ git branch -a
> LS1-HSSI
> LS1-IOT
> LS1-SDK
> LS1-SDK-Rev2.0
> LS1-SDK1.5
> ls1-dev
> ls1-emu
> ls1-emu-2.0
> ls1-emu2.0-rebase
>* master

You can see the kernel recipe extracts the LS1-SDK-Rev2.0 branch, which contains kernel 3.12.37. I explored the ls1-linux repository and found that at least the LS1-IOT and ls1-dev branches contain 3.12.0. To build my module, I:

Checked out LS1-IOT
Built the kernel
Built my out-of-tree module against the resulting kernel

It is unlikely that the kernel resulting from (2) exactly matches what's on the SD card, but this was sufficient to build a compatible module which loads successfully.

It is frustrating that the provided SDK cannot reproduce the software shipping with this platform. In fact, the accompanying documentation never mentions fsl-image-rds, though I suspect this is what's present on my system as it serves a web page claiming "Firmware Freescale-RDS - ARM Cortex A7 V4.24"

Re: LS1021A-IOT SDK and SD Card kernel version mismatch?

Pavel — Fri, 23 Sep 2016 03:38:46 GMT

It is correct solution. Recompile module using toolchain from the same core as using core.

Have a great day,
Pavel Chubakov