All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralph Siemsen <ralphs@netwinder.org>
To: buildroot@busybox.net
Subject: [Buildroot] Failed MMC & USB Mount
Date: Wed, 17 Jun 2020 13:47:04 -0400	[thread overview]
Message-ID: <20200617174704.GA23053@rfs.netwinder.org> (raw)
In-Reply-To: <ccd1b0539d4d4936baf2ae9be8d89a72@enduropls.ca>

Hi Joel,

On Wed, Jun 17, 2020 at 04:21:28PM +0000, Joel Brunetti wrote:
>?
>The system is running off an initrd image so there is no root file system and the system does otherwise boot as expected.
>?
>It appears from the logs the USB device or eMMC device drivers are not fully initialized when the kernel hands off to init.
>?
>I have tried adding 'root=/dev/sda1 rootwait' and 'rootdelay=10' to my kernel arguments in u-boot and while they are being passed (cat /proc/cmdline) they are not being respected. probably because I'm not waiting on root.
>?
>My question is; Is there another way to convince the kernel or busybox init to wait for the devices in /etc/fstab before continuing? Is there a better place to ask?

Since you are using an initrd (probably initramfs in fact) as your root 
filesystem, the "rootwait" will not have intended effect of delaying the 
mount until the SD/eMMC is ready. This commandline argument is normally 
used when the root device is the SD card, such as root=/dev/mmcblk0p1.

Also keep in mind that the kernel does not know about /etc/fstab at all.

Your observation that mount is successful after logging in and manually 
mounting it is consistent with the fact that SD takes some time to 
initialize. Means the hardware works, which is always good to know ;-)

A few possible options for you to consider:
- you can modify the init scripts, to put a time delay before the 
   automatic "mount -a". Of course this delays everything else too,
   and tuning the amount of delay is tedious and unreliable
- do not use /etc/fstab for the SD card. Instead write your own init 
   script to delay until the SD appears. Basically just a loop:
   while ! test -e /dev/mmcblk0p1 ; do sleep 1 ; done
   Of course this could block forever if no SD card is present, so you 
   probably want to limit maximum retries
- do not use /etc/fstab to mount the SD card, instead use one of the
   hotplug mechanisms, such as mdev for small systems (see 
   https://git.busybox.net/busybox/tree/docs/mdev.txt).

I'd recommend the third option personally. It also handles removable 
media like USB sticks nicely. Of course, since it is now dynamic, any 
code that depends on accessing SD card will need to be able to deal with 
the card missing / appearing later / possibly being removed / etc.

Regards,
-Ralph

  reply	other threads:[~2020-06-17 17:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-17 16:21 [Buildroot] Failed MMC & USB Mount Joel Brunetti
2020-06-17 17:47 ` Ralph Siemsen [this message]
2020-06-17 20:27   ` Joel Brunetti

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=20200617174704.GA23053@rfs.netwinder.org \
    --to=ralphs@netwinder.org \
    --cc=buildroot@busybox.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.