[U-Boot] Rework the network stack

Simon Glass sjg at chromium.org
Mon Mar 23 17:46:39 CET 2015


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?

Regards,
Simon


More information about the U-Boot mailing list