From: Ben Warren <biggerbadderben@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2 V2] IOMUX: Add console multiplexing support.
Date: Mon, 20 Oct 2008 13:13:32 -0700 [thread overview]
Message-ID: <48FCE66C.4050106@gmail.com> (raw)
In-Reply-To: <20081020194346.6EA2783C572F@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Gary Jennejohn,
>
> In message <20081020182635.4ed9ca48@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.
> Best regards,
>
> Wolfgang Denk
>
>
regards,
Ben
next prev parent reply other threads:[~2008-10-20 20:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-14 14:45 [U-Boot] [PATCH 2/2] IOMUX: Add console multiplexing support Gary Jennejohn
2008-09-14 16:07 ` Wolfgang Denk
2008-09-14 17:19 ` Gary Jennejohn
2008-09-14 18:34 ` Wolfgang Denk
2008-09-15 8:46 ` Gary Jennejohn
2008-09-15 11:08 ` Wolfgang Denk
2008-10-20 11:58 ` [U-Boot] [PATCH 2/2 V2] " Gary Jennejohn
2008-10-20 13:24 ` Wolfgang Denk
2008-10-20 13:57 ` Gary Jennejohn
2008-10-20 16:26 ` Gary Jennejohn
2008-10-20 19:43 ` Wolfgang Denk
2008-10-20 20:13 ` Ben Warren [this message]
2008-10-21 9:45 ` Gary Jennejohn
2008-10-21 10:34 ` Wolfgang Denk
2008-10-21 11:32 ` Gary Jennejohn
2008-10-20 19:32 ` Wolfgang Denk
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=48FCE66C.4050106@gmail.com \
--to=biggerbadderben@gmail.com \
--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