CAM, FreeBSD, GSoC, mmccam, RTEMS, SDIO

Backporting MMCCAM/SDIO framework to FreeBSD head 642b174dadd

My phase 2, GSoC objectives includes Backporting the current(rev: d6756a3ac8 ) MMCCAM framework to FreeBSD head 642b174dadd and then importing it to RTEMS. This post mainly concerns with intricacies and workarounds during the backporting process.

Backporting is a process that enables old kernels run a latest driver. MMCCAM framework is one such enhancement in the past few months that enables FreeBSD to talk to devices behind the SDIO bus. It’s a major architectural change, that enables further driver development for devices on SDIO bus.

So, first step during backporting is to finalize the revisions from which driver will be imported(d6756a3ac8 in my case) and to the one it will be applied(642b174dadd). It’s really important to select these versions wisely, only after substantial testing to ensure bug free working of the driver.

Next step is to make a list of commits that we are concerned with i.e those which are used to introduce driver into the kernel. In my case,  github’s web interface was used to view all the commits like: .

Now, among these , commits are selected based on the following criteria:

  • Either it’s a small bug fix in CAM framework or the one that has no functional changes like: changes in comments/license etc.
  • These commits should only affect the CAM core files or applies directly to MMCCAM/SDIO stack. Major changes in CAM core files aren’t appreciated as they require updating CAM’s dependencies too, along with other CAM based frameworks like NVME,ATA etc. However, there were situations when updating dependencies becomes a necessity. For that, we have to first find all the dependencies on which CAM depends on and the ones which are dependent on CAM.

Finding dependencies

#include dependencies can be found by following methods:

View for other option. I used clangs -MM option to find all CAM dependencies. Dependencies, in my case mainly includes user space tools like camcontrol etc and CAM based frameworks(ATA,NVME,SCSI). Look at my patch used to import MMCCAM stack here, changes in sys/cam/ata/* , sys/cam/nvme/* , sys/cam/scsi/*, sys/dev/aic7xxx/* , sys/dev/drm/*, usr.bin/sdiotool/* are all minor changes in dependencies.

Now, we have the commits we want to apply. We can now apply them one by one and build kernel (With -MM option, if you are using that) to see any error/unmet dependency. I used git cherry-pick (here) to selectively apply commits.

Few workarounds:

While backporting MMCCAM stack, there were few workarounds which have to be taken care of when upgrading rtems-libbsd:

    • See commit e437fbd6d8c09cab8d2dcdcddd75834370e08e02 which is an CAM core API change and further require changes in all it’s dependencies, so i havn’t applied it. In short. due to this commit cam_periph_acquire returns 0(earlier it was returning CAM_REQ_CMP) on successful device acquire. Since this was skipped, new code added into MMCCAM stack needs some changes like look at line 423 of: here cam_periph_acquire(periph) != 0  has to be replaced with cam_periph_acquire(periph) != CAM_REQ_CMP . Similarly other occurrences of this function has to be changes.
    • All changes in user space  tools like camcontrol are not applied, mainly the ones which further require change in other modules, so it might not work properly. However, ‘camcontrol devlist’ is working correctly to scan and list cards. This is a bit irrelevant for the end purpose of porting it to RTEMS. similarly other userspace tools like sdiotool,mmcnull controller may not work as expected.

Building the kernel with backported MMCCAM stack

To build kernel with backported MMCCAM stack:

  • Grab the Freebsd-current repository and checkout to tree 642b174dadd
  • Grab the patch(here) and apply it to the repository.
  • Build the kernel with GENERIC-MMCCAM config file
  • Test the image and it will probably stop abruptly at mountroot> prompt, enter ufs:ufs/eMMCroota
  • This will scan eMMC partitions and will then export each partition as a separate disk. These can be viewed by entering ? in mountprompt.

Actually, with latest changes in SDIO stack, naming is a bit altered. Now the partitions are named as eMMCroot, sdda0s2a etc while by default it should be mmcsd0s2a. It was just a small tweak in fstab which solved this issue. But my fstab solution isn’t universally true, it will vary with the development board too. So, it’s always better to scan for available partitions by typing ‘?’ in mountprompt and then enter the root partition to boot from.

  • Here’s the log:


Tagged , ,

4 thoughts on “Backporting MMCCAM/SDIO framework to FreeBSD head 642b174dadd

  1. Nice work Udit! Thanks for the graphic too. How does the rtems team track patches to libbsd?

    I’m curious if there will be any differences in benchmarks from your earlier performance tests on Illya’s branch. Did you do any bench marking on FreeBSD head? Did you ever work out a standard deviation from your results?

    1. True, It would be fun to see if there is any difference in benchmarking results after latest partition update of the stack. I’ll carry forward with the tests right after the stack gets imported to RTEMS i.e in phase 3. I also have to compare the results of IOZONE with FIO, and yes i’ll work out standard deviation too. Thanks for feedback!

Leave a Reply

Your email address will not be published.

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