2008-08-22 02:00:55

by Bruce Leonard

[permalink] [raw]
Subject: [PATCH 0/2][MTD] Support for > 2GiB MTD devices

All,

Over the course of the last several months, I've been working on adding support to
the kernel for MTD devices that exceed 2GiB in size. In my particular case I
have a need for 8GiB of NAND flash that appears as a single device. I'm now
ready to submit my (first ever!) patch (please be kind :) ).

Design Details:
The problem - The size field of struct mtd_info is only 32-bits, which limits
the size of mtd devices to 2GiB (0x80000000).
The solution - The size of a device can be calculated buy multiplying the number
of erase blocks by the erase block size. I added a new field to struct
mtd_info to hold the number of erase blocks and an inline function to
determine the device size by returning mtd_info->size if it's non-zero
or returning (mtd_info->num_eraseblocks * mtd_info->erasesize).

A couple of comments. First and foremost, these patches don't completely change
the MTD layer. Due to my in-experience outside of what I was focused on
(NAND/UBI/UBIFS/MTDCHAR) I felt it was best if I restricted my changes to what I
knew. If the community feels I need to take these changes into the rest of the
MTD layer please advise. Secondly, there were changes that I needed to make in
mtd-utils, but I again only focused on the UBI sub-set. mtd-utils no longer builds
because of the changes (though the UBI tools still build). But I really do NOT
feel qualified to make changes to the rest of mtd-utils as they're tools I don't
use and don't understand and I don't want to accidentaly break something I don't
understand. The changes in mtd-utils are the same changes as in
.../include/linux/mtd/mtd.h and .../include/mtd/mtd-abi.h. If anyone has a
suggestion as to how I should handle mtd-utils I would appreciate it.

Thanks again to everyone who's answered my endless stupid questions.

Bruce


2008-08-22 08:35:43

by Frans Meulenbroeks

[permalink] [raw]
Subject: Re: [PATCH 0/2][MTD] Support for > 2GiB MTD devices

Suggest you also post this to [email protected]

2008/8/22 Bruce Leonard <[email protected]>:
> All,
>
> Over the course of the last several months, I've been working on adding support to
> the kernel for MTD devices that exceed 2GiB in size. In my particular case I
> have a need for 8GiB of NAND flash that appears as a single device. I'm now
> ready to submit my (first ever!) patch (please be kind :) ).
>
> Design Details:
> The problem - The size field of struct mtd_info is only 32-bits, which limits
> the size of mtd devices to 2GiB (0x80000000).
> The solution - The size of a device can be calculated buy multiplying the number
> of erase blocks by the erase block size. I added a new field to struct
> mtd_info to hold the number of erase blocks and an inline function to
> determine the device size by returning mtd_info->size if it's non-zero
> or returning (mtd_info->num_eraseblocks * mtd_info->erasesize).
>
> A couple of comments. First and foremost, these patches don't completely change
> the MTD layer. Due to my in-experience outside of what I was focused on
> (NAND/UBI/UBIFS/MTDCHAR) I felt it was best if I restricted my changes to what I
> knew. If the community feels I need to take these changes into the rest of the
> MTD layer please advise. Secondly, there were changes that I needed to make in
> mtd-utils, but I again only focused on the UBI sub-set. mtd-utils no longer builds
> because of the changes (though the UBI tools still build). But I really do NOT
> feel qualified to make changes to the rest of mtd-utils as they're tools I don't
> use and don't understand and I don't want to accidentaly break something I don't
> understand. The changes in mtd-utils are the same changes as in
> .../include/linux/mtd/mtd.h and .../include/mtd/mtd-abi.h. If anyone has a
> suggestion as to how I should handle mtd-utils I would appreciate it.
>
> Thanks again to everyone who's answered my endless stupid questions.
>
> Bruce
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>