This is the final report of the work done under GSoC’18 with the RTEMS community. I’ll begin with a summary of all the work done during this summer and will then move towards the corresponding code and documentation developed throughout the timeline.
Porting SDIO driver to RTEMS and benchmarking
Student:- Udit Kumar Agarwal
Mentors:- Christian Mauderer, Punit Vara
Original proposal link: Here
Weekly updates:- https://devel.rtems.org/wiki/GSoC/2018#UditkumarAgarwal
Project tickets:- ticket#3429, ticket#3430, ticket#3428
Github Repository:– https://github.com/madaari/GSoC-rtems-18
ABSTRACT
RTEMS, being an open-source hard real-time operating system, is already supported by a vast community of developers, hobbyists, and industrialists. With its full application, it needs to stay updated and compatible with the new modern technology. Secure Digital Input Output(SDIO) is one such enhancement over pre-existing SD/MMC stack that not only provides external memory interface but also includes standard I/O features, thus supporting Wifi, Bluetooth, GPS, etc. access via our regular SD card slot. With that in mind, the first part of the project aims at importing the MMCCAM framework of FreeBSD via libbsd interface. The second part was more focused on importing a benchmarking tool and then to gather performance statistics of various drivers and filesystems.
Project deliverables
Phase 1 Evaluation:
Contrast and Import a Filesystem and IO Benchmarking tool to RTEMS. Fio was considered to be a suitable candidate. Here’s the corresponding ticket: https://devel.rtems.org/ticket/3429
Phase 2 Evaluation:
Phase 2 goals comprise of first backporting the current FreeBSD’s MMCCAM stack and then importing it to RTEMS. Here’s the ticket: https://devel.rtems.org/ticket/3428 Work that has to be done during phase 2 is NOT 100% complete, and there are bugs still needed to be resolved, Please have a look at the later sections for more details on the current state of the Imported MMCCAM stack and the bugs associated with it.
Phase 3 Evaluation:
Phase 3 goals were more focused on using the benchmarking tool and then gathering some detailed performance statistics of different RTEMS supported filesystems. The result of Phase 3 has to be an official report/document comprising of all the collected results along with their interpretations and conclusions for the end-user. Here’s the ticket: https://devel.rtems.org/ticket/3430
What was done – Code and Documentation
During phase 1:
Finished bare minimum FIO’s port for RTEMS. Further, revision in the port was done during phase 3.
Publication/Documentation: Blog_post#1 , Blog_post#2
Mailing list: Thread#1 , Thread#2
How to use this code?
Above mentioned patches can be applied to the latest FIO revision(commit id: 17924179519397e49a7a82fd99d860f9ef077645 ) and then follow the steps given below to get started with benchmarking on RTEMS.
- Prepare the RTEMS Toolchain: RTEMS toolchain can be prepared by using the RSB(tested with version 5 and commit id: commit id :25f4db09c85a52fb1640a29f9bdc2de8c2768988 ) for the desired BSP. While building the BSP, please enable POSIX support(required by fio) by –enable-posix option. Moreover, depending on your application, RTEMS-libbsd can be used to import device drivers, etc.
- Cross-Compile FIO using the above toolchain: Variable to be used for passing toolchain path is TOOL_PATH_PREFIX, and it can be set by something like:
$ export TOOL_PATH_PREFIX=/home/uka_in/development/sandbox/5
After setting up the variable, fio can be configured and built by:
$ make clean $ ./configure --cc=$TOOL_PATH_PREFIX/bin/arm-rtems5-gcc --disable-optimizations --extra-cflags=-O3 $ make fio CROSS_COMPILE=$TOOL_PATH_PREFIX/bin/arm-rtems5- V=1
By now, you should have the fio binary.
- Load the binary using the bootloader and enter the job configuration file: Use an appropriate bootloader like u-boot to load up the binary on the target platform. Please have a look at this note for configuring the u-boot. Once loaded, RTEMS will boot up, and RTEMS shell will get started. Use the file editor of the shell(which can be invoked via `edit` command) to enter the job configuration file.
- Call fio with the job-configuration filename as an argument :
$ fio config_file_name
Visit here for a more detailed overview of using Fio’s RTEMS port.
During phase 2:
Backported the MMCCAM framework and further imported it to RTEMS.
Publication/Documentation: Blog_post#1 , Blog_post#2
How to use this code?
During the time of writing this report, rrtemslibbsd(commit id: 137250239e9e0b244eb924928e8d1ec7996dcfef) uses FreeBSD rev. 642b174dadd for its sources, so the first step of using the SDIO stack is to backport the latest MMCCAM stack to the above mentioned FreeBSD version. This can be done by using Patch#1, which has to be applied on a clean FreeBSD rev. 642b174dadd.
Please note that soon there will be an update in the FreeBSD version used by rtems-libbsd, in that case above step would be not be required.
Patch#2 can then be applied to rtems-libbsd(tested with commit id: 137250239e9e0b244eb924928e8d1ec7996dcfef) and then follow these steps :
For exporting changes from `Freebsd` directory to `Freebsd-org` directory:
Run git status and make sure your working directory is clean. Run ./freebsd-to-rtems.py -R
For building libbsd:
$ cd rtems-libbsd $ git submodule init $ git submodule update rtems_waf $ waf configure --prefix="$sandbox/rtems-5" --rtems-bsps=arm/beagleboneblack --buildset=buildset/default-mmccam.ini $ waf $ waf install
What all results to expect?
You may see the stack powering up and initializing the SD/MMC/SDIO card along with various other information like CSD, CID register content, LUN ID, total size, partition types ,etc. For example:
(sdda1:sdhci_slot1:0:0:0): Capacity: 3925868544, sectors: 7667712 (sdda1:sdhci_slot1:0:0:0): Set SD freq to 52 MHz (min out of host f=96 MHz and card f=52 MHz) sdhci_ti1-slot0: Timing => 1 sdhci_ti1-slot0: sdhci_cam_update_ios: power_mode=2, clk=375000, bus_width=0, timing=1 sdhci_ti1: Custom-disabling 8-bit bus (sdda1:sdhci_slot1:0:0:0): Partition type 'RPMB', size 131072
Things may seem to work well until the following media_server failure log:
media listener: event = MOUNT, state = INQUIRY, src = /dev/sdda-0 media listener: event = MOUNT, state = FAILED, src = /dev/sdda-0 media listener: event = PARTITION INQUIRY, state = INQUIRY, src = /dev/sdda-0 media listener: event = PARTITION INQUIRY, state = FAILED, src = /dev/sdda-0 media listener: event = DISK ATTACH, state = INQUIRY, src = sdda media listener: event = DISK ATTACH, state = SUCCESS, src = sdda, dest = /dev/s1 media listener: event = MOUNT, state = INQUIRY, src = /dev/sdda-1 media listener: event = MOUNT, state = FAILED, src = /dev/sdda-1 media listener: event = PARTITION INQUIRY, state = INQUIRY, src = /dev/sdda-1 media listener: event = PARTITION INQUIRY, state = FAILED, src = /dev/sdda-1 media listener: event = DISK ATTACH, state = INQUIRY, src = sdda1boot
Above output states the inability of the driver to mount the partitions.
During phase 3:
In phase 3, more focus was put on the documentation rather than the code. We’ve collected several benchmarking statistics for different RTEMS-supported filesystems.
Documentation: Blog_post#1 , Blog_post#2
Publication: Paper on ‘Comparison between RTEMS filesystems in the EWiLi’18 conference.
What all results we got? – A Brief Insight
Different RTEMS-supported file systems were quantitatively contrasted against each other. Effect of different parameters like cache size, filesystem block size on the IO bandwidth, and latency was noted and was interpreted for the use of end user. Further, the overhead due to different calls for reading and writing a file like read()/pread()/readv() or write()/pwrite()/writev() was recorded and contrasted. Effect of IO block size on the bandwidth and it’s a variation with the file system was another interesting statistics that we gathered. Additionally, we carried out benchmarking of different RTEMS supported flash file systems, namely, JFFSv2 and YAFFS2.
Please note that the link to the paper will be added soon, once it gets published.
What is left – Bugs and Further Enhancements
Summarizing in a few words, Currently, the SDIO stack can Detect and initialize all sorts of SD/MMC/SDIO cards. It’s able to read and modify registers. However, several bugs exist in part responsible for mounting the partitions using the RTEMS media server. Details on this can be found in my previous blogs.
There is always some scope of enhancement. Similar is the case with Fio’s RTEMS port. Currently, only a few of the standard ioengines were made to work. However, there’s a large part, currently disabled like ioengines for benchmarking network filesystems that can be fixed and put to work.
Acknowledgment
So this is it – the end of the official GSoC coding period, time to sign off for a couple of days. Thank you to the Google Summer of Code Team and the RTEMS community for bringing this project to life, and of course, huge thanks to my mentors Christian Mauderer and Punit Vara for their feedback and guidance throughout the entire project. I would further like to extend my deep gratitude towards our RTEMS organization admins, Dr. Joel Sherrill and Gedare Bloom, for their valuable inputs and support. Special thanks to Russell Haley, Illya Bauklin, and the FreeBSD and FIO community for their wonderful reviews and generosity.
Altogether, this was a great experience, and I will remain an active contributor for the foreseeable future. Happy coding!