From: Konstantin Kletschke <lists@ku-gbr.de>
To: linux-mtd@lists.infradead.org
Subject: Intel flash that powers up locked
Date: Wed, 1 Jun 2005 15:41:30 +0200 [thread overview]
Message-ID: <20050601134130.GA19482@synertronixx3> (raw)
Hi there!
I have intel K3 devices on my Board and the linux Kernel needs to unlock
them.
I found
http://lists.infradead.org/pipermail/linux-mtd/2005-April/012431.html
and incorporated the provided diff into a daily-mtd-cvs snapshot from
20050530 in 2.6.11.
However, this code Oopses in cfi_intelext_unlockall():
static void cfi_intelext_unlockall(struct mtd_info *mtd)
{
#if 1
int i;
for (i = 0; i <= mtd->numeraseregions; i++) {
printk("mtd->numeraseregions %x\n", mtd->numeraseregions);
int j;
printk("rumms\n");
printk("mtd->eraseregions[0].numblocks %x\n",
mtd->eraseregions[i].numblocks);
printk("bumms\n");
...
The printk("mtd->eraseregions[0].numblocks %x\n",
mtd->eraseregions[i].numblocks);
causes The Oops. How is that possible?
Also weird is that mtd->numeraseregions is 0.
Probing scb9328_flash at physical address 0x10000000 (16-bit buswidth)
scb9328_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
Feature/Command Support: 01E6
- Chip Erase: unsupported
- Suspend Erase: supported
- Suspend Program: supported
- Legacy Lock/Unlock: unsupported
- Queued Erase: unsupported
- Instant block lock: supported
- Protection Bits: supported
- Page-mode read: supported
- Synchronous read: supported
- Simultaneous operations: unsupported
Supported functions after Suspend: 01
- Program after Erase Suspend: supported
Block Status Register Mask: 0007
- Lock Bit Active: yes
- Valid Bit Active: yes
- Unknown Bit 2 Active: yes
Vcc Logic Supply Optimum Program/Erase Voltage: 3.3 V
cfi_cmdset_0001: Erase suspend on write enabled
number of CFI chips: 1
devsize 16777216
5 cmdlinepart partitions found on MTD device scb9328_flash
Creating 5 MTD partitions on "scb9328_flash":
0x00000000-0x00020000 : "U-boot"
0x00020000-0x00040000 : "U-boot_env"
mtd->numeraseregions 0
rumms
Unable to handle kernel NULL pointer dereference at virtual address 00000008
After that I tried another approach like that in message
http://lists.infradead.org/pipermail/linux-mtd/2005-April/012396.html
so the for loop went away in a replacement for the oneliner which calls
cfi_intelext_unlock(). This function is called and Oopses at
cfi_varsize_frob(mtd, do_printlockstatus_oneblock,
ofs, len, 0);
imediately.
What can be the cause of that?
Has anybody Intel K3 unlocking working and if yes, how is his or her map
driver looking?
Regards, konsti
next reply other threads:[~2005-06-01 13:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-01 13:41 Konstantin Kletschke [this message]
2005-06-02 4:15 ` Intel flash that powers up locked Ratan Panneerselvam
2005-06-02 10:19 ` Konstantin Kletschke
2005-06-02 10:46 ` Thomas Gleixner
2005-06-02 11:52 ` Konstantin Kletschke
2005-06-02 23:31 ` Todd Poynor
2005-06-23 15:35 ` Konstantin Kletschke
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=20050601134130.GA19482@synertronixx3 \
--to=lists@ku-gbr.de \
--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.