[Buildroot] Loading modules with device tree after rootfs is mounted

[Buildroot] Loading modules with device tree after rootfs is mounted

[Tim Michals]

I've created new buildroot defconfig for Udoo Neo board, u-boot, linux
kernel boots and busybox prompt is active and accepts commands.  The issue
is several drivers (wifi, camera, etc) are built as kernel modules and
stored on ext4 rootfs.  How can the kernel load these modules via the
device tree from the rootfs?

Udoo team has a lubuntu image, and the drivers are loaded after rootfs is
mounted, so I'm confused how this works.



Thank your for help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160130/d3a1f1fc/attachment.html>

[Buildroot] Loading modules with device tree after rootfs is mounted

[Arnout Vandecappelle]

On 30-01-16 18:56, Tim Michals wrote:
> I've created new buildroot defconfig for Udoo Neo board, u-boot, linux kernel
> boots and busybox prompt is active and accepts commands.  The issue is several
> drivers (wifi, camera, etc) are built as kernel modules and stored on ext4
> rootfs.  How can the kernel load these modules via the device tree from the rootfs? 

 The kernel doesn't automatically load modules, you need a userspace hotplug
helper to handle that. You have the following options:

1. modprobe the required drivers in an init script (no hotplugging).
2. Write a hotplug script that modprobes as required (google it).
3. Use mdev as the /dev handler and add a modprobe handler in mdev.conf (google it).
4. Use udev as the /dev handler.


 Regards,
 Arnout

> 
> Udoo team has a lubuntu image, and the drivers are loaded after rootfs is
> mounted, so I'm confused how this works.  
> 
> 
> 
> Thank your for help.
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Loading modules with device tree after rootfs is mounted

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 > On 30-01-16 18:56, Tim Michals wrote:
 >> I've created new buildroot defconfig for Udoo Neo board, u-boot, linux kernel
 >> boots and busybox prompt is active and accepts commands.  The issue is several
 >> drivers (wifi, camera, etc) are built as kernel modules and stored on ext4
 >> rootfs.  How can the kernel load these modules via the device tree from the rootfs? 

 >  The kernel doesn't automatically load modules, you need a userspace hotplug
 > helper to handle that. You have the following options:

 > 1. modprobe the required drivers in an init script (no hotplugging).
 > 2. Write a hotplug script that modprobes as required (google it).
 > 3. Use mdev as the /dev handler and add a modprobe handler in mdev.conf (google it).

We should really fix our mdev setup to do this correctly out of the
box. I don't usually use mdev, but I've just tried it on the pandaboard
which has the same problems as the kernel config builds almost
everything as modules.

As far as I can see from looking at the code and googling it, we need
to:

- Add a line to mdev.conf to support dynamic module loading:

# load modules
$MODALIAS=.*    0:0 660 @modprobe "$MODALIAS"

- Add a line to the init script for cold plugging modules (E.G. modules
for which the devices were already present before mdev was added as the
hotplug handler). mdev -s should arguable handle this, but it doesn't.

find /sys/ -name modalias | xargs sort -u | xargs modprobe -abq

I'll send a patch to add this, but it would be good if somebody who
is more familiar with mdev could take a look.

-- 
Bye, Peter Korsgaard

[Buildroot] Loading modules with device tree after rootfs is mounted

[Arnout Vandecappelle]

On 02/27/16 11:19, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> 
>  > On 30-01-16 18:56, Tim Michals wrote:
>  >> I've created new buildroot defconfig for Udoo Neo board, u-boot, linux kernel
>  >> boots and busybox prompt is active and accepts commands.  The issue is several
>  >> drivers (wifi, camera, etc) are built as kernel modules and stored on ext4
>  >> rootfs.  How can the kernel load these modules via the device tree from the rootfs? 
> 
>  >  The kernel doesn't automatically load modules, you need a userspace hotplug
>  > helper to handle that. You have the following options:
> 
>  > 1. modprobe the required drivers in an init script (no hotplugging).
>  > 2. Write a hotplug script that modprobes as required (google it).
>  > 3. Use mdev as the /dev handler and add a modprobe handler in mdev.conf (google it).
> 
> We should really fix our mdev setup to do this correctly out of the
> box. I don't usually use mdev, but I've just tried it on the pandaboard
> which has the same problems as the kernel config builds almost
> everything as modules.
> 
> As far as I can see from looking at the code and googling it, we need
> to:
> 
> - Add a line to mdev.conf to support dynamic module loading:
> 
> # load modules
> $MODALIAS=.*    0:0 660 @modprobe "$MODALIAS"

 that's right.

> 
> - Add a line to the init script for cold plugging modules (E.G. modules
> for which the devices were already present before mdev was added as the
> hotplug handler). mdev -s should arguable handle this, but it doesn't.

 Well, mdev was not originally meant to do the module probing, it's more of a
hack on top of it. mdev was meant for changing names and permissions of device
nodes. So in the coldplug (mdev -s) it will just handle the device nodes it
finds in /sys/class.

> 
> find /sys/ -name modalias | xargs sort -u | xargs modprobe -abq

 I wouldn't have thought of the sorting, but looks good to me.

 Regards,
 Arnout

> 
> I'll send a patch to add this, but it would be good if somebody who
> is more familiar with mdev could take a look.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Loading modules with device tree after rootfs is mounted

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> - Add a line to the init script for cold plugging modules
 >> (E.G. modules for which the devices were already present before mdev
 >> was added as the hotplug handler). mdev -s should arguable handle
 >> this, but it doesn't.

 > Well, mdev was not originally meant to do the module probing, it's
 > more of a hack on top of it. mdev was meant for changing names and
 > permissions of device nodes. So in the coldplug (mdev -s) it will
 > just handle the device nodes it finds in /sys/class.

 >> find /sys/ -name modalias | xargs sort -u | xargs modprobe -abq

 >  I wouldn't have thought of the sorting, but looks good to me.

This was cut'n'paste from:

http://lists.busybox.net/pipermail/busybox/2014-September/081780.html

Replacing the 'sort -u' with cat would also work. I'm not sure exactly
what the pros/cons of using sort -u is.

As that message states, we also need to make sure that we have a
modprobe understanding the aliases (so not the MODPROBE_SMALL busybox
variant).

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] Loading modules with device tree after rootfs is mounted

[Arnout Vandecappelle]

On 02/27/16 18:57, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> 
> Hi,
> 
>  >> - Add a line to the init script for cold plugging modules
>  >> (E.G. modules for which the devices were already present before mdev
>  >> was added as the hotplug handler). mdev -s should arguable handle
>  >> this, but it doesn't.
> 
>  > Well, mdev was not originally meant to do the module probing, it's
>  > more of a hack on top of it. mdev was meant for changing names and
>  > permissions of device nodes. So in the coldplug (mdev -s) it will
>  > just handle the device nodes it finds in /sys/class.
> 
>  >> find /sys/ -name modalias | xargs sort -u | xargs modprobe -abq
> 
>  >  I wouldn't have thought of the sorting, but looks good to me.
> 
> This was cut'n'paste from:
> 
> http://lists.busybox.net/pipermail/busybox/2014-September/081780.html
> 
> Replacing the 'sort -u' with cat would also work. I'm not sure exactly
> what the pros/cons of using sort -u is.

 It removes duplicates from the list.

> 
> As that message states, we also need to make sure that we have a
> modprobe understanding the aliases (so not the MODPROBE_SMALL busybox
> variant).

 I think in our system scripts we are allowed to rely on the things that
are enabled in our default busybox config. So that should be OK.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Loading modules with device tree after rootfs is mounted

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> This was cut'n'paste from:
 >> 
 >> http://lists.busybox.net/pipermail/busybox/2014-September/081780.html
 >> 
 >> Replacing the 'sort -u' with cat would also work. I'm not sure exactly
 >> what the pros/cons of using sort -u is.

 >  It removes duplicates from the list.

Yes, that I get. My question is more about if duplicates can ever occur
/ how likely it is that duplicates are present / what is the problem
about duplicates?

I would think that duplicates are sufficiently rare that the
(potentially) extra modprobe calls vs extra overhead of sort vs cat is
probably down in the noise, but we can certainly keep the sort (it does
mean that we depend on another busybox applet though).

 >> As that message states, we also need to make sure that we have a
 >> modprobe understanding the aliases (so not the MODPROBE_SMALL busybox
 >> variant).

 >  I think in our system scripts we are allowed to rely on the things that
 > are enabled in our default busybox config. So that should be OK.

Yes, or we can force the options on, like we do for other things in
busybox.

-- 
Venlig hilsen,
Peter Korsgaard