Dear Macpaul Lin,
In message AANLkTimK=c1+aVsJcRwtPG4hPKp6Lvvu0Ji6a_7B3O_u@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?
[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.]
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.
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.
...or form another copy of the data segment.
Do you have further idea of supporting feature "restart" (warm start)?
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