Moffett, Kyle D wrote: > Hi! > > On Mar 08, 2011, at 19:13, Scott McNutt wrote: >> Hi Kyle, >> >> Kyle Moffett wrote: >>> The Nios-II port appears to use no generic hardware capability for >>> performing a CPU reset. Since all of the supported boards use the exact >>> same code to perform a jump-to-flash it goes into __arch_restart(). >>> >>> This means that Nios-II has a no-op __arch_emergency_restart() function. >>> If the CPU is in an invalid state then jump-to-FLASH probably won't >>> work. >> If the CPU state is stable enough to call __arch_emergency_restart(), >> a jump to the reset address should be fine. In many implementations >> the reset code is in on-chip ROM. If things get screwed up enough >> to affect the code in on-chip ROM, it probably won't matter what >> gets called. ;-) > ... <snip> ...
> Basically the emergency_restart() code should handle being called even in the > following scenarios: > * Unexpected CPU exception or interrupt occurs > * Interrupts on or off, or *from* an interrupt or trap handler. > * FLASH or other peripherals in an undefined state > > If that's the case for your onboard ROM then I will certainly remove the > no-op emergency restart hook from this patch. From a practical perspective, in the case of on-chip ROM, it would be no different than a hard reset during any of the above activities. But please don't remove it. Your position is sound and conservative. I haven't had time to review the entire patch set yet. I'm assuming the __board_emergency_restart() routine is where a board can override the default arch-specific behavior? If so, you already provided the hooks for more daring developers. ;-) Regards, --Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot