[U-Boot] [PATCH 1/3] [RFC] Add support for early serial debug console

[Wolfgang Denk]

Dear Peter,

In message <1218839108.1273.144.camel at localhost.localdomain> you wrote:
> 
> I attempted to account for this fact.  I followed the program flow of
> run_command() and readline() in particular looking for global data
> writes and bss reads.  For the instances where global data was being

Indeed you did this, but only for a minor part of the U-Boot code - at
the cost of added compexity, ugly $ifdeffery and inconsistent and
undefined behaviour as soon as you run any "uninspected" command.

> written, I made it conditional on (gd->flags & GD_FLG_RELOC).  I also
> forced some variables to reside in the data section so that they could
> be read while executing from flash (__attribute__ ((section(".data")))).

This just helps to make the initial values readable. The variables
still cannot be written. Even worse, on some flash types (namely Intel
ones) such write operations to flash memory can corrupt your U-Boot
image.

> I also monitored the flash WE pin while executing the memory and i2c
> commands to make sure that the data section (which is still in flash)
> was not being written to.  There is a chance that uninitialized data is

But that's just these two commands. What happens when I run any other
command? And you don't prevent me from doing that.

> > And your patch seems to be inclomplete, it does not apply.
> 
> Hmm, I built the patches off 07efc9e321619c3dec213310c32e011aa6f02783
> with the 2 patches I just submitted also applied ("mod_i2c_mem()
> bugfix" and "Replace references to extern console_buffer with a function
> call").  What error are you seeing while applying it?
> 
> 
> > Some parts seem to be missing (like the necessary changes to eliminate
> > accesses to the console_buffer[] in BSS).
> 
> I don't follow.  The console_buffer_addr() conditionally places the
> console_buffer in SDRAM if U-Boot has relocated, or at
> CFG_DEBUG_CONSOLE_ADDR if executing from flash.  That's why the "Replace
> references to extern console_buffer with a function call" patch I just
> submitted was necessary.

Ah, so that patch is a prerequisite? You shoul have  mentioned  that,
then, or poosted the three of them as a series.

> I agree that it is hokey that some commands work, some don't.  However,
> the ones that are very useful do work:)  The memory test, modify, and
> display functions as well as the i2c functions work.  These few commands
> allow further diagnosis (and possible fixing) of most board hardware
> problems that prevent a board from booting.

Well, someone who is working in these stages of bard bringup  usually
uses a debugger.

> Thanks for the feedback, I'm curious what others have to say as well.
> Let me know if I can provide any additional details.

The longer I think about it the more I tend to reject  it.  It  makes
the  code worse for the benefit of just a very special situation that
probably can be handled as well (or even better)  using  a  debugger.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.