Dear Macpaul Lin,
In message 1293779628-9804-1-git-send-email-macpaul@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 reinitdlmalloc 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 insidereset_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