BBB: "sd" command mostly implemented; Some tests in booting RTEMS sample applications

[Ed Sutter]

Cool!  Yeah it is very possible that the code is specific to SPI mode.  If I recall correctly I've only implemented SD over SPI , so it's very possible I did something specific to that mode. I am on vacation most of this week so I'll be a bit out of touch.

On July 28, 2015, at 2:28 AM, Jarielle Catbagan <jcatbagan93 at gmail.com> wrote:

Hello all:

So I was finally able to retrieve an SD card's ID as well as
reading/writing multiple data blocks to/from the SD card to the DDR3.

As I was in the process of implementing the BBB port specific
functions to get the "sd" command to work, I came across that most of
the current SD implementation in uMon tailor to SPI mode.  There are
some CMDx commands that require what's known as an RCA, or Relative
Card Address, that essentially addresses a particular command to a
specific SD card which doesn't exist in SPI mode.

Since I wanted to make no change to the core files as of right now, I
kept the RCA as a global variable in the BBB port.  This choice is
probably not ideal in the long term but is a temporary approach as of
right now and I look forward to improving the implementation when the
time comes to fully optimize the code.

Additionally, I am looking to coordinate in generalizing the "sd"
command source implementation to take into account SD mode in addition
to SPI mode.

Taking the idea from the csb740 port, where it separated the SD
functions in a separate source file, I chose to do the same.  I
implemented all the necessary back-end functions to the "sd" command
in a new file "am335x_sdmmc.c".  This can be found in my dev branch
here: https://github.com/jrcatbagan/umon/blob/dev-sd-card/ports/beagleboneblack/am335x_sdmmc.c
.

This source file still needs cleaning up, which is my next task to get
ready to integrate the "sd" command functionality into the main BBB
port.

I have attached a screenshot illustrating my attempt in using the "sd"
command after I implemented the necessary parts.  Basically what I was
doing was displaying some memory in DDR3, copying that memory to the
SD card via "sd write", clearing the same memory in DDR3 with "fm",
displaying it once more to show that it has been cleared, and finally
reading back the old contents from the SD card to the same area in
memory via "sd read".

During the time I was implementing the SD card data block read/write,
surprisingly it did not take that much to integrate some temporary
mechanisms to transfer an application image from the SD card into DDR3
and then execute it.

I built some RTEMS sample applications, placed it in the SD card in a
location where uMon can find it and had it transferred into DDR3
before finally passing execution to the application.  I have attached
an additional two screenshots illustrating my attempt in booting both
the "hello" and "ticker" RTEMS sample applications for the BBB.
Basically this gave me the idea that booting an application image is
not far off.

As I am cleaning up the "sd" command functions in the BBB port, I am
simultaneously looking into implementing the interface to the onboard
eMMC which should be pretty much similar to the interface to the SD
card. After that I will be pursuing Ethernet.