Wolfgang Denk wrote: > Dear Gary Jennejohn, > > In message <[EMAIL PROTECTED]> 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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot