Re: [PATCH] spi-nor: Fix for Freescale i.MX6 reboot issue when using a N25Q00A boot device.

[Marek Vasut <marex@denx.de>]

On Friday, September 26, 2014 at 09:46:10 PM, Jeremy Garff wrote:

[...]

> > This patch would not work in case you were doing a PageProgram operation
> > and I came around and mashed the 'reset' button on your board. The SPI
> > NOR would be somewhere in the middle of the PP and your MX6 would simply
> > not boot.
> 
> It's actually worse than this.  _Any_ time the reset button is pushed
> after linux initializes the device, the system won't boot.  Not just
> during a page program.  Obviously this problem is outside the scope of
> my fix, but it does however fix the case where the user initiates the
> reboot.

That's just papering over bugs.

> > So the solution here is to fix your hardware ;-)
> 
> Easier said than done.  In many circumstances, hardware fixes like the
> one you suggest are outside the control of the developer and/or incur
> additional board and part costs.

Again, this doesn't justify papering over bugs. It's a plain and simple hardware 
bug.

> In my opinion, the real fix for this issue is in the Freescale boot
> ROM, which should do a soft reset of the SPI NOR prior to any reads.
> Unfortunately it doesn't do this, and can't be changed except by
> Freescale.

In case the SPI NOR is completely stuck, the only way to bring it into defined 
state is to power-cycle it or toggle it's reset pin. Software reset would again 
be just a plaster as the SPI NOR might ignore it.

> > btw this is a common issue, we should really document this before more
> > people get hurt.
> 
> What you are effectively saying is that you simply can't and shouldn't
> use this part with a i.MX6.

Does MX6 not have an Reset Out ? I recall it does have one.

> But why not implement the fix if the
> following are true?
> 
> - It's as you say, a common issue.
> - A hardware fix may be outside the developers control or parts are
> fielded. - The fix simply puts the part in a consistent state on
> reboot/shutdown and seems reasonable.

Because this just hides the bug ; the real solution is to make hardware which 
has correct reset routing, the software in this case cannot solve the problem.

Best regards,
Marek Vasut