Hi Kyle
On Tue, Mar 8, 2011 at 9:06 AM, Moffett, Kyle D Kyle.D.Moffett@boeing.com wrote:
Hi!
On Mar 07, 2011, at 16:54, Graeme Russ wrote:
On Tue, Mar 8, 2011 at 4:37 AM, Kyle Moffett Kyle.D.Moffett@boeing.com wrote:
The i386 port has its own reset_cpu() dispatch for its various supported CPU families, so the existing do_reset() function is simply altered to use the new prototype for __arch_restart().
In addition, the debug message and delay are duplicated from the generic code, so they are removed.
This reset code will probably work even when the CPU is in a bad state, so no separate __arch_emergency_restart() function is required.
This part does not make much sense - If the CPU is in 'a bad state' then it will probably be lights out anyway. As I understand it, an emergency restart is a restart not initiated by the user (divide by zero, unhandled exception etc), in which case i386 will make use of it
I was considering unhandled exceptions, etc. to be "a bad state" :-D.
Maybe I didn't explain it well enough in the patch summary, but basically the default for "__arch_emergency_restart()" is to just call "__arch_restart()". Since the i386 "__arch_restart()" function should work fine even when U-Boot is in trouble, that architecture does not need to override the default.
Hopefully I am making sense now? Should I reword it from "when the CPU is in a bad state" to "when U-Boot is in trouble", or is there something else that would be easier to understand?
I understand what you are doing now, thanks.
I think you can scrap this part of the description and I will have i386 start using __arch_emergency_restart() for 'Internal U-Boot Errors' such as divide by zero, unhandled exception, general protection faults etc
I don't particularly like the 'emergency' naming - It's like if we don't do it things will blow up :) I think 'automatic' might be a closer term
Is there anywhere yet where the code paths for the emergency and non emergency variants differ in the way they end up resetting the board?
Regards,
Graeme