Update: uMon is now booting from SD

[Ed Sutter]

On 7/4/2015 10:42 PM, Jarielle Catbagan wrote:
> On Sat, Jul 4, 2015 at 6:02 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
>> On 7/4/2015 2:29 PM, Jarielle Catbagan wrote:
>>> Great to hear that it's working now!
>> Yep,  I will go ahead and push the patches as they are (since I was able to
>> verify the build), but we still need some documentation or a script on the
>> procedure for building the SD card.
> I agree, I'll most likely do a combination of a documentation and a
> script.to take care of the SD preparation.  I'll work it out and I'll
> send it over to you for review once I have it ready.
>
>>>
>>> For the "raw" mode, a Configuration Header TOC Structure had to be
>>> prepended before the GP header, am I right?
>> Right, and that is placed at the base of the SD card (or at one of a few
>> offsets)
>> just using 'dd'.  I can add that if you want me to.
>>>
>>> What are the other tasks that you would recommend I pursue.  I am
>>> thinking of getting the DDR initialization working and then Ethernet.
>>> What are your thoughts?
>>>
>> Definitely DDR init should be next on the list.  After that, Ethernet is a
>> good candidate,
>> however one other more fundamental interface is MMC.  Think about the actual
>> bootup of a full-blown bootmonitor that is then capable of loading an RTEMS
>> application...
> I see what you mean.  Yeah, the ultimate and ideal goal is to be able
> to boot from the onboard memory which makes getting the MMC interface
> working one of the main tasks along with DDR init.
>
>> First of all, we're building the "MLO" as they call it.  As we know, that
>> image is pulled from
>> SD (or EMMC) directly into SRAM.  This is the first stage, and I think we're
>> almost there.
>> Next, the program needs to initialize DDR and then load the FULL uMon into
>> DDR.  To do that
>> the MLO needs to be able to read from the SD card.  So it seems to me that
>> the MMC interface
>> to the SD card is really the next most important interface to tackle.
>>
>> Lets think about this a bit.  Obviously both interfaces are needed; but my
>> personal opinion is
>> that the ability to read from MMC is more fundamental.  Actually, a
>> functional BBB boot
>> monitor *could* run without Ethernet as long as it had the ability to load
>> from SD.
>> Let me know what you think...
> I am with you on that, both interfaces are very important.
>
> I was actually looking into DDR init for a while now by using AM335x
> TRM and http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
> and http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling
> for references, and I honestly feel like I can get the DDR init
> working first.  Nonetheless, I'll start looking into the MMC interface
> simulataneously as well so that I can also start working on the MMC
> initialization as soon as possible.
>
> Thank you for your advice.  I'll get started.
>
Great, sounds like a good plan to me.
Once you have DDR init working, I think you can claim that you've handled the low-level
bootup that the guys working on the BSP have not had to think about (because u-boot did it
for them).
After DDR is working, then MMC & Ethernet.   We need to reach out to the these guys
(Ben Gras & others) and see if they've already done some of these interfaces.  If they have,
then we reuse what they've done.  No point in reinventing that stuff if other folks on the
RTEMS team have done the work already.

Regarding MMC...
There are really two parts of code for MMC: the device specific code and the command line access
to it.  For the MMC, look at the main/common/cf.c code.  That is just a front end for a block accessible
device (cf=compact flash).  I suggest you just add a new file (mmc.c) in main/common that is
essentially a duplicate of cf.c, but pointing to mmc instead.  Then keep all of the command line
stuff in that file, and put the device specific code in your port directory.
Let me know if that makes sense.

More to come...
Another aspect we need to consider (after MMC & Ethernet) is cache.  At bootup, its all disabled
and that's safe, but its also slow.  On the other hand, enabling cache makes things messy for
a couple of reasons...
1. one of uMon's jobs is to "load" the RTEMS image from MMC to DDR. That means it will be using
     *data* writes to place *instructions* into memory.  Those instructions will eventually be fetched through
     the instruction cache.  Think about that... you wrote to memory through the dcache, but your fetching (the
     same address) through the icache.  You gotta make sure caches are flushed and invalidated in those areas.
2. some devices (Ethernet is a good example) can write incoming packets to memory space and the
     cache may not be aware of it (snooping sometimes deals with this, but not always), so again there is need
     to invalidate and flush depending on the operation.

Cache is a wonderful thing, but it does make this level of coding more more complex.
Don' t worry about that yet; concentrate on DDR & MMC for now.
I just wanted to make sure you know "we ain't done yet"!  LOL!!

Good work!