Flash Mapping and gpio

Flash Mapping and gpio

[Fundu]

Hi,

I trying to access 256mb flash from a pripheral that can only access 128 mb.
flash are in x16 mode and interleaved.
A gpio is connected to A25 pin of the flash parts.

Such that any of the two 128mb "areas" can be accessed.

I'm trying to configure the mtd drivers such that i can do the following 

so when ofs 00000000 -> 07ffffff, A25(gpio)= 0
ofs 08000000 -> 0fffffff, A25(gpio) =1


i have added helper the following function in include/linux/cfi.h

#define GPIO_FLASH_MASK 0x00000800
static inline void flash_cs(u32 addr, char is_ret)
{
    u32 gpio_data = is_ret ? 0 : GPIO_FLASH_MASK;
    if (addr & 0x08000000)
    {
        ibm_gpio_out(0, GPIO_FLASH_MASK, gpio_data);
    }
}

/* adjust the ofs such that 0800_0000 seems like 0000_0000 */
static inline u32 update_addr(u32 addr)
{
    return (addr & 0x08000000) ? (addr - 0x08000000) : addr;
}


static inline void cfi_write(struct map_info *map, cfi_word val, __u32 addr)
{
    flash_cs(map->phys + addr, 0);
    u32 new_addr = update_addr(addr);

    cfi_write_o(map, val, new_addr);

    flash_cs(map->phys + addr, 1); // sets A25 back to 0
}

static inline cfi_word cfi_read(struct map_info *map, __u32 addr)
{
    flash_cs(map->phys + addr, 0);
    u32 new_addr = update_addr(addr);

    cfi_word returnVal = cfi_read_o(map, new_addr);

    flash_cs(map->phys + addr, 1); // sets A25 back to 0

    return returnVal;
}

cfi_read_o and cfi_write_o are the original fn.

Also in cfi_send_gen_cmd i don't call the modified cfi_write 
as all Commands go to base address which is 0.

Questions 
---------
there are 2 things that i'm seeing that doesn't make sense
in cfi_probe.c the print_cfi_ident prints the following

Typical byte/word write timeout: 64 us
Maximum byte/word write timeout: 512 us
Typical full buffer write timeout: 64 us
Maximum full buffer write timeout: 2048 us
Typical block erase timeout: 512 ms
Maximum block erase timeout: 4096 ms
Typical chip erase timeout: 524288 ms
Maximum chip erase timeout: 2097152 ms
Device size: 0x8000000 bytes (128 MiB)
Flash Device Interface description: 0x0002

1) which seems wrong as the Device size should come out to be 256 instead of 128.
This doesn't look right, any ideas ? 

other is that when i do a erase i'm seeing a this ...
MTD do_erase_oneblock(): Wacky!  Unable to decode failure status
MTD do_erase_oneblock(): 0x07f40000(0x00ff00ff): 0x27051956 0x27051956 0x27051956 0x27051956

thanks !
fundu


      

Re: Flash Mapping and gpio

[Mike Frysinger]

On Thu, Sep 11, 2008 at 16:52, Fundu wrote:
> I trying to access 256mb flash from a pripheral that can only access 128 mb.
> flash are in x16 mode and interleaved.
> A gpio is connected to A25 pin of the flash parts.
>
> Such that any of the two 128mb "areas" can be accessed.
>
> I'm trying to configure the mtd drivers such that i can do the following
>
> so when ofs 00000000 -> 07ffffff, A25(gpio)= 0
> ofs 08000000 -> 0fffffff, A25(gpio) =1
>
>
> i have added helper the following function in include/linux/cfi.h

you shouldnt go mucking about in common code.  this is what flash
mapping drivers are for.

ive already written a generic gpio one to do exactly what you want
(but it's only been tested on nommu/Blackfin so far):
http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=blob_plain;f=drivers/mtd/maps/gpio-addr-flash.c;hb=HEAD
-mike

Re: Flash Mapping and gpio

[Fundu]

> 
> you shouldnt go mucking about in common code.  this is what
> flash
> mapping drivers are for.
> 
> ive already written a generic gpio one to do exactly what
> you want
> (but it's only been tested on nommu/Blackfin so far):
> http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=blob_plain;f=drivers/mtd/maps/gpio-addr-flash.c;hb=HEAD

these are on 2.6 kernel. i'm using 2.4.20.




      

Re: Flash Mapping and gpio

[Mike Frysinger]

On Thu, Sep 11, 2008 at 17:34, Fundu wrote:
>> you shouldnt go mucking about in common code.  this is what
>> flash
>> mapping drivers are for.
>>
>> ive already written a generic gpio one to do exactly what
>> you want
>> (but it's only been tested on nommu/Blackfin so far):
>> http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=blob_plain;f=drivers/mtd/maps/gpio-addr-flash.c;hb=HEAD
>
> these are on 2.6 kernel. i'm using 2.4.20.

didnt realize anyone ran ancient cruft like that anymore.  big waste
of time.  g'luck.
-mike

Re: Flash Mapping and gpio

[Fundu]

> > these are on 2.6 kernel. i'm using 2.4.20.
> 
> didnt realize anyone ran ancient cruft like that anymore. 
> big waste
> of time.  g'luck.
it's really not a possibility to port to 2.6 at this time. 
is there anything else that you can point me at, i would much appreciate it.

how about this error 

MTD do_erase_oneblock(): Wacky!  Unable to decode failure status
MTD do_erase_oneblock(): 0x07f40000(0x00ff00ff): 0x27051956 0x27051956 0x27051956 0x27051956

any ideas here, this hasn't changed much. 
i still get these even after backing out my changes that i mentioned in the original post. 

thanks !
fundu 


      

Re: Flash Mapping and gpio

[Allon Stern]

On Sep 11, 2008, at 6:23 PM, Fundu wrote:
>
> these are on 2.6 kernel. i'm using 2.4.20.
>
> how about this error
>
> MTD do_erase_oneblock(): Wacky!  Unable to decode failure status
> MTD do_erase_oneblock(): 0x07f40000(0x00ff00ff): 0x27051956
> 0x27051956 0x27051956 0x27051956
>
> any ideas here, this hasn't changed much.  i still get these even  
> after backing out my changes that i mentioned in the original post.


Dunno about that one, but here is what I did on my system, where I
have a 64MB part in a 16MB address window. It was on 2.6.26 (get
current, man!) so I don't know how closely it will match what you
need, but the basic technique should be very similar.


in drivers/mtd/maps, I added a new mapping, let's call it "custom.c".
Add it to the makefile and KConfig so you can select it.

in custom.c, I added a "CUSTOM_BANKSWITCH(x)" macro, which takes an
address, and sets the GPIOs for the flash to access that address.

In my case, I based it on the "avnet5282.c" map file, except instead
of using

simple_map_init(&avnet5282_map);

I created my own "custom_map_init", which looks something like:

void custom_map_init(struct map_info *map)
{
	BUG_ON(!map_bankwidth_supported(map->bankwidth));

	map->read = custom_map_read;
	map->write = custom_map_write;
	map->copy_from = custom_map_copy_from;
	map->copy_to = custom_map_copy_to;
}


then for the individual map functions, implemented them something like:

static map_word __xipram custom_map_read(struct map_info *map,
unsigned long ofs)
{
      CUSTOM_BANKSWITCH(ofs);
      return inline_map_read(map, ofs & BANK_MASK); // mask out the bank
}

individual
The inline_map will do 99% of what you need - you just have to bank
switch.

Note that in the custom_map_copy_from and custom_map_copy_to, you
need to figure out what happens if a read or read spans banks.
In my case, I asserted that a copy won't be more than 16MB, and two
the copy in two chunks, switching banks in the middle, if need be.

HTH.
-
allon

Re: Flash Mapping and gpio

[Fundu]

First off thanks Allon, I really appreciate your input.
> static map_word __xipram custom_map_read(struct map_info
> *map,
> unsigned long ofs)
> {
>       CUSTOM_BANKSWITCH(ofs);
>       return inline_map_read(map, ofs & BANK_MASK); //
> mask out the bank
> }
> 
that makes sense. but one question don't you need to adjust the offset before calling inline_map_read ? or does the macro do that for you ? 

> In my case, I asserted that a copy won't be more than
> 16MB, and two
> the copy in two chunks, switching banks in the middle, if
> need be.
yeah i have setup mtd partitions such that they don't span across the banks.

> HTH.
yup you bet. 


      

Re: Flash Mapping and gpio

[Allon Stern]

On Sep 12, 2008, at 12:54 PM, Fundu wrote:

> First off thanks Allon, I really appreciate your input.
>> static map_word __xipram custom_map_read(struct map_info
>> *map,
>> unsigned long ofs)
>> {
>>       CUSTOM_BANKSWITCH(ofs);
>>       return inline_map_read(map, ofs & BANK_MASK); //
>> mask out the bank
>> }
>>
> that makes sense. but one question don't you need to adjust the  
> offset before calling inline_map_read ? or does the macro do that  
> for you ?

That's what the BANK_MASK does. It contains the high address field  
which points to the chip, and the low address bits for the bank, but  
masks off the bits of offset that change. In this case, my chip is at  
0xA0000000, and the banks are 16MB, so my mask is 0xA0FFFFFF.

-
allon