[U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

[Wolfgang Denk]

Dear "Moffett, Kyle D",

In message <44A75130-ED4F-46D6-B0E4-12433CC15142 at boeing.com> you wrote:
> 
> Oh, absolutely. I do think there still needs to be a separation
> between a "normal user-initiated restart" and an "panic-time
> emergency restart" though, see further on in this email.

These terms refer to another software level, though.

do_reset() is supposed to provide a hard reset function, nothing else
- as mentioned, the software way of pressing the reset button (or
pulling the plug).

A "normal user-initiated restart" would be the equivalent of a
"shutdown -r" in Linux context. We don't offer such a service in
U-Boot, as it has never been needed yet. If implemented, it would
probably call do_reset() as last of it's actions.

A "panic-time emergency restart" can be anything, too - again, it
would probably call do_reset() at the end.

> Such decisions on what is and is not "acceptable" to run on a panic()
> are better left to the individual boards and architectures.

This is a completely new topic now.   We have not been discussing the
implementation or function of panic() before.  This has nothing to do
with what do_reset() is supposed to do - do_reset() may (or may not)
be one action called by panic() [and if so, it should be the last
thing that panic() has been doing.]

> Specifically, the separate board and arch hooks for regular and
> "emergency" restarts that I included in the patch:
> 
>   __arch_restart()
>   __board_restart()
>   __arch_emergency_restart()
>   __board_emergency_restart()

Yes, and I object against such unneeded (for everybody else)
complexity.


> I would argue that is a bug to be fixed. Regardless of how various
> boards and architectures implement "reset", U-Boot should provide
> generic functionality to drivers and library code to allow them to
> indicate what they want:
> 
>   (1) A safe normal operational restart, with all hardware shut down
> (as much as is considered necessary on the platform). Depending on
> the platform this may fail or take some time.
> 
>   (2) A critical error restart, where system state may be undefined
> and the calling code does not expect the function to ever return.

This is overkill for a boot loader.  We assume that when anything goes
wrong we do the best we can to perform a hard reset.  Any halfway sane
hardware design will allow you do do that.  There is a zillion of ways
to do that - from causing a machine check, using a hardware watchdog,
messing limits of system monitor chips, etc. etc.  Or there is a
simple GPIO pin that triggers an external hard reset.

If some hardware provides no such option I will not hesitate to call
this a hardare bug and blame the hardware designer.

Workarounds for such bugs should be dealt with in board specific code.

> Linux has *both* of those cases in the kernel: sys_reboot() and
> emergency_restart().

Linux is an OS.  U-Boot is a boot loader.

Linux offers many things and services that are not available in
U-Boot.

I am even tempted to recommend you to boot Linux as part of your reset
sequence ;-)

> The "jump to _start" case is very similar to Linux kexec().  There are two specific use-cases:

The "jump to _start" case is something I consider a bug that should be
fixed.  I will not accept the existence of such code as reason to
build arbitrarily complex layers on top of it.  It may be the best
possible solution in the given case (which I actually doubt), but even
then it's just that: the best possible approximation to what
actuallyis needed.

>   (1) Safe reliable run-time handoff from one kernel to another
>   (2) Emergency panic() call into another kernel to record the error and reboot safely

U-Boot just provides "reset".


I think I understand what you have in mind, but I'm not going to
accept that, especially not in common code.  Sorry.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Remember that Beethoven wrote his first symphony in C ...