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.