On Sun, Mar 21, 2010 at 2:35 PM, Wolfgang Denk <w...@denx.de> wrote: > Dear Michael Zaidman, > > In message <660c0f821002240238t71a6d793we93747bbb8bb8...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot