[U-Boot] The abortboot routine misses key hits issued via netconsole.
Hello,
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.
I solved it localy on my mpc8349 @ 514MHz based board by expanding netloop receive window for netconsole case by 10 in nc_tstc routine and eliminating 10ms delays from wait loop of abortboot routine when compiled with CONFIG_NETCONSOLE and stdin configured to "nc".
This solution has following drawback - the Console multiplexing (CONFIG_CONSOLE_MUX) will not work because it relates on tstc immediate return. The mitigation factors are: 1) The console mutiplexing could not work anyway when is used with netconsole due to the same limitation as in case with abortboot explained above. 2) See CAVEATS in README.iomux; 3) Currently, AFAIK, console multiplexing is not used by any board.
Definitely, not resetting of the eth interface as discussed in http://lists.denx.de/pipermail/u-boot/2010-January/067260.html would be better solution but I am afraid its proper realization may require significant effort under current IP stack architectural limitations.
Any thoughts/opinions/comments will be highly appreciated.
Regards, Michael
Dear Michael Zaidman,
In message 660c0f821002240238t71a6d793we93747bbb8bb8cf9@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
On Sun, Mar 21, 2010 at 2:35 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Zaidman,
In message 660c0f821002240238t71a6d793we93747bbb8bb8cf9@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
participants (2)
-
Michael Zaidman -
Wolfgang Denk