All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louie Boczek <louie@calimatech.com>
To: Christopher Hoover <ch@murgatroid.com>
Cc: 'ARM Linux kernel Mailinglist'
	<linux-arm-kernel@lists.arm.linux.org.uk>,
	linux-mtd@lists.infradead.org
Subject: Re: Unlocking flash problem with the epxa10db device
Date: Fri, 20 Sep 2002 06:52:44 -0700	[thread overview]
Message-ID: <3D8B282C.9080004@calimatech.com> (raw)
In-Reply-To: 000001c26061$7d20c8f0$7e00000a@bergamot

Sounds good to me.  I could have gone either way.    So I actually fixed 
it the way you want.

On a side note, is there any reason that the entire flash is unlocked on 
boot instead of just the filesystem.  I am referencing the unlock code 
in epxa10db-flash.c.

thanks
louie


Christopher Hoover wrote:

>I wrote cfi_intelext_varsize_frob().  It is behaving as intended.
>
>You have to unlock/lock/erase/etc. an *entire* block/sector at a time.  
>
>There's no way to unlock 4 bytes and leave the other (erasesize - 4)
>bytes locked.  So the function returns EINVAL if the size isn't an even
>"multiple" of the block size(s).  ("Multiple" here is not meant strictly
>in the mathematical sense; consider variably-sized blocks.)
>
>You'll find the other functions behave identically, e.g. erase.
>
>-ch
>
>
>-----Original Message-----
>From: linux-arm-kernel-admin@lists.arm.linux.org.uk
>[mailto:linux-arm-kernel-admin@lists.arm.linux.org.uk] On Behalf Of
>Louie Boczek
>Sent: Thursday, September 19, 2002 8:11 PM
>To: ARM Linux kernel Mailinglist
>Subject: Unlocking flash problem with the epxa10db device
>
>
>I just started working with the Altera Excalibur board and ran into the 
>following problem.
>
>I was not able to write to the flash and found the problem lied in the 
>unlocking code.  
>In the epxa10db-flash.c:epxa10db_mtd_init() routine it calls:
>
>       mymtd->unlock(mymtd, mymtd->eraseregions[i].offset + j * 
>mymtd->eraseregions[i].erasesize, 4);
>
>which eventually calls "cfi_cmdsetc_001.c:cfi_intelext_varsize_frob()" 
>in this routine there is a check to make sure that the region being 
>unlocked is the whole region with  the check:
>        if ((ofs + len) & (regions[i].erasesize -1))
>            return -EINVAL;
>
>this fails since the call was only to unlock 4 bytes not erasesize.  So 
>I fixed the problem by changing the call to mymtd->unlock()  to pass the
>
>erasesize instead of 4.
>
>But the question is, should "cfi_intelext_varsize_frob()" check to see 
>if the whole region is specifed or should it unlock the region that the 
>specified location is located.  I think the later.
>
>I am using the linux-2.4.18-rmk7 but I also checked linux-2.4.19 and the
>
>problem is also there.
>
>
>I am new to this, I hope I gave enough and thorough informartion.
>
>thanks
>louie
>
>
>-------------------------------------------------------------------
>Subscription options:
>http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
>FAQ/Etiquette:
>http://www.arm.linux.org.uk/armlinux/mailinglists.php
>
>
>  
>

  reply	other threads:[~2002-09-20 13:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3D8A91C3.5030404@calimatech.com>
2002-09-20  4:52 ` Unlocking flash problem with the epxa10db device Christopher Hoover
2002-09-20 13:52   ` Louie Boczek [this message]
2002-09-20 14:14     ` Clive Davies

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D8B282C.9080004@calimatech.com \
    --to=louie@calimatech.com \
    --cc=ch@murgatroid.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.