[U-Boot] Rework the network stack

[Jörg Krause]

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 at 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 at 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?

Best regards,
Jörg