linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: run udev on ARM system kernel 2.6.22
Date: Tue, 11 Sep 2007 06:23:34 +0000	[thread overview]
Message-ID: <20070911062334.GF27404@kroah.com> (raw)
In-Reply-To: <d722e40c0709092111i518d6590v2b6060a59860de10@mail.gmail.com>

On Tue, Sep 11, 2007 at 09:14:43AM +1000, jim hugh wrote:
> On 9/10/07, Greg KH <greg@kroah.com> wrote:
> > On Mon, Sep 10, 2007 at 02:11:07PM +1000, jim hugh wrote:
> > > Hi,
> > >
> > > I've just upgraded my ARM system from kernel 2.6.11 to kernel 2.6.22.
> > > Now, I've got problems,  Neither MMC nor USB works, I was told that
> > > the udev need be run and be configured. I've looked at udev FAQ and
> > > other documents, but still not clear how to run MMC and USB on kernel
> > > 2.6.22. Is there an example to set up udev and to get MMC and USB
> > > work?
> > >
> > > Thank you and sorry for asking an FAQ.
> >
> > I don't understand why you would think that udev would need to be
> > running in order for USB to work.  Unless you are having problems
> > accessing usbfs from userspace, or some userspace interaction with
> > plugged-in usb storage devices?
> >
> > I think we are going to need more information on exactly what is not
> > working for you.
> >
> > thanks,
> 
> Thanks Greg. Let me provide more details here:
> 
> We have an ARM 920T board, it was all fine when kernel 2.6.11 was
> running on it. Since I upgraded it to kernel 2.6.22, USB and MMC all
> stopped working, the modules loading was fine, but there was nothing
> happen when a USB stick or MMC card was inserted into it (dmesg did
> not show out anything when the device was inserted). I understand that
> the major difference between 2.6.11 and 2.6.22 is the devfs, in kernel
> 2.6.11, devfs is used and the /dev is mounted to the devfs, everything
> works fine. In kernel 2.6.22, devfs is no longer used that caused
> couple of problems:
> 
> 1. /dev is no longer mounted to devfs, we have to manually edit it to
> static /dev.
> 
> 2. In our system, when /dev was mounted to devfs, it was mapped to
> ramfs, now it is mapped to squashfs and I know that caused the problem
> of USB and MMC as you mentioned above. We are currently working to
> change it to map to ramfs, but it broken the booting, it could not
> start the console, we are trying to fix it. So, booting /dev without
> devfs is another issue.
> 
> Anyway, I am still not clear what is a proper procedure to use /dev
> without devfs on kernel 2.6.22. People advised me from kernel mailing
> list, we should use udev and proper configuration. Personally, I don't
> like to use static /dev and I hope to switch using udev will fix all
> the problem we currently face (please correct me). I've read the udev
> documents including your good paper, but I have to admit, I still have
> lots of questions to change to udev, such as:
> 
> Does the kernel 2.6.22 has already included udev package, or we have
> to download and install udev package?
> 
> What need be change in boot procedure?
> 
> In an essence, is there a step by step howdo document to use and install udev?

Ah, yeah, that would be nice to have, a document describing exactly how
to integrate udev into your "distro".  Unfortunatly, the closest thing
that I know of like that is the "Linux From Scratch" type rules, you
might look into how they do things.

Or just grab your favorite desktop distro and investigate how the boot
process works for them.  I know that Gentoo, Red Hat, Debian, and SuSE,
all have very good udev support, but each distro has a different type of
boot process, so it is integrated a little bit differently in each one.

So, depending on how your system starts up, things will work a bit
differently for you, but you can get the idea from the above.

The basic steps you need to do are the following:

  - as early as possible, mount a tmpfs at /dev
  - turn off calling /sbin/hotplug by either disabling it in your
    kernel, or by echoing "" to /proc/sys/kernel/hotplug
  - start /sbin/udevd in daemon mode (with the --daemon command line
    option)
  - run udevtrigger to populate /dev with the initial devices that have
    been found by the kernel in the boot process
  - run udevsettle to let udevtrigger finish properly before continuing.

Now udevd should be listening to the proper socket and your /dev tree
should be all up and full.  Any new devices that are then found in the
boot process (due to modules being loaded or new devices being plugged
in) will be handled properly.

Oh, and you need to have installed udev in the proper way, with the
needed rules files.  The ones in the releases should work just fine for
you, but you might need to tweak some group and other permissions
depending on your system needs.

If you have any specific questions about the above, or it isn't working
for you, feel free to ask here on the list.

Hope this helps,

greg k-h

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2007-09-11  6:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-10  4:11 run udev on ARM system kernel 2.6.22 jim hugh
2007-09-10  5:48 ` Greg KH
2007-09-10 23:14 ` jim hugh
2007-09-11  6:23 ` Greg KH [this message]
2007-09-11 15:19 ` Dan Nicholson
2007-09-11 15:34 ` Kay Sievers
2007-09-11 22:52 ` jim hugh
2007-09-11 23:05 ` Greg KH
2007-09-11 23:21 ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070911062334.GF27404@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).