Direction of UMon Was: Re: Umon command line reached in BBB

Gedare Bloom gedare at gwu.edu
Fri Jun 19 13:53:34 UTC 2015


Hi Jarielle,

Here are some ideas about the vision we had when decided to move
forward with this path for umon.

The version you are developing is going to be "the umon". We are
re-vitalizing umon and giving it a fresh look with the blessing of its
original maintainer Ed, who is on-board for this. Future releases will
be based on the work you are doing, and probably the first version
that "works" is going to be for the BBB.

Thus, the umon tree at git.rtems.org/umon.git is going to be the main
umon tree, and we can continue to add code into it from the old tree,
or from other suitably-licensed sources.

I hope that helps,
Gedare

On Thu, Jun 18, 2015 at 6:12 PM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> 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
>>>
> _______________________________________________
> 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