Dear Wolfgang,
2011/1/3 Wolfgang Denk wd@denx.de:
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?
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.