From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 26 Sep 2011 12:11:35 -0700 Subject: [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files In-Reply-To: References: <1316278139-28635-2-git-send-email-sjg@chromium.org> <20110925192515.B50861407980@gemini.denx.de> <201109260048.41976.vapier@gentoo.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Anton, On Mon, Sep 26, 2011 at 10:10 AM, Anton Staaf wrote: > On Mon, Sep 26, 2011 at 9:49 AM, Simon Glass wrote: >> Hi Mike, >> >> On Sun, Sep 25, 2011 at 9:48 PM, Mike Frysinger 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 at lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> >