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

[Ed Sutter]

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.
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.
>
> 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:
> https://github.com/jrcatbagan/umon/blob/dev-ddr-init/ports/beagleboneblack/cpuio.c
> . 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!
:-)

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