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

Wed Jun 17 17:42:53 UTC 2015

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