[PATCH 3/16] Renamed BBB template linker scripts, updated architecture header file, Makefile, config.h

Wed Jun 17 22:00:30 UTC 2015

On 6/17/2015 1:42 PM, Jarielle Catbagan wrote:
> Ed,
>
> Thank you for your detailed responses.
>
> In regards to your first response, I understand perfectly that the
> terms "ram" and "rom" don't really apply to the BBB.  I was putting
> ram_reset.S to the side, but with your clarification I can now focus
> only on rom_reset.S.  What helps me avoid any confusion is that I like
> to think that in a sense the internal SRAM is acting like a ROM access
> when the processor (AM335x) first boots up an image.
Right
> I just want to acknowledge some of the things you have stated in your responses.
>
> I understand that all RAM used by Umon is within the bss section, and
> as you have mentioned and was stated in the comments for umonBssInit()
> that the stack is located within this section as well.  I understand
> perfectly that this stack must not be initialized when its in use
> otherwise program corruption can occur, which you have already
> mentioned.
Right
> Furthermore, I know that the intended location of the bss section for
> the BBB will be in DDR3 and so I understand that DDR3 will have to be
> initialized early on before umonBssInit() is invoked.  The blog post
> regarding DDR3 is still a work in progress and as a result I still
> have to add in a lot more information in particular how DDR3
> initialization should be done in rom_reset.S.  Actually, I already
> started implementing the DDR3 configuration in rom_reset.S and I'll be
> pushing the changes to my github once I have something substantial,
> which should be very soon.  Once that's working, I'll have a patch
> that will include these changes.
Great!
> I actually didn't really think much about having the Umon bss section
> within the internal SRAM as I was focused on setting up DDR3 and then
> having the bss section there.  But since you mentioned about mapping
> all of Umon within the internal SRAM, it got me thinking.  Looking at
> the simple Umon image that I had built a while back that simply prints
> a character in a loop, I noticed that everything gets built into the
> image.  I went ahead to verify this using 'objdump -d'.  The point
> that I am trying to make is that the size of this boot version of Umon
> (the .bin file, not .elf) is roughly 36KB.  The internal SRAM is 109KB
> so it's possible to have all of Umon mapped within the internal SRAM.
> Running everything from the internal SRAM for now can surely result in
> having something up and running a lot sooner.
Right, that's the idea.  And it lets you more easily test your DDR3 
initialization because
now you can do it through a temporary command built into uMon instead of 
testing
it by just blindly booting and running the init code in rom_reset.S.  
Know what I mean?
>
> So I'll shift gears a bit.  I work on having everything mapped in the
> internal SRAM, while working simultanesouly on the DDR3
> initialization.  With the former task, I just want to be able to reach
> the Umon command line.  Once DDR3 is set up and running, the BBB Umon
> implementation will be configured to have its RAM there instead of the
> internal SRAM.
Right!
> Right now I have two git branches, one of which is for development.
> So I'll make a new development branch that way I can have one branch
> solely for the development in getting a fully internal SRAM mapped
> Umon image working and another in getting the DDR3 set up.  I'll push
> the branches shortly to my github, that way you can track my progress.
Yea, the port that I was playing with works that way.  I was trying to 
get it to boot directly
from the SD card so that I wouldn't have to keep doing the UART boot.  I 
will pursue that
if that helps.
> Thank you for the suggestion about the DM and PM commands.  I will be
> looking into these commands right now.
Then you can use DM and PM (in place of the assembly code in 
rom_reset.S) to write to
the DDR control registers and then verify that DDR is accessible. Then 
eventually you
could enable the "MT" (memory test) command to do more rugged tests.  
Once that
is somewhat solid, then you can move those command sequences over to 
equivalent
assembly code in rom_reset.S.

>
> On Wed, Jun 17, 2015 at 9:52 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
>> Jarielle,
>> One other thing I just noticed (still related to the blog)...
>>
>> This is a big one actually, so I wanna make sure you understand this.
>>
>> The umonBssInit() function assumes that the memory it is initializing
>> is already configured.  This means if you want to use DDR3 as uMon's
>> BSS space you need to configure it somewhere in rom_reset.S
>> (prior to any code that actually uses it).
>> Note, there is a difference between "configure" and "init" here...
>> In this context, "configure" means you program the CPU's DDR
>> controller to deal with the physical memory that is attached to it.
>> Then "init" simply means that we clear the content to be zero.
>>
>> So, to keep things simple (at least until you get DDR3 initialized clean), I
>> would just map all of uMon (both rom and ram) to reside in the internal
>> SRAM of the CPU.   Then you can use the DM and PM commands at the
>> console prompt to test your DDR3 initialization.
>> Know what I mean?
>> Ed
>>
>>> Hello Ed,
>>>
>>> Your Git terminology is spot on. :-)
>>>
>>> I cloned the source tree from the RTEMS git repositories.  The Umon
>>> source tree that I worked off of was cloned from
>>> https://git.rtems.org/umon/.
>>>
>>> Please let me know if you have any questions, comments, or concerns in
>>> regards to cloning Umon.
>>>
>>> I am finishing up patches 4/16 to 16/16.  These patches simply include
>>> various modifications/additions to get the BBB directory looking more
>>> like a BBB directory.  I will be submitting them very shortly.
>>>
>>> Hopefully these patches come out all right because to be honest this
>>> is actually my first time preparing and submitting patches.  If there
>>> are any discrepancies, please do let me know along with any
>>> suggestions on how I can resolve the issue.
>>>
>>> Just FYI, I created a blog post documenting how I was approaching the
>>> porting process.  It can be found here
>>> http://www.jariellecatbagan.com/the-approach-to-porting-umon-to-the-bbb/.
>>> Just as before, please let me know if there are any discrepancies.
>>>
>>> As of right now, I am simultaneously preparing the remaining patches
>>> while working on implementing the DDR3 initialization.  I have also
>>> created a blog post regarding the fundamentals of DDR3 and what it
>>> entails to configure it for use on the AM335x/BBB.  The blog post that
>>> I created can be found here
>>>
>>> http://www.jariellecatbagan.com/the-theory-behind-external-ddr3-initialization-on-the-bbb/.
>>>
>>> I just want to ask what do you think about my thought-process.  Am I
>>> approaching the porting process in the right direction?
>>>
>>> Thank you.
>>>
>>> Best Regards.
>>>
>>> On Wed, Jun 17, 2015 at 5:08 AM, Ed Sutter <ed.sutter at alcatel-lucent.com>
>>> wrote:
>>>> On 6/17/2015 4:51 AM, Jarielle Catbagan wrote:
>>>>> Please excuse me if I might have caused any confusion regarding the
>>>>> order of the patches.  The first two submitted, with the first patch
>>>>> still waiting for approval to be submitted into this mailing list at
>>>>> the time of this patch's submission, are [PATCH 1/16] and [PATCH
>>>>> 2/16].
>>>>>
>>>>> The template linker scripts were renamed to correspond to the PLATFORM
>>>>> variable in the BBB Makefile.  The architecture header file was
>>>>> renamed to relate to the BBB platform.
>>>>>
>>>>> Modified the CPU type supplied to the -mcpu compiler switch to
>>>>> cortex-a8.
>>>>>
>>>>> Updated the ROM length that can be potentially allocated to Umon
>>>>> during the initial boot.  This is done through the modification of
>>>>> BOOTROMLEN in the Makefile.  The value assigned reflects the fact that
>>>>> there are 109KB that can be used by Umon during the initial boot
>>>>> procedures.
>>>>>
>>>>> Modified the DEFAULT_ETHERADD in config.h to match the MAC addresses
>>>>> associated with the MAC address of the BBB's that I have.  This value
>>>>> should be updated on a user-by-user basis.
>>>>>
>>>>>
>>>> Jarielle,
>>>> Good stuff...
>>>> Now I need to play catchup.
>>>> I had been working with my own local copy of the bbb port, so I need to
>>>> sync
>>>> up
>>>> with you and the repository.  Last I recall, there was confusion
>>>> regarding
>>>> where
>>>> to grab the code from.  Where are you cloning your tree from?
>>>> Sorry if my "git terminology" is off, I'm still a relatively new user of
>>>> git
>>>> (moving off svn
>>>> slowly but surely).
>>>> Ed
>>>>
>>>> --
>>>> Ed Sutter
>>>> Alcatel-Lucent Technologies -- Bell Laboratories
>>>> Phone: 908-582-2351
>>>> Email: ed.sutter at alcatel-lucent.com
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> --
>> Ed Sutter
>> Alcatel-Lucent Technologies -- Bell Laboratories
>> Phone: 908-582-2351
>> Email: ed.sutter at alcatel-lucent.com
>>
>> _______________________________________________
>> 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


-- 
Ed Sutter
Alcatel-Lucent Technologies -- Bell Laboratories
Phone: 908-582-2351
Email: ed.sutter at alcatel-lucent.com