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

Jarielle Catbagan jcatbagan93 at gmail.com
Tue Jul 28 21:06:15 UTC 2015


On Tue, Jul 28, 2015 at 12:46 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
> 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.

Have a great vacation! :-)

>
> 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.


More information about the umon-devel mailing list