[U-Boot] Sandbox question

[Wolfgang Denk <wd@denx.de>]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.