sector locks handling for J3 flashes?

[alfred hitch]

Hi All,

I found the reason and solutions to my problems.

J3 ver C flash has these stupid values, it was corrected in j3 v d.

Thanks everyone for their help, appreciate it.
(Ghannon, I shall not need your code now, guess u are also on ioctl
based only ? )

Regards,
Alfred

On 1/12/06, alfred hitch <alfred.hitch at gmail.com> wrote:
> Just to add to last post:
>
> Reason for asking register question is that when I enable traces in
> cfi_cmdset0001.c: funcitons do_xxlock_oneblock and do_xxlock_oneblock
>
> and call netflash <blah baah> with -u -l -b -i -n
> That is invoking lock / unlock ioctls.
>
> I see the value dumped for registers as:
> before unlock: 0xfc
> after unlock : 0xfc
>
> (some erase / write's I presume)
>
> Before Lock: 0xfc
> After Lock: 0xff
>
> 1) This is apparently matching with the code, Block Status register
> dump. But, if my understanding is correct the value should have bit 0
> and 1 only set, rest all bits should be zero ! which isnt .. and why
> is bit 1 also toggling ?
>
> Do you also see same behaviour ? (I guess and hope not -:) )
>
> 2) Can you please point to me the place where mtd does an unlock for
> all flash sectors ?
>
> Regards,
> Alfred
>
> I will try in
>
>
>
> On 1/12/06, alfred hitch <alfred.hitch at gmail.com> wrote:
> > Hi Ghannon,
> >
> > Could you please share the code for lock / unlock.
> > I presume that it must be based on ioctl calls to mtd , same as like
> > what netlfash does with -l option ?'
> >
> > Our flash corruption is pretty much random as of now.
> > Sometimes within a week on new boards (and while running itself, no
> > resets) and sometimes as much as 3 weeks.
> > Suspecting some hardware isssues, but difficult to convince them !
> >
> > Our requirement is pretty much similar to you, to avoid corruption
> > lock some flash sectors.  No permanent lock desired.
> >
> > The fact you mentioned of unlock "feature" wasnt known to me, thanks a
> > lot for the timely tip.
> >
> > One more thing, I happened to have put some traces in the lock /
> > unlock handlers attached to MTD layer.
> > And I observed that when netflash tried to unlock, erase, write,  lock
> >  the registers value dumped were ff which became fc after lock.
> > Just curious to know if these are correct as I am confused from the
> > data sheet on which register is this actually .. is it the status
> > register ? Block Status register ?
> >
> > Regards,
> > Alfred
> >
> >
> > On 1/11/06, ghannon at cspi.com <ghannon at cspi.com> wrote:
> > >
> > > On Wed, 11 Jan 2006, alfred hitch wrote:
> > >
> > > > I am actually surprised that noone is running his / her boards with
> > > > flash sectors locked ?
> > >
> > > > I am new to embedded designs, but wont this be a pretty standard /
> > > > accepted practice to lock your flash sectors ?
> > >
> > > We are also using that same part and we were having some flash
> > > corruption at reboot, although I think it was due to an
> > > error in the reset timing on the board.
> > >
> > > I keep the flash locked at all times except to reflash our firmware.
> > > The locking and unlocking is all handled  by a userspace tool
> > > we wrote up and the reflashing script takes care of doing the
> > > unlock/lock around the programming step.
> > >
> > > I could send you the code if you would like.
> > >
> > > Also, one thing about the J3 part is that any "unlock" of
> > > a block unlocks the whole flash, and a lock only locks one block.
> > > The linux mtd drivers do not take this into consideration.
> > > Although I think the lazy unlock mentioned would not have a
> > > problem with it, it would just never find anything locked once
> > > it unlocked the first block.
> > >
> > > The rev D of J3 allows you to make certain sectors permanently locked,
> > > so that an unlock of one area will not unlock sectors that are
> > > setup to not allow unlocking.   Be careful though, or your can turn your
> > > flash into rom very easily if you have no way of stopping the code
> > > before it sets up these bits.
> > >
> > > Gary Hannon
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>