[Buildroot] Linux driver load failure with BR 2018.05

[Buildroot] Linux driver load failure with BR 2018.05

[Fabrice Mousset | GEOCEPT GmbH]

Hi all,

I have build a custom Linux BS for a i.MX6SX base board (Linux 4.1.15 with Freescale/NXP patches).

Linux boots on device but I've got strange errors for some modules (which are part of Linux source code):
[    7.637965] bcmdhd: disagrees about version of symbol alloc_etherdev_mqs
[    7.644774] bcmdhd: Unknown symbol alloc_etherdev_mqs (err -22)
[    7.650832] bcmdhd: disagrees about version of symbol __nlmsg_put
[    7.657348] bcmdhd: Unknown symbol __nlmsg_put (err -22)
[    7.662748] bcmdhd: disagrees about version of symbol cfg80211_scan_done
[    7.669752] bcmdhd: Unknown symbol cfg80211_scan_done (err -22)
[    7.675814] bcmdhd: disagrees about version of symbol consume_skb
[    7.681916] bcmdhd: Unknown symbol consume_skb (err -22)
[    7.687755] bcmdhd: disagrees about version of symbol unregister_netdev
[    7.694428] bcmdhd: Unknown symbol unregister_netdev (err -22)
[    7.700298] bcmdhd: disagrees about version of symbol cfg80211_remain_on_channel_expired
...
[    8.991856] bcmdhd: disagrees about version of symbol wiphy_free
[    8.998191] bcmdhd: Unknown symbol wiphy_free (err -22)
[    9.003479] bcmdhd: disagrees about version of symbol register_netdevice
[    9.010457] bcmdhd: Unknown symbol register_netdevice (err -22)
modprobe: can't load module bcmdhd (kernel/drivers/net/wireless/bcmdhd/bcmdhd.ko): Invalid argument
...
[    9.951557] gpio_mcp23s08: disagrees about version of symbol dev_err
[    9.961581] gpio_mcp23s08: Unknown symbol dev_err (err -22)
...
modprobe: can't load module gpio_mcp23s08 (kernel/drivers/gpio/gpio-mcp23s08.ko): Invalid argument
...
[   10.037540] mcp251x: disagrees about version of symbol can_free_echo_skb
[   10.046368] mcp251x: Unknown symbol can_free_echo_skb (err -22)
[   10.055396] mcp251x: disagrees about version of symbol can_put_echo_skb
[   10.062025] mcp251x: Unknown symbol can_put_echo_skb (err -22)
[   10.068195] mcp251x: disagrees about version of symbol consume_skb
[   10.074430] mcp251x: Unknown symbol consume_skb (err -22)
[   10.079845] mcp251x: disagrees about version of symbol can_get_echo_skb
[   10.086825] mcp251x: Unknown symbol can_get_echo_skb (err -22)
[modprobe: can't load module mcp251x (kernel/drivers/net/can/spi/mcp251x.ko): Invalid argument



I can't figure out why I have "unknown symbol" errors and only for those drivers? All other drivers are working well (Serial/Ethernet/SDCard/etc).
Thanks' in advance for any help.

Best regards

Fabrice Mousset

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181022/1700eaa2/attachment.html>

[Buildroot] Linux driver load failure with BR 2018.05

[Fabio Estevam]

Hi Fabrice,

On Mon, Oct 22, 2018 at 5:19 PM Fabrice Mousset | GEOCEPT GmbH
<fabrice.mousset@geocept.com> wrote:
>
> Hi all,
>
>
>
> I have build a custom Linux BS for a i.MX6SX base board (Linux 4.1.15 with Freescale/NXP patches).

In the latest Buildroot version we have:

configs/imx6sx-sdb_defconfig: which uses kernel mainline 4.14
configs/freescale_imx6sxsabresd_defconfig: which uses NXP 4.9 kernel

None of them use 4.1.15, so it seems you have selected an old kernel
for your target.

I would suggest you to use mainline kernel if you can.

[Buildroot] Linux driver load failure with BR 2018.05

[Fabrice Mousset | GEOCEPT GmbH]

Hi Fabio and Arnout,

> In the latest Buildroot version we have:
> 
> configs/imx6sx-sdb_defconfig: which uses kernel mainline 4.14
> configs/freescale_imx6sxsabresd_defconfig: which uses NXP 4.9 kernel
> 
> None of them use 4.1.15, so it seems you have selected an old kernel for your
> target.
> 
> I would suggest you to use mainline kernel if you can.

Yes I know this is not an "up to date" Kernel Version, but it is the used by the board manufacturer which we are using.
I have ported a Yocto/Poky BSP to BuildRoot, to not have to use multiple build tools... and in my eyes, Yocto is too big and complex.

I have notice a strange something which looks strange to me in the kernel build command.
After the "make -j9" then is a HOSTCC="/usr/bin/gcc -02  -I/opt/crosstools/sitec-s4/include ..."

Why HOSTCC is using /usr/bin/gcc and not /opt/crosstools/sitec-s4/bin/arm-geocept-linux-gnueabihf-gcc ?

Is there something wrong in my BSP?

> This is an indication that you built the bcmdhd module with a different configuration (or maybe even different kernel version) 
> than whatever module (or core kernel) is  providing alloc_etherdev_mqs. When you do a proper kernel build, it shouldn't 
> happen though. So it looks like you didn't properly install everything to your target (e.g. you updated the modules but not the kernel).

To build and install my Linux kernel and modules, I only use "make linux". Those drivers are from the linux source tree. No external drivers are used.

Best regards

Fabrice

[Buildroot] Linux driver load failure with BR 2018.05

[Peter Korsgaard]

>>>>> "Fabrice" == Fabrice Mousset | GEOCEPT GmbH <fabrice.mousset@geocept.com> writes:

Hi,

 >> I would suggest you to use mainline kernel if you can.

 > Yes I know this is not an "up to date" Kernel Version, but it is the
 > used by the board manufacturer which we are using.
 > I have ported a Yocto/Poky BSP to BuildRoot, to not have to use
 > multiple build tools... and in my eyes, Yocto is too big and complex.

 > I have notice a strange something which looks strange to me in the kernel build command.
 > After the "make -j9" then is a HOSTCC="/usr/bin/gcc -02  -I/opt/crosstools/sitec-s4/include ..."

 > Why HOSTCC is using /usr/bin/gcc and not /opt/crosstools/sitec-s4/bin/arm-geocept-linux-gnueabihf-gcc ?

Because HOSTCC is the compiler used to build stuff for the host
machine.

The -I/opt/crosstools/sitec-s4/includes looks as if you have configured
the Host directory (BR2_HOST_DIR) to that location. This is normally
only done if you want to build toolchain once and then store it there
for later reuse (notice that we now have 'make sdk' to handle such
things instead).

When you do your normal build using that toolchain you should NOT set
BR2_HOST_DIR to that location.

-- 
Bye, Peter Korsgaard

[Buildroot] Linux driver load failure with BR 2018.05

[Fabrice Mousset | GEOCEPT GmbH]

Hi all,

sorry for the noise!

I found my mistake. I have forgot to update the linux kernel in my install script. I have installed an older linux kernel.
This is why I've got those errors.
I think I need more sleep.
Now all works perfectly.

Thanks a lot for you time.

Best regards

Fabrice Mousset

> -----Urspr?ngliche Nachricht-----
> Von: Peter Korsgaard <jacmet@gmail.com> Im Auftrag von Peter Korsgaard
> Gesendet: Dienstag, 23. Oktober 2018 09:04
> An: Fabrice Mousset | GEOCEPT GmbH <fabrice.mousset@geocept.com>
> Cc: 'Fabio Estevam' <festevam@gmail.com>; 'Arnout Vandecappelle'
> <arnout@mind.be>; buildroot <buildroot@busybox.net>
> Betreff: Re: Linux driver load failure with BR 2018.05
> 
> >>>>> "Fabrice" == Fabrice Mousset | GEOCEPT GmbH
> <fabrice.mousset@geocept.com> writes:
> 
> Hi,
> 
>  >> I would suggest you to use mainline kernel if you can.
> 
>  > Yes I know this is not an "up to date" Kernel Version, but it is the  > used by
> the board manufacturer which we are using.
>  > I have ported a Yocto/Poky BSP to BuildRoot, to not have to use  > multiple
> build tools... and in my eyes, Yocto is too big and complex.
> 
>  > I have notice a strange something which looks strange to me in the kernel
> build command.
>  > After the "make -j9" then is a HOSTCC="/usr/bin/gcc -02  -
> I/opt/crosstools/sitec-s4/include ..."
> 
>  > Why HOSTCC is using /usr/bin/gcc and not /opt/crosstools/sitec-s4/bin/arm-
> geocept-linux-gnueabihf-gcc ?
> 
> Because HOSTCC is the compiler used to build stuff for the host machine.
> 
> The -I/opt/crosstools/sitec-s4/includes looks as if you have configured the Host
> directory (BR2_HOST_DIR) to that location. This is normally only done if you
> want to build toolchain once and then store it there for later reuse (notice that
> we now have 'make sdk' to handle such things instead).
> 
> When you do your normal build using that toolchain you should NOT set
> BR2_HOST_DIR to that location.
> 
> --
> Bye, Peter Korsgaard

[Buildroot] Linux driver load failure with BR 2018.05

[Arnout Vandecappelle]

On 10/22/18 2:46 PM, Fabrice Mousset | GEOCEPT GmbH wrote:
> Linux boots on device but I?ve got strange errors for some modules (which are
> part of Linux source code):
> 
> [??? 7.637965] bcmdhd: disagrees about version of symbol alloc_etherdev_mqs

 This is an indication that you built the bcmdhd module with a different
configuration (or maybe even different kernel version) than whatever module (or
core kernel) is providing alloc_etherdev_mqs. When you do a proper kernel build,
it shouldn't happen though. So it looks like you didn't properly install
everything to your target (e.g. you updated the modules but not the kernel).

> 
> [??? 7.644774] bcmdhd: Unknown symbol alloc_etherdev_mqs (err -22)

 It can't find the symbol with the version it requires.

 Regards,
 Arnout

[snip]