Hi Wolfgang,
On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger <vap...@gentoo.org> wrote:
> On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
>> =>md 0x100
>> 00000100:Segmentation fault
>
> yes, this is because the code to make this work was reverted because of ppc
> oddity. i haven't reviewed that yet to see why, but it seems to me that the
> ppc code is not quite right.
The commit which made this work was this one:
355a835 sandbox: Change md command to use map_physmem
and was reverted by:
94c50f1 Revert "sandbox: Change md command to use map_physmem"
The commit message from the revert is
The original commit broke long standing assumption that md commands work
on effective addresses. This normally isn't an issue for most systems
that map 1:1, however on systems with a 36-bit address map it breaks.
I did try to start a discussion on the list about how to deal with
this. One idea was to add a translation function in the md command
(and potentially then in other code) that converts an effective
address as seen by U-Boot into one that can be used by the
architecture. The down side is that all architectures except sandbox
would have this as a no-op.
I am pretty keen for sandbox memory to start at 0 if possible, since
it makes test code easier to write if we can make that assumption.
Also I don't like the idea of different people writing test code with
different assumptions about the memory map, such that we can't run all
the tests with the same sandbox config.
>
>> 2) Sandbox does no handle EOF on stadin; this makes it impossible to
>> use it in test scripts. For example, something like this should
>> work:
>>
>> $ echo printenv | ./u-boot
>
> currently as designed -- this is how the hardware works after all. it keeps
> polling stdin forever and there is no concept of "EOF" in a serial port. the
> reads are also non-blocking, so i'm not sure it's possible to tell when you've
> got EOF vs read too fast. might be able to contingent on stdin being a TTY
> though.
Yes I think this captures the current situation. We could perhaps add
some sort of hack to make this work, perhaps with a new CONFIG option
which accepts EOF on input and somehow passes it up the stack, or
keeps the info in sandbox's state. Another option would be to create a
special sandbox input device. In any case, it would be nice to
implement EOF in the console layer for this. Could be related to
serial cleanup also.
>
>> 3) For automatic test suites it would make a lot of sense if the
>> return code of U-Boot was the return code of the last executed
>> command (expecially when termination of U-Boot is the result of
>> encountering EOF on stdin).
>
> i'm not sure how hard that is to pass on. Simon might know since he's been
> grubbing around the shell internals lately. we could have reset take an
> argument in the sandbox path so it's easy to pass back arbitrary values in the
> middle of a script.
I'm pretty sure I had this working, at least for one shell. It was
part of the motivation for the command cleanup.
It would be worth sorting out these three things. Once we have a bit
of agreement on which way to go, I'm happy to come up with some
patches for any that don't have volunteers.
> -mike
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
