Hi Wolfgang,
On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger vapier@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.
- 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.
- 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