On Thu, Mar 24, 2016 at 10:46:42AM -0500, Matthew McClintock wrote: > On Mar 23, 2016, at 5:42 PM, Stephen Boyd <[email protected]> wrote: > > > > On 03/23, Matthew McClintock wrote: > >> For certain parts and some versions of TZ, TZ will reset the chip > >> when a BARK is triggered even though it was not configured here. So > >> by default let's configure this BARK time as well. > >> > > > > Why isn't TZ configuring the bark time to what it wants? I'm lost > > why we have to do this for them. > > So it was done like this to ensure we had a valid upgrade. The bootloader is > using the watchdog to ensure the system is bootable and if not it will revert > back to the working images. > > Bottom line is, for some versions of TZ out there, if we enable watchdog > coming out of boot the bark time is already configured by the boot loader and > TZ is configured to intercept this interrupt and do some register saving (for > crashdump) and we end up getting a watchdog reset during boot. > > It’s even a little more complex, because in order for the TZ to save the > registers you need to pad the BITE time a bit higher than the BARK time, but > I was leaving that for another day. > Sounds like an op[timal target for using pretimeout ?
Guenter
