Dear Simon,
In message CAPnjgZ1aV723LzF1vnMOArix6DNXFHO-962Y8WQij5-G46226g@mail.gmail.com you wrote:
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 don't see why such a function would be needed. Other architectures don't need it either. Yes, some architectures use a common, fixed mapping (like PPC, where physical RAM almost always starts at address 0x0) - but others don't have such a common map- for example on ARM, there is a wild mix where RAM starts, and basicly every SoC defines his own mapping.
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.
On ARM you don't have this either.
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.
Eventually introducing two variables like ramstart and ramend would solve 90% of the potential issues.
In any case, information returned by commands like bdinfo must be correct.
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
I don't see why we cannot simply read from stdin (or rathr from file descriptor 0) as usual? You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF.
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.
Good point.
Marek, can you please add this to the DM planning?
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.
Thanks!
Best regards,
Wolfgang Denk