[U-Boot] [PATCH 2/2 V2] IOMUX: Add console multiplexing support.

[Gary Jennejohn]

On Mon, 20 Oct 2008 13:13:32 -0700
Ben Warren <biggerbadderben at gmail.com> wrote:

> Wolfgang Denk wrote:
> > Dear Gary Jennejohn,
> >
> > In message <20081020182635.4ed9ca48 at ernst.jennejohn.org> you wrote:
> >   
> >> I looked at this some more.  eth_initialize() is called in every
> >> architecture-specific library which means changing 8 files to move
> >> it up to before the initialization of netconsole.
> >>
> >> netconsole is intialized in devices_init() which is called even before
> >> console_init_r() and long before eth_initialize().
> >>     
> >
> > Well, maybe there is a less intrusive approach to solve the problem.
> >
> >   
> >> One alrernative which occurs to me would be to introduce a new flag
> >> GD_FLG_ETHINIT, but this is even worse because it requires modifying
> >> 12 header files and 3 or more C files.
> >>     
> >
> > Hm... let's sum up what exactly the problem is; you wrote:
> >
> > | This causes problems because u-boot will try to write to nc as soon
> > | as GD_FLG_DEVINIT is set in gd->flags, which happens before the
> > | network devices are initialized in net/eth.c. This results in error
> > | messages being spewed out.
> >
> > I read this that what we actually want to do is stopping NC to
> > transmit too early. Correct?
> >
> > Well, nc_send_packet() (see "drivers/net/netconsole.c") can be easily
> > shortcut if we find a way to make eth_get_dev() return NULL.
> >
> > And eth_get_dev() (see "net/eth.c") just returns "eth_current".
> >
> > So maybe there is a way to make sure "eth_current" is set to NULL
> > until it's OK for netconsole to transmit?
> >
> > Maybe, maybe eventually the real  cause  of  your  problems  is  that
> > "eth_current"  is  not  read  as NULL while running from flash? Maybe
> > changing the declaration in "net/eth.c" into something like this would
> > help?
> >
> > static struct eth_device *eth_current  __attribute__ ((section(".data"))) = NULL;
> >
> > What do you think?
> >
> >   
> This looks like a good idea.  eth_current is a variable that should 
> definitely be in a known state.
> 

By the time the problem arises we're already running out of RAM.

I think the real problem is that console_init_r() is called too
early.  If it were called *after* eth_initialize() then there would
be no difficulties.

AFAICT moving console_init_r() shouldn't present any problems, since
until its invocation U-Boot will simply use the serial interface.
I can't imagine that waiting a few milliseconds longer to switch to
whatever console the user has set in the environment would present
a problem.

This has the following advantages
a) nc has been initialized and can be used as a console, if so desired
b) any hardware initializations, such as SPI or I2C, which may be
   required to initialize an ethernet device have already happened
c) the ethernet device is already initialized and ready to go
d) no need to split up setting gd->flags

What do you think about this idea?  It requires changing a lot of
files but seems like the cleanest approach to me.

It isn't clear to me whether the architecture-specific libs have custodians.
Does anyone know?

---
Gary Jennejohn
*********************************************************************
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
*********************************************************************