From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Tue, 11 Sep 2007 06:23:34 +0000 Subject: Re: run udev on ARM system kernel 2.6.22 Message-Id: <20070911062334.GF27404@kroah.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Tue, Sep 11, 2007 at 09:14:43AM +1000, jim hugh wrote: > On 9/10/07, Greg KH 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