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

Jarielle Catbagan jcatbagan93 at gmail.com
Wed Jun 17 18:32:31 UTC 2015


If there are any inconsistencies with the patches I submitted
regarding the changes I made, I am open to any suggestions/advice on
how I can improve them.  I am still familiarizing myself with the
process of preparing and submitting patches.

On Wed, Jun 17, 2015 at 10:42 AM, Jarielle Catbagan
<jcatbagan93 at gmail.com> 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.
> 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.
> 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.
> 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.
> 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 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.
> Thank you for the suggestion about the DM and PM commands.  I will be
> looking into these commands right now.
> 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

More information about the umon-devel mailing list