Map driver usage

Map driver usage

[Robert Kaiser]

Hi everybody,

I have a question regarding the usage od the access primitives
(e.g. xx_read8(), xx_read16(), xx_copy_from() and so on). In writing
a map driver, can one assume that the MTD layer never calls these
functions to cross a flash device's block boundary ?

The reason I'm asking is that I am writing a new map driver for a board
that has a somwhat strange logical flash layout and I would like
to hide that by "shuffling" some of the blocks so that they appear
at different offsets. Transforming the offset parameter in the above
mentioned functions would be an easy way to do this, but it requires
that these functions are never asked to cross an erase block boundary.

Thanks for any insights

Rob

----------------------------------------------------------------
Robert Kaiser                          email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10

Re: Map driver usage

[David Woodhouse]

rob@sysgo.de said:
>  I have a question regarding the usage od the access primitives (e.g.
> xx_read8(), xx_read16(), xx_copy_from() and so on). In writing a map
> driver, can one assume that the MTD layer never calls these functions
> to cross a flash device's block boundary ?

No. JFFS may do large reads which cross eraseblock boundaries, and the 
flash driver will translate that directly into a large ->copy_from call.

> The reason I'm asking is that I am writing a new map driver for a
> board that has a somwhat strange logical flash layout and I would like
> to hide that by "shuffling" some of the blocks so that they appear at
> different offsets. Transforming the offset parameter in the above
> mentioned functions would be an easy way to do this, but it requires
> that these functions are never asked to cross an erase block boundary.

I wouldn't do it in the map driver. Do it in the partitioning layer - 
that's already mucking around with the offsets anyway.

--
dwmw2

Re: Map driver usage

[Robert Kaiser]

David,

thanks for your response,

On Tue, 18 Dec 2001, David Woodhouse wrote:

> 
> rob@sysgo.de said:
> >  I have a question regarding the usage od the access primitives (e.g.
> > xx_read8(), xx_read16(), xx_copy_from() and so on). In writing a map
> > driver, can one assume that the MTD layer never calls these functions
> > to cross a flash device's block boundary ?
> 
> No. JFFS may do large reads which cross eraseblock boundaries, and the 
> flash driver will translate that directly into a large ->copy_from call.

OK, so if I implement the copy_from call to break the large transfer
into smaller ones if necessary, then I should be safe ?

> 
> > The reason I'm asking is that I am writing a new map driver for a
> > board that has a somwhat strange logical flash layout and I would like
> > to hide that by "shuffling" some of the blocks so that they appear at
> > different offsets. Transforming the offset parameter in the above
> > mentioned functions would be an easy way to do this, but it requires
> > that these functions are never asked to cross an erase block boundary.
> 
> I wouldn't do it in the map driver. Do it in the partitioning layer - 
> that's already mucking around with the offsets anyway.

Yep. Only my problem here is, that I want some physically non-contiguous
blocks to form a single MTD partition. Is that possible with the
MTD partition API ?

Here are some details:

The board's flash map (SSV DIL/Net PC, btw.) looks like this:

    +--------------------------+ 0x00000000
    |                          |
    |    Bootstrap ROM code    |
    |       (15 blocks)        |
    +--------------------------+ 0x000f0000
    | System BIOS #1 (1 block) |
    +--------------------------+ 0x00100000
    |                          |
    | Free for use (e.g. JFFS) |
    |       (15 blocks)        |
    +--------------------------+ 0x001f0000
    | System BIOS #2 (1 block) |
    +--------------------------+ 0x00200000
    |                          |
    | Free for use (e.g. JFFS) |
    |       (32 blocks)        |
    +--------------------------+ 0x00400000

The space actually needed for the bootstrap ROM part may vary
considerably, depending on how the system is configured: it may contain an
etherboot image, in which case a single block would be more than enough,
but it may as well contain a linux kernel with an initial RAM disk, in
which case 15 blocks may not be enough. I would like to be able
to freely configure the size of the  bootstrap ROM part and assign
any space that is not used by it to the "Free for use" part.

My idea was to have the mapping driver implement something
like this:

    +--------------------------+ 0x00000000
    |                          |
    |    Bootstrap ROM code    |                -> /dev/mtd0
    |       (N blocks)         |
    +--------------------------+ configurable
    |                          |
    | Free for use (e.g. JFFS) |                -> /dev/mtd1
    |       (62 - N blocks)    |
    +--------------------------+ 0x003e0000
    | System BIOS #1 (1 block) |                -> /dev/mtd2
    +--------------------------+ 0x003f0000
    | System BIOS #2 (1 block) |                -> /dev/mtd3
    +--------------------------+ 0x00400000

(where /dev/mtd{2,3} would be disabled by default to keep
people from inadvertadly erasing their BIOS.)

Could I do this with the MTD partition layer ? If so, is there
an example I could look at for some hints ?

Thanks for any help

Rob

----------------------------------------------------------------
Robert Kaiser                          email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10

Re: Map driver usage

[David Woodhouse]

rob@sysgo.de said:
>  OK, so if I implement the copy_from call to break the large transfer
> into smaller ones if necessary, then I should be safe ?

Depending on the flash chips you're using, maybe. Sometimes you need to 
access the chip with the correct address.


>  Yep. Only my problem here is, that I want some physically
> non-contiguous blocks to form a single MTD partition. Is that possible
> with the MTD partition API ? 

The MTD partitioning code is (currently) just a set of wrappers round the 
real MTD functions, which add an offset and call the real chip driver's 
methods. It's fairly simple to do your own such wrapper rather than using 
the ones in mtdpart.c.

--
dwmw2

Re: Map driver usage

[Jörn Engel]

Hi!

> Yep. Only my problem here is, that I want some physically non-contiguous
> blocks to form a single MTD partition. Is that possible with the
> MTD partition API ?

You should have a look at Aleksander Sanochkin's code. He changed the
partitioning code to do exactly, what you need. But my guess is, that
this won't go into the development kernel for some month and might
never make it into 2.4.

He gave a quick overview in some mail to this list. Happy grepping.
:-)

Jörn

-- 
My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S )
"br.ret.spnt.few" - got back from getting beer, did not spend a lot.

Re: Map driver usage

[Robert Kaiser]

On Tue, 18 Dec 2001, David Woodhouse wrote:

> 
> rob@sysgo.de said:
> >  OK, so if I implement the copy_from call to break the large transfer
> > into smaller ones if necessary, then I should be safe ?
> 
> Depending on the flash chips you're using, maybe. Sometimes you need to 
> access the chip with the correct address.

That doesn't sound very reassuring ....

I definitely want the driver to go into the MTD CVS when it's done,
so I guess you wouldn't accept it if I did it this way, right ?

> >  Yep. Only my problem here is, that I want some physically
> > non-contiguous blocks to form a single MTD partition. Is that possible
> > with the MTD partition API ? 
> 
> The MTD partitioning code is (currently) just a set of wrappers round the 
> real MTD functions, which add an offset and call the real chip driver's 
> methods. It's fairly simple to do your own such wrapper rather than using 
> the ones in mtdpart.c.

OK, I'll look into that. It will probably mean to duplicate a bit of
stuff from mtdpart.c into my mapping driver, but I guess that's OK
since then I won't need to enable MTD partitioning support at all.
I'll also check Aleksander Sanochkin's code as Jörn suggested, maybe
I can keep my stuff compatible with it.

Thanks

Rob

----------------------------------------------------------------
Robert Kaiser                          email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10

Re: Map driver usage

[Robert Kaiser]

Hi David,

I just looked at Aleksander Sanochkin's code as Jörn suggested. It looks as if
it indeed implements just what I need for my mapping driver. (Actually it 
implements quite a few more things, I only need support for partitions that 
are not physically contiguous). I see that his code has not made it into the  
MTD CVS so far. Is that because you have objections ? I would really like to 
build on this stuff in my mapping driver.

Cheers

Rob

-- 
----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10

Re: Map driver usage

[David Woodhouse]

rob@sysgo.de said:
>  I just looked at Aleksander Sanochkin's code as Jörn suggested. It
> looks as if it indeed implements just what I need for my mapping
> driver. (Actually it  implements quite a few more things, I only need
> support for partitions that  are not physically contiguous). I see
> that his code has not made it into the   MTD CVS so far. Is that
> because you have objections ? I would really like to  build on this
> stuff in my mapping driver.

The plan, such as there was one, was to leave 2.4 as it is for a while, and 
to adopt Jörn's code in 2.5 - so I hadn't applied Aleksander's patch; I was 
hoping that its extra functionality would be merged into Jörn's version 
before the time comes to start paying attention to 2.5 and playing with the 
MTD code.

--
dwmw2

Two flash chips with a gap between them.

[Vladimir Doukhanine]

Hi,

I have two flash chips Am29lv320db90ei, which are physically mapped to
different memory areas and even have a memory gap between each other. I
would like to have one file system (JFFS2) for these two chips.
Is it possible to create only one MTD partition&JFFS2 on top of them?
Or the only way is to create MTD partitions & JFFS2 for each of the
chips? (Does it mean that in this case each JFFS2 going to have 4 blocks
overhead? I guess so.)

Thanks,
Vlad

Re: Two flash chips with a gap between them.

[David Woodhouse]

vdoukhan@wann.com said:
> I have two flash chips Am29lv320db90ei, which are physically mapped to
> different memory areas and even have a memory gap between each other.

Just create a 'map' driver for your board which makes them appear 
to be together. 

__u16 xxx_read16(struct map_info *map, unsigned long ofs)
{
	if (ofs < CHIP_SIZE)
		return __raw_readw(map->map_priv_1 + ofs);
	else
		return __raw_readw(map->map_priv_2 + ofs - CHIP_SIZE);
}

etc.
}

--
dwmw2