[U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dirk Behme
dirk.behme at googlemail.com
Sat Jun 20 07:33:55 CEST 2009
Dear Stefan,
having this patch in mainline [1] now, I have some issues with it. I
use omap3_beagle_config (ARM). There was already a short discussion
with Wolfgang on IRC regarding this, he directed my to you ;) I
identified three topics, two minor and one major one:
Stefan Roese wrote:
> This patch brings the U-Boot MTD infrastructure in sync with the current
> Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size
> support and a resync of the mtdpart.c file which has seen multiple fixes
> meanwhile.
>
> Signed-off-by: Stefan Roese <sr at denx.de>
> Cc: Scott Wood <scottwood at freescale.com>
> Cc: Kyungmin Park <kmpark at infradead.org>
> ---
> common/cmd_onenand.c | 6 +-
> common/env_onenand.c | 2 +-
> drivers/mtd/cfi_mtd.c | 4 +-
> drivers/mtd/mtdpart.c | 488 +++++++++++++++++++-----------------------
> drivers/mtd/nand/nand_util.c | 11 +-
> include/linux/mtd/mtd.h | 29 ++-
> 6 files changed, 256 insertions(+), 284 deletions(-)
>
> diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
> index 5832ff8..e8f06d7 100644
> --- a/common/cmd_onenand.c
> +++ b/common/cmd_onenand.c
> @@ -19,6 +19,10 @@
>
> #include <asm/io.h>
>
> +#if !defined(CONFIG_SYS_64BIT_VSPRINTF)
> +#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
> +#endif
> +
1. This preprocessor warning is annoying. Why not enable it in all
configs where needed and then remove this warning here?
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 354e3a0..c884567 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -8,6 +8,7 @@
> #define __MTD_MTD_H__
>
> #include <linux/types.h>
> +#include <div64.h>
> #include <linux/mtd/mtd-abi.h>
>
> #define MTD_CHAR_MAJOR 90
> @@ -20,6 +21,8 @@
> #define MTD_ERASE_DONE 0x08
> #define MTD_ERASE_FAILED 0x10
>
> +#define MTD_FAIL_ADDR_UNKNOWN -1LL
> +
> /*
> * Enumeration for NAND/OneNAND flash chip state
> */
> @@ -37,13 +40,13 @@ enum {
> };
>
> /* If the erase fails, fail_addr might indicate exactly which block failed. If
> - fail_addr = 0xffffffff, the failure was not at the device level or was not
> + fail_addr = MTD_FAIL_ADDR_UNKNOWN, the failure was not at the device level or was not
> specific to any particular block. */
> struct erase_info {
> struct mtd_info *mtd;
> - u_int32_t addr;
> - u_int32_t len;
> - u_int32_t fail_addr;
> + uint64_t addr;
> + uint64_t len;
> + uint64_t fail_addr;
> u_long time;
> u_long retries;
> u_int dev;
> @@ -55,7 +58,7 @@ struct erase_info {
> };
>
> struct mtd_erase_region_info {
> - u_int32_t offset; /* At which this region starts, from the beginning of the MTD */
> + uint64_t offset; /* At which this region starts, from the beginning of the MTD */
> u_int32_t erasesize; /* For this region */
> u_int32_t numblocks; /* Number of blocks of erasesize in this region */
> unsigned long *lockmap; /* If keeping bitmap of locks */
> @@ -110,7 +113,7 @@ struct mtd_oob_ops {
> struct mtd_info {
> u_char type;
> u_int32_t flags;
> - u_int32_t size; /* Total size of the MTD */
> + uint64_t size; // Total size of the MTD
2. C++ style comment. Found by Wolfgang ;)
3. The major one: By the new 64bit variables, depending on tool chain,
there are now calls to libgcc introduced. Depending on tool chain,
this might work, or fail. As it does with one of my tool chains, which
worked totally fine until here. It was my understanding that U-Boot
shall not rely on libgcc, i.e. proper tool chain libraries.
Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs
"_lshrdi3", which comes from nand_base.o and nand_bbt.o. E.g. from
"len = mtd->size >> (this->bbt_erase_shift + 2);" from nand_bbt.c.
Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests
_lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc.
Looking into U-Boot's lib_arm/ directory, we have already some low
level math functions there to avoid libgcc. E.g. nand_bbt.c has
references to _ashrdi3, too, but this is resolved by lib_arm's version
what is fine.
I'd like that NAND code is modified that only math is used which
U-Boot provides and no libgcc is needed.
Best regards
Dirk
[1]
http://git.denx.de/?p=u-boot.git;a=commit;h=8d2effea23e938631126a7888008a0637e13b389
More information about the U-Boot
mailing list