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

[Ed Sutter]

Jarielle,
This response is limited to discussing the blog regarding your approach to
porting umon to the BBB...

First, I agree that you are best to start with CSB740 code as you are doing.
But when reading the umon documentation and code, always keep in mind one
big difference between the CSB740 and the BBB (i think we discussed some
of this already)...

The CSB740 had NOR flash for boot; the BBB's boot device is MMC (either
eMMC or uSD).  NOR flash is XIP (execute in place) capable; but MMC is not.
The significance here is that the code in rom_reset.S was placed directly
in the NOR flash (i.e. rom) and when the CSB740 came out of reset it was
configured to jump to the base address of the NOR flash device and start
executing that code.  In that case there was no need for intervention from
the CPU's rom-based bootloader.
Since the BBB does not have XIP boot memory, the AM335x's rom-based
bootloader has to retrieve the image from the eMMC (or uSD) and put it in
internal SRAM and then start executing it.

I realize you already know all this; but I'm pointing it out because the
terms "ram" and "rom" as they are used in the CSB740 port don't really
apply for the BBB.  You even mention this in your blog, I just want to make
sure its clear that the "rom_reset.S" will be running out of ram on the BBB
because of the need for the transfer from eMMC to SRAM.  Further, I'd
say that its safe for us to just ignore the use of ram_reset.S (and the
corresponding linker file) for this scope.

I think that's already clear, but I just want to make sure there is no
confusion.

Regarding umonBssInit()...
The important thing to note here is that ALL ram used by uMon is statically
allocated as part of umon's bss space.  This includes heap and stack
(as mentioned in the comments).  For heap, we assume this is called prior
to any use of the heap.  For stack we just have to be careful. The point
to note is that the STACK space (array = MonStack, size = MONSTACKSIZE) is
within the same bss space and since we are calling this from 'C', we're
using that stack so we don't want to initialize it here cause it'll cause
the system to crash due to a corrupt stack.  Know what I mean?

Some of this stuff may seem odd when compared to normal systems; but you
need to keep in mind that the original goal of uMon was to allow it to
"assist" the running application.  This meant that it had to maintain its
context even after control was turned over to the application. This is a
philosophical decision that probably needs to be made per port, and for
this scope I suggest we assume that once uMon turns over control to the
application it will not return (this is a nice simplication we can undo
if time allows).

That's it for now; I hope I didn't confuse things.  I just want to clarify.
Hopefully a reasonably equipped uMon will run directly out of the AM335x's
internal SRAM; otherwise we may have to turn this into a 2-stage bootup.
For now, lets assume that won't be necessary.

That being the case, then I agree that the next big hurdle is DDR3 init.
Good work!
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