Intel flash that powers up locked

Intel flash that powers up locked

[Konstantin Kletschke]

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

Re: Intel flash that powers up locked

[Ratan Panneerselvam]

Konstantin Kletschke wrote:

>Has anybody Intel K3 unlocking working and if yes, how is his or her map
>driver looking?
>  
>
I had the Intel K3 unlocked successfully in the map driver on a 2.4.20
kernel with this call:
nor_info->unlock( nor_info, 0, nor_info->size );

However on the 2.6.12 from cvs@ftp.linux-mips.org, the same map driver
gives an oops similar to yours.

regards,
ratan

map driver code snippet:
>>>>>
    simple_map_init(&nor_map);
    nor_info = do_map_probe("cfi_probe", &nor_map);
    if (!nor_info) {
        err("cfi_probe: NOR flash probe failed");
        iounmap(nor_map.virt);
        return -ENXIO;
    }

    nor_info->owner = THIS_MODULE;
   
    if (nor_info->unlock)
    {
        info("Unlocking the entire NOR flash");
        nor_info->unlock( nor_info, 0, nor_info->size );
    }

#ifdef CONFIG_MTD_PARTITIONS
    rval = add_mtd_partitions(nor_info, nor_partition,
NUM_PARTITIONS(nor_partition));
#else   
    rval = add_mtd_device(nor_info);
#endif
>>>>>>
 


>>>>>>
[4294667.381000] nor_flash[FBC0]: virt=0xBC000000 phys=0x1C000000
size=0x100000
[4294667.382000] Xilleon NOR flash [Memory Mapped]: Found 1 x16 devices
at 0x0 in 16-bit bank
[4294667.383000]  Intel/Sharp Extended Query Table at 0x0031
[4294667.384000] Using buffer write method
[4294667.385000]   Feature/Command Support:      01E6
[4294667.386000]      - Chip Erase:              unsupported
[4294667.387000]      - Suspend Erase:           supported
[4294667.388000]      - Suspend Program:         supported
[4294667.389000]      - Legacy Lock/Unlock:      unsupported
[4294667.390000]      - Queued Erase:            unsupported
[4294667.391000]      - Instant block lock:      supported
[4294667.392000]      - Protection Bits:         supported
[4294667.393000]      - Page-mode read:          supported
[4294667.394000]      - Synchronous read:        supported
[4294667.395000]      - Simultaneous operations: unsupported
[4294667.396000]   Supported functions after Suspend: 01
[4294667.397000]      - Program after Erase Suspend: supported
[4294667.398000]   Block Status Register Mask: 0007
[4294667.399000]      - Lock Bit Active:      yes
[4294667.400000]      - Valid Bit Active:     yes
[4294667.401000]      - Unknown Bit 2 Active: yes
[4294667.402000]   Vcc Logic Supply Optimum Program/Erase Voltage: 3.3 V
[4294667.403000] cfi_cmdset_0001: Erase suspend on write enabled
[4294667.404000] Unlocking the entire NOR flash
[4294667.414000] CPU 0 Unable to handle kernel paging request at virtual
address 00000000, epc == 80122d94, ra == 80122e48
[4294667.414000] Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
[4294667.414000] Cpu 0
[4294667.414000] $ 0   : 00000000 1000f800 00000000 00000000
[4294667.414000] $ 4   : 802a826c 00000003 00000001 00000000
[4294667.414000] $ 8   : 80295fe0 0000f800 00000000 8023c000
[4294667.414000] $12   : 00000000 00000000 00000000 7fffffff
[4294667.414000] $16   : 1000f801 80245a70 00000001 802a826c
[4294667.414000] $20   : 00000000 00000000 00000003 80295e94
[4294667.414000] $24   : 00000000 00000000                 
[4294667.414000] $28   : 80294000 80295dd0 80295dd0 80122e48
[4294667.414000] Hi    : 00000000
[4294667.414000] Lo    : 00000000
[4294667.414000] epc   : 80122d94 __wake_up_common+0x44/0xb8     Not tainted
[4294667.414000] ra    : 80122e48 __wake_up+0x40/0x7c
[4294667.414000] Status: 1000f802    KERNEL EXL
[4294667.414000] Cause : 90800008
[4294667.414000] BadVA : 00000000
[4294667.414000] PrId  : 00018448
[4294667.414000] Process swapper (pid: 1, threadinfo=80294000,
task=8028dc08)
[4294667.414000] Stack : fffb6c96 00000002 80295e08 80240000 1000f801
80245a70 802a8218 00000000
[4294667.414000]         00000001 80295e9c 80295e98 80295e08 80122e48
1000f801 00100100 00200200
[4294667.414000]         fffb6c96 4b87ad6e 00000000 8028dc08 802a8250
80295e30 8021a074 00000002
[4294667.414000]         80270000 00000000 80295e40 80135624 00000002
00000000 00418937 fffbbab6
[4294667.414000]         80245a70 00000000 00000001 80295e68 8021f11c
8021eefc 80245a70 00000001
[4294667.414000]         ...
[4294667.414000] Call Trace:
[4294667.414000]  [<80122e48>] __wake_up+0x40/0x7c
[4294667.414000]  [<8021a074>] put_chip+0x9c/0x404
[4294667.414000]  [<80135624>] msleep+0x64/0x8c
[4294667.414000]  [<8021f11c>] do_xxlock_oneblock+0x330/0x8d4
[4294667.414000]  [<8021eefc>] do_xxlock_oneblock+0x110/0x8d4
[4294667.414000]  [<802184f4>] cfi_varsize_frob+0x278/0x384
[4294667.414000]  [<8015ae44>] cache_alloc_debugcheck_after+0xe0/0x1c4
[4294667.414000]  [<80220000>] mtd_do_chip_probe+0x298/0x418
[4294667.414000]  [<80220000>] mtd_do_chip_probe+0x298/0x418
[4294667.414000]  [<8021f858>] cfi_intelext_unlock+0x98/0x100
[4294667.414000]  [<8021edec>] do_xxlock_oneblock+0x0/0x8d4
[4294667.414000]  [<8026ee08>] xilleon_nor_init+0x160/0x1dc
[4294667.414000]  [<8026ede8>] xilleon_nor_init+0x140/0x1dc
[4294667.414000]  [<80100520>] init+0xa0/0x270
[4294667.414000]  [<80100520>] init+0xa0/0x270
[4294667.414000]  [<80103c08>] kernel_thread_helper+0x14/0x1c
[4294667.414000]
[4294667.414000]
[4294667.414000] Code: 00a0b021  00c09021  00e0a821 <10730010> 8c710000 
2464fff4  8c820008  8c70fff4  02c02821
[4294667.415000] Kernel panic - not syncing: Attempted to kill init!
>>>>>>

Re: Intel flash that powers up locked

[Konstantin Kletschke]

* Ratan Panneerselvam <ratan@thattiko.net> [Thu, Jun 02, 2005 at 12:15:17AM -0400]:

> However on the 2.6.12 from cvs@ftp.linux-mips.org, the same map driver
> gives an oops similar to yours.

He, weird...

at first, what I don't understand in my quoted code snippets is the
following:

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00020000
cfi_intelext_unlock: lock status after, ret=-1070912512                
0x00040000-0x00240000 : "kernel"                       
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00200000
cfi_intelext_unlock: lock status after, ret=-1070913024                
0x00240000-0x00740000 : "root"                         
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00500000
cfi_intelext_unlock: lock status after, ret=-1070913536                
0x00740000-0x01000000 : "fs"                           
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x008C0000
cfi_intelext_unlock: lock status after, ret=-1070914048

That comes from 
cfi_intelext_unlock(mtd, 0, mtd->size);
being called, the cfi_varsize_frob functions are all commented out,
only the DEBUG_LOCK_BITS are functional.

Why is cfi_intelext_unlock() called with ofs=0, is that correct?
Shouldn't there be hardware addresses?

Regards, Konsti

Re: Intel flash that powers up locked

[Thomas Gleixner]

On Thu, 2005-06-02 at 12:19 +0200, Konstantin Kletschke wrote:

> Why is cfi_intelext_unlock() called with ofs=0, is that correct?
> Shouldn't there be hardware addresses?

Maybe it helps if you read the code of the invoked function
(cfi_varsize_frob).

tglx

Re: Intel flash that powers up locked

[Konstantin Kletschke]

Am 2005-06-02 12:46 +0200 schrieb Thomas Gleixner:

> Maybe it helps if you read the code of the invoked function
> (cfi_varsize_frob).

Ok, I took a closer look into cfi_varsize_frob() trying to understand,
if ofs should be 0 (beginning of partition) or address (physical address
of beginning of partition).

What I found out is, that mtd->numeraseregions contains 0 which is the
problem and causes the Oops regardless with which ofs the funtion is
called.

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00020000
KONSTI mtd->numeraseregions: 0x0                                       
KONSTI first: 0xffffffff        
KONSTI adr:  0x0

Is the output of

int cfi_varsize_frob(struct mtd_info *mtd, varsize_frob_t frob,
                                     loff_t ofs, size_t len, void *thunk)
{

...
	i = 0;

        printk("KONSTI mtd->numeraseregions: 0x%x\n", mtd->numeraseregions);

        while (i < mtd->numeraseregions && ofs >= regions[i].offset)
               i++;
        i--;

//      if (ofs & (regions[i].erasesize-1))
//              return -EINVAL;

        /* Remember the erase region we start on */
        first = i;
        printk("KONSTI first: 0x%x\n", first);

The while loop is not entered because 0 is NOT < 0 and 0 is 
decremented by one.
Acessing regions[-1].erasesize gives the Oops, is that correct?

So why is mtd->numeraseregions 0 in my setup and what should be in it (I 
mean in speaking words).

regards, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: Intel flash that powers up locked

[Todd Poynor]

Konstantin Kletschke wrote:
...
> However, this code Oopses in cfi_intelext_unlockall():
...
> 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

I'll hazard a guess that you're calling the function passing the 
partition "slave" mtd structure instead of the "master" mtd structure 
created at chip probe time (since you're passing the partition creation 
stage instead of doing this at chip probe time).  See the mtdpart.c code 
for the mapping between the two kinds of structures, such as 
part_unlock(), which passes the master structure.  Only the master 
structure has various fields properly filled out, especially things 
determined by the chip driver, and numeraseregions doesn't seem to be 
copied from master to slave after a quick glance.

If that's a bad guess then sorry for the misdirection. ;)  Let us know 
how you are calling the unlock function to take some of the guesswork 
out of it.

-- 
Todd

Re: Intel flash that powers up locked

[Konstantin Kletschke]

* Todd Poynor <tpoynor@mvista.com> [Thu, Jun 02, 2005 at 04:31:12PM -0700]:

> If that's a bad guess then sorry for the misdirection. ;)  Let us know 
> how you are calling the unlock function to take some of the guesswork 
> out of it.

Sorry for late Reply, I had to do other nasty stuff last weeks :/

cfi_intelext_unlockall() calls cfi_intelext_unlock(mtd, 0, mtd->size);

These I got out of your patches initially handling this issue.

cfi_intelext_unlock() calls cfi_varsize_frob() where the Oops happenes
then. I had to remove all while loops and inserted some printk and the
Oops does not happen. So the system runs as before when I unlock whole
Flash in the bootloader. For example it Oopses here in cfi_varsize_frob:

//      while (i < mtd->numeraseregions && ofs >=
//      regions[i].offset)
//             i++;

I will take a closer look tomorrow to start again fix this issue.

Regards, Konsti