[U-Boot] NetConsole and network API

[U-Boot] NetConsole and network API

[Stefano Babic]

Hi all,

I have seen an issue using netconsole and I am asking myself if there is
a problem in the actual concept of a network interface in u-boot.

I admit soon I have not used a "normal" network controller, but I ran
NetConsole on Ethernet over USB. However, I have checked with other
network drivers  (smc9111.c, for example) and I can imagine there are
similar problems.

The assumption we have is that any network command is atomic.
Any network command initializes the interface, uses it (eth_send(), ..)
and at the end deactivates the interface (eth_halt()). This makes an
application as netconsole simply unusable, because it is not thinkable
that after any message the interface is put in a down state. Not only,
it makes impossible to use network commands as TFTP inside netconsole,
because they try to initialize the same interface that netconsole uses.

Of course, in my case things get even worse. After any network command,
the eth_halt() callback is called, making the interface disappearing on
the host side. And any time the host starts to enumerate again the
interface, setting MAC, etc.....

Well, I have fixed this issue avoiding the interface is initialized or
stopped after each command, but it seems this is a general problem. I
see in other drivers that the phy is set or stop after each command, and
this should generate the same problems I noted with USB.

My main question to the ML is, independently from the particular problem
on my target, if we should change the actual concept. For example, if we
provide to stop all devices only before booting an OS, but leaving them
alive after the first initialization. I understand that this generate
other issues (as u-boot cannot recognize that a cable was removed and
inserted again), but it makes the system usable in other circumstances.

Any thought about this ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] NetConsole and network API

[Joe Hershberger]

On Fri, Aug 13, 2010 at 8:52 AM, Stefano Babic <sbabic@denx.de> wrote:
> My main question to the ML is, independently from the particular problem
> on my target, if we should change the actual concept. For example, if we
> provide to stop all devices only before booting an OS, but leaving them
> alive after the first initialization. I understand that this generate
> other issues (as u-boot cannot recognize that a cable was removed and
> inserted again), but it makes the system usable in other circumstances.

I've run into the same issue and patched net.c a bit to improve the
behavior of the NetConsole use case.  It's a surgical change, though,
not a fundamental change to how the network subsystem works.  Only if
using NetConsole do you get this behavior.  And even if using other
network operations with NetConsole, those other operations mostly
maintain their current behavior.

I'll post the patch at some point in the next month or so when I can
get the time to extract it and test it on modern u-boot.

Best regards,
-Joe

[U-Boot] NetConsole and network API

[RaúlSánchez Siles]

  Hello Joe:

Joe Hershberger <joe.hershberger <at> gmail.com> writes:

> 
> On Fri, Aug 13, 2010 at 8:52 AM, Stefano Babic <sbabic <at> denx.de> wrote:
> > My main question to the ML is, independently from the particular problem
> > on my target, if we should change the actual concept. For example, if we
> > provide to stop all devices only before booting an OS, but leaving them
> > alive after the first initialization. I understand that this generate
> > other issues (as u-boot cannot recognize that a cable was removed and
> > inserted again), but it makes the system usable in other circumstances.
> 
> I've run into the same issue and patched net.c a bit to improve the
> behavior of the NetConsole use case.  It's a surgical change, though,
> not a fundamental change to how the network subsystem works.  Only if
> using NetConsole do you get this behavior.  And even if using other
> network operations with NetConsole, those other operations mostly
> maintain their current behavior.
> 
> I'll post the patch at some point in the next month or so when I can
> get the time to extract it and test it on modern u-boot.
> 
> Best regards,
> -Joe
> 

  I've also bumped into this issue and I'm not familiar enough with U-Boot to
properly think of a solution fixing the issue. However, I share the analisys
Stefano did. In my case I use a davinci DM355 custom board, very similar to the
EVM.

You offered to send a patch some time ago, is there any chance we could see it?
I offer to test it. Alternatively, I'm interested in hearing your approach to
the solution so maybe I can get a slot to make up a patch from it.

  Regards,

-- 
Ra?l S?nchez Siles

[U-Boot] NetConsole and network API

[RaúlSánchez Siles]

  Hello:

Stefano Babic <sbabic <at> denx.de> writes:

> 
> Hi all,
> 
> I have seen an issue using netconsole and I am asking myself if there is
> a problem in the actual concept of a network interface in u-boot.
> 
> I admit soon I have not used a "normal" network controller, but I ran
> NetConsole on Ethernet over USB. However, I have checked with other
> network drivers  (smc9111.c, for example) and I can imagine there are
> similar problems.
> 
> The assumption we have is that any network command is atomic.
> Any network command initializes the interface, uses it (eth_send(), ..)
> and at the end deactivates the interface (eth_halt()). This makes an
> application as netconsole simply unusable, because it is not thinkable
> that after any message the interface is put in a down state. Not only,
> it makes impossible to use network commands as TFTP inside netconsole,
> because they try to initialize the same interface that netconsole uses.
> 
> Of course, in my case things get even worse. After any network command,
> the eth_halt() callback is called, making the interface disappearing on
> the host side. And any time the host starts to enumerate again the
> interface, setting MAC, etc.....
> 
> Well, I have fixed this issue avoiding the interface is initialized or
> stopped after each command, but it seems this is a general problem. I
> see in other drivers that the phy is set or stop after each command, and
> this should generate the same problems I noted with USB.
> 
> My main question to the ML is, independently from the particular problem
> on my target, if we should change the actual concept. For example, if we
> provide to stop all devices only before booting an OS, but leaving them
> alive after the first initialization. I understand that this generate
> other issues (as u-boot cannot recognize that a cable was removed and
> inserted again), but it makes the system usable in other circumstances.
> 
> Any thought about this ?
> 
> Best regards,
> Stefano Babic
> 

  IMHO, this analisys, I share, leaves to the same conclussion: there's a
network redesign need.

  The problem, as Wolgang suggested on IRC, is that there's no active network
custodian currently, which makes things like this hard to discuss and
implement.

  By the way, have you had further advances on this topic? I'd like to hear
about what I can expect from your netconsole fix. Is it working? Does it allow
concurrent other network services usage (like TFTP)? Any major draback?

  Thanks and regards,

-- 
Ra?l S?nchez Siles

[U-Boot] NetConsole and network API

[Joe Hershberger]

On Fri, Oct 22, 2010 at 2:23 AM, Ra?lS?nchez Siles
<rsanchezs@infoglobal.es> wrote:
> ?Hello Joe:
>
> Joe Hershberger <joe.hershberger <at> gmail.com> writes:
>
>> I've run into the same issue and patched net.c a bit to improve the
>> behavior of the NetConsole use case. ?It's a surgical change, though,
>> not a fundamental change to how the network subsystem works. ?Only if
>> using NetConsole do you get this behavior. ?And even if using other
>> network operations with NetConsole, those other operations mostly
>> maintain their current behavior.
>>
>> I'll post the patch at some point in the next month or so when I can
>> get the time to extract it and test it on modern u-boot.
>>
>> Best regards,
>> -Joe
>>
>
> ?I've also bumped into this issue and I'm not familiar enough with U-Boot to
> properly think of a solution fixing the issue. However, I share the analisys
> Stefano did. In my case I use a davinci DM355 custom board, very similar to the
> EVM.
>
> You offered to send a patch some time ago, is there any chance we could see it?
> I offer to test it. Alternatively, I'm interested in hearing your approach to
> the solution so maybe I can get a slot to make up a patch from it.

Hi Raul,

I apologize for not getting to this.  As usual, deadline pressure
pushes this kind of thing out.  I don't have the time to create the
patch for the git head and submit it officially at this time, however
I can give you the patch against u-boot-2009.11.  I'll get to
officially submitting it at some point, but for now this is the best I
can do for you.

Apply this patch to u-boot 2009.11 and then #define
CONFIG_NETCONSOLE_PERSIST_ETH in your board config header.

I use this on an MPC8313 with the TSEC Ethernet driver and it greatly
increases the speed and reliability of the NetConsole.  All other
protocols such as TFTP still work the same as before.

Hopefully this helps.

Best regards,
-Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-2009.11-netconsole-persist-eth.patch
Type: application/octet-stream
Size: 4470 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101022/eebc180f/attachment.obj 

[U-Boot] NetConsole and network API

[Raúl Sánchez Siles]

  Hi:

On Viernes, 22 de Octubre de 2010 22:14:45 Joe Hershberger escribi?:
> On Fri, Oct 22, 2010 at 2:23 AM, Ra?lS?nchez Siles
> 
> <rsanchezs@infoglobal.es> wrote:
> >  Hello Joe:
> > 
> >  I've also bumped into this issue and I'm not familiar enough with U-Boot
> > to properly think of a solution fixing the issue. However, I share the
> > analisys Stefano did. In my case I use a davinci DM355 custom board,
> > very similar to the EVM.
> > 
> > You offered to send a patch some time ago, is there any chance we could
> > see it? I offer to test it. Alternatively, I'm interested in hearing
> > your approach to the solution so maybe I can get a slot to make up a
> > patch from it.
> 
> Hi Raul,
> 
> I apologize for not getting to this.  As usual, deadline pressure
> pushes this kind of thing out.  I don't have the time to create the
> patch for the git head and submit it officially at this time, however
> I can give you the patch against u-boot-2009.11.  I'll get to
> officially submitting it at some point, but for now this is the best I
> can do for you.
> 
> Apply this patch to u-boot 2009.11 and then #define
> CONFIG_NETCONSOLE_PERSIST_ETH in your board config header.
> 
> I use this on an MPC8313 with the TSEC Ethernet driver and it greatly
> increases the speed and reliability of the NetConsole.  All other
> protocols such as TFTP still work the same as before.
> 
> Hopefully this helps.
> 
> Best regards,
> -Joe

  Great! Thank you. I'll address this as soon as I have some time, hopefully 
among this 2 weeks.

  Regards

-- 
Ra?l S?nchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarc?n (Madrid), Espa?a
* T: +34 91 506 40 00
* F: +34 91 506 40 01