[U-Boot] [PATCH] common/dlmalloc: support reinit bin for fast reset

[Wolfgang Denk]

Dear Macpaul Lin,

In message <1293779628-9804-1-git-send-email-macpaul at andestech.com> you wrote:
> There are several way to reset the u-boot.

To avoid confusion, we should try and agree on certain terms.

Reset means (at least in U-Boot context) to bring a system to an
initial state, similar to what whappens when you press the reset
button.  "Initial state" also means that the hardware, including
memory and peripherals, are reset to an initial state where they can
reliably be accessed.  As a result of a "reset", the CPU will begin
execution at it's reset entry point, loading code from the configured
boot device.

This differs from "restart", where an existing instance of a software
component (which might be an U-Boot image loaded to memory) begins
execution from some starting point.  In U-Boot context, a different
term for a restart might be "warm start" or "warm boot".

U-Boot only supports "reset".  It does NOT support any way of
restart.  THere are a number of reasons for that:

1) We do not keep a copy of the initial state of the data segment.
   Thus any changes to data that are used by the code as indicators
   for steps already performed will remain, which will cause such
   steps will be missing or will run based on incorrect assumptions.

2) There are situations where a restart will not be possible, For
   example, if you have a system which boots from NOR flash, and you
   attempt a restart when the flash chips just happen to be in some
   command mode.  The you cannot read normal data from them, and the
   CPU will not be able to fetch instructions from the boot device.

> Some platform will use watchdog timeout to reset the system.

Correct.  Using a watchdog reset is one of the common ways to cause a
hard reset on some systems.

> Some platfrom will jump to 0x0 to reload the u-boot.

Wrong. This may attempt to restart U-Boot, and if you are lucky it
will eventually even load a fresh copy of U-Boot to RAM.  But this is
highly SoC and board specific, and it is only a restart, and NOT a
reset.

> Some platform will jump to CONFIG_SYS_TEXT_BASE to do fast reset.

Wrong. This is not a reset either. Even worse, here you don;t even
attempt to reload U-Boot and thus to re-initialize the data and bss
segments, which is just begging for all sorts of trouble.

This is a fundamentally broken design.  Please do not try to paper
over problems, fix the design.


> This patch fixed the problem of static varible didn't cleared on
> the platforms which "CONFIG_SKIP_LOWLEVEL_INIT" is enabled and do
> software reset by simply jump to the address "CONFIG_SYS_TEXT_BASE".

It makes no sense to try and fix individual variables to their
initial state - you would have to reload the whole data segment from
some copy holding it's original values, and you have to re-initialize
the whole bss segment to zero.  [And even then you are still trying to
o somthing which is unsupported.]

> This patch also introduce a new define named "CONFIG_FAST_RESET" for
> developer to distinguish this method from other reset methods.

This is a misnomer in severasl ways: it does not perform any reset
operation of the system (but attempts to perform a (unsupported)
restart.

> +- CONFIG_FAST_RESET
> +		If both CONFIG_SKIP_LOWLEVEL_INIT and this varible is defined,
> +		the system could use do fast software reset by simply reinit
> +		dlmalloc module then jump to the starting address
> +		"CONFIG_SYS_TEXT_BASE".
> +
> +		To use this feature, the extern function "reinit_malloc_pool()"
> +		in dlmalloc.c should be called inside
> +		reset_cpu(CONFIG_SYS_TEXT_BASE).

This makes the problems of your design obvious.

Why should resetting the processor include a reinitalization of malloc?

I will not accept any such changes.  Please fix your design and
implement a real reset.


If you want to extend the U-Boot design by adding support for a
restart feature (or "warm start"), then this needs to be done right;
setting of a few selected variables is definitely not sufficient.

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
The number you have dialed is imaginary. Please divide by 0  and  try
again.