GSoC Project Introduction : Importing SDIO stack and Benchmarking

Hi all, This post is basically an introduction of my GSoC 2018 project under RTEMS. It marks the beginning of a series of blog posts that will be put on ( under the tag 'GSoC' ) for documenting my work throughout the time span.

Before moving on, I would like to thank RTEMS project and Google for giving me this opportunity of working on a highly fruitful Open source project, whose proposal can be found here ,under the mentorship of Christian Mauderer and punit vara. It would be great working with you both :).



Some important links:

Wiki page: https://devel.rtems.org/wiki/GSoC/2018/Porting_SDIO_and_Benchmarking

Project Github Repo: https://github.com/madaari/GSoC-Porting-SDIO-driver-and-benchmarking

Issues targeted : ticket#3429 , ticket#3430 , ticket#3428

Project proposal: Google doc

GSoC acceptance letter(To whom it may concern): here



Starting with the project description, so the project objective is divided into two sections:
First part of this project is intended to add SDIO support to BeagleBone Black BSP,  specifically by importing the current SDIO stack(MMCCAM ) from FreeBSD. Second part is devoted towards importing the necessary benchmarking tools and benchmarking the SDIO driver against the already present SDHC driver on both FreeBSD and RTEMS to determine their relative performance and thus to find the efficacy of importing drivers from FreeBSD.

SDIO cards are intended to provide high speed data Input/Output on our regular sd card slot. Nowadays it's extensively used to connect WiFi/Bluetooth chips on ARM boards, like Wandboard, Raspberry Pi 3 or Banana Pi. GlobalScale DreamPlug has an internal SDIO slot with the Marvell WLAN/Bluetooth module. I have previously published a blog post on SDIO card which will be sufficient to provide an overview of the SDIO cards , their types and internal working.

FreeBSD receives it's MMCCAM implemented SDIO stack under the commit https://github.com/freebsd/freebsd/commit/a87c7a85be3e3727b6b08b19741b4282f942400d  . SDIO stack was implemented under the preexisting CAM control bus for systematic ease in driver development with improved performance and hotplug interrupt handling. CAM(Common Access Method) is a method for separating HBA(Host Bus Adapter) adapters from storage adapters and is primarily used for SCSI. By separating these drivers it reduces the complexity of both the drivers.Furthermore, this separation enables storage drivers (such as CD-ROM and tape drivers) to control their devices on any I/O bus (such as IDE, SCSI, and so on) as long as an appropriate HBA driver is available. For detailed CAM explanation, refer my another blog post on CAM

With the great success of MMCCAM SDIO stack, it was proposed under my project to import it to RTEMS using rtems-libbsd. Challenges involves resolving CAM's dependencies in RTEMS. Moreover, userspace tools assumes a system with with memory management that cleans up after they exit, so they don't reinitialize their global variables. In case of RTEMS, special procedure has to be followed for importing such tools.

Regarding part 2 of the project i.e. Benchmarking, RTEMS has a number of tools/drivers imported from FreeBSD. However, due to difference in both the os , performance of these device drivers may not be the same. This part aims at importing a suitable filesystem / IO benchmarking tool to RTEMS and then carrying out some tests with tweaking different features. I have carried out some initial benchmarking and results are quite stable and in agreement with other tools.

Benchmarking results: https://docs.google.com/spreadsheets/d/1_lf9S136z0tJyni9W3t1__Rlrkal1fd6L7-vnlmYQpc/edit?usp=sharing

Project Timeline


As far a project timeline is concerned, here's an excerpt from my proposal:

May 14 - June 11 (First Phase)

Phase 1 will mainly deliver the following tasks:

  • Study, compare and finalize the multi purpose I/O benchmark to be used

  • Test and verify the benchmarks on FreeBSD

  • Port the desired benchmark on RTEMS

  • Test and verify the benchmark on RTEMS by accessing SD card via pre existing SDHC driver


June 15 - July 9 (Second Phase)

In the second phase,  I will :

  • Backport the SDIO driver to RTEMS-libbsd. Resolve all non-RTEMS dependencies.

  • Test the imported SDIO driver on BBB BSP by accessing sd card. Successful porting of the SDIO protocol is indicated by following checkpoints:

    • Should be able to read OCR, CID and different registers and thus would be able to configure the sd controller

    • Should be able to perform data transfer at least in 1 bit mode.



  • Prepare a suitable testsuite for the same


July 13 - August 14 (Third Phase)

In the third phase of GSoC, I will be taking up the following tasks:

  • Since the testbench worked with SDHC driver, i will then aim to test it with SDIO driver as well.

  • Port maximum possible number of features of benchmark on RTEMS and then make a suitable testsuite to invoke them.

  • Benchmarking other block storage device drivers like USB will be my next task.



  • Preparing a formal document containing all the test results will be made and will get it evaluated by the community.

Comments

Post a Comment

Popular posts from this blog

Understanding SD, SDIO and MMC Interface

Image
    In this blog post i will present the gist of the paper http://www.kaltech.co.il/pdf/Eureka_sd_wp1.pdf ,  It's crucial for anyone willing to understand how removable devices like sd card work, different protocols/functionalities they support. Secure Digital (SD) memory card today, is one of the most popular non-volatile removable data storage media for consumer applications. It's not intended to remove hard-disk. Hard-disk can still deliver much better speed and memory capacity. SD card is used in applications demanding optimum memory capacity, smaller size, and low end product cost.  The combination of small foot print, lower cost and optimal performance contributed in SD-card's success. What is MultiMedia Card (MMC)? MMC and Sd-card share many common features and have the same physical and electrical specifications. The differences between the two standards are mainly on the software level commands. The similarities allow many hosts to accept both MMC and SD cards on ...
Read more

Software licensing : Introduction and it's types

Image
A lot of things changes when you write your first code for commercially use. Software licensing is one of those. Usually while coding for my own projects, i earlier use to omit this. However, recently i was hit hard by this 'vague' topic of licensing. So, i decided to study in depth about different types of licenses for open source and propriety usage and here's the summary: A software license is a type of contract between the company/person who produces the code and the one who uses it. It defines the terms of usage of that piece of code. Before moving forward i have a curious question: What if, i copy a code without accepting it's license and use it under my own terms?Who's gonna know it, just copy, paste and use!! ? Well after searching the net i came across various case studies, some of which are very interesting... Reference: here Now, coming to the types of available licenses in Open source community:  GNU GPL License GPL license has mai...
Read more

Implementing a MMC/SD/SDIO stack using CAM framework(Part 2)

Image
Hi, In the next part lets look at other files which makes up the SDIO stack within mmccam framework. Please have  a look at previous part for more info: http://81.4.107.225/wordpress/index.php/2018/03/19/implementing-a-mmc-sd-sdio-stack-using-cam-framework/ mmc_sdio.c +void sdio_fill_mmcio_rw_direct(union ccb *ccb, uint8_t f, uint8_t wr, uint32_t adr, uint8_t *data) { + struct ccb_mmcio *mmcio; + + CAM_DEBUG(ccb->ccb_h.path, CAM_DEBUG_TRACE, + ("sdio_fill_mmcio(f=%d, wr=%d, adr=%02x, data=%02x)\n", f, wr, adr, (data == NULL ? 0 : *data))); + mmcio = &ccb->mmcio; + + mmcio->cmd.opcode = SD_IO_RW_DIRECT; + mmcio->cmd.arg = SD_IO_RW_FUNC(f) | SD_IO_RW_ADR(adr); + if (wr) + mmcio->cmd.arg |= SD_IO_RW_WR | SD_IO_RW_RAW | SD_IO_RW_DAT(*data); + mmcio->cmd.flags = MMC_RSP_R5 | MMC_CMD_AC; + mmcio->cmd.data->len = 0; +} sdio_fill_mmcio_rw_direct is basically a wrapper for CMD_52 that's needed ...
Read more