* [Buildroot] Failed MMC & USB Mount
@ 2020-06-17 16:21 Joel Brunetti
2020-06-17 17:47 ` Ralph Siemsen
0 siblings, 1 reply; 3+ messages in thread
From: Joel Brunetti @ 2020-06-17 16:21 UTC (permalink / raw)
To: buildroot
Hey Team,
?
I've been using Buildroot for about a year on a Terasic DE10-Nano and a custom but similar board with a Cyclone V. This is a great project and I've really appreciated the strait forward systems and all the work you have put into it.
?
This may not be the best place to ask but I'm having my first issue that is really stumping me. It may be the confluence of u-boot, linux, & busybox.
?
Configured:
- U-Boot boot from USB.
- U-Boot boot from eMMC.
- eMMC or USB device in /etc/fstab
?
USB Boot process:
- U-Boot boot from USB.
- Load linux kernel & initrd.
- Start /bin/init
- Error: Failed to mount USB partition.
- Finish init process.
- Login:
o '$ mount -a' successfully mounts previously failed USB partition.
?
eMMC Boot process:
- Same as for USB but fails to mount eMMC.
?
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?
?
Thanks for all your amazing work!
Joel
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200617/c8702ac8/attachment.html>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Buildroot] Failed MMC & USB Mount
2020-06-17 16:21 [Buildroot] Failed MMC & USB Mount Joel Brunetti
@ 2020-06-17 17:47 ` Ralph Siemsen
2020-06-17 20:27 ` Joel Brunetti
0 siblings, 1 reply; 3+ messages in thread
From: Ralph Siemsen @ 2020-06-17 17:47 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Buildroot] Failed MMC & USB Mount
2020-06-17 17:47 ` Ralph Siemsen
@ 2020-06-17 20:27 ` Joel Brunetti
0 siblings, 0 replies; 3+ messages in thread
From: Joel Brunetti @ 2020-06-17 20:27 UTC (permalink / raw)
To: buildroot
Hi Ralph,
Thanks for your feedback.
I've already started on an init script to mount the drives... what I had been hoping would be a temporary work around.
My application does require these drives to be present to move forward with the init (other processes expected the drives to be mounted) so I will forgo hotplugging for the time being. The USB is only for provisioning.
Thanks again,
Joel
-----Original Message-----
From: Ralph Siemsen <ralphs@netwinder.org>
Sent: June 17, 2020 11:47 AM
To: Joel Brunetti <joel.brunetti@enduropls.ca>
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Failed MMC & USB Mount
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
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200617/85fc3090/attachment.html>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-06-17 20:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-17 16:21 [Buildroot] Failed MMC & USB Mount Joel Brunetti
2020-06-17 17:47 ` Ralph Siemsen
2020-06-17 20:27 ` Joel Brunetti
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.