[U-Boot] The abortboot routine misses key hits issued via netconsole.

[Michael Zaidman]

On Sun, Mar 21, 2010 at 2:35 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Michael Zaidman,
>
> In message <660c0f821002240238t71a6d793we93747bbb8bb8cf9 at mail.gmail.com> you wrote:
>>
>> The "Hit any key to stop autoboot:" of abortboot routine misses
>> the key hits issued via netconsole.
>> It happens due to delays of 10ms used to count passed seconds in
>> the abortboot routine of main.c file. All key events arrived
>> asynchronously during these delays are lost.
>
> If I understand your message correctly you did not try changing this
> 10ms delay?
>
> I mean, functionally it makes no difference if we implement the 1
> second delay loop as 100 iterations of 10 ms or as 1,000 iterations
> of 1 ms or as 10,000 iterations of 100 us. OK, the shorter the delay
> the worse the accuracy due to the per-loop overhead, but this could be
> easily fixed if it really was a problem.
>
> Maybe you can try of 1000*1ms or 10,000*0.1ms works for you?
>
> Best regards,
>
> Wolfgang Denk
>

I got your point... It may reduce the number of key misses by the
nc_tstc but will not eliminate the key misses at all. In current
implementation the netconsole interface while calling the nc_tstc() is
able to capture the pressed key during extremely short period of time
only – starting from the eth_init() until testing for incoming packet
in the Netloop routine. The related overhead for rest of the loop and
especially for eth_halt() and eth_init() is significantly longer then
active “ready to receive” window event if we will call only the
nc_tstc() in loop with no abortboot() involved at all. My coarse
estimation of “ready to receive/not ready” states duty cycle is far
worse than 1:10, i.e. lesser than 10% probability of success.  Now,
with abortboot() added it changes this ratio to be even worse making
capturing the key via netconsole interface almost impossible.

BTW, increasing by 10 the time of “ready to receive” state in
nc_tstc() as in described by me solution changed probability of key
capturing to ~ 90% but not eliminate the key misses completely.

Regards,
Michael