Hi Michael, On Wed, Apr 10, 2013 at 5:07 AM, Michael Walle <mich...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
