Umon command line reached in BBB

Jarielle Catbagan jcatbagan93 at gmail.com
Thu Jun 18 22:12:43 UTC 2015 

Ok so I tried changing the while() condition in strtol.c (just a temporary fix)

from:

        while (isspace((unsigned char) c));

to:

        while (c == ' ');

and now it doesn't hang.

I tried building the same Umon image that is fully mapped in internal
SRAM using the previous Umon 1.19 sources and it doesn't hang in
"isspace()" as well.  isspace() is from ctype.h and so one of the
things that I found was that strtol() in strtol.c from the old Umon
sources pulls in a local ctype.h and as a result ctype.h exists under
the "common" directory.

On the other hand, strtol() in strtol.c in the new Umon sources pulls
in a system defined ctype.h.  There is no local ctype.h under the
"common" directory for the new Umon sources.  If I am not mistaken,
did this local ctype.h contain code that conflicted with the licenses
involved?  Either way, this new configuration where the system defined
ctype.h, in particular when isspace() is executed, causes program
execution to hang when the "help" command is executed.

The "while (c == ' ');" is only a temporary fix and I want to keep
strtol.c along with the other main Umon files (i.e. under the "main"
directory) intact otherwise it will probably break other existing
ports (even though I am working on the BBB port in isolation from the
other ports).  So really, I want to get isspace() working.  I still
need to find out why isspace() from the system-defined ctype.h hangs.

I have some questions:
    1. The development towards implementing a BBB port uses the new
Umon sources stripped of any code from the old Umon sources that would
conflict with the licenses involved.  Will this mean that there will
be two different versions of Umon where one of the versions will
satisfy RTEMS and perhaps other projects that share the same
perspective on license requirements.
    2. If the BBB port will ultimately be integrated with the main
Umon source tree, how will projects like RTEMS be satisfied?  Will
something like conditional building be integrated or something of the
like?
    3.  I am also curious as to whether or not there is any
possibility that the main Umon source tree will migrate to Git?

On Thu, Jun 18, 2015 at 3:11 PM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> Thanks! :-)
>
> Ok so I tried changing the while() condition in strtol.c (just a temporary fix)
>
> from:
>
>         while (isspace((unsigned char) c));
>
> to:
>
>         while (c == ' ');
>
> and now it doesn't hang.
>
> I tried building the same Umon image that is fully mapped in internal
> SRAM using the previous Umon 1.19 sources and it doesn't hang in
> "isspace()" as well.  isspace() is from ctype.h and so one of the
> things that I found was that strtol() in strtol.c from the old Umon
> sources pulls in a local ctype.h and as a result ctype.h exists under
> the "common" directory.
>
> On the other hand, strtol() in strtol.c in the new Umon sources pulls
> in a system defined ctype.h.  There is no local ctype.h under the
> "common" directory for the new Umon sources.  If I am not mistaken,
> did this local ctype.h contain code that conflicted with the licenses
> involved?  Either way, this new configuration where the system defined
> ctype.h, in particular when isspace() is executed, causes program
> execution to hang when the "help" command is executed.
>
> The "while (c == ' ');" is only a temporary fix and I want to keep
> strtol.c along with the other main Umon files (i.e. under the "main"
> directory) intact otherwise it will probably break other existing
> ports (even though I am working on the BBB port in isolation from the
> other ports).  So really, I want to get isspace() working.  I still
> need to find out why isspace() from the system-defined ctype.h hangs.
>
> I have some questions:
>     1. The development towards implementing a BBB port uses the new
> Umon sources stripped of any code from the old Umon sources that would
> conflict with the licenses involved.  Will this mean that there will
> be two different versions of Umon where one of the versions will
> satisfy RTEMS and perhaps other projects that share the same
> perspective on license requirements.
>     2. If the BBB port will ultimately be integrated with the main
> Umon source tree, how will projects like RTEMS be satisfied?  Will
> something like conditional building be integrated or something of the
> like?
>     3.  I am also curious as to whether or not there is any
> possibility that the main Umon source tree will migrate to Git?
>
> On Thu, Jun 18, 2015 at 4:29 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
>> Get some sleep! :-)
>>
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>

More information about the umon-devel mailing list