WP# line on flash chip?

WP# line on flash chip?

[Steve deRosier]

Our flash chip has an active-low write-protect line controlled via a
GPIO. It's out-of-band of everything, the interface still has CS and
other normal signals and those are connected to the NAND controller
pins on our controller.  This pin isn't controlled by the controller,
it's a GPIO activated pin. It's also out-of-band of the various LOCK
commands that can be sent.

The datasheet basically says it locks down the chip so that random
data on the bus doesn't cause erase or programs.  Micron is telling us
that we really should keep it asserted and only deassert it when we
want to erase/write the device.  Right now, we deassert it shortly
after boot.

I can't find any way to add this pin to our device tree, nor do I see
any evidence for support in either our atmel_nand driver or in
higher-level MTD stuff like nand_base.

Does the support for this exist and am I simply missing finding it, or
is it not there at all (expected)?

Assuming it's not there, and assuming I actually add it, is this a
feature that the MTD maintainers would allow to go upstream? I'm
assuming it's not a unique feature to this chip and that other chips
may have it.

Thanks,
- Steve

Re: WP# line on flash chip?

[Daniel Ehrenberg]

In designs I've worked on, the WP# line is only low initially when
coming out of reset in order to prevent random signals that might go
on the bus from messing up the state of the chip. You can hold it high
the rest of the time. So it's not typically controlled by the kernel
but by simple structures on the board itself. In fact, the kernel
can't drive it appropriately because the important time to hold it low
is before the kernel is up (or actually it can go low sooner than
that), and by the time the kernel is up, it's fine to have it high all
the time.

Dan

On Thu, Jan 8, 2015 at 9:59 AM, Steve deRosier <derosier@gmail.com> wrote:
> Our flash chip has an active-low write-protect line controlled via a
> GPIO. It's out-of-band of everything, the interface still has CS and
> other normal signals and those are connected to the NAND controller
> pins on our controller.  This pin isn't controlled by the controller,
> it's a GPIO activated pin. It's also out-of-band of the various LOCK
> commands that can be sent.
>
> The datasheet basically says it locks down the chip so that random
> data on the bus doesn't cause erase or programs.  Micron is telling us
> that we really should keep it asserted and only deassert it when we
> want to erase/write the device.  Right now, we deassert it shortly
> after boot.
>
> I can't find any way to add this pin to our device tree, nor do I see
> any evidence for support in either our atmel_nand driver or in
> higher-level MTD stuff like nand_base.
>
> Does the support for this exist and am I simply missing finding it, or
> is it not there at all (expected)?
>
> Assuming it's not there, and assuming I actually add it, is this a
> feature that the MTD maintainers would allow to go upstream? I'm
> assuming it's not a unique feature to this chip and that other chips
> may have it.
>
> Thanks,
> - Steve
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: WP# line on flash chip?

[Brian Norris]

On Thu, Jan 08, 2015 at 11:00:03AM -0800, Daniel Ehrenberg wrote:
> In fact, the kernel
> can't drive it appropriately because the important time to hold it low
> is before the kernel is up (or actually it can go low sooner than
> that),

That's not true. It's also helpful to have it low during a power cut
scenario, which theoretically can occur at any time.

> and by the time the kernel is up, it's fine to have it high all
> the time.

As Steve quoted Micron, it's good to keep WP asserted when you're not
writing to the flash.

Brian

Re: WP# line on flash chip?

[Brian Norris]

On Thu, Jan 08, 2015 at 09:59:37AM -0800, Steve deRosier wrote:
> I can't find any way to add this pin to our device tree, nor do I see
> any evidence for support in either our atmel_nand driver or in
> higher-level MTD stuff like nand_base.
> 
> Does the support for this exist and am I simply missing finding it, or
> is it not there at all (expected)?

I believe it does not exist yet.

I've seen a driver for a controller which has WP# control built directly
into its register space. This driver would just toggle WP# before/after
each PROGRAM_PAGE and ERASE operation. Not beautiful, but it works. I'd
expect this might be nicer to do with larger granularity -- i.e., only
toggle twice per mtd_write() even for larger transfers, in nand_base.c.

> Assuming it's not there, and assuming I actually add it, is this a
> feature that the MTD maintainers would allow to go upstream? I'm
> assuming it's not a unique feature to this chip and that other chips
> may have it.

We don't often get asked for permission here, but I appreciate the
sentiment :)

The idea sounds fine to me. One obstacle is that we don't have a
standardized "NAND" device tree node that nand_base can use. We have a
few standardized properties, but they're mostly handled per-driver. But
anything done to improve that is welcome.

Regards,
Brian