* sector locks handling for J3 flashes?
@ 2006-01-11 5:54 alfred hitch
2006-01-11 10:11 ` Peter Wippich
0 siblings, 1 reply; 8+ messages in thread
From: alfred hitch @ 2006-01-11 5:54 UTC (permalink / raw)
To: linux-mtd
Hi,
I am trying to understand how it works for flash'es which have
Hardware flash protection.
Bootloader say locks say 1 partition, then linux kernel / MTD while coming up
reads / probes flash (sector by sector) for locked sectors ?
If yes, and it maintain this in an internal software structure. Using
it when writes to partitions is done ?
I hope linux kernel arm-linux2.4.25-x (snapgear 3.1) has support for
ixdp425 and Intel J3 Strata flash for automatic detection and working
with locked flashes ?
Any one already tried this ?
Regards,
Alfred
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
2006-01-11 5:54 alfred hitch
@ 2006-01-11 10:11 ` Peter Wippich
2006-01-11 10:41 ` alfred hitch
2006-01-13 7:40 ` alfred hitch
0 siblings, 2 replies; 8+ messages in thread
From: Peter Wippich @ 2006-01-11 10:11 UTC (permalink / raw)
To: alfred hitch; +Cc: linux-mtd
Hi Alfred,
the original MTD driver unlocks all flash sector during initialization.
However, this is a lenghty operation. Took about 2..3 seconds, depending
on flash size. Uli Luckas has supplied a patch which does "lazy"
unlocking. Each time a write / erase operation fails it unlocks the sector
and retries the operation. But this is only available for the latest 2.6
kernel. You may have a look there and / or check Russel's patch history
for the ARM linux kernel.
Ciao,
Peter
On Wed, 11 Jan 2006, alfred hitch wrote:
> Hi,
>
> I am trying to understand how it works for flash'es which have
> Hardware flash protection.
> Bootloader say locks say 1 partition, then linux kernel / MTD while coming up
> reads / probes flash (sector by sector) for locked sectors ?
> If yes, and it maintain this in an internal software structure. Using
> it when writes to partitions is done ?
>
> I hope linux kernel arm-linux2.4.25-x (snapgear 3.1) has support for
> ixdp425 and Intel J3 Strata flash for automatic detection and working
> with locked flashes ?
>
> Any one already tried this ?
>
> Regards,
> Alfred
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
| Peter Wippich Voice: +49 30 46776411 |
| G&W Instruments GmbH fax: +49 30 46776419 |
| Gustav-Meyer-Allee 25, Geb. 12 Email: pewi@gw-instruments.de |
| D-13355 Berlin / Germany |
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
2006-01-11 10:11 ` Peter Wippich
@ 2006-01-11 10:41 ` alfred hitch
2006-01-13 7:40 ` alfred hitch
1 sibling, 0 replies; 8+ messages in thread
From: alfred hitch @ 2006-01-11 10:41 UTC (permalink / raw)
To: Peter Wippich; +Cc: linux-mtd
HI Peter,
Thanks for your reply.
If my partitions are to be used as read only jffs2 partitions ..
Will removing this unlock on these sectors harm anything ??
We are currently undergoing a whole exercise of locking flash sectors
to get past some random flash corruptions we are observing.
Can you please help me to point in code, where this unlock is being done ?
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 ?
Regards,
Alfred
On 1/11/06, Peter Wippich <pewi@gw-instruments.de> wrote:
>
> Hi Alfred,
>
> the original MTD driver unlocks all flash sector during initialization.
> However, this is a lenghty operation. Took about 2..3 seconds, depending
> on flash size. Uli Luckas has supplied a patch which does "lazy"
> unlocking. Each time a write / erase operation fails it unlocks the sector
> and retries the operation. But this is only available for the latest 2.6
> kernel. You may have a look there and / or check Russel's patch history
> for the ARM linux kernel.
>
> Ciao,
>
> Peter
>
>
>
> On Wed, 11 Jan 2006, alfred hitch wrote:
>
> > Hi,
> >
> > I am trying to understand how it works for flash'es which have
> > Hardware flash protection.
> > Bootloader say locks say 1 partition, then linux kernel / MTD while coming up
> > reads / probes flash (sector by sector) for locked sectors ?
> > If yes, and it maintain this in an internal software structure. Using
> > it when writes to partitions is done ?
> >
> > I hope linux kernel arm-linux2.4.25-x (snapgear 3.1) has support for
> > ixdp425 and Intel J3 Strata flash for automatic detection and working
> > with locked flashes ?
> >
> > Any one already tried this ?
> >
> > Regards,
> > Alfred
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
>
> | Peter Wippich Voice: +49 30 46776411 |
> | G&W Instruments GmbH fax: +49 30 46776419 |
> | Gustav-Meyer-Allee 25, Geb. 12 Email: pewi@gw-instruments.de |
> | D-13355 Berlin / Germany |
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
@ 2006-01-11 18:36 ghannon
2006-01-12 6:18 ` alfred hitch
0 siblings, 1 reply; 8+ messages in thread
From: ghannon @ 2006-01-11 18:36 UTC (permalink / raw)
To: alfred hitch; +Cc: linux-mtd, Peter Wippich
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
2006-01-11 18:36 sector locks handling for J3 flashes? ghannon
@ 2006-01-12 6:18 ` alfred hitch
2006-01-12 7:26 ` alfred hitch
0 siblings, 1 reply; 8+ messages in thread
From: alfred hitch @ 2006-01-12 6:18 UTC (permalink / raw)
To: ghannon@cspi.com; +Cc: linux-mtd, Peter Wippich
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@cspi.com <ghannon@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
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
2006-01-12 6:18 ` alfred hitch
@ 2006-01-12 7:26 ` alfred hitch
2006-01-12 11:09 ` alfred hitch
0 siblings, 1 reply; 8+ messages in thread
From: alfred hitch @ 2006-01-12 7:26 UTC (permalink / raw)
To: ghannon@cspi.com; +Cc: linux-mtd, Peter Wippich
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@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@cspi.com <ghannon@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
> >
> >
> >
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
2006-01-12 7:26 ` alfred hitch
@ 2006-01-12 11:09 ` alfred hitch
0 siblings, 0 replies; 8+ messages in thread
From: alfred hitch @ 2006-01-12 11:09 UTC (permalink / raw)
To: ghannon@cspi.com; +Cc: linux-mtd, Peter Wippich
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@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@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@cspi.com <ghannon@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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: sector locks handling for J3 flashes?
2006-01-11 10:11 ` Peter Wippich
2006-01-11 10:41 ` alfred hitch
@ 2006-01-13 7:40 ` alfred hitch
1 sibling, 0 replies; 8+ messages in thread
From: alfred hitch @ 2006-01-13 7:40 UTC (permalink / raw)
To: Peter Wippich; +Cc: linux-mtd
Hi Peter,
I have been trying to find the patch you have mentioned for whole day in vain.
Could you please point me to the correct path ?
I shall have to do back porting for it to 2.4. Will share the results
back to community if anyone is interested.
Regards,
Alfred
On 1/11/06, Peter Wippich <pewi@gw-instruments.de> wrote:
>
> Hi Alfred,
>
> the original MTD driver unlocks all flash sector during initialization.
> However, this is a lenghty operation. Took about 2..3 seconds, depending
> on flash size. Uli Luckas has supplied a patch which does "lazy"
> unlocking. Each time a write / erase operation fails it unlocks the sector
> and retries the operation. But this is only available for the latest 2.6
> kernel. You may have a look there and / or check Russel's patch history
> for the ARM linux kernel.
>
> Ciao,
>
> Peter
>
>
>
> On Wed, 11 Jan 2006, alfred hitch wrote:
>
> > Hi,
> >
> > I am trying to understand how it works for flash'es which have
> > Hardware flash protection.
> > Bootloader say locks say 1 partition, then linux kernel / MTD while coming up
> > reads / probes flash (sector by sector) for locked sectors ?
> > If yes, and it maintain this in an internal software structure. Using
> > it when writes to partitions is done ?
> >
> > I hope linux kernel arm-linux2.4.25-x (snapgear 3.1) has support for
> > ixdp425 and Intel J3 Strata flash for automatic detection and working
> > with locked flashes ?
> >
> > Any one already tried this ?
> >
> > Regards,
> > Alfred
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
>
> | Peter Wippich Voice: +49 30 46776411 |
> | G&W Instruments GmbH fax: +49 30 46776419 |
> | Gustav-Meyer-Allee 25, Geb. 12 Email: pewi@gw-instruments.de |
> | D-13355 Berlin / Germany |
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-01-13 7:40 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-11 18:36 sector locks handling for J3 flashes? ghannon
2006-01-12 6:18 ` alfred hitch
2006-01-12 7:26 ` alfred hitch
2006-01-12 11:09 ` alfred hitch
-- strict thread matches above, loose matches on Subject: below --
2006-01-11 5:54 alfred hitch
2006-01-11 10:11 ` Peter Wippich
2006-01-11 10:41 ` alfred hitch
2006-01-13 7:40 ` alfred hitch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox