Hi Michael,
On Wed, Apr 10, 2013 at 5:07 AM, Michael Walle michael@walle.cc wrote:
On Wed, April 10, 2013 03:51, Joe Hershberger wrote:
Hi Michael,
I just tested this on my Zynq target and it worked. However, you make a good point that it is possible for there to be more traces after the eth_halt call. I can't imagine the stack would like that in all situations (since eth_init() will not be called again by netconsole). I think the solution to this is probably to disable netconsole somehow before the eth_halt command, so subsequent prints do not try to use Ethernet again. However, most of the things you might switch to are conditional, such as a nulldev or silent. Any thoughts on how you would like to see it solved?
Hi Joe,
disabling the network console before control is handed over to an operating system sounds reasonable.
If i understand you correctly, the network will only be halted once the bootloader starts an operating system. Then what do you think about making either the nc_send_packet() or nc_putc()/nc_puts() function a noop when the network is halted?
It's not quite that simple since the state does not really reflect the hardware (I know... that's my fault). I can try to fix this for next release, but it is probably too risky to put into the April release. In the mean time a simple work-around is to use silent or nulldev on your target and turn off netconsole as part of your boot script (before you bootm).
Cheers, -Joe