Hi, Ok this was a great help and allow our automount scripts to create a mount point on an SD card when running from eMMC.
But I'm having a bit of a STRANGE problem, with the /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh script apparently affecting UDEV's ability to trigger on an SD card (e.g. mmcblk0p1) inserted in the slot - both on the source eMMC image and the destination flasher image on SD card, after I run the eMMC cloner script. When I run beaglebone-black-make-microSD-flasher-from-eMMC.sh, for some reason, it does something to the image currently flashed on the eMMC to permanently kill udev's ability to trigger on an SD card plugged into the SD card slot. However, while in this state, our udev rule still triggers on the presence of mmcblk1p1. Then when we subsequently use that flasher image from the cloned SD card to re-flash the eMMC, this udev excommunicating mmcblk0p1 behavior seems to persist. I've got a a master SD card image, which when I utilize it to flash the eMMC, udev triggers on mmcblk0p1 when a properly formatted SD card is inserted. So in other words, before running this eMMC cloner script, our working image running from eMMC triggers off the following line just fine in our udev rules file in /etc/udev/rules.d/ (10-mmc-blah-blah): KERNEL!="mmcblk0p1", GOTO="mmc_mount_end" But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, it appears like udev stops seeing mmcblk0p1 when an uSD card is inserted. Even though calling ls -l /dev/mmc* shows both mmcblk0p1 and mmcblk1p1 (see listing below). However, after calling the script, if we change this line in the udev rules file to: KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end" Then udev triggers on the presence of mmcblk1p1 (eMMC) and ultimately the shell script for formatting and mounting the uSD card gets called. Notes: 1) ***I have a master flasher image an an SD card which contains the same SD card auto-mount scripts, and when I run the SD card to eMMC flasher script to flash the eMMC. Everything works just fine!! UDEV triggers on mmcblk0p1 when an SD card is plugged into the slot and the above rules file initiates the systemd service which calls a shell script. It's just after running beaglebone-black-make-microSD-flasher-from-eMMC.sh that UDEV apparently no longer reacts to a "blank" SD card inserted in the slot. 2) Initially the SD card inserted in the slot, was originally formatted with a single, FAT 32 WIN95 partition, but then reformatted to ext4 by mkfs.ext4 in the "automount" shellscript. When this was the case, the application was actively storing logfiles on the mount point on the SD card when I called the eMMC to SD cloner script. 3) I then reformatted the SD card by just erasing the first 1GB (and not creating a partition ) per a comment the eMMC cloner script spits out. This time the SD automount script wasn't able to create a mount point, so the application wasn't running when I called the cloner script, converted the SD card to a flasher, and flashed the eMMC, but I got the same result as before: UDEV excommunicated mmcblk0p1. 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) After running the eMMC to SD card cloner script, even though UDEV apparently no longer reacts to mmcblk0p1: ls -l /dev/mmc* : brw-rw---- 1 root disk 179, 0 Apr 5 19:58 /dev/mmcblk0 brw-rw---- 1 root disk 179, 1 Apr 5 19:58 /dev/mmcblk0p1 brw-rw---- 1 root disk 179, 8 Apr 5 19:58 /dev/mmcblk1 brw-rw---- 1 root disk 179, 16 Apr 5 19:58 /dev/mmcblk1boot0 brw-rw---- 1 root disk 179, 24 Apr 5 19:58 /dev/mmcblk1boot1 brw-rw---- 1 root disk 179, 9 Apr 5 19:58 /dev/mmcblk1p1 8) 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. As always, thanks for reading my novels on here!! On Tuesday, April 3, 2018 at 4:18:35 PM UTC-5, Jeff Andich wrote: > > Thanks Robert!! > > ...One of these days, I need to be following what's going on with the > commits and the upstream... > > Regards, > > jeff > > > > > On Tuesday, April 3, 2018 at 4:05:42 PM UTC-5, RobertCNelson wrote: >> >> On Tue, Apr 3, 2018 at 3:53 PM, Jeff Andich <jeff....@gmail.com> wrote: >> > Hi, >> > >> > When Linux and our application is running from eMMC, we wish to be able >> to >> > create log files on a uSD card plugged into the uSD slot on our board. >> > >> > I've ported some scripts which a former colleague wrote for the >> BeagleBone >> > Black that create a mount point on a factory default SD card if the SD >> card >> > exists, and re-formats the FAT to an ext4 partition. Basically they >> used a >> > udev script to trigger on the presence of /dev/mmcblk0p1 or >> /dev/mmcblk1p1 >> > and then call a shell script (from a systemd service launched by udev) >> for >> > formatting and mounting the SD card. >> > >> > One key thing that that shell script did was to detect where Linux was >> > running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label >> of >> > the storage device, and then mounting the other device if it exists. >> This >> > capability to handle the '/' mount point "pingponging" between >> /dev/mmcblk0 >> > and mmcblk1 was needed due to the mount point changing for the eMMC >> > depending on whether an uSD card was plugged into the slot on the >> BeagleBone >> > Black with kernel 3.8.?. >> > >> > However, on the baseline images I've been using for the BB-X15, I >> haven't >> > yet observed any pingponging in that '/' always SEEMS to be mounted on >> > /dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running >> from uSD >> > card. I've been working with a BB-X15 console image consisting of >> (Debian >> > 8.10, kernel 4.4.110, and some variant of u-boot 2017.01), >> > >> > ?? Will this always be the case for the BB-X15 (and other devices) or >> at >> > least with the Debian version, kernel version, and u-boot version we're >> > using?? >> > >> > If so I'd like to take advantage of this fact in the shell script to >> only >> > create a mount point on the SD card when it doesn't contain a Linux >> image >> > and when '/' is mounted on /dev/mmcblk1p1. But I'm afraid that this >> > assumption may not hold and come back to bite us at some point. >> >> According to my notes, this "randomness-race-label" condition was >> first "fixed" in the v4.5.x merge and "really" fixed in v4.5.3 >> >> We back-ported these two fixes to our v4.4.x-ti tree for the bbb and >> bbx15. >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=58821da858919f93f85c7e6823b49d439722a9e9 >> >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=520bd7a8b4152aacfbd34eb7f7a447354b631039 >> >> >> Regards, >> >> -- >> Robert Nelson >> https://rcn-ee.com/ >> > -- 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 https://groups.google.com/d/msgid/beagleboard/b02d6f9e-5b9d-486e-adcd-4655753b30bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.