CAM, GSoC, mmccam, RTEMS, SDIO

RTEMS SDIO driver: Current progress

Hi, this post mainly concerns with the current progress of SDIO driver’s implementation on RTEMS. In a nutshell, driver is able to detect, initialize the type of card. However, the part concerned with registering the partitions of the card as RTEMS disks is still buggy. So, I’ll discuss some of the bugs which were previously resolved and the ones that are still left.

Starting with a very short introduction of how MMCCAM driver is being interfaced with SDHCI driver:

Part 1: Interfacing

Complete interfacing task is done mainly via these two files:

nexus_devices.h

During initialization of the nexus bus following modules should be initialized:

  • cam : this initializes the CAM XPT layer along with the queues and does some initialization work for SIM’s.
  • mmcprobe : this initializes the SIM i.e MMCCAM stack and prepares the stack for handling interrupts from devices which will be added to the cam queue in future. Please note that any MMC/SD/SDIO interrupt occurring before the initialization of this module will be ignored. That’s why it’s being called via nexus-devices.h. Also, it is responsible for initializing the card and to do IO in case of SDIO cards.
  • sdda : this module is mainly concerned with handling and registering the partitions of the respective disk. It probably will not be used in case of SDIO where we just have to do I/O.

Moreover, please find the default-mmccam.ini file. It’s the buildset configuration file for turning mmccam on with this content:

sdhci.c

Head towards sys/dev/sdhci/sdhci.c file,

sdhci_start_slot function has a separate definition in case of normal sdhci driver, which can be found here:https://github.com/madaari/rtems-libbsd/blob/master/freebsd/sys/dev/sdhci/sdhci.c#L921

After getting the interrupt like in the form sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x48060000-0x48060fff irq 64 on simplebus0 sdhci_start_slot() is called with an appropriate slot id. In case of BBB, there were actually two of these interrupts. One for eMMC another for SDHCI.

sdhci_start_slot() calls the cam_sim_alloc() which registers the SIM on the CAM bus. cam_simq_alloc() checks the device queue. Then xpt_bus_register initializes a bus(a  list containing all the CCB’s related to the card) between the mmcprobe/sdda module and the SIM. Rest of the work is handled by the CAM initializing routines.

Part 2: Card Initialization

Main file responsible for initialization of the SD/MMC/SDIO card is sys/cam/mmc/mmc_xpt.c

Notice the below structure:

here, all the functions mentioned in mmc_xport_ops struct act as an interface to the CAM module. Whenever CAM discovers a SD/MMC/SDIO card it first announces it’s presence using mmc_alloc_device. Similarly, whenever, a CCB is created mmc_action is called to server the request. mmc_dev_async is used to handle asynchronous events.

Here’s the order in which these functions are called:

mmc_alloc_device -> mmc_dev_async -> mmc_probe_{LUN,BUS,TGT} scan -> mmc_probe_find_card type

After selecting the card type, it is then initialized and the initialization process looks somewhat like:

Card is then supplied with few SDIO related commands which if they didn’t respond to, confirms their card type .Here are all the commands supported by the mmcprobe module.

After initializing the card completely, sdda module is then called upon to determine and register the SDHC/MMC partitions as separate disks.

Part 3: Determine Partitions and register them as separate disks

sdda module is responsible for determining the partitions and registering them as separate disks. Corresponding file is sys/cam/mmc/mmc_da.c 

The bug lies here!! Theoretically, i have to replace the BIO/GEOM part concerned with disk attachment with the RTEMS media_server. In FreeBSD, BIO first calls the sddastrategy routine which further calls the sdda_schedule and then calls the sdda_start routine which converts the BIO requests into a CCB which is then passed to the CAM_XPT layer. For RTEMS, we have to do something like this only. In the sdda_add_part function which invokes the disk routines, rtems_media_server is called as:

After which it should successfully add the path:

After attaching the disk, RTEMS media server will try to read the partition table and will thus invoke rtems_bsd_sdda_disk_read_write:

Till here, we have converted the rtems_blkdev_request into bare information which we can use to form the CCB, In my view it is this part which is faulty, CCB being created here is probably wrong and that’s why the requested IO fails, and thus media server fails to add it as a disk.

CCB is being created as:

 

Tagged , ,

1 thought on “RTEMS SDIO driver: Current progress

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.