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

[Jarielle Catbagan]

Ed,

That fixed it! Thanks!

You were right about "MonStack" being mapped to DDR3 and being
utilized before the memory was initialized.

Prior to initializing the SP at the top of SRAM before invoking
pll_init and ddr_init, the SP was being initialized to point within
the DDR3 memory space.  Below is a part of the disassembly output that
shows this.

At 0x402f0538, SP is loaded with the value from 0x402f05b4.

        402f0524 <warmstart>:
        402f0524: e1a0b000 mov fp, r0
        402f0528: e10f0000 mrs r0, CPSR
        402f052c: e3c0001f bic r0, r0, #31
        402f0530: e3800013 orr r0, r0, #19
        402f0534: e121f000 msr CPSR_c, r0
        402f0538: e59fd074 ldr sp, [pc, #116] ; 402f05b4 <cache_init+0x4c>

Viewing this location, the SP is indeed loaded with a location within DDR3.

        402f05b4: 8000a880 .word 0x8000a880

I modified rom_reset.S to take into account your suggestions, and it works now!

Here is the commit that reflects these changes:
https://github.com/jrcatbagan/umon/commit/20d1fbe3e6738182cec1c920635b5898a074d35f

I will now prepare the changes for submission.

Thanks.

On Thu, Jul 16, 2015 at 4:38 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> 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
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel