Umon command line reached in BBB

Jarielle Catbagan jcatbagan93 at gmail.com
Thu Jun 18 09:44:49 UTC 2015


I did some investigating as to why the 'help' command was hanging in
the BBB.  I am just going to specify the general order of function
invocations to help put the situation that I will try to describe into
context.

The Umon command line is presented in start.c via CommandLoop() and
any commands entered are passed to docommand().

Entering 'help' causes the command to be search through a command
table where Help() is soon invoked in docmd.c.  Help() then calls
showhelp().  I was able to pinpoint that program execution hangs at
the very last printf in showhelp().  This printf is
"printf("%-12s",cptr->name);

Removing the "-12" between '%' and 's' eliminates the issue of program
execution hanging but the format of the output is not justified
correctly.  Diving more deeper into the printf(). vsnprintf() in
mprintf.c is then invoked, followed by build_string(), then atoi() and
then finally strtol() in strtol.c.

The do/while loop in strtol() runs for one interation and then program
execution seems to hang in the 'while' conditional where isspace() is
invoked.  Based on my understanding, this do/while loop should execute
more than once, but its not.

Its 2:40 AM here at the time of this post, I will be investigating
more into this after I get some sleep.

Hopefully I did not miss anything.

Any suggestions will be much appreciated.

On Wed, Jun 17, 2015 at 4:09 PM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> Ed,
>
> I apologize for the misinterpretation/confusion.  My brain was
> thinking one thing but I managed to state something else.  What I
> actually meant to say was that some commands will not work just yet.
> Like the ARP, DHCP, or any of the TFS commands since the ethernet and
> flash drivers will have to be implemented first.
>
> I am still analyzing the results that I got, in particular when I
> executed the "help" command.  I am going to start looking into why its
> hanging, i.e. no help text is outputted.  Just wanted to ask, do you
> have any idea why it might be hanging?
>
> On Wed, Jun 17, 2015 at 3:57 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
>> Jarielle,
>> Those commands will work as long as you access valid memory.
>> Ed
>>>
>>> Going off of the discussion that I had with Ed in regards to getting a
>>> fully internal SRAM mapped Umon image to work before proceeding to
>>> implement the DDR3 configuration to have the RAM used by Umon mapped
>>> there, I went ahead and started working on it.
>>>
>>> I configured the Umon image to be fully mapped within the internal
>>> SRAM of the AM335x (i.e. BOOTROMBASE/BOOTRAMBASE defined to be within
>>> the internal SRAM with their corresponding lengths ensured to not
>>> overlap each other and to not exceed the SRAM boundaries), and then
>>> enabled INCLUDE_MEMCMDS by setting it to test the DM and PM commands.
>>> I know that these commands will not work properly given the fact that
>>> DDR3 is not set up yet, but just wanted to see if some command
>>> execution is possible.
>>>
>>> I then proceeded to build the image and then booted the image on the
>>> BBB via UART.  Once booted, the Umon command line was presented and
>>> did some command execution testing.  Nothing works properly as of
>>> right now, but now that I am able to reach the Umon command line I can
>>> now proceed to getting the other functions implemented.
>>>
>>> My results of getting the Umon command line on the BBB can be found in
>>> the screen capture provided below.
>>>
>>>
>>> https://drive.google.com/file/d/0B_44Dkqbmn75TjQwZjJaczNJYk0/view?usp=sharing
>>> _______________________________________________
>>> 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


More information about the umon-devel mailing list