Update: uMon is now booting from SD

[Jarielle Catbagan]

On Sat, Jul 4, 2015 at 8:18 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
> 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).

It would be quite an accomplishment I would say. :-)

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

Definitely, will do!  I know that Ben has been dealing with the BB for
the most part with RTEMS, so I'll be asking him about that.

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

It makes sense.  I'll be keeping that in mind.  Thanks.

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

I have never dealt with setting up caches before.  This would
certainly be a great opportunity to have hands-on experience when the
time to deal with caches comes.  It would also be quite an
accomplishment along with the DDR init.

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

Hehehe :-)

I feel like I barely scratched the surface.  No doubt about it that
there is still a long way to go. But nonetheless, it's going to be a
fun journey and I am looking forward to it.

>
> Good work!
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel