On Tue, 21 Oct 2008 12:34:30 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20081021114543.1c44ff03@ernst.jennejohn.org you wrote:
By the time the problem arises we're already running out of RAM.
So maybe you can describe exactly what happens, and when?
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 am not so sure. Moving things around not as trivial as it may seem, as we have all kinds of configurations with LCD display, modem support etc.
All console_init_r() does is to search for devices which can be used for STDIN/STDOUT/STDERR (whether in the environment or the device list), call console_setfile() and then print out the list of devices found. console_setfile() actually calls the device start routines. The actual registration of the devices happens in device_init() which is called before console_init_r().
So I see no reason why moving console_init_r() would have any effect.
It isn't clear to me whether the architecture-specific libs have custodians. Does anyone know?
What is not clear about that? Do we have custodians for architecture specific files? Yes, we do. So whay do you doubt that the libs fall into their responsibility, too?
Did I write that I doubt anything? No. I just asked for some clarification because it wasn't clear to me from the very abbreviated descriptions on the Custodian page just exactly what is within the purview of a custodian.
--- 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@denx.de *********************************************************************