On Fri, 2009-11-13 at 12:01 -0500, Justin Waters wrote:
> Hi Peter,
>
> On Fri, 2009-11-13 at 11:50 -0500, Peter Tyser wrote:
> > Do no commands work for you, or just "help" in particular?
>
> >From what I can tell, just "help".
Interesting...
> > And are you seeing 2 separate issues: 1 where the help output is
> > garbled, and 1 where the "help" command can't be ran?
>
> Yes, I am seeing two separate issues. It depends on which commit I use.
> If I go back to the "readline" commit, then I get garbled output. Once
> the editenv commit is added back, I get the 'help not found' error.
I'm not sure what to make of this. I can't figure out how
"246c69225c7b962d5c93e92282b78ca9fc5fefee - Add 'editenv' command" would
fix the garbled output or cause the help command not to be found. Its
just adding a new command and shouldn't really have any impact on common
code.
> If I disable editenv and revert the changes to 'cread_line', then the
> error disappears. It will also work if I disable LONG_HELP and revert
> cread_line.
>
> > Would it be possible for you to add a bit of debug to diagnose the
> > problem further as I can't seem to reproduce it here?
>
> Absolutely. What would you like me to check?
Thanks. If I understand correctly, chronologically you first start
having issues when "ecc5500ee487170d8af6ff893fd1e0082380a01a -
readline(): Add ability to modify a string buffer" is applied.
If this is the case, I'd try debugging this issue first before
addressing the later 'help not found' issue.
Is there any pattern in the garbled output? Could you send an example of
it? Is only the output of 'help' is garbled, everything else is fine?
Could you add some debug to print out the value of init_len in
common/main.c:cread_line()? In theory as long as you don't run
"editenv" it should always be 0. Assuming it is always 0, could you try
commenting out the following snippet in the same file:
if (init_len)
cread_add_str(buf, init_len, 1, &num, &eol_num, buf, *len);
Then also try commenting out the modification to
common/main.c:readline():
console_buffer[0] = '\0';
Those 2 modifications are all that commit
ecc5500ee487170d8af6ff893fd1e0082380a01a added - I'd be curious to know
which one caused the problem.
Another interesting data point would be to remove CONFIG_SYS_HUSH_PARSER
from the AT91SAM9263-EK u-boot image and see if it breaks in the same
way.
Thanks again,
Peter
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
