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

Jarielle Catbagan jcatbagan93 at gmail.com
Fri Jun 19 22:51:26 UTC 2015 

Gedare,

Thank you for the clarification.  That makes perfect sense.

On Fri, Jun 19, 2015 at 6:53 AM, Gedare Bloom <gedare at gwu.edu> wrote:
> 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