From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] NetConsole and network API
Date: Fri, 13 Aug 2010 15:52:19 +0200 [thread overview]
Message-ID: <4C654E13.1060908@denx.de> (raw)
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
=====================================================================
next reply other threads:[~2010-08-13 13:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-13 13:52 Stefano Babic [this message]
2010-08-13 18:44 ` [U-Boot] NetConsole and network API Joe Hershberger
2010-10-22 7:23 ` RaúlSánchez Siles
2010-10-22 20:14 ` Joe Hershberger
2010-10-25 7:03 ` Raúl Sánchez Siles
2010-10-22 7:30 ` RaúlSánchez Siles
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C654E13.1060908@denx.de \
--to=sbabic@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox