From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott McNutt Date: Tue, 08 Mar 2011 20:33:08 -0500 Subject: [U-Boot] [PATCH 15/21] nios2: Generic system restart support In-Reply-To: References: <1299519462-25320-1-git-send-email-Kyle.D.Moffett@boeing.com> <1299519462-25320-16-git-send-email-Kyle.D.Moffett@boeing.com> <4D76C636.9090907@psyent.com> Message-ID: <4D76D8D4.6070308@psyent.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. ;-) > ... ... > 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