We've got a mechanism for creating a mount point on an SD card, 
specifically used for storage/logging while our main application is running 
from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
rules to fire on the presence of a properly formatted SD card in the slot 
which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
for the presence of mmcblk0p1, and if found, initiates a systemd service 
which calls a shell script which then detects mmcblk0p1 (while the main 
image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
the script checks the formatting on the SD card, re-formats to ext4, if 
necessary, and then creates a mount point for storage on the card.

Everything was working ok when I copied/created the scripts on the running 
eMMC image (and on a master SD card flasher image to install the image + 
scripts on the eMMC).

However, when I called the script for cloning the eMMC to an SD card, 
beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
the eMMC image after the script finished uploading to SD card.   As after I 
powered the image running from eMMC down and inserted a "properly formatted 
SD card" in the slot (but without the label rootfs), our UDEV rules never 

But from this state UDEV was still able to fire on the presence of 
MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
card if found.  But I really don't want to change this as we've shown that 
that the UDEV rule fires so long as I don't run the cloner script.  
Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
and not on MMCBLK1P1, as I don't know about the order that the drivers load 
when the kernel is booting..  What if the shell script runs before 
/dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
guess I could create a systemd service (?or cron job??) which periodically 
looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 

More details on what's happening:
The following UDEV rule triggers on our working image, running from eMMC 
with a properly formatted SD card in the slot, but breaks after we run, 
beaglebone-black-make-microSD-flasher-from-eMMC.sh .
KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"

But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, the 
only rule which will fire is:

KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end"


1) I have not yet tested if UDEV will fire on MMCBLK0 in place of MMCBLK0P1.

2) When I ran beaglebone-black-make-microSD-flasher script for the first 
time, the uSD card (utilized for the clone of eMMC) was formatted with a 
single ext4 partition.  (Linux said ext4 partition, but when I ran fdisk, 
fdisk said FAT32 W95).  

3) But when the beaglebone-black-make-microSD script ran, it spat out a 
comment leading me to believe that the uSD card (for cloning eMMC) should 
be partionless (e.g. just run sudo dd if=/dev/zero of=${DISK} bs=512 
count=1, but I ran bs=1M and count=1000), so I erased it without running 
fdisk to create a partition, and then re-ran 
beaglebone-black-make-microSD....  But I ended up with the same issue with 
the script disabling UDEV's ability to see MMCBLK0P1. 

??I was wondering if the beaglebone cloner script needed to disable UDEV 
rules for MMCBLK0P1 without really understanding the nuts and bolts of what 
the script actually does..

4) cat  /etc/dogtag:  2018-01-01.  

5) I have not run a git pull on the /opt/scripts/tools directory, but I 
didn't SEE any updates to functions.sh post 2018-01-01..

6) kernel: 4.4.110

7) I "slightly hacked" and renamed functions.sh in that I copied our custom 
board u-boot and MLO to the backup/uboot folder and reference that in the 
functions.sh script instead of the default (This maybe not needed and a bad 
idea which I will have to fix later), but I don't THINK any of this gets 
called anyway for the eMMC to SD card and flasher scripts I'm running.


*I need to run a git pull on the /opt/scripts directory on target and 
re-run the beaglebone cloner script to see if the outcome is different.

*Start looking into the script to figure out why this could be happening.

*Modify UDEV rules to trigger on MMCBLK0 instead of MMCBLK0P1..

For more options, visit http://beagleboard.org/discuss
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to