Hi, On 23 March 2015 at 13:55, Jörg Krause <joerg.krause@embedded.rocks> wrote: > > Joe, Simon, > > On Mo, 2015-03-23 at 10:46 -0600, Simon Glass wrote: > > Hi Jörg, > > > > On 22 March 2015 at 14:37, Jörg Krause <joerg.krause@embedded.rocks> wrote: > > > Hi Joe, > > > > > > On Sa, 2015-03-21 at 22:59 -0500, Joe Hershberger wrote: > > >> Hi Jörg, > > >> > > >> On Sat, Mar 21, 2015 at 3:33 AM, Jörg Krause > > >> <joerg.krause@embedded.rocks> > > >> wrote: > > >> > > > >> > Hi all, > > >> > > > >> > there is an issue with the current network stack using netconsole. It's > > >> > impossible to use network commands as TFTP inside netconsole, because > > >> > they try to run as atomic network commands. > > >> > > > >> > The issue was already reported by Stefano Babic in 2010: > > >> > [U-Boot] NetConsole and network API > > >> > http://lists.denx.de/pipermail/u-boot/2010-August/075535.html > > >> > > >> I worked around this problem here: > > >> > > >> http://lists.denx.de/pipermail/u-boot/2012-August/129913.html > > > > > > I know about this patch, and I understand the problem it tries to > > > workaround. But it does not work for using netconsole with another > > > protocol like ping. When for example ping enters the NetLoop() it will > > > halt the network device. > > > > > > The problem for this is here: > > > if (eth_is_on_demand_init() || protocol != NETCONS) { > > > eth_halt(); > > > ... > > > } > > > > > > eth_is_on_demand_init() returns correctly with false, because PING != > > > NETCONS. But the second expression results in true, because PING != > > > NETCONS. > > > > > >> > I run into the same problem: > > >> > [U-Boot] netconsole: USB Ethernet connection dropping with ping or > > >> > tftpboot > > >> > http://lists.denx.de/pipermail/u-boot/2015-February/203838.html > > >> > > >> I didn't understand what about your case was not able to work given the > > >> workaround I implemented previously. What was different about it? > > >> > > >> > I have looked at the current network stack. The stack is based on the > > >> > concept of atomic network commands. The implementation for netconsole > > >> > looks very confusing. > > >> > > >> There is no doubt that netconsole is quite confusing as it exists today. > > > > > > I tried to fix the issue, but it did not work properly. > > > > > >> > Sascha Hauer has reimplemented the network stack for Barebox: > > >> > http://www.spinics.net/lists/u-boot-v2/msg00914.html > > >> > > > >> > Looking at the current implementation of net.c looks very clean and > > >> > well-designed. > > >> > > >> Thanks for pointing this out. I hadn't gone to look at the network stack > > >> in > > >> barebox. > > >> > > >> > What do you think about porting this to U-Boot? > > >> > > >> I can look into this. Naturally there are many other changes to u-boot > > >> network stack since the time barebox forked, so I expect such a port to > > >> be > > >> very intensive... most likely a near complete rewrite of Sascha's series, > > >> but I will investigate further. > > > > > > I had a look at the patches and the code base is not entirely the same. > > > But maybe we should just stick to the crucial points of the new network > > > stack: > > > > > > 1) A network device gets initialized when it becomes the current one and > > > gets brought down when it's not used anymore or prior booting to Linux > > > so the connection remains active all the time. > > > > > > My thoughts about this one: > > > Bringing the device down can be done in eth_unregister(). Initializing > > > for the current device can be done in eth_current_changed(). What I like > > > even better is to make eth_current_changed() the sole place for calling > > > init() and halt(). It would have to be extend to take at least two > > > parameters, eth_current and new_current. If eth_current is null just > > > bring up the new device, if new_current is null just bring down the > > > current device. > > > > > > 2) Replace the NetLoop by a connection list where each protocol uses a > > > connection to send and receive packets. > > > > > > This induce to port all protocols to use the new network, of cause. > > > > > > In my opinion it would be also good to do some clean ups and > > > restructuring of code. Put more functions into net-utils, is there a > > > need for eth_init and so on. > > > > Joe has done a lot of work to move U-Boot's network stack over to > > driver model. This is now at u-boot-dm/next waiting for the merge > > window to open. > > > > The connection list idea does not sound like a hugely complex change. > > Are you thinking of trying it out? > > I have just noticed today the big series of u-boot-dm patches of Joe. I > will try it out. But before I will start I want to discuss the concept. > What do you think about my thoughts about bringing up and down a network > device?
Joe is the expert here. With driver model the actual bring-up should be automatic (i.e. it is probed as soon as it is used). Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot