[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 16:57:16 Mike Frysinger wrote:
> On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote:
> > Mike Frysinger wrote:
> > > > You can use standard methods like select() or poll() to wait for
> > > > input, which will also inform you about events like EOF.
> > > 
> > > because that isn't how u-boot on the hardware works.  u-boot itself
> > > calls tstc() to see if there's any data and does so in a continuous
> > > loop.  when there is data, it calls getc().  tstc() should not block,
> > > and getc() isn't call unless u-boot knows there's data.
> > 
> > That's why I suggested to use select() or poll() to poll for available
> > characters, just like the hardware does.  Only we do NOT want to tun
> > this in a tight loop.  We will most likely want to add a sufficiently
> > large delay to keep CPU load in reasonable bounds.
> 
> where exactly do you propose adding this delay ?  tstc() is called in many
> places (not just the main console loop), many of which are done simply to
> handle the unlikely CTRL+C interrupt.  thus we don't want tstc() delaying
> at all or it'll slow down random CPU-bound operations.
> 
> also, what you're proposing is changing the behavior of u-boot when it's in
> the sandbox so that it acts less like the hardware.  when you run u-boot on
> the hardware and it's sitting at the prompt, u-boot is running the cpu at
> 100%.

hmm, maybe the hush shell works differently and calls getc() directly rather 
than itself calling tstc().  so in the hardware, it eats the cpu because the 
hardware has no way of sleeping for the data, but in an OS we can wait for 
input.  should be easy to post a patch for this code path.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/bb019221/attachment.pgp>