From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Thu, 05 Feb 2015 11:22:32 -0700 Subject: [U-Boot] [PATCH] imx: don't clobber reset cause In-Reply-To: <54D3ADCF.7010102@denx.de> References: <1423086661-5860-1-git-send-email-eric.nelson@boundarydevices.com> <874mr0pbl2.fsf@nbsps.com> <54D3A625.5000101@denx.de> <54D3A6D9.8040602@boundarydevices.com> <54D3ADCF.7010102@denx.de> Message-ID: <54D3B4E8.1040505@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefano, On 02/05/2015 10:52 AM, Stefano Babic wrote: > Hi Eric, > > On 05/02/2015 18:22, Eric Nelson wrote: > >>>> There is very similar code in 'arch/arm/cpu/armv7/vf610/generic.c'. The >>>> write is for a hard power on case where these reason registers are full >>>> of weird bogus values (at least on Vybrid; I suspect on iMx). In the >>>> case of a non-POR, the register bits are good. However, if you don't >>>> clear the status, on the next reset it may have multiple registers bits >>>> even though you really want to know the last reason (bit). >>>> >>>> Another option would be to clear the value and store the 'cause' >>>> somewhere for other U-Boot users. Unless you wanted to read this from >>>> an OS? I think both files should behave the same, all else equal. >>>> >>> >>> I have assumed (maybe wrong ?) that the reason for the patch is to let >>> the OS reading these bits. >>> >> >> In some cases (Windows Embedded), yes. >> >> In the Linux case, we'll likely pass the value to the kernel through >> the kernel command-line, so it's available to userspace. >> >> I'm not aware of any kernel functionality for this at the moment. >> > > It remains the issue raised by Bill (thanks for that). If the bits are > not reset, we can determine the cause only after POR, but not anymore > after a warm start. Can you maybe use the IRAM to pass the information > to Windows ? > Certainly, but it seems wrong to make a decision about where and how this might get passed to an O/S in code. If we want to generalize it, I'd be inclined to add commands to query (into a variable) and clear the reset cause. That would still require this patch though. Regards, Eric