Hi Anton,
On Mon, Sep 26, 2011 at 10:10 AM, Anton Staaf robotboy@chromium.org wrote:
On Mon, Sep 26, 2011 at 9:49 AM, Simon Glass sjg@chromium.org wrote:
Hi Mike,
On Sun, Sep 25, 2011 at 9:48 PM, Mike Frysinger vapier@gentoo.org wrote:
On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:
On Sun, Sep 25, 2011 at 12:25 PM, Wolfgang Denk wrote:
Simon Glass wrote:
> do_reset() is not supposed to return
I have adjusted the function meaning (which luckily for me was not defined) so that it can return -1 on failure. This makes my code correct :-)
I think it is reasonable to provide a reset function which might not be able to do its job. That is the current state of sandbox.
No, I don't want to change the current definition of reset().
OK.
And "not able to do the job" is something different than "unimplemented".
Why cannot we do a real reset here? Re-exec'in the running binary or performing a longjmp() to the start might be ideas how to implement this.
While this could be done I believe that it might be possible / desirable to exit out of the main loop, rather than longjmp or re-exec. I have not implemented it because I have not got to that bit yet and don't want to put time into a solution I will throw away.
I'm happy to just put:
while (1) ;
in the reset code if you like?
i would expect "reset" in the sandbox to "exit(1)". how else would you exit ? -mike
Right, I will do that then for now.
Perhaps even nicer would be to define exit codes for the couple of cases where we expect to "leave" U-Boot. So reset, and jump to linux kernel, and perhaps power off. So a script calling the sandbox u-boot can check the reason and possibly rerun it in the reset case.
Given the comments on this thread I will go with exit(EXIT_SUCCESS) for now. But of course we will have to address this in test cases later.
Regards, Simon
Thanks, Anton
Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot