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

[Macpaul Lin]

HI Wolfgang,

2010/12/31 Wolfgang Denk <wd at denx.de>:
> 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".


Thanks for your clarification.

The reason of the need of implementing "warm start" is for the following
scenario.

There are 2 boot loaders in the same flash on our evaluation board
"ADP-AG101".

The flash layout of evb "ADP-AG101" is like this:
The starting address of flash is 0x80400000
0x80400000: evb_loader
0x80500000: u-boot
0x80600000: non-OS demo programs
0x80800000: OS (Linux)
0x80980000: rootfs

One is customized boot loader, e.g, "an evaluation boot loader" (evb_loader),
which is used for quick application demo and diagnostic the peripherals.This
evaluation boot loader also deals with loading and execution OS
(LInux, RTOS) and non-OS application in the memory. This boot loader
also load and jump to generic u-boot (CONFIG_SKIP_LOWLEVEL_INIT is enabled
in this u-boot) for demo, training, and development purpose.

The second boot loader is generic u-boot. Since the evaluation board is booted
by evb_loader, then the memory controller and mem relocation will be initialized
by evb_loader.

User could evaluate the board function with evb_board, then develops the product
software by using u-boot and Linux kernel to simulate the real product behavior.
Once the user has done development process, he/she can replace the evb_loader
with real generic u-boot (with CONFIG_SKIP_LOWLEVEL_INIT is disabled).

That's why we may need "warm start" or "warm boot" which let user
restart the u-boot
without resetting the board and jumping to the evb_loader again..

Even there exist a need with "warm boot", the NDS32 architecture still do
CPU and memory reset. In the current reset_cpu() function whihc NDS32
has provided
(it could be hooked to watchdog reset or warm boot), reset still do
the following reset
process.
1. do_reset(). (cpu.c)
2. disable interrupts. (cpu.c)
3. reset_cpu(). (cpu.c)
3.1. invalidate I/D cache.
3.2. reset MMU, TLB,
3.3. flush TLB,
3.4. reset cache control registers.
if use watchdog reset
3.5 telling watchdog to reset the hardware.
4. system loads the boot loader from flash. (start.S)
else if use warm boot.
3.5. jump the to the CONFIG_SYS_TEXT_BASE,
4. execute start up code in memory. (start.S)

> 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.  Then you cannot read normal data from them, and the
>   CPU will not be able to fetch instructions from the boot device.
>

[deleted]

> 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.
>

Okay, if I want to make U-boot supports "restart feature", it seems I need to
find a reasonable method to reload the data segment and clear bss. It seems
the most secure method is to load code (data segment) from flash.

Do you have further idea of supporting feature "restart" (warm start)?

-- 
Best regards,
Macpaul Lin