All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Todd Poynor <tpoynor@mvista.com>
Cc: linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: latest mtd changes broke collie
Date: Fri, 11 Nov 2005 01:16:17 +0100	[thread overview]
Message-ID: <20051111001617.GD9905@elf.ucw.cz> (raw)
In-Reply-To: <4373DEB4.5070406@mvista.com>

Hi!

> >With these hacks, I'm able to mount flash at least read-only. On
> >attempt to remount read-write, I get 
> >
> >"Write error in obliterating obsoleted node at 0x00bc0000: -30
> >...
> >Erase at 0x00c00000 failed immediately: -EROFS. Is the sector locked?"
> >
> >Is it good news?
> 
> I see the old sharp driver has a normally-not-defined AUTOUNLOCK symbol 
> that would enable some code to unlock blocks before writing/erasing 
> (which isn't recommended since the code doesn't know the policy on 
> whether the block is supposed to be locked).  The tree previously in use 
> may have had something similar setup.  It seems these flashes have all 
> blocks locked by default at power up.

Is there some quick hack I can do in kernel to unlock it? Is it
possible to accidentally unlock "BIOS" area and brick the device?

> Try flash_unlock /dev/mtdX before remounting.  More automatic means of 
> handling this are still under debate, I need to try another stab at 
> resolving that soon.

Good news is that I do have /dev/mtdX. Bad news is I do not have
flash_unlock. Does anyone have binary suitable for arm, preferably
statically linked?

> Looks like you're close to obsoleting the pre-CFI Sharp flash driver, 
> it's good news...

Ok, good. Read-only access is certainly better than nothing, and might
even be enough. Sharp shipped it with flash read-only originally.

								Pavel
-- 
Thanks, Sharp!

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@suse.cz>
To: Todd Poynor <tpoynor@mvista.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	linux-mtd@lists.infradead.org,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: latest mtd changes broke collie
Date: Fri, 11 Nov 2005 01:16:17 +0100	[thread overview]
Message-ID: <20051111001617.GD9905@elf.ucw.cz> (raw)
In-Reply-To: <4373DEB4.5070406@mvista.com>

Hi!

> >With these hacks, I'm able to mount flash at least read-only. On
> >attempt to remount read-write, I get 
> >
> >"Write error in obliterating obsoleted node at 0x00bc0000: -30
> >...
> >Erase at 0x00c00000 failed immediately: -EROFS. Is the sector locked?"
> >
> >Is it good news?
> 
> I see the old sharp driver has a normally-not-defined AUTOUNLOCK symbol 
> that would enable some code to unlock blocks before writing/erasing 
> (which isn't recommended since the code doesn't know the policy on 
> whether the block is supposed to be locked).  The tree previously in use 
> may have had something similar setup.  It seems these flashes have all 
> blocks locked by default at power up.

Is there some quick hack I can do in kernel to unlock it? Is it
possible to accidentally unlock "BIOS" area and brick the device?

> Try flash_unlock /dev/mtdX before remounting.  More automatic means of 
> handling this are still under debate, I need to try another stab at 
> resolving that soon.

Good news is that I do have /dev/mtdX. Bad news is I do not have
flash_unlock. Does anyone have binary suitable for arm, preferably
statically linked?

> Looks like you're close to obsoleting the pre-CFI Sharp flash driver, 
> it's good news...

Ok, good. Read-only access is certainly better than nothing, and might
even be enough. Sharp shipped it with flash read-only originally.

								Pavel
-- 
Thanks, Sharp!

  reply	other threads:[~2005-11-11  0:17 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-09 22:17 latest mtd changes broke collie Pavel Machek
2005-11-10  0:19 ` Josh Boyer
2005-11-10  9:48   ` Pavel Machek
2005-11-10  2:59 ` Todd Poynor
2005-11-10  9:50   ` Pavel Machek
2005-11-10 10:02     ` David Woodhouse
2005-11-10 10:38       ` Pavel Machek
2005-11-10 10:51         ` David Woodhouse
2005-11-10 10:59           ` Pavel Machek
2005-11-10 11:11             ` David Woodhouse
2005-11-10 11:44               ` Pavel Machek
2005-11-10 12:07               ` Pavel Machek
2005-11-10 13:02                 ` David Vrabel
2005-11-10 13:02                   ` David Vrabel
2005-11-10 13:09                   ` Pavel Machek
2005-11-10 13:09                     ` Pavel Machek
2005-11-10 17:41                     ` Richard Purdie
2005-11-10 17:41                       ` Richard Purdie
2005-11-10 18:09                       ` Richard Purdie
2005-11-10 18:09                         ` Richard Purdie
2005-11-10 22:06                         ` Pavel Machek
2005-11-10 22:06                           ` Pavel Machek
2005-11-10 22:41               ` Pavel Machek
2005-11-10 23:58                 ` Todd Poynor
2005-11-10 23:58                   ` Todd Poynor
2005-11-11  0:16                   ` Pavel Machek [this message]
2005-11-11  0:16                     ` Pavel Machek
2005-11-11  7:01                     ` Ian Campbell
2005-11-12 21:33                       ` Pavel Machek
2005-11-12 21:33                         ` Pavel Machek
2005-11-13 10:35                         ` Ian Campbell
2005-11-13 10:35                           ` Ian Campbell
2005-11-14 12:10                           ` Pavel Machek
2005-11-14 12:10                             ` Pavel Machek
2005-11-13 19:40                         ` Todd Poynor
2005-11-13 19:40                           ` Todd Poynor
2005-11-14 12:08                           ` Pavel Machek
2005-11-14 12:08                             ` Pavel Machek

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=20051111001617.GD9905@elf.ucw.cz \
    --to=pavel@suse.cz \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tpoynor@mvista.com \
    /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.