Automount for a SDIO interfaced SD-card (similar to nucleo-144)

[bob.fe...@rafresearch.com]

I am using a clone of the /configs/nucleo-144 set of board specific files.
The SD-card is working great. I get messages when a sd-card is inserted and removed. The sd-card's registers are read and displayed via info level debug output.
So, the card detect interrupt mechanism is working. But, I have not gotten the interface to the file system automounter to work.
I attempted to follow the instructions at http://nuttx.org/doku.php?id=wiki:howtos:automounter .
The key piece that I think I am missing is "Where to place the stm32_automount_event() function call?"
The nucleo-144 board files are structured differently than clicker2 and sama5d4-ek (examples using automount).

My best guess is that it should be placed in the /configs/nucleo-144/src/stm32_sdio.c:stm32_sdio_initialize(void) function. But the
SDIO_REGISTERCALLBACK and SDIO_CALLBACKENABLE functions also seem like a viable candidate for linking to media changes to
the automounter.

How should this a board structured like the nucleo-144 be interfaced with the file system automounter?

[patacongo]

 

The key piece that I think I am missing is "Where to place the stm32_automount_event() function call?"
The nucleo-144 board files are structured differently than clicker2 and sama5d4-ek (examples using automount).

 

My best guess is that it should be placed in the /configs/nucleo-144/src/stm32_sdio.c:stm32_sdio_initialize(void) function. ...

For the SAMA5D4-EK, it is a a separate file:

sam_automount.c:void sam_automount_event(int slotno, bool inserted)
sam_hsmci.c:  sam_automount_event(HSMCI0_SLOTNO, sam_cardinserted(HSMCI0_SLOTNO));
sam_hsmci.c:  sam_automount_event(HSMCI1_SLOTNO, sam_cardinserted(HSMCI1_SLOTNO));

(HSMCI = High Speed Memory Interface, Atmel-speak.  In STM32 speak that is SDIO).

As it is for the clicker2:

stm32_automount.c:void stm32_automount_event(int slotno, bool inserted)
stm32_mmcsd.c:  stm32_automount_event(state->slotno, stm32_cardinserted(state->slotno));
stm32_mmcsd.c:  stm32_automount_event(state->slotno, stm32_cardinserted(state->slotno));

 

... But the

SDIO_REGISTERCALLBACK and SDIO_CALLBACKENABLE functions also seem like a viable candidate for linking to media changes to
the automounter.

I don't understand that at all.  Those SDIO interfaces are used exclusively internal to the mmcsd_sdio.c driver.

Greg

[bob.fe...@rafresearch.com]

Both of these examples have the automount code read a GPIO pin to determine "SD card inserted". I guess I am not understanding how the actions are sequenced correctly.

When a SD-card is inserted, the sdmmc driver processes the gpio card detect pin interrupt and makes the card accessible through the /dev/mmcsd0 driver instance.
Then the automount code should receive the event of /dev/mmcsd0 being created and mount the file system as /mnt/sdcard.
The automount code directly accesses the card detect gpio pin. What prevents the automount code from winning the race and trying to mount the card before the sdmmc driver creates /dev/mmcsd0. Shouldn't the automount code be receiving an event from the sdmmc driver than directly from the gpio pin?

Or, is the event coming from the sdmmc driver and the automount code is just verifying that the card is still present?

-Bob

[patacongo]

I think this is incorrect.  I don't work a lot with STM32 F7, that does not sound correct to me.

Both of these examples have the automount code read a GPIO pin to determine "SD card inserted". I guess I am not understanding how the actions are sequenced correctly.

When a SD-card is inserted, the sdmmc driver processes the gpio card detect pin interrupt and makes the card accessible through the /dev/mmcsd0 driver instance.

I don't think so, the SDMMC driver does not know anything at all about card-detect.  Only the board logc knows about card detect  When there is a change the board logic should call  sdio_mediachange() function in the driver.

Then the automount code should receive the event of /dev/mmcsd0 being created and mount the file system as /mnt/sdcard.
The automount code directly accesses the card detect gpio pin. What prevents the automount code from winning the race and trying to mount the card before the sdmmc driver creates /dev/mmcsd0. Shouldn't the automount code be receiving an event from the sdmmc driver than directly from the gpio pin?

Which automount code?  The automount code in the board/src directory or the code automount code at fs/mount/fs_automount.c.  You are being vague.

What race are you talking about.  You never mentioned any race.  You don't explain in any clarity why you think there is a race.  Of course you cannot mount the SD card before the device has been created  There is no race in that.

Or, is the event coming from the sdmmc driver and the automount code is just verifying that the card is still present?

Again you are being vague  If you mean the fs/mount/fs_automount.c code, that is stimulated by the driver.  It calls SDIO_REGISTERCALLBACK and when the driver has something to say to the fs automounter, it performs the callback.

This is not difficult.  But clearly you do not understand the logic  If you take the time to study the code and express the concepts succintly and clearly then I think you see how simple it is.

broard GPIO interrupt -> sdio_mediachange -> callback

Pretty simple-minided stuff.

Greg

[bob.fe...@rafresearch.com]

OK, I see the sequencing.
The nucleo-144's src/stm32_sdio.c stm32_ncd_interrupt() interrupt handler is calling sdio_mediachange().
So that create/destroys /dev/mmcsd0.
It should then call stm32_automount_event().
Is it safe to call it from interrupt context?

-Bob


On Saturday, June 23, 2018 at 5:05:50 PM UTC-7, bob.fe...@rafresearch.com wrote:

[bob.fe...@rafresearch.com]

The automount code I am referring to is a clone of configs/clicker2 that I copied to my local /configs/<board>/src.
The clicker2 calls to stm32_automount_event() don't seem to be occurring from from interrupt context.
In the nucleo-144 and indium-f7, the equivalent place to make the call will be from interrupt context.
-Bob

[bob.fe...@rafresearch.com]

I still don't know if it is safe, but calling stm32_automount_event() from interrupt context seems to be working.

-Bob

[bob.fe...@rafresearch.com]

Well maybe not totally working.
It does seem to mount and umount OK, but...

Upon sd-card insertion... (errors from automount_interrupt)
nsh>
nsh> automount_interrupt: inserted=1
automount_interrupt: ERROR: Failed to cancel work: -2
mmcsd_mediachange: arg: 200178f0
mmcsd_probe: type: 0 probed: 0
mmcsd_removed: type: 0 present: 1
mmcsd_cardidentify: SD V2.x card
...
mmcsd_widebus: Wide bus operation selected
mmcsd_probe: Capacity: 3907584 Kbytes
automount_mount: Mounting /mnt/sdcard
mmcsd_open: Entry
mmcsd_geometry: Entry
mmcsd_geometry: available: true mediachanged: true writeenabled: true
mmcsd_geometry: nsectors: 7815168 sectorsize: 512
mmcsd_read: startsector: 0 nsectors: 1 sectorsize: 512
mmcsd_readsingle: startblock=0
mmcsd_readsingle: offset=0
fat_checkbootrecord: ERROR: Signature: aa55 FS sectorsize: 36352 HW sectorsize: 512
fat_mount: Partition 0, offset 446, type 11                         
mmcsd_read: startsector: 2048 nsectors: 1 sectorsize: 512           
mmcsd_readsingle: startblock=2048                                   
mmcsd_readsingle: offset=2048                                       
fat_mount: MBR found in partition 0                                 
mmcsd_read: startsector: 2049 nsectors: 1 sectorsize: 512
mmcsd_readsingle: startblock=2049
mmcsd_readsingle: offset=2049
fat_mount: FAT32:
fat_mount:      HW  sector size:     512
fat_mount:          sectors:         7815168
fat_mount:      FAT reserved:        32
fat_mount:          sectors:         7813120
fat_mount:          start sector:    2080
fat_mount:          root sector:     2
fat_mount:          root entries:    0
fat_mount:          data sector:     5894
fat_mount:          FSINFO sector:   2049
fat_mount:          Num FATs:        2
fat_mount:          FAT sectors:     1907
fat_mount:          sectors/cluster: 32
fat_mount:          max clusters:    244039
fat_mount:      FSI free count       244038
fat_mount:          next free        2

It looks like fs/automount.c tried to process the insertion before sdmmc.c had a chance to deal with it.

Later when the sd-card is removed...
nsh>
automount_interrupt: inserted=1
automount_interrupt: ERROR: Failed to cancel work: -2
automount_interrupt: inserted=0
mmcsd_mediachange: arg: 200178f0
mmcsd_removed: type: 12 present: 0
automount_unmount: Unmounting /mnt/sdcard
mmcsd_close: Entry

Again fs/automount.c process the event before the sdmmc driver.
If seems to auto-mount and auto-umount OK, but the error messages are concerning.
Especially with this comment in fs/automount.c
  ret = work_cancel(LPWORK, &priv->work);
  if (ret < 0)
    {
      /* NOTE: Currently, work_cancel only returns success */

      ferr("ERROR: Failed to cancel work: %d\n", ret);
    }

Confused and concerned, but generally doing OK,
Bob

[patacongo]

automount_interrupt: ERROR: Failed to cancel work: -2

If seems to auto-mount and auto-umount OK, but the error messages are concerning.
Especially with this comment in fs/automount.c
  ret = work_cancel(LPWORK, &priv->work);
  if (ret < 0)
    {
      /* NOTE: Currently, work_cancel only returns success */

      ferr("ERROR: Failed to cancel work: %d\n", ret);
    }

he comment in fs/mount/fs_automounter.c is incorrect:

include errno.h:

134 #define ENOENT              2
135 #define ENOENT_STR          "No such file or directory"

sched/wqueue/kwork_cancel.c:

 58 /****************************************************************************
 59  * Name: work_qcancel
 60  * ...
 70  * Returned Value:
 71  *   Zero (OK) on success, a negated errno on failure.  This error may be
 72  *   reported:
 73  *
 74  *   -ENOENT - There is no such work queued.
 75  *   -EINVAL - An invalid work queue was specified
 76  *
 77  ****************************************************************************/

[bob.fe...@rafresearch.com]

But, is it normal to get these error messages during automount?

If so, then they should be printed as info or warning messages.

Regards,

Bob