BBB: DDR3 is now initialized, next step is initializing MMC interface.

[Ed Sutter]

Jarielle,
I think I see the problem (assuming I'm looking at the correct 
rom_reset.S)...
Since you're mapping uMon's space to be in DDR3, that means you can't
use that space until after you've initialized DDR3.

That means when you set up your initial (temporary) stack pointer so that
you can call the C-functions that you wrote to do the initialization, 
you need
  to use memory that is in SRAM,  you can't use "MonStack" (because it is
mapped to DDR3 space).
So, you want to do this (pseudocode):

    - INIT SP to top of SRAM space in Sitara
    - Call pll_init
    - Call ddr_init
    - INIT SP to MonStack
    - Call start with R11 as parameter

That should do it for you.
Lemme know,
Ed


> Hi Ed,
>
> I was able to make the necessary modifications in order to move the
> DDR3 initialization to rom_reset.S.
>
> Despite being able to access and manipulate values in the DDR3 memory
> space from the uMon command line, I am currently encountering an issue
> when attempting to map uMon's RAM in the DDR3.  Doing so is causing
> uMon to "hang".  I am currently looking into this issue.  In the
> meantime, the changes I made to rom_reset.S and cpuio.c that
> initialize the DDR in rom_reset.S can be found in one of the latest
> commit at my temporary github development branch which can be found
> here: https://github.com/jrcatbagan/umon/commit/d9da7ab9cc6c21d9bfc293e0422ef00dbe03d6c2
> .
>
> I'll be updating as I go along and I will be submitting the changes
> once I have this issue resolved.
>
> On Wed, Jul 15, 2015 at 8:03 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
>> On 7/15/2015 7:08 PM, Chris Johns wrote:
>>> On 15/07/2015 8:48 pm, Ed Sutter wrote:
>>>> On 7/14/2015 9:47 PM, Chris Johns wrote:
>>>>> On 15/07/2015 1:40 am, Ed Sutter wrote:
>>>>>> http://www.umonfw.com/docs/umon_user_manual.pdf
>>>>> Where is the source for this ?
>>>> Its a WORD document on my server.  Why?
>>> I was just wondering how we maintain the documentation. I do not use
>>> Word of OpenOffice.
>> I started that document around 2000, and it just grew as uMon progressed.
>>>
>>>>> For documentation I suggest the reST format
>>>>> (http://sphinx-doc.org/rest.html). I think RTEMS will move to this
>>>>> format in time.
>>>> I'll take a look.
>>> It is really neat stuff and we can generate the doco in the server based
>>> on a commit. This keeps the online documentation updated.
>>>
>>>
>> So is this some kind of alternative to doxygen?
>>
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel