On Tue, Mar 8, 2011 at 9:57 AM, Moffett, Kyle D <kyle.d.moff...@boeing.com> wrote: > On Mar 07, 2011, at 17:26, Graeme Russ wrote: >> On Tue, Mar 8, 2011 at 9:06 AM, Moffett, Kyle D <kyle.d.moff...@boeing.com> >> wrote: >>> On Mar 07, 2011, at 16:54, Graeme Russ wrote: >>>> 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 > > The name "emergency_restart()" was borrowed from the Linux kernel; the kernel > shuts down disks and network interfaces prior to a regular restart but not > during an emergency restart. The best analogy is to the "EMERG" log level > (KERN_EMERG inside the Linux kernel).
OK, makes sense to stick with emergency then > > Furthermore, you should *not* directly call __arch_emergency_restart(), that > is simply the architecture hook you provide to the generic code. Your > exception handlers should call "emergency_restart()" to allow board-specific > code to override the reboot, for example by triggering an onboard watchdog to > reset other hardware. > > EG: > > => some_i386_trap_handler() > => emergency_restart() > => __board_emergency_restart() > => __arch_emergency_restart() > > => do_reset() [The new, generic version] > => system_restart() > => __board_restart() > => __arch_restart() > OK > The __{board,arch}_restart(), etc are just predefined weak functions that can > be overridden by the implementation. > > For example, my HWW-1U-1A board file effectively does this: > > int __board_restart(void) > { > while (poll_external_software()) { > if (ctrlc()) > return -1; > } > return 0; > } > > void __board_emergency_restart(void) > { > while (poll_external_software_uninterruptible()) > ; > } > > During a normal restart, I allow the polling to be interrupted with Ctrl-C, > but during an emergency restart I don't. In both cases, my function just > *returns* to allow the default MPC85xx code to actually perform the > hardware-level restart (by poking at the "reset request" bit in a CPU > register). > > >> 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? > > There are several U-Boot board ports whose do_reset() functions (now called > "__board_restart()") just perform an unconditional jump to "_start" or a > FLASH "soft-reset" address. If the system has experienced an unexpected > exception or other problem then that is not safe, and it would be better to > just hang(). > OK - All sounds good to me. I'll try run it all up on my board 'soon' Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot