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

Jarielle Catbagan jcatbagan93 at
Tue Jul 14 14:47:16 UTC 2015

On Tue, Jul 14, 2015 at 4:39 AM, Ed Sutter <ed.sutter at> wrote:
> Jarielle,
> Great!
> Some comments embedded...
> Ed
>> Hello all,
>> I finally manage to get the DDR3 memory initialized on the BBB! I was
>> able to access and manipulate values within the DDR3 memory space.
>> According to the AM335x TRM, Section 2.1 "ARM Cortex-A8 Memory Map",
>> Table 2-1 "L3 Memory Map", DDR memories can span the range 0x80000000
>> - 0xBFFFFFFF.
>> Prior to getting the DDR3 initialized, accessing an address within the
>> DDR memory space resulted in a data abort exception.  Now that I got
>> the DDR3 initialized I was able to manipulate values within the DDR3
>> memory space.
>> I have attached 2 screenshots showcasing my attempt to access the
>> beginning of the DDR3 memory space (0x80000000) both when the DDR3 is
>> uninitialized and initialized within uMon.
>> Shortly after getting the initialization working, I updated the
>> BOOTRAMBASE in the Makefile to map uMon's RAM in the DDR3.  After
>> doing this, uMon has appeared to enter a deadloop.  After some
>> investigation I have found that uMon's BSS section is being
>> initialized before the DDR3 is even initialized in start.c.
>> It appears that the current mechanisms of initializing the BSS prevent
>> uMon on the BBB to map the BSS in the DDR3.  I am thinking that
>> probably a workaround to this is to have uMon test and initialize the
>> RAM before using it, where this approach would be applied in general
>> among different platforms to cover all scenarios especially with
>> special cases like the AM335x.
> Note that there are two types of initialization going on here.  The more
> fundamental
> one is what you've done.  You configured the controller so that DDR is
> accessible
> and useable as general purpose random access memory.  That's the hard part.
> The umonBssInit() function is simply clearing out the memory space (setting
> all of
> bss to zero), it has to assume that the memory space is already initialized.
> If you look closer, there are times when the bootup steps around calling
> umonBssInit().
> This allows for cases where exceptions occur and we want to attempt to
> preserve state.
> So, umonBssInit() is where it should be.
> DDR3 should be initialized as early as possible.  This is a fundamental
> initialization
> so doing it in start.c is too late.  There are two ways to do this for
> BBB...
> 1. rewrite it in assembly and put the code in rom_reset.s (before the call
> to start).
> 2. in rom_reset.s (prior to calling start) temporarily set up a stack
> pointer that is at
>     the top of the SRAM, then call the C function you use to init DDR3
> Since you have SRAM to use as stack while you call the C function, you're
> able to
> use #2.  I always prefer keeping code in C whenever possible.  Note that you
> would
> not have this option if the SOC did not have internal SRAM; hence you would
> be forced
> to use #1.
>> Nonetheless with the current uMon, (DDR init included), the size of
>> the image is roughly 35 KB.  Given that the internal SRAM is roughly
>> 109 KB, I would say that uMon is still happy and so mapping uMon's RAM
>> in the internal SRAM is still OK.
> If you call your init out of rom_reset.S, then I think your problem will be
> solved.

I agree,fortunately the AM335x has an internal SRAM, so I'll take
advantage of option #2.

> Also, you can use the "MT" command to just let the board loop on the memory
> space testing it for a while.  That should just run cleanly until you stop
> it.

That is definitely handy.  I'll be looking into the "mt" command" that
way I can test the DDR3 memory even further.

>> My github branch "dev-ddr-init" contains everything I have so far with
>> setting up the DDR3.  Specifically, everything I have done so far is
>> in cpuio.c, which can be found here:
>> . Note that this branch is a moving target and is quite messy as of
>> right now.  I will now take this time to clean up the DDR3
>> initialization before submitting patches that will integrate this
>> feature with the master uMon sources.
>> With DDR3 initialization done, my next step aside from cleaning up the
>> DDR init is to get the MMC interface working.  This will ultimately
>> lead to booting up RTEMS applications not just from a uSD card but
>> ultimately from the onboard eMMC memory.  Once I get the MMC interface
>> working, I feel that booting up an RTEMS application is possible.
> Yep good stuff!  Still, its handy to have Ethernet as well, so don't forget
> about that!
> :-)

Definitely!  Ethernet is my next target after MMC.

Thanks for the advice!
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at
> _______________________________________________
> umon-devel mailing list
> umon-devel at

More information about the umon-devel mailing list