This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: J3 flash lockbits across reset
- From: Andrew Lunn <andrew at lunn dot ch>
- To: alfred hitch <alfred dot hitch at gmail dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 12 Jan 2006 09:44:49 +0100
- Subject: Re: [ECOS] J3 flash lockbits across reset
- References: <29f916510601120033m64d536e7geeede5747f2ad952@mail.gmail.com>
On Thu, Jan 12, 2006 at 03:33:03AM -0500, alfred hitch wrote:
> Hi,
>
> I am confused on what is the correct behavior across power resets
> (of hardware) for J3 flash'es.
>
> 1) Will all sectors which were locked before power reset, remain so ?
>
> I am confused by some posts on net, saying they get locked (all) by
> default across resets (irr. of before power reset status)
>
> Some say, it is unlocked (all blocks )by default across resets.
>
> I dont think flash should change status across resets. It should
> preserve whatever I locked before reboot and vice versa.
The data sheet for the chip is the best source of answer for this
question.
> 2) Is it dependant on version, looking at j3 v d there seem to be a
> bug on registers for same also which was fixed. Gives me an errie
> feeling that responses on net were diff. because of people using diff.
> kernels and flash revisions and so diff. observations ?
"kernels" are you talking "Linux" here? This is an eCos mailling list.
> 3) Intel FAQ says, that :
>
> While setting up a Set Block Lock-Bit or Clear Block-Bits operation.
> must the first and second bus cycles be sequential write operations
> (i.e., no other bus operations to the flash between write cycles)?
> For the Set and Clear Block Lock Bit operations, the first and second
> bus cycles must be sequential. If the 28xxxJ3 receives any other
> command during the second write cycle, an invalid command sequence
> occurs. This causes the mode (the first bus cycle) to be aborted, and
> bits 5 and 4 in the Status Register will be set.
>
> So, will this effectively mean that I cannot use this lock / unlock
> feature unless I can be sure there will be no read / write etc from
> ANY flash location ? as this will break the WSM sequence ?
It sounds like you need to ensure the functions to lock/unlock are
running from RAM and that you disable interrupts. Running from RAM is
easy to acheive, in fact all code which acts on the FLASH needs to do
this. Just cut&paste the attribute section statement. Most of the
flash drivers don't disable interrupts, but this is also easy to add
for your specific driver.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss