[Buildroot] Firmware auto-loading does not work

[Buildroot] Firmware auto-loading does not work

[Guillaume GARDET - Oliséo]

Hello,

I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware auto-loading does not work. I need to do it manually (through sysfs). I tried mdev and eudev, both are not working.

Is there a known bug about that? In busybox, maybe?


Guillaume

[Buildroot] Firmware auto-loading does not work

[Peter Korsgaard]

>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:

 > Hello,
 > I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware
 > auto-loading does not work. I need to do it manually (through
 > sysfs). I tried mdev and eudev, both are not working.

 > Is there a known bug about that? In busybox, maybe?

If you have tried both eudev and mdev, then it is unlikely to be a bug
in busybox (mdev). Are you using busybox modprobe applet or kmod?

What mdev or eudev does is just to read the modalias file from the
device in sysfs and call modprobe with the content. Can you verify that
your driver(s) provide sensible modalias data and that the module gets
correctly loaded if you do:

modprobe "$(cat /sysfs/path/to/device/modalias)"

We do have 1 bugfix in mdev module loading since 2016.05 for modalias
data containing spaces, but if you also have problems with eudev then
that cannot be it:

commit b4fc5a180c81689a982d5c595844331684c14f51
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Jul 1 21:56:19 2016 +0300

    package/busybox: support spaces in module aliases in mdev

    The new change which enabled automatic module loading on boot does not handle
    the cases when module alias includes spaces. It prevents modules to be loaded
    since script fails:

      % find /sys/ -name modalias | xargs sort -u
      sort: /sys/devices/platform/Fixed: No such file or directory

    First alias in question is "platform:Fixed MDIO bus".

    Amend the script to support above like cases.

    Fixes: 07f46c2b6dae ("package/busybox: support automatic module loading with mdev")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

-- 
Bye, Peter Korsgaard

[Buildroot] Firmware auto-loading does not work

[Guillaume GARDET - Oliséo]

Le 25/01/2017 ? 13:51, Peter Korsgaard a ?crit :
>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
>   > Hello,
>   > I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware
>   > auto-loading does not work. I need to do it manually (through
>   > sysfs). I tried mdev and eudev, both are not working.
>
>   > Is there a known bug about that? In busybox, maybe?
>
> If you have tried both eudev and mdev, then it is unlikely to be a bug
> in busybox (mdev). Are you using busybox modprobe applet or kmod?

This is not a problem of module loading (it is working fine) but loading _firmware_ to devices for the WiFi dongle in my case.

Without the _firmware_ loading, the device does not work. I need to load the firmware manually through the sysfs.


Guillaume

[Buildroot] Firmware auto-loading does not work

[Peter Korsgaard]

>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:

 > Le 25/01/2017 ? 13:51, Peter Korsgaard a ?crit :
 >>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
 >> > Hello,
 >> > I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware
 >> > auto-loading does not work. I need to do it manually (through
 >> > sysfs). I tried mdev and eudev, both are not working.
 >> 
 >> > Is there a known bug about that? In busybox, maybe?
 >> 
 >> If you have tried both eudev and mdev, then it is unlikely to be a bug
 >> in busybox (mdev). Are you using busybox modprobe applet or kmod?

 > This is not a problem of module loading (it is working fine) but
 > loading _firmware_ to devices for the WiFi dongle in my case.

Heh, I wonder how I could misread your email so much - Sorry about that.

First of all, our default busybox configuration has
CONFIG_FEATURE_MDEV_LOAD_FIRMWARE disabled. Have you enabled it? Without
that option, mdev doesn't do anything about firmware.

Less ancient (since 3.7, so 2012) Linux kernels directly loads firmware
files from the kernel, so the support in mdev isn't needed, but as you
are using an ancient kernel this doesn't work for you:

commit abb139e75c2cdbb955e840d6331cb5863e409d0e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Oct 3 15:58:32 2012 -0700

    firmware: teach the kernel to load firmware files directly from the filesystem

    This is a first step in allowing people to by-pass udev for loading
    device firmware.  Current versions of udev will deadlock (causing us to
    block for the 30 second timeout) under some circumstances if the
    firmware is loaded as part of the module initialization path, and this
    is causing problems for media drivers in particular.

    The current patch hardcodes the firmware path that udev uses by default,
    and will fall back to the legacy udev mode if the firmware cannot be
    found there.  We'd like to add support for both configuring the paths
    and the fallback behaviour, but in the meantime this hopefully fixes the
    immediate problem, while also giving us a way forward.

    [ v2: Some VFS layer interface cleanups suggested by Al Viro ]
    [ v3: use the default udev paths suggested by Kay Sievers ]

    Suggested-by: Ivan Kalvachev <ikalvachev@gmail.com>
    Acked-by: Greg KH <gregkh@linuxfoundation.org>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
    Cc: Kay Sievers <kay@redhat.com>
    Cc: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Looking at eudev git history, I see that the legacy user space loading
support got removed in 2014, so that is why it isn't working with eudev
either:

commit 3b717594600fa717cdf9bcfd0c7c1b703b245482
Author: Kay Sievers <kay@vrfy.org>
Date:   Mon Sep 1 09:07:49 2014 -0400

   udev: remove userspace firmware loading support

   Signed-off-by: Anthony G. Basile <blueness@gentoo.org>

We should probably enable CONFIG_FEATURE_MDEV_LOAD_FIRMWARE in our
default busybox.config to better support these old systems.

Can you confirm that it works if you enable that option.

-- 
Bye, Peter Korsgaard

[Buildroot] Firmware auto-loading does not work

[Guillaume GARDET - Oliséo]

Le 25/01/2017 ? 14:52, Peter Korsgaard a ?crit :
>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
>   > Le 25/01/2017 ? 13:51, Peter Korsgaard a ?crit :
>   >>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
>   >> > Hello,
>   >> > I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware
>   >> > auto-loading does not work. I need to do it manually (through
>   >> > sysfs). I tried mdev and eudev, both are not working.
>   >>
>   >> > Is there a known bug about that? In busybox, maybe?
>   >>
>   >> If you have tried both eudev and mdev, then it is unlikely to be a bug
>   >> in busybox (mdev). Are you using busybox modprobe applet or kmod?
>
>   > This is not a problem of module loading (it is working fine) but
>   > loading _firmware_ to devices for the WiFi dongle in my case.
>
> Heh, I wonder how I could misread your email so much - Sorry about that.
>
> First of all, our default busybox configuration has
> CONFIG_FEATURE_MDEV_LOAD_FIRMWARE disabled. Have you enabled it? Without
> that option, mdev doesn't do anything about firmware.

I though I checked that it was enabled but it seems it isn't.

>
> Less ancient (since 3.7, so 2012) Linux kernels directly loads firmware
> files from the kernel, so the support in mdev isn't needed, but as you
> are using an ancient kernel this doesn't work for you:
>
> commit abb139e75c2cdbb955e840d6331cb5863e409d0e
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Wed Oct 3 15:58:32 2012 -0700
>
>      firmware: teach the kernel to load firmware files directly from the filesystem
>
>      This is a first step in allowing people to by-pass udev for loading
>      device firmware.  Current versions of udev will deadlock (causing us to
>      block for the 30 second timeout) under some circumstances if the
>      firmware is loaded as part of the module initialization path, and this
>      is causing problems for media drivers in particular.
>
>      The current patch hardcodes the firmware path that udev uses by default,
>      and will fall back to the legacy udev mode if the firmware cannot be
>      found there.  We'd like to add support for both configuring the paths
>      and the fallback behaviour, but in the meantime this hopefully fixes the
>      immediate problem, while also giving us a way forward.
>
>      [ v2: Some VFS layer interface cleanups suggested by Al Viro ]
>      [ v3: use the default udev paths suggested by Kay Sievers ]
>
>      Suggested-by: Ivan Kalvachev <ikalvachev@gmail.com>
>      Acked-by: Greg KH <gregkh@linuxfoundation.org>
>      Acked-by: Al Viro <viro@zeniv.linux.org.uk>
>      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
>      Cc: Kay Sievers <kay@redhat.com>
>      Cc: Ming Lei <ming.lei@canonical.com>
>      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> Looking at eudev git history, I see that the legacy user space loading
> support got removed in 2014, so that is why it isn't working with eudev
> either:
>
> commit 3b717594600fa717cdf9bcfd0c7c1b703b245482
> Author: Kay Sievers <kay@vrfy.org>
> Date:   Mon Sep 1 09:07:49 2014 -0400
>
>     udev: remove userspace firmware loading support
>
>     Signed-off-by: Anthony G. Basile <blueness@gentoo.org>

Thanks for this history.

>
> We should probably enable CONFIG_FEATURE_MDEV_LOAD_FIRMWARE in our
> default busybox.config to better support these old systems.
>
> Can you confirm that it works if you enable that option.
>

As soon as I get back the problematic hardware, I check that and come back to you.

Guillaume

[Buildroot] Firmware auto-loading does not work

[Julien Boibessot]

Hello Guillaume,

On 25/01/2017 09:56, Guillaume GARDET - Olis?o wrote:
> Hello,
>
> I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware
> auto-loading does not work. I need to do it manually (through sysfs).
> I tried mdev and eudev, both are not working.
>
> Is there a known bug about that? In busybox, maybe?

it has always work for us (Armadeus), with mdev, whatever
Buildroot/Linux version we used (i.MX platforms). (Our Wi-Fi firmwares
are auto-loaded.)

Regards,
Julien

[Buildroot] Firmware auto-loading does not work

[Guillaume GARDET - Oliséo]

Le 25/01/2017 ? 14:52, Peter Korsgaard a ?crit :
>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
>   > Le 25/01/2017 ? 13:51, Peter Korsgaard a ?crit :
>   >>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
>   >> > Hello,
>   >> > I am using buildroot 2016.05 (with a 2.6.37 kernel) and firmware
>   >> > auto-loading does not work. I need to do it manually (through
>   >> > sysfs). I tried mdev and eudev, both are not working.
>   >>
>   >> > Is there a known bug about that? In busybox, maybe?
>   >>
>   >> If you have tried both eudev and mdev, then it is unlikely to be a bug
>   >> in busybox (mdev). Are you using busybox modprobe applet or kmod?
>
>   > This is not a problem of module loading (it is working fine) but
>   > loading _firmware_ to devices for the WiFi dongle in my case.
>
> Heh, I wonder how I could misread your email so much - Sorry about that.
>
> First of all, our default busybox configuration has
> CONFIG_FEATURE_MDEV_LOAD_FIRMWARE disabled. Have you enabled it? Without
> that option, mdev doesn't do anything about firmware.
>
> Less ancient (since 3.7, so 2012) Linux kernels directly loads firmware
> files from the kernel, so the support in mdev isn't needed, but as you
> are using an ancient kernel this doesn't work for you:
>
> commit abb139e75c2cdbb955e840d6331cb5863e409d0e
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Wed Oct 3 15:58:32 2012 -0700
>
>      firmware: teach the kernel to load firmware files directly from the filesystem
>
>      This is a first step in allowing people to by-pass udev for loading
>      device firmware.  Current versions of udev will deadlock (causing us to
>      block for the 30 second timeout) under some circumstances if the
>      firmware is loaded as part of the module initialization path, and this
>      is causing problems for media drivers in particular.
>
>      The current patch hardcodes the firmware path that udev uses by default,
>      and will fall back to the legacy udev mode if the firmware cannot be
>      found there.  We'd like to add support for both configuring the paths
>      and the fallback behaviour, but in the meantime this hopefully fixes the
>      immediate problem, while also giving us a way forward.
>
>      [ v2: Some VFS layer interface cleanups suggested by Al Viro ]
>      [ v3: use the default udev paths suggested by Kay Sievers ]
>
>      Suggested-by: Ivan Kalvachev <ikalvachev@gmail.com>
>      Acked-by: Greg KH <gregkh@linuxfoundation.org>
>      Acked-by: Al Viro <viro@zeniv.linux.org.uk>
>      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
>      Cc: Kay Sievers <kay@redhat.com>
>      Cc: Ming Lei <ming.lei@canonical.com>
>      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> Looking at eudev git history, I see that the legacy user space loading
> support got removed in 2014, so that is why it isn't working with eudev
> either:
>
> commit 3b717594600fa717cdf9bcfd0c7c1b703b245482
> Author: Kay Sievers <kay@vrfy.org>
> Date:   Mon Sep 1 09:07:49 2014 -0400
>
>     udev: remove userspace firmware loading support
>
>     Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
>
> We should probably enable CONFIG_FEATURE_MDEV_LOAD_FIRMWARE in our
> default busybox.config to better support these old systems.
>
> Can you confirm that it works if you enable that option.
>

I get back the hardware for testing and it still does not work, even if I enable CONFIG_FEATURE_MDEV_LOAD_FIRMWARE=y :
     phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'.
and after 60 seconds, I get:
     phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
     phy0 -> rt2x00lib_request_firmware: Error - Error is '-2'.

Whereas the firmware file is in /lib/firmware/

Any idea what could be wrong?

Guillaume

[Buildroot] Firmware auto-loading does not work

[Peter Korsgaard]

>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:

Hi,

 >> Can you confirm that it works if you enable that option.
 >> 

 > I get back the hardware for testing and it still does not work, even if I enable CONFIG_FEATURE_MDEV_LOAD_FIRMWARE=y :
 >     phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'.
 > and after 60 seconds, I get:
 >     phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
 >     phy0 -> rt2x00lib_request_firmware: Error - Error is '-2'.

 > Whereas the firmware file is in /lib/firmware/

 > Any idea what could be wrong?

Not really. Please double check that you enabled
CONFIG_FEATURE_MDEV_LOAD_FIRMWARE in busybox. To debug further, I
suggest you stick some fprintf statements (E.G. to your serial port /
console) in mdev.c to see if it gets called and what is going on.

-- 
Bye, Peter Korsgaard

[Buildroot] Firmware auto-loading does not work

[Guillaume GARDET - Oliséo]

Hi,

I found the problem thanks to mdev log:
     mdev[716]: 00:04:57.841774 ACTION:add SUBSYSTEM:firmware DEVNAME:(null) DEVPATH:/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0 FW:rt2870.bin
     mdev[716]: rule matched, line -1
     mdev[716]: can't change directory to '/sys/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0': No such file or directory
     mdev[717]: 00:05:57.982454 ACTION:remove SUBSYSTEM:firmware DEVNAME:(null) DEVPATH:/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0 FW:rt2870.bin
     mdev[717]: 00:05:57.982545 exiting

The thing is that the PATH is not good :
* requested : /sys/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
* real: /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0

The only difference is the ".0" missing after musb-omap2430. Any idea why there is this difference?


Guillaume




Le 30/01/2017 ? 16:27, Peter Korsgaard a ?crit :
>>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:
> Hi,
>
>   >> Can you confirm that it works if you enable that option.
>   >>
>
>   > I get back the hardware for testing and it still does not work, even if I enable CONFIG_FEATURE_MDEV_LOAD_FIRMWARE=y :
>   >     phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'.
>   > and after 60 seconds, I get:
>   >     phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
>   >     phy0 -> rt2x00lib_request_firmware: Error - Error is '-2'.
>
>   > Whereas the firmware file is in /lib/firmware/
>
>   > Any idea what could be wrong?
>
> Not really. Please double check that you enabled
> CONFIG_FEATURE_MDEV_LOAD_FIRMWARE in busybox. To debug further, I
> suggest you stick some fprintf statements (E.G. to your serial port /
> console) in mdev.c to see if it gets called and what is going on.
>

[Buildroot] Firmware auto-loading does not work

[Peter Korsgaard]

>>>>> "Guillaume" == Guillaume GARDET <- Olis?o <guillaume.gardet@oliseo.fr>> writes:

 > Hi,
 > I found the problem thanks to mdev log:
 >     mdev[716]: 00:04:57.841774 ACTION:add SUBSYSTEM:firmware
 > DEVNAME:(null)
 > DEVPATH:/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
 > FW:rt2870.bin
 >     mdev[716]: rule matched, line -1
 >     mdev[716]: can't change directory to
 > '/sys/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0':
 > No such file or directory
 >     mdev[717]: 00:05:57.982454 ACTION:remove SUBSYSTEM:firmware
 > DEVNAME:(null)
 > DEVPATH:/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
 > FW:rt2870.bin
 >     mdev[717]: 00:05:57.982545 exiting

 > The thing is that the PATH is not good :
 > * requested : /sys/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
 > * real: /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0

 > The only difference is the ".0" missing after musb-omap2430. Any idea why there is this difference?

This information is all from the kernel, so it sounds like a bug
somewhere (presumably musb or rt2xxx drivers).

-- 
Bye, Peter Korsgaard

[Buildroot] Firmware auto-loading does not work

[Fabio Estevam]

On Fri, Feb 3, 2017 at 7:51 AM, Guillaume GARDET - Olis?o
<guillaume.gardet@oliseo.fr> wrote:

> The thing is that the PATH is not good :
> * requested :
> /sys/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
> * real:
> /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
>
> The only difference is the ".0" missing after musb-omap2430. Any idea why
> there is this difference?

This depends on how you registered the musb-omap2430 platform device.
If you pass '-1' as the id then it will not register with the .0 in
the name.

Check how we do this on arch/arm/mach-imx/devices/platform-pata_imx.c,
for example.

imx_add_platform_device("pata_imx", -1, res, ARRAY_SIZE(res), NULL, 0);

The '-1' is the key thing here.

[Buildroot] Firmware auto-loading does not work

[Guillaume GARDET - Oliséo]

Le 03/02/2017 ? 14:30, Fabio Estevam a ?crit :
> On Fri, Feb 3, 2017 at 7:51 AM, Guillaume GARDET - Olis?o
> <guillaume.gardet@oliseo.fr> wrote:
>
>> The thing is that the PATH is not good :
>> * requested :
>> /sys/devices/platform/musb-omap2430/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
>> * real:
>> /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/usb2/2-1/2-1:1.0/firmware/2-1:1.0
>>
>> The only difference is the ".0" missing after musb-omap2430. Any idea why
>> there is this difference?
> This depends on how you registered the musb-omap2430 platform device.
> If you pass '-1' as the id then it will not register with the .0 in
> the name.
>
> Check how we do this on arch/arm/mach-imx/devices/platform-pata_imx.c,
> for example.
>
> imx_add_platform_device("pata_imx", -1, res, ARRAY_SIZE(res), NULL, 0);
>
> The '-1' is the key thing here.
>

I am using an old kernel (2.6.37), but there is a similar function:
     dev_set_name(dev, "musb-omap2430");

I will try to append the ".0" here and see if it is ok.


Guillaume