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.

Reply via email to