mtd partitions limited to 4 GB?

mtd partitions limited to 4 GB?

[Mitch Bradley]

In drivers/mtd/mtdpart.c, struct mtd_part has  "u_int32_t offset", thus 
(apparently) limiting the partition start offset to 4 GiB.  Similarly, 
struct mtd_partition in include/linux/mtd/partititions.h has "u_int32_t 
size" and "u_int32_offset".

Now that NAND FLASH device sizes have exceeded that, this appears to be 
a significant limitation.

Is anyone in the mtd community already addressing this?

Fixing the core infrastructure might be as simple as using "loff_t" 
instead of "u_int32_t" for those fields.  However, all of the existing 
partition map parsers appear to have the same 32-bit limitation, so 
partitioning a >4GiB device will require a new or modified partition map 
format.

Re: mtd partitions limited to 4 GB?

[Josh Boyer]

On Mon, 16 Jun 2008 14:04:06 -1000
Mitch Bradley <wmb@firmworks.com> wrote:

> In drivers/mtd/mtdpart.c, struct mtd_part has  "u_int32_t offset", thus 
> (apparently) limiting the partition start offset to 4 GiB.  Similarly, 
> struct mtd_partition in include/linux/mtd/partititions.h has "u_int32_t 
> size" and "u_int32_offset".

This is not limited to partitions.  The entire MTD subsystem is limited
to 4 GiB sized devices.

> Now that NAND FLASH device sizes have exceeded that, this appears to be 
> a significant limitation.
> 
> Is anyone in the mtd community already addressing this?

There have been some that have offered to help in recent weeks.  A
brainstorming session of sorts happened on the list a couple of weeks
ago.  You might check there for what was decided.

> Fixing the core infrastructure might be as simple as using "loff_t" 
> instead of "u_int32_t" for those fields.  However, all of the existing 
> partition map parsers appear to have the same 32-bit limitation, so 
> partitioning a >4GiB device will require a new or modified partition map 
> format.

IIRC, one of the outcomes of the discussion was to introduce a new
interface so that chips are addressed in block+offset mappings.  This
will be better overall, but requires a bit more overhead in the initial
implementation.

josh

Re: mtd partitions limited to 4 GB?

[Charles Manning]

On Tuesday 17 June 2008 12:04:06 Mitch Bradley wrote:
> In drivers/mtd/mtdpart.c, struct mtd_part has  "u_int32_t offset", thus
> (apparently) limiting the partition start offset to 4 GiB.  Similarly,
> struct mtd_partition in include/linux/mtd/partititions.h has "u_int32_t
> size" and "u_int32_offset".

As Josh says it is not just an mtd_part issue, but the whole guts of mtd 
suffer from this. The actual mtd_xxx interface to the kernel is close enough 
for most purposes.

I am aware of people using Linux with >4GB of NAND for a long time now (well 
over a year). They did this by writing their own mtd drivers that just fit 
onto the existing interface.  Many people do that anyway because the nand 
core stuff is slow relative to a tailor made driver.

>
> Now that NAND FLASH device sizes have exceeded that, this appears to be
> a significant limitation.
>
> Is anyone in the mtd community already addressing this?
>
> Fixing the core infrastructure might be as simple as using "loff_t"
> instead of "u_int32_t" for those fields.  However, all of the existing
> partition map parsers appear to have the same 32-bit limitation, so
> partitioning a >4GiB device will require a new or modified partition map
> format.

It is more than just changing the 32 to 64 bit types.

Re: mtd partitions limited to 4 GB?

[Bruce_Leonard]

> > In drivers/mtd/mtdpart.c, struct mtd_part has  "u_int32_t offset", 
thus
> > (apparently) limiting the partition start offset to 4 GiB.  Similarly,
> > struct mtd_partition in include/linux/mtd/partititions.h has 
"u_int32_t
> > size" and "u_int32_offset".
> 
> As Josh says it is not just an mtd_part issue, but the whole guts of mtd 

> suffer from this. The actual mtd_xxx interface to the kernel is close 
enough 
> for most purposes.
> 

<snip>

> It is more than just changing the 32 to 64 bit types.
> 

It is indeed more than just a type change, as I'm discovering :\.  I'm 
currently working on a change that will allow greater than 2GiB size, but 
since my project isn't going to have any partitions in it, I wasn't aware 
of any limitations there.  As I go through my work I'll try and keep it in 
mind, but I'm mired in the NAND layer and make no promises.  I'm trying to 
do this in small increments rather than a wholesale change that introduces 
numerous bugs :).

Bruce