[PATCH 3/16] Renamed BBB template linker scripts, updated architecture header file, Makefile, config.h
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:
> 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
> 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:
>> 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?
>>> 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
>>> 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
>>> 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
>>> 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>
>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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.
>>>> 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
>>>> with you and the repository. Last I recall, there was confusion
>>>> 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
>>>> (moving off svn
>>>> slowly but surely).
>>>> 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
>>> umon-devel mailing list
>>> umon-devel at rtems.org
>> 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
More information about the umon-devel