SD controller now initialized; still need to read SD ID and perform data block transfer. Some questions on TFS and booting an application image

[Ed Sutter]

Jarielle,
As usual, good progress!  :-)
I suggest you just continue down the path of hooking uSD/eMMC to the "sd"
command, and deal with TFS after Ethernet is working.    I say that 
because the
use (or not) of TFS here is going to be philosophical more than 
technical.  Its
just going to depend on how RTEMS users think they want to bring up 
their system.
I personally think a TFS-centric uMon bootup is very convenient and 
simple, but
I can't speak for the RTEMS folks that will be using it.

The BBB has MMC (for this discussion, just assume MMC refers to either 
uSD or eMMC);
therefore, it will likely have some other flash file system overlayed on 
it (FAT, YAFFS, etc...),
which is what will be "the" FS for the operating system at runtime.

There are several configurations to consider here...

1. Don't use any FFS in uMon at all:
    uMon boots up, establishes connectivity with MMC and Ethernet and 
based on
    the content of some area of raw MMC, it can either boot some 
already-installed
    RTEMS application or it can look to the network for a network boot.  
Once RTEMS
    is running, it will have access to the MMC in whatever format it wants.

2. Incorporate whatever FFS RTEMS will use into uMon:
    Since RTEMS already has some FFS-ish capabilities, just hook that 
same code
    (or fragments of it) into uMon so that both the bootloader and app 
can access
    all files easily.

3. Incorporate TFS in uMon by allocating some block of MMC to it:
    At startup, uMon initializes all periphery, and then has a section 
of MMC that
    it sucks into RAM and then TFS is overlayed on that block of RAM.
    Then uMon can have its typical script driven bootup, and RTEMS can 
optionally
    have access to that, while still using some other FFS for the MMC.

IMHO, mode #3 is ideal because that philosophy can be applied to any system
regardless of the memory configuration; however, I'd prefer that we get 
feedback
from some other RTEMS core developers to get thoughts on that.
Ed

> Hi Ed and all:
>
> Initializing the SD controller on the AM335x took a bit longer than I
> expected which was mostly a result of encountering some issues with
> the SD controller initialization, specifically the clocks that are
> involved.
>
> Now that I was able to resolve the issues I was facing, I was able to
> initiate CMD0 (GO_IDLE_STATE), CMD8 (SEND_IF_COND), and CMD55
> (APP_CMD) and was able to receive appropriate responses from any
> arbitrary SD card that is connected.
>
> Right now I have the interface setup using 4-bit SD mode with the SD
> clock frequency set to 6MHz and currently operating on 3.0 V.
>
> Currently, I am looking into reading the ID register and to write and
> read to/from the SD card.  I suspect that this would be much easier
> now since the SD controller is set up properly already.
>
> As I am approaching in getting ready to integrate the SD code, i.e.
> establishing the necessary code to get the "sd" command working, I am
> also simultaneously looking into TFS.
>
> It looks like a RAM-based TFS would have to be set up as both the
> MMC/SD can not be accessed linearly.
>
> Once TFS is set up, I would say that the next step would be to have
> the ability to transfer an application image from the SD card into TFS
> for uMon to boot from or, if it's possible, to transfer a raw
> application image from SD into DDR3 and then pass control to the entry
> point of the application image.
>
> Am I approaching the idea of TFS and booting an application image correctly.
>
> Thanks.
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel