| Message ID | 1299519462-25320-16-git-send-email-Kyle.D.Moffett@boeing.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
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. ;-) Thomas, any thoughts? Regards, --Scott
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
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
diff --git a/arch/nios2/cpu/cpu.c b/arch/nios2/cpu/cpu.c index ef360ee..9f40188 100644 --- a/arch/nios2/cpu/cpu.c +++ b/arch/nios2/cpu/cpu.c @@ -40,10 +40,20 @@ int checkcpu (void) return (0); } -int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) +int __arch_restart(void) { disable_interrupts(); /* indirect call to go beyond 256MB limitation of toolchain */ nios2_callr(CONFIG_SYS_RESET_ADDR); return 0; } + +/* + * The __arch_restart() just jumps back to flash, which isn't safe to do in + * emergency conditions. Since we don't have anything better to do, just + * fall through into the default hang(). + */ +void __arch_emergency_restart(void) +{ + return; +}
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. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Cc: Scott McNutt <smcnutt@psyent.com> --- arch/nios2/cpu/cpu.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-)