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

[Macpaul Lin]

Dear Wolfgang,

2011/1/3 Wolfgang Denk <wd at denx.de>:
> Dear Macpaul Lin,
>
> In message <AANLkTimK=c1+aVsJcRwtPG4hPKp6Lvvu0Ji6a_7B3O_u at mail.gmail.com> you wrote:
>>
>> 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..
>
> All understood, except for the "That's why" - IO do not see any part
> in your explanation above why the "reset" in U-Boot should not perform
> a real reset operation?

Sorry for the description before was not clear enough.
I agree that "reset" in u-boot should perform real reset no matter
the u-boot is the 1st boot loader or the 2nd boot loader.
Of course, the flaw of the original design should be changed.

However, according to the current design specification, AndesTech is trying to
provide a feature which made user could "warm restart" back into u-boot when
u-boot is the 2nd boot loader.

> [Of course I wonder which features your evb_loader provides that are
> missing in U-Boot and cannot be added there, but that's your decision.]

The start.S and lowlevel_init.S in evb_loader and in u-boot are the same.
They perform code copying, relocation, setup stack, and etc. Only the difference
is NDS32 support (CONFIG_SKIP_LOWLEVEL_INIT) which skips some
memory controller and remap configuration. If user disable
CONFIG_SKIP_LOWLEVEL_INIT, u-boot could replace that evb_loader for mass
production purpose.

>> 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.
>
> Why?  All this is bogus if you perform a real hardware reset as you
> are supposed to do.

The above is just the description of the current design.

If we want to have a warm restart, I fully agree there must be another
program logic or API inside the u-boot to support the correctness of "restart".

> Well, I can just say that I see no need for such a fature - doing a
> real reset is much more reliable and convenient, as you do not need
> any extra code.
>
> Best regards,
>
> Wolfgang Denk
>

Okay, understood.

-- 
Best regards,
Macpaul Lin