From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg?= Krause Date: Mon, 23 Mar 2015 20:55:10 +0100 Subject: [U-Boot] Rework the network stack In-Reply-To: References: <1426926818.1894.12.camel@embedded.rocks> <1427056640.2141.44.camel@embedded.rocks> Message-ID: <1427140510.17082.8.camel@embedded.rocks> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 > >> 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? Best regards, J?rg