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. ;-)
I'm not at all familiar with the Nios-II hardware platform. Is the on-chip ROM really safe to be called in arbitrary system states? Using FLASH memory as an example, consider a FLASH driver in the middle of a programming cycle when an unexpected exception occurs: * FLASH programming in process * CPU takes an unexpected trap * CPU calls exception vector (possibly with interrupts disabled or enabled) * emergency_restart() * __arch_emergency_restart() * Boot ROM is called Until the FLASH memory is reset and put back into a defined state it will be unusable, and if your boot process depends on the FLASH then serious problems will result. In that case it would be better not to just hang than try to restart. 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. Cheers, Kyle Moffett _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
