[PATCH] spi-nor: Fix for Freescale i.MX6 reboot issue when using a N25Q00A boot device.
Marek Vasut
marex at denx.de
Fri Sep 26 16:42:10 PDT 2014
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
More information about the linux-mtd
mailing list