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

[Jarielle Catbagan]

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