This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Can someone help with udev, please?

Other Parts Discussed in Thread: OMAP-L137

My slow boot boils down to udev being the final remaining problem, preventing me from booting in less than 75 seconds, which is simply too darned slow.  I'm not a linux kernel expert at all.  I've searched and searched and found lots of different avenues, but none of which I understand enough about to follow.  For example, I believe I might be best off changing things to not use udev at all, but mknod instead.  And my own thought is to do this in my tar ball before flashing nand, so that all the devices are ready to go with no time to be spent on them at all during boot.  But I have no clue how to do this.  Or how to do what I should possibly do instead.

So, your help with this would be GREATLY appreciated.

Note as an aside, I've discovered something interesting that I don't understand.  I was able to speed my jffs2 mount up from 25 seconds to as fast as 6 seconds, merely by making my file system smaller (58K->15K).  However, in doing so, udev slowed down from 15 seconds to 90 seconds.  In hopes of getting the best times of both worlds, I investigated.  My 58K file system inadvertently included a /mnt/nand folder on my Ubuntu host nfs, which seemed redundant.  It make sense that everything on my host nfs EXCEPT that /mnt/nand stuff should go onto the target's /mnt/nand.  I deleted that /mnt/nand from the host nfs and made a new tar.gz, then extracted it onto my target.  The file system size shown by "df" fell t 15K.  But then when I booted, I found udev doing much more work, doing many mknod's that it didn't do before.  It's as if the target could see the /mnt/nand stuff in addition to the root file system stuff, and this was impacting what udev does.  This is a bit complicated to explain; sorry.  But the target shouldn't even see that stuff extracted to /mnt/nand, because the actual nand should go into that place.  But regardless, this had that kind of impact.  And the extra mknod's of many, many tty* files takes forever.  If I can fix this directly, or get rid of udev altogether, then I should have little to zero time creating devices, in addition to a small file system and 6 second jffs2 mount.  Well, I tried something that didn't help.  I noticed the running target had all these tty* files, all the way up to ttyzf, and there were not in the Ubuntu host nfs version of /dev.  I copied them from the target (while nand booted and separately mounting nfs) over to the host, and then re-did the whole tar ball compress extract thing.  I confirmed they now existed on the actual nand in folder /dev.  But when I booted again with nand file system, udev still recreated all of them rather than taking the ones that were there.  Well, perhaps you can help me with this.  But even if I can get around this problem, which might get me back to 15 seconds for udev, I *should* be able to hard code those devices and get down to nearly 0 seconds for this task.

Again, your help is greatly appreciated.

  • You can create constant device, e.g. tty* or mtd*, in advance or on first boot.
    For dynamic device you can use script, .eg.
    modprobe -q drv
    if [ ! -f /dev/dev_i2c ]; then
              major=$(awk '$2=="dev_i2c" {print $1}' /proc/devices)
              mknod /dev/dev_i2c c ${major} 0
    fi

    Execuse me my bad english.


  • Thanks for your advice.

    I don't need dynamic devices, only constant ones.  But I don't understand how to create them in advance or on first boot of the target.  I've tried the "first boot" thing once, but must have done it wrong.  Specifically, I booted the target from nand and separately mounted my nfs from host.  Then I copied /dev from nand to my nfs host.  I then rebuilt the tar.gz of the file system on my nfs host, and then extracted that to freshly erased nand on my target.  udev didn't speed up at all.

    Perhaps you could give me some more detail, and then I'll be able to figure it out.

    Thanks again.

  • If you haven't already seen it, this article, and those it links to, have good general boot-time optimization tips:

        http://processors.wiki.ti.com/index.php/All_This_For_1_Second_Boot

    Chris

  • Chris,

    Thanks for pointing that out.  FYI I had already looked there.  It's written from the point of view that you're already below 10 seconds.  I'm still FAR above that.  

    I have gotten from 137sec to 52sec via (1) Engine_start() in lieu of TraceUtil_start(), and (2) CONFIG_JFFS2_SUMMARY=y, not to mention (3) bootargs "quiet" that I intend to slip in at the end of my work.  Of those, the 1 second boot link doesn't address the first two, from which I've gotten all my savings so far (62%).  Note that when I'm done, I plan to write a more detailed post, refer all my post liter over to that one, and detail what I did (hopefully) to get from "minutes" to "seconds" in order for it to be germane to start working on just "one second."

    BTW, Over at http://e2e.ti.com/support/embedded/linux/f/354/t/177211.aspx#637951 I describe my other most recent effort.  I'm still trying to get rid of udev, but also need to reanalyze my current slow spots, since things have changed so much...

    -Helmut

  • I think the runlevel scripts start udev. At least they do on my OMAP-L137. The symbolic link "etc/rcS.d/S03udev" is what tells the runlevel script to start udev. Removing this link should prevent udev from starting. Moving the link mught better. Recreating the symbolic links is more work than I like. Something like this:

    cd ROOT_OF_TARGET
    mkdir etc.bak
    mkdir etc.bak/rcS.d
    mv etc/rcS.d/S03udev etc.bak/rcS.d

    A warning though, I suspect removing udev may cause some spectacular boot failures. Especially if the static device files are not setup correctly. Similiarly, you can remove other startup and shutdown processes, ie network stuff if you don't have network HW.

    Device files are tricky to copy. Some google hits would suggest this on the target.

    cp -av /dev YOUR_MOUNTED_NFS_ROOT

    The command recursively copies /dev to /mnt/nfs_root_directory/dev. Othewise you would have to mknod or MAKEDEV each device file manually. Do a  "ls -l" on the copied files to check that they are still device files.

  • Norman,

    Thanks, that worked.  Now power-button-to-codec-active-video-out time is 41.5 seconds, reduced from 137 seconds.  Will post full summary for others later.

    Note 1: I'm still seeking that 10 second range, from where I can then finally begin to apply other 1 second boot advice.

    Note 2: My version of linux 2.6.32 on target didn't like the "-v", so I simply used "cp -a".

    Note 3: Even though I could see /dev/cmem on my nfs drive, and so it *should* have copied to the nand fs, when I booted to nand that file was missing.  This caused cmemk to not work.  From nand boot, I shared over to nfs and "cp -a" that file to nand's /dev.  Then it worked.  I also made fresh tar ball of nfs and rebuilt the target nand completely via extract.  Booted to nand again.  No problems.  Worked fine.  So, I'm just keeping a note that /dev/cmem may disappear in the future somehow and need handholding.  This also makes we consider remaking it via udev in the future if I ever change anything about cmem.  This may or may not be necessary, but it wouldn't hurt.

  • The lack of "-v" of "cp" command is not from Linux itself. It is probably is from whatever BusyBox implemented in their version of "cp. This always a problem moving scripts from "real" Linux and "embedded" Linux.

    CMEM might one of those dynamic device guys. The script suggested in Krill's post could be used instead of udev. It might be that one of the runlevel scripts remove the CMEM device.