* [U-Boot] mtdparts fails with NAND >= 4GB
@ 2011-01-28 0:24 Aaron Williams
2011-01-28 1:06 ` Scott Wood
[not found] ` <201102092228.40033.Aaron.Williams@caviumnetworks.com>
0 siblings, 2 replies; 26+ messages in thread
From: Aaron Williams @ 2011-01-28 0:24 UTC (permalink / raw)
To: u-boot
Hi all,
It looks like the mtd partitioning code fails if the flash size exceeds a u32.
I am working with an 8GB flash chip on our board and was wondering if anyone
else has any experience with MTD with a chip this large?
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] mtdparts fails with NAND >= 4GB
2011-01-28 0:24 [U-Boot] mtdparts fails with NAND >= 4GB Aaron Williams
@ 2011-01-28 1:06 ` Scott Wood
2011-01-28 1:14 ` Aaron Williams
[not found] ` <201102092228.40033.Aaron.Williams@caviumnetworks.com>
1 sibling, 1 reply; 26+ messages in thread
From: Scott Wood @ 2011-01-28 1:06 UTC (permalink / raw)
To: u-boot
On Thu, 27 Jan 2011 16:24:31 -0800
Aaron Williams <Aaron.Williams@caviumnetworks.com> wrote:
> Hi all,
>
> It looks like the mtd partitioning code fails if the flash size exceeds a u32.
> I am working with an 8GB flash chip on our board and was wondering if anyone
> else has any experience with MTD with a chip this large?
There's been some effort to make the U-Boot NAND code work with large
devices, but it's not complete. Patches to take care of the rest of
the problem spots are welcome, especially if you have hardware to
test.
-Scott
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] mtdparts fails with NAND >= 4GB
2011-01-28 1:06 ` Scott Wood
@ 2011-01-28 1:14 ` Aaron Williams
2011-01-28 1:43 ` [U-Boot] [PATCH 1/1] NAND " Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-01-28 1:14 UTC (permalink / raw)
To: u-boot
I'll probably have something later today. I got it working with an earlier
version of u-boot though it hasn't been thoroughly tested.
-Aaron
On Thursday, January 27, 2011 05:06:09 pm Scott Wood wrote:
> On Thu, 27 Jan 2011 16:24:31 -0800
>
> Aaron Williams <Aaron.Williams@caviumnetworks.com> wrote:
> > Hi all,
> >
> > It looks like the mtd partitioning code fails if the flash size exceeds a
> > u32. I am working with an 8GB flash chip on our board and was wondering
> > if anyone else has any experience with MTD with a chip this large?
>
> There's been some effort to make the U-Boot NAND code work with large
> devices, but it's not complete. Patches to take care of the rest of
> the problem spots are welcome, especially if you have hardware to
> test.
>
> -Scott
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB
2011-01-28 1:14 ` Aaron Williams
@ 2011-01-28 1:43 ` Aaron Williams
2011-01-31 23:15 ` Aaron Williams
2011-01-31 23:28 ` Scott Wood
0 siblings, 2 replies; 26+ messages in thread
From: Aaron Williams @ 2011-01-28 1:43 UTC (permalink / raw)
To: u-boot
I have included my preliminary patch which seems to be working.
It has not been extensively tested yet. All of the changes were basically
making the sizes and offsets u64 instead of u32. When looking at the Linux
kernel code it looks like they also use u64. I was mistaken and our NAND
flash chip is 4GiB in size so I can't test with any larger chips.
-Aaron
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 5481c88..26d24b0 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -21,6 +21,11 @@
* $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
* Copyright 2002 SYSGO Real-Time Solutions GmbH
*
+ * (C) Copyright 2011
+ * Aaron Williams, Cavium Networks, Inc. <aaron.williams@caviumnetworks.com>
+ *
+ * Added support for partitions and flash greater than or equal to 4GiB.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -174,7 +179,7 @@ static int device_del(struct mtd_device *dev);
* @param retptr output pointer to next char after parse completes (output)
* @return resulting unsigned int
*/
-static unsigned long memsize_parse (const char *const ptr, const char **retptr)
+static u64 memsize_parse (const char *const ptr, const char **retptr)
{
unsigned long ret = simple_strtoul(ptr, (char **)retptr, 0);
@@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const ptr, const char **retptr)
* @param buf output buffer
* @param size size to be converted to string
*/
-static void memsize_format(char *buf, u32 size)
+static void memsize_format(char *buf, u64 size)
{
#define SIZE_GB ((u32)1024*1024*1024)
#define SIZE_MB ((u32)1024*1024)
#define SIZE_KB ((u32)1024)
if ((size % SIZE_GB) == 0)
- sprintf(buf, "%ug", size/SIZE_GB);
+ sprintf(buf, "%llug", size/SIZE_GB);
else if ((size % SIZE_MB) == 0)
- sprintf(buf, "%um", size/SIZE_MB);
+ sprintf(buf, "%llum", size/SIZE_MB);
else if (size % SIZE_KB == 0)
- sprintf(buf, "%uk", size/SIZE_KB);
+ sprintf(buf, "%lluk", size/SIZE_KB);
else
- sprintf(buf, "%u", size);
+ sprintf(buf, "%llu", size);
}
/**
@@ -325,7 +330,7 @@ static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
{
struct mtd_info *mtd = NULL;
int i, j;
- ulong start;
+ u64 start;
if (get_mtd_info(id->type, id->num, &mtd))
return 1;
@@ -337,7 +342,7 @@ static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
* Only one eraseregion (NAND, OneNAND or uniform NOR),
* checking for alignment is easy here
*/
- if ((unsigned long)part->offset % mtd->erasesize) {
+ if ((u64)part->offset % mtd->erasesize) {
printf("%s%d: partition (%s) start offset"
"alignment incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
@@ -412,7 +417,7 @@ static int part_validate(struct mtdids *id, struct part_info *part)
part->size = id->size - part->offset;
if (part->offset > id->size) {
- printf("%s: offset %08x beyond flash size %08x\n",
+ printf("%s: offset %08llx beyond flash size %08llx\n",
id->mtd_id, part->offset, id->size);
return 1;
}
@@ -595,8 +600,8 @@ static int part_add(struct mtd_device *dev, struct part_info *part)
static int part_parse(const char *const partdef, const char **ret, struct part_info **retpart)
{
struct part_info *part;
- unsigned long size;
- unsigned long offset;
+ u64 size;
+ u64 offset;
const char *name;
int name_len;
unsigned int mask_flags;
@@ -615,7 +620,7 @@ static int part_parse(const char *const partdef, const char **ret, struct part_i
} else {
size = memsize_parse(p, &p);
if (size < MIN_PART_SIZE) {
- printf("partition size too small (%lx)\n", size);
+ printf("partition size too small (%llx)\n", size);
return 1;
}
}
@@ -687,14 +692,14 @@ static int part_parse(const char *const partdef, const char **ret, struct part_i
part->auto_name = 0;
} else {
/* auto generated name in form of size at offset */
- sprintf(part->name, "0x%08lx at 0x%08lx", size, offset);
+ sprintf(part->name, "0x%08llx at 0x%08llx", size, offset);
part->auto_name = 1;
}
part->name[name_len - 1] = '\0';
INIT_LIST_HEAD(&part->link);
- debug("+ partition: name %-22s size 0x%08x offset 0x%08x mask flags %d\n",
+ debug("+ partition: name %-22s size 0x%08llx offset 0x%08llx mask flags %d\n",
part->name, part->size,
part->offset, part->mask_flags);
@@ -710,7 +715,7 @@ static int part_parse(const char *const partdef, const char **ret, struct part_i
* @param size a pointer to the size of the mtd device (output)
* @return 0 if device is valid, 1 otherwise
*/
-int mtd_device_validate(u8 type, u8 num, u32 *size)
+int mtd_device_validate(u8 type, u8 num, u64 *size)
{
struct mtd_info *mtd = NULL;
@@ -842,7 +847,7 @@ static int device_parse(const char *const mtd_dev, const char **ret, struct mtd_
LIST_HEAD(tmp_list);
struct list_head *entry, *n;
u16 num_parts;
- u32 offset;
+ u64 offset;
int err = 1;
debug("===device_parse===\n");
@@ -1077,15 +1082,16 @@ int mtd_id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 *dev_num)
* @param buflen buffer size
* @return 0 on success, 1 otherwise
*/
-static int generate_mtdparts(char *buf, u32 buflen)
+static int generate_mtdparts(char *buf, size_t buflen)
{
struct list_head *pentry, *dentry;
struct mtd_device *dev;
struct part_info *part, *prev_part;
char *p = buf;
char tmpbuf[32];
- u32 size, offset, len, part_cnt;
- u32 maxlen = buflen - 1;
+ u64 size, offset, len;
+ u32 part_cnt;
+ size_t maxlen = buflen - 1;
debug("--- generate_mtdparts ---\n");
@@ -1204,7 +1210,7 @@ cleanup:
* @param buflen buffer size
* @return 0 on success, 1 otherwise
*/
-static int generate_mtdparts_save(char *buf, u32 buflen)
+static int generate_mtdparts_save(char *buf, size_t buflen)
{
int ret;
@@ -1265,13 +1271,13 @@ static void print_partition_table(void)
printf(" #: name\t\tsize\t\tnet size\toffset\t\tmask_flags\n");
list_for_each(pentry, &dev->parts) {
- u32 net_size;
+ u64 net_size;
char *size_note;
part = list_entry(pentry, struct part_info, link);
net_size = net_part_size(mtd, part);
size_note = part->size == net_size ? " " : " (!)";
- printf("%2d: %-20s0x%08x\t0x%08x%s\t0x%08x\t%d\n",
+ printf("%2d: %-20s0x%08llx\t0x%08llx%s\t0x%08llx\t%d\n",
part_num, part->name, part->size,
net_size, size_note, part->offset,
part->mask_flags);
@@ -1283,7 +1289,7 @@ static void print_partition_table(void)
list_for_each(pentry, &dev->parts) {
part = list_entry(pentry, struct part_info, link);
- printf("%2d: %-20s0x%08x\t0x%08x\t%d\n",
+ printf("%2d: %-20s0x%08llx\t0x%08llx\t%d\n",
part_num, part->name, part->size,
part->offset, part->mask_flags);
#endif /* defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
@@ -1310,7 +1316,7 @@ static void list_partitions(void)
if (current_mtd_dev) {
part = mtd_part_info(current_mtd_dev, current_mtd_partnum);
if (part) {
- printf("\nactive partition: %s%d,%d - (%s) 0x%08x @ 0x%08x\n",
+ printf("\nactive partition: %s%d,%d - (%s) 0x%08llx @ 0x%08llx\n",
MTD_DEV_TYPE(current_mtd_dev->id->type),
current_mtd_dev->id->num, current_mtd_partnum,
part->name, part->size, part->offset);
@@ -1410,7 +1416,7 @@ static int delete_partition(const char *id)
if (find_dev_and_part(id, &dev, &pnum, &part) == 0) {
- debug("delete_partition: device = %s%d, partition %d = (%s) 0x%08x at 0x%08x\n",
+ debug("delete_partition: device = %s%d, partition %d = (%s) 0x%08llx at 0x%08llx\n",
MTD_DEV_TYPE(dev->id->type), dev->id->num, pnum,
part->name, part->size, part->offset);
@@ -1499,7 +1505,7 @@ static int spread_partitions(void)
part = list_entry(pentry, struct part_info, link);
debug("spread_partitions: device = %s%d, partition %d ="
- " (%s) 0x%08x at 0x%08x\n",
+ " (%s) 0x%08llx at 0x%08llx\n",
MTD_DEV_TYPE(dev->id->type), dev->id->num,
part_num, part->name, part->size,
part->offset);
@@ -1596,7 +1602,7 @@ static int parse_mtdids(const char *const ids)
struct list_head *entry, *n;
struct mtdids *id_tmp;
u8 type, num;
- u32 size;
+ u64 size;
int ret = 1;
debug("\n---parse_mtdids---\nmtdids = %s\n\n", ids);
@@ -1670,7 +1676,7 @@ static int parse_mtdids(const char *const ids)
id->mtd_id[mtd_id_len - 1] = '\0';
INIT_LIST_HEAD(&id->link);
- debug("+ id %s%d\t%16d bytes\t%s\n",
+ debug("+ id %s%d\t%16llu bytes\t%s\n",
MTD_DEV_TYPE(id->type), id->num,
id->size, id->mtd_id);
@@ -1999,7 +2005,7 @@ int do_mtdparts(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
if (!strcmp(&argv[1][3], ".spread")) {
spread_partition(mtd, p, &next_offset);
- debug("increased %s to %d bytes\n", p->name, p->size);
+ debug("increased %s to %llu bytes\n", p->name, p->size);
}
#endif
diff --git a/include/jffs2/load_kernel.h b/include/jffs2/load_kernel.h
index 906eb3d..dda096d 100644
--- a/include/jffs2/load_kernel.h
+++ b/include/jffs2/load_kernel.h
@@ -46,8 +46,8 @@ struct part_info {
struct list_head link;
char *name; /* partition name */
u8 auto_name; /* set to 1 for generated name */
- u32 size; /* total size of the partition */
- u32 offset; /* offset within device */
+ u64 size; /* total size of the partition */
+ u64 offset; /* offset within device */
void *jffs2_priv; /* used internaly by jffs2 */
u32 mask_flags; /* kernel MTD mask flags */
u32 sector_size; /* size of sector */
@@ -58,7 +58,7 @@ struct mtdids {
struct list_head link;
u8 type; /* device type */
u8 num; /* device number */
- u32 size; /* device size */
+ u64 size; /* device size */
char *mtd_id; /* linux kernel device id */
};
On Thursday, January 27, 2011 05:14:15 pm Aaron Williams wrote:
> I'll probably have something later today. I got it working with an earlier
> version of u-boot though it hasn't been thoroughly tested.
>
> -Aaron
>
> On Thursday, January 27, 2011 05:06:09 pm Scott Wood wrote:
> > On Thu, 27 Jan 2011 16:24:31 -0800
> >
> > Aaron Williams <Aaron.Williams@caviumnetworks.com> wrote:
> > > Hi all,
> > >
> > > It looks like the mtd partitioning code fails if the flash size exceeds
> > > a u32. I am working with an 8GB flash chip on our board and was
> > > wondering if anyone else has any experience with MTD with a chip this
> > > large?
> >
> > There's been some effort to make the U-Boot NAND code work with large
> > devices, but it's not complete. Patches to take care of the rest of
> > the problem spots are welcome, especially if you have hardware to
> > test.
> >
> > -Scott
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB
2011-01-28 1:43 ` [U-Boot] [PATCH 1/1] NAND " Aaron Williams
@ 2011-01-31 23:15 ` Aaron Williams
2011-01-31 23:28 ` Scott Wood
1 sibling, 0 replies; 26+ messages in thread
From: Aaron Williams @ 2011-01-31 23:15 UTC (permalink / raw)
To: u-boot
This patch seems to be working fine in my setup. Any comments?
-Aaron
On Thursday, January 27, 2011 05:43:10 pm Aaron Williams wrote:
> I have included my preliminary patch which seems to be working.
> It has not been extensively tested yet. All of the changes were basically
> making the sizes and offsets u64 instead of u32. When looking at the Linux
> kernel code it looks like they also use u64. I was mistaken and our NAND
> flash chip is 4GiB in size so I can't test with any larger chips.
>
> -Aaron
>
> diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
> index 5481c88..26d24b0 100644
> --- a/common/cmd_mtdparts.c
> +++ b/common/cmd_mtdparts.c
> @@ -21,6 +21,11 @@
> * $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
> * Copyright 2002 SYSGO Real-Time Solutions GmbH
> *
> + * (C) Copyright 2011
> + * Aaron Williams, Cavium Networks, Inc.
> <aaron.williams@caviumnetworks.com> + *
> + * Added support for partitions and flash greater than or equal to 4GiB.
> + *
> * See file CREDITS for list of people who contributed to this
> * project.
> *
> @@ -174,7 +179,7 @@ static int device_del(struct mtd_device *dev);
> * @param retptr output pointer to next char after parse completes
> (output) * @return resulting unsigned int
> */
> -static unsigned long memsize_parse (const char *const ptr, const char
> **retptr) +static u64 memsize_parse (const char *const ptr, const char
> **retptr) {
> unsigned long ret = simple_strtoul(ptr, (char **)retptr, 0);
>
> @@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const
> ptr, const char **retptr) * @param buf output buffer
> * @param size size to be converted to string
> */
> -static void memsize_format(char *buf, u32 size)
> +static void memsize_format(char *buf, u64 size)
> {
> #define SIZE_GB ((u32)1024*1024*1024)
> #define SIZE_MB ((u32)1024*1024)
> #define SIZE_KB ((u32)1024)
>
> if ((size % SIZE_GB) == 0)
> - sprintf(buf, "%ug", size/SIZE_GB);
> + sprintf(buf, "%llug", size/SIZE_GB);
> else if ((size % SIZE_MB) == 0)
> - sprintf(buf, "%um", size/SIZE_MB);
> + sprintf(buf, "%llum", size/SIZE_MB);
> else if (size % SIZE_KB == 0)
> - sprintf(buf, "%uk", size/SIZE_KB);
> + sprintf(buf, "%lluk", size/SIZE_KB);
> else
> - sprintf(buf, "%u", size);
> + sprintf(buf, "%llu", size);
> }
>
> /**
> @@ -325,7 +330,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part) {
> struct mtd_info *mtd = NULL;
> int i, j;
> - ulong start;
> + u64 start;
>
> if (get_mtd_info(id->type, id->num, &mtd))
> return 1;
> @@ -337,7 +342,7 @@ static int part_validate_eraseblock(struct mtdids *id,
> struct part_info *part) * Only one eraseregion (NAND, OneNAND or uniform
> NOR), * checking for alignment is easy here
> */
> - if ((unsigned long)part->offset % mtd->erasesize) {
> + if ((u64)part->offset % mtd->erasesize) {
> printf("%s%d: partition (%s) start offset"
> "alignment incorrect\n",
> MTD_DEV_TYPE(id->type), id->num,
> part->name); @@ -412,7 +417,7 @@ static int part_validate(struct mtdids
> *id, struct part_info *part) part->size = id->size - part->offset;
>
> if (part->offset > id->size) {
> - printf("%s: offset %08x beyond flash size %08x\n",
> + printf("%s: offset %08llx beyond flash size %08llx\n",
> id->mtd_id, part->offset, id->size);
> return 1;
> }
> @@ -595,8 +600,8 @@ static int part_add(struct mtd_device *dev, struct
> part_info *part) static int part_parse(const char *const partdef, const
> char **ret, struct part_info **retpart) {
> struct part_info *part;
> - unsigned long size;
> - unsigned long offset;
> + u64 size;
> + u64 offset;
> const char *name;
> int name_len;
> unsigned int mask_flags;
> @@ -615,7 +620,7 @@ static int part_parse(const char *const partdef, const
> char **ret, struct part_i } else {
> size = memsize_parse(p, &p);
> if (size < MIN_PART_SIZE) {
> - printf("partition size too small (%lx)\n", size);
> + printf("partition size too small (%llx)\n", size);
> return 1;
> }
> }
> @@ -687,14 +692,14 @@ static int part_parse(const char *const partdef,
> const char **ret, struct part_i part->auto_name = 0;
> } else {
> /* auto generated name in form of size at offset */
> - sprintf(part->name, "0x%08lx at 0x%08lx", size, offset);
> + sprintf(part->name, "0x%08llx at 0x%08llx", size, offset);
> part->auto_name = 1;
> }
>
> part->name[name_len - 1] = '\0';
> INIT_LIST_HEAD(&part->link);
>
> - debug("+ partition: name %-22s size 0x%08x offset 0x%08x mask flags
> %d\n", + debug("+ partition: name %-22s size 0x%08llx offset
> 0x%08llx mask flags %d\n", part->name, part->size,
> part->offset, part->mask_flags);
>
> @@ -710,7 +715,7 @@ static int part_parse(const char *const partdef, const
> char **ret, struct part_i * @param size a pointer to the size of the mtd
> device (output)
> * @return 0 if device is valid, 1 otherwise
> */
> -int mtd_device_validate(u8 type, u8 num, u32 *size)
> +int mtd_device_validate(u8 type, u8 num, u64 *size)
> {
> struct mtd_info *mtd = NULL;
>
> @@ -842,7 +847,7 @@ static int device_parse(const char *const mtd_dev,
> const char **ret, struct mtd_ LIST_HEAD(tmp_list);
> struct list_head *entry, *n;
> u16 num_parts;
> - u32 offset;
> + u64 offset;
> int err = 1;
>
> debug("===device_parse===\n");
> @@ -1077,15 +1082,16 @@ int mtd_id_parse(const char *id, const char
> **ret_id, u8 *dev_type, u8 *dev_num) * @param buflen buffer size
> * @return 0 on success, 1 otherwise
> */
> -static int generate_mtdparts(char *buf, u32 buflen)
> +static int generate_mtdparts(char *buf, size_t buflen)
> {
> struct list_head *pentry, *dentry;
> struct mtd_device *dev;
> struct part_info *part, *prev_part;
> char *p = buf;
> char tmpbuf[32];
> - u32 size, offset, len, part_cnt;
> - u32 maxlen = buflen - 1;
> + u64 size, offset, len;
> + u32 part_cnt;
> + size_t maxlen = buflen - 1;
>
> debug("--- generate_mtdparts ---\n");
>
> @@ -1204,7 +1210,7 @@ cleanup:
> * @param buflen buffer size
> * @return 0 on success, 1 otherwise
> */
> -static int generate_mtdparts_save(char *buf, u32 buflen)
> +static int generate_mtdparts_save(char *buf, size_t buflen)
> {
> int ret;
>
> @@ -1265,13 +1271,13 @@ static void print_partition_table(void)
> printf(" #: name\t\tsize\t\tnet
> size\toffset\t\tmask_flags\n");
>
> list_for_each(pentry, &dev->parts) {
> - u32 net_size;
> + u64 net_size;
> char *size_note;
>
> part = list_entry(pentry, struct part_info, link);
> net_size = net_part_size(mtd, part);
> size_note = part->size == net_size ? " " : " (!)";
> - printf("%2d: %-20s0x%08x\t0x%08x%s\t0x%08x\t%d\n",
> + printf("%2d:
> %-20s0x%08llx\t0x%08llx%s\t0x%08llx\t%d\n", part_num, part->name,
> part->size, net_size, size_note, part->offset, part->mask_flags);
> @@ -1283,7 +1289,7 @@ static void print_partition_table(void)
>
> list_for_each(pentry, &dev->parts) {
> part = list_entry(pentry, struct part_info, link);
> - printf("%2d: %-20s0x%08x\t0x%08x\t%d\n",
> + printf("%2d: %-20s0x%08llx\t0x%08llx\t%d\n",
> part_num, part->name, part->size,
> part->offset, part->mask_flags);
> #endif /* defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
> @@ -1310,7 +1316,7 @@ static void list_partitions(void)
> if (current_mtd_dev) {
> part = mtd_part_info(current_mtd_dev, current_mtd_partnum);
> if (part) {
> - printf("\nactive partition: %s%d,%d - (%s) 0x%08x @
> 0x%08x\n", + printf("\nactive partition: %s%d,%d -
> (%s) 0x%08llx @ 0x%08llx\n", MTD_DEV_TYPE(current_mtd_dev->id->type),
> current_mtd_dev->id->num, current_mtd_partnum, part->name, part->size,
> part->offset); @@ -1410,7 +1416,7 @@ static int delete_partition(const
> char *id)
>
>
> if (find_dev_and_part(id, &dev, &pnum, &part) == 0) {
>
> - debug("delete_partition: device = %s%d, partition %d = (%s)
> 0x%08x at 0x%08x\n", + debug("delete_partition: device = %s%d,
> partition %d = (%s) 0x%08llx at 0x%08llx\n", MTD_DEV_TYPE(dev->id->type),
> dev->id->num, pnum, part->name, part->size, part->offset);
>
> @@ -1499,7 +1505,7 @@ static int spread_partitions(void)
> part = list_entry(pentry, struct part_info, link);
>
> debug("spread_partitions: device = %s%d, partition
> %d =" - " (%s) 0x%08x at 0x%08x\n",
> + " (%s) 0x%08llx at 0x%08llx\n",
> MTD_DEV_TYPE(dev->id->type), dev->id->num,
> part_num, part->name, part->size,
> part->offset);
> @@ -1596,7 +1602,7 @@ static int parse_mtdids(const char *const ids)
> struct list_head *entry, *n;
> struct mtdids *id_tmp;
> u8 type, num;
> - u32 size;
> + u64 size;
> int ret = 1;
>
> debug("\n---parse_mtdids---\nmtdids = %s\n\n", ids);
> @@ -1670,7 +1676,7 @@ static int parse_mtdids(const char *const ids)
> id->mtd_id[mtd_id_len - 1] = '\0';
> INIT_LIST_HEAD(&id->link);
>
> - debug("+ id %s%d\t%16d bytes\t%s\n",
> + debug("+ id %s%d\t%16llu bytes\t%s\n",
> MTD_DEV_TYPE(id->type), id->num,
> id->size, id->mtd_id);
>
> @@ -1999,7 +2005,7 @@ int do_mtdparts(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
>
> if (!strcmp(&argv[1][3], ".spread")) {
> spread_partition(mtd, p, &next_offset);
> - debug("increased %s to %d bytes\n", p->name,
> p->size); + debug("increased %s to %llu bytes\n",
> p->name, p->size); }
> #endif
>
> diff --git a/include/jffs2/load_kernel.h b/include/jffs2/load_kernel.h
> index 906eb3d..dda096d 100644
> --- a/include/jffs2/load_kernel.h
> +++ b/include/jffs2/load_kernel.h
> @@ -46,8 +46,8 @@ struct part_info {
> struct list_head link;
> char *name; /* partition name */
> u8 auto_name; /* set to 1 for generated name */
> - u32 size; /* total size of the partition */
> - u32 offset; /* offset within device */
> + u64 size; /* total size of the partition */
> + u64 offset; /* offset within device */
> void *jffs2_priv; /* used internaly by jffs2 */
> u32 mask_flags; /* kernel MTD mask flags */
> u32 sector_size; /* size of sector */
> @@ -58,7 +58,7 @@ struct mtdids {
> struct list_head link;
> u8 type; /* device type */
> u8 num; /* device number */
> - u32 size; /* device size */
> + u64 size; /* device size */
> char *mtd_id; /* linux kernel device id */
> };
>
> On Thursday, January 27, 2011 05:14:15 pm Aaron Williams wrote:
> > I'll probably have something later today. I got it working with an
> > earlier version of u-boot though it hasn't been thoroughly tested.
> >
> > -Aaron
> >
> > On Thursday, January 27, 2011 05:06:09 pm Scott Wood wrote:
> > > On Thu, 27 Jan 2011 16:24:31 -0800
> > >
> > > Aaron Williams <Aaron.Williams@caviumnetworks.com> wrote:
> > > > Hi all,
> > > >
> > > > It looks like the mtd partitioning code fails if the flash size
> > > > exceeds a u32. I am working with an 8GB flash chip on our board and
> > > > was wondering if anyone else has any experience with MTD with a chip
> > > > this large?
> > >
> > > There's been some effort to make the U-Boot NAND code work with large
> > > devices, but it's not complete. Patches to take care of the rest of
> > > the problem spots are welcome, especially if you have hardware to
> > > test.
> > >
> > > -Scott
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB
2011-01-28 1:43 ` [U-Boot] [PATCH 1/1] NAND " Aaron Williams
2011-01-31 23:15 ` Aaron Williams
@ 2011-01-31 23:28 ` Scott Wood
2011-02-01 2:56 ` [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try Aaron Williams
1 sibling, 1 reply; 26+ messages in thread
From: Scott Wood @ 2011-01-31 23:28 UTC (permalink / raw)
To: u-boot
On Thu, 27 Jan 2011 17:43:10 -0800
Aaron Williams <Aaron.Williams@caviumnetworks.com> wrote:
> I have included my preliminary patch which seems to be working.
> It has not been extensively tested yet. All of the changes were basically
> making the sizes and offsets u64 instead of u32. When looking at the Linux
> kernel code it looks like they also use u64. I was mistaken and our NAND
> flash chip is 4GiB in size so I can't test with any larger chips.
>
> -Aaron
Patch is whitespace-mangled and does not apply.
Also needs sign-off and propper commit message. See
http://www.denx.de/wiki/U-Boot/Patches
and also the Developer's Certificate of Origin in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD
> @@ -207,20 +212,20 @@ static unsigned long memsize_parse (const char *const ptr, const char **retptr)
> * @param buf output buffer
> * @param size size to be converted to string
> */
> -static void memsize_format(char *buf, u32 size)
> +static void memsize_format(char *buf, u64 size)
> {
> #define SIZE_GB ((u32)1024*1024*1024)
> #define SIZE_MB ((u32)1024*1024)
> #define SIZE_KB ((u32)1024)
>
> if ((size % SIZE_GB) == 0)
> - sprintf(buf, "%ug", size/SIZE_GB);
> + sprintf(buf, "%llug", size/SIZE_GB);
> else if ((size % SIZE_MB) == 0)
> - sprintf(buf, "%um", size/SIZE_MB);
> + sprintf(buf, "%llum", size/SIZE_MB);
> else if (size % SIZE_KB == 0)
> - sprintf(buf, "%uk", size/SIZE_KB);
> + sprintf(buf, "%lluk", size/SIZE_KB);
> else
> - sprintf(buf, "%u", size);
> + sprintf(buf, "%llu", size);
> }
>
Need to make sure there are no boards with MTD enabled but not
CONFIG_SYS_64BIT_VSPRINTF.
-Scot
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-01-31 23:28 ` Scott Wood
@ 2011-02-01 2:56 ` Aaron Williams
2011-02-07 22:58 ` Scott Wood
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-01 2:56 UTC (permalink / raw)
To: u-boot
Trying again submitting the patch.
Adds support for NAND flash chips that are 4GiB and larger.
Signed-off-by: Aaron Williams <aaron.williams@caviumnetworks.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nand64.patch
Type: text/x-patch
Size: 10270 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110131/62db4f2e/attachment.bin
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-01 2:56 ` [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try Aaron Williams
@ 2011-02-07 22:58 ` Scott Wood
2011-02-08 15:38 ` Andrew Dyer
0 siblings, 1 reply; 26+ messages in thread
From: Scott Wood @ 2011-02-07 22:58 UTC (permalink / raw)
To: u-boot
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> Trying again submitting the patch.
>
> Adds support for NAND flash chips that are 4GiB and larger.
>
> Signed-off-by: Aaron Williams <aaron.williams@caviumnetworks.com>
>
> diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
> index 5481c88..26d24b0 100644
> --- a/common/cmd_mtdparts.c
> +++ b/common/cmd_mtdparts.c
> @@ -21,6 +21,11 @@
> * $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
> * Copyright 2002 SYSGO Real-Time Solutions GmbH
> *
> + * (C) Copyright 2011
> + * Aaron Williams, Cavium Networks, Inc. <aaron.williams@caviumnetworks.com>
> + *
> + * Added support for partitions and flash greater than or equal to 4GiB.
> + *
> * See file CREDITS for list of people who contributed to this
> * project.
> *
Changelogs go in git, not at the top of the file.
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index dd394a8..105eb3f 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1162,10 +1162,10 @@ void flash_print_info (flash_info_t * info)
> info->name,
> (info->portwidth << 3), (info->chipwidth << 3));
> if (info->size < 1024*1024)
> - printf (" Size: %ld kB in %d Sectors\n",
> + printf (" Size: %ld KiB in %d Sectors\n",
> info->size >> 10, info->sector_count);
> else
> - printf (" Size: %ld MB in %d Sectors\n",
> + printf (" Size: %ld MiB in %d Sectors\n",
> info->size >> 20, info->sector_count);
> printf (" ");
> switch (info->vendor) {
> @@ -1924,6 +1924,7 @@ ulong flash_get_size (phys_addr_t base, int banknum)
>
> /* Do manufacturer-specific fixups */
> switch (info->manufacturer_id) {
> + case 0x0000:
> case 0x0001:
> flash_fixup_amd(info, &qry);
> break;
This seems unrelated.
Otherwise, the patch looks good. Whose tree should it go through?
It's not really a NAND patch, though NAND is the reason for it.
-Scott
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-07 22:58 ` Scott Wood
@ 2011-02-08 15:38 ` Andrew Dyer
2011-02-08 23:11 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Dyer @ 2011-02-08 15:38 UTC (permalink / raw)
To: u-boot
On Mon, Feb 7, 2011 at 16:58, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
>> Trying again submitting the patch.
>>
>> ? ? ? ? ? ? ? /* Do manufacturer-specific fixups */
>> ? ? ? ? ? ? ? switch (info->manufacturer_id) {
>> + ? ? ? ? ? ? case 0x0000:
>> ? ? ? ? ? ? ? case 0x0001:
>> ? ? ? ? ? ? ? ? ? ? ? flash_fixup_amd(info, &qry);
>> ? ? ? ? ? ? ? ? ? ? ? break;
>
> This seems unrelated.
>
> Otherwise, the patch looks good. ?Whose tree should it go through?
> It's not really a NAND patch, though NAND is the reason for it.
NAK
This is not only unrelated (which the OP was told to fix on the
previous post of this patch), but wrong. The S29GL series chips don't
return 0x0000 for the manufacturer ID. AMD (later Spansion) have
always had mfg. ID 0x0001.
I have various boards with S29GL064, S29GL128N, and S29GL256P, and
they all return the correct value (0x0001) for the mfg. ID. I looked
up the latest datasheet and they have not changed that section.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-08 15:38 ` Andrew Dyer
@ 2011-02-08 23:11 ` Aaron Williams
2011-02-09 1:56 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-08 23:11 UTC (permalink / raw)
To: u-boot
On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> On Mon, Feb 7, 2011 at 16:58, Scott Wood <scottwood@freescale.com> wrote:
> > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> >> Trying again submitting the patch.
> >>
> >> /* Do manufacturer-specific fixups */
> >> switch (info->manufacturer_id) {
> >> + case 0x0000:
> >> case 0x0001:
> >> flash_fixup_amd(info, &qry);
> >> break;
> >
> > This seems unrelated.
> >
> > Otherwise, the patch looks good. Whose tree should it go through?
> > It's not really a NAND patch, though NAND is the reason for it.
>
> NAK
>
> This is not only unrelated (which the OP was told to fix on the
> previous post of this patch), but wrong. The S29GL series chips don't
> return 0x0000 for the manufacturer ID. AMD (later Spansion) have
> always had mfg. ID 0x0001.
>
> I have various boards with S29GL064, S29GL128N, and S29GL256P, and
> they all return the correct value (0x0001) for the mfg. ID. I looked
> up the latest datasheet and they have not changed that section.
I always get 0x0000 for the mfg ID and cannot explain it. The full part number
is S29GL064N90TF103 010FF058. That is why it was added. Without it, the proper
fixup doesn't happen with this chip.
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-08 23:11 ` Aaron Williams
@ 2011-02-09 1:56 ` Aaron Williams
0 siblings, 0 replies; 26+ messages in thread
From: Aaron Williams @ 2011-02-09 1:56 UTC (permalink / raw)
To: u-boot
On Tuesday, February 08, 2011 03:11:54 pm Aaron Williams wrote:
> On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> > On Mon, Feb 7, 2011 at 16:58, Scott Wood <scottwood@freescale.com> wrote:
> > > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> > >> Trying again submitting the patch.
> > >>
> > >> /* Do manufacturer-specific fixups */
> > >> switch (info->manufacturer_id) {
> > >>
> > >> + case 0x0000:
> > >> case 0x0001:
> > >> flash_fixup_amd(info, &qry);
> > >> break;
> > >
> > > This seems unrelated.
> > >
> > > Otherwise, the patch looks good. Whose tree should it go through?
> > > It's not really a NAND patch, though NAND is the reason for it.
> >
> > NAK
> >
> > This is not only unrelated (which the OP was told to fix on the
> > previous post of this patch), but wrong. The S29GL series chips don't
> > return 0x0000 for the manufacturer ID. AMD (later Spansion) have
> > always had mfg. ID 0x0001.
> >
> > I have various boards with S29GL064, S29GL128N, and S29GL256P, and
> > they all return the correct value (0x0001) for the mfg. ID. I looked
> > up the latest datasheet and they have not changed that section.
>
> I always get 0x0000 for the mfg ID and cannot explain it. The full part
> number is S29GL064N90TF103 010FF058. That is why it was added. Without it,
> the proper fixup doesn't happen with this chip.
>
> -Aaron
Note that in our case the port width is 16-bits and the chip width is 8 bits.
I added some printf statements for all read accesses to help.
Here's the output when I enable debugging:
flash detect cfi
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
fwc addr 1f400000 cmd ff ffff 16bit x 8 bit
fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr 1f400020 flash_read16: address 1f400020, value 0x5151
is= 5151 5151
flash_read16: address 1f400020, value 0x5151
is= cmd 52(R) addr 1f400022 flash_read16: address 1f400022, value 0x5252
is= 5252 5252
flash_read16: address 1f400022, value 0x5252
is= cmd 59(Y) addr 1f400024 flash_read16: address 1f400024, value 0x5959
is= 5959 5959
flash_read16: address 1f400024, value 0x5959
flash_read8: address 1f400021, value 0x51
flash_read8: address 1f400023, value 0x52
flash_read8: address 1f400025, value 0x59
flash_read8: address 1f400027, value 0x2
flash_read8: address 1f400029, value 0x0
flash_read8: address 1f40002b, value 0x40
flash_read8: address 1f40002d, value 0x0
flash_read8: address 1f40002f, value 0x0
flash_read8: address 1f400031, value 0x0
flash_read8: address 1f400033, value 0x0
flash_read8: address 1f400035, value 0x0
flash_read8: address 1f400037, value 0x27
flash_read8: address 1f400039, value 0x36
flash_read8: address 1f40003b, value 0x0
flash_read8: address 1f40003d, value 0x0
flash_read8: address 1f40003f, value 0x7
flash_read8: address 1f400041, value 0x7
flash_read8: address 1f400043, value 0xa
flash_read8: address 1f400045, value 0x0
flash_read8: address 1f400047, value 0x3
flash_read8: address 1f400049, value 0x5
flash_read8: address 1f40004b, value 0x4
flash_read8: address 1f40004d, value 0x0
flash_read8: address 1f40004f, value 0x17
flash_read8: address 1f400051, value 0x2
flash_read8: address 1f400053, value 0x0
flash_read8: address 1f400055, value 0x5
flash_read8: address 1f400057, value 0x0
flash_read8: address 1f400059, value 0x2
flash_read8: address 1f40005b, value 0x7
flash_read8: address 1f40005d, value 0x0
flash_read8: address 1f40005f, value 0x20
flash_read8: address 1f400061, value 0x0
flash_read8: address 1f400063, value 0x7e
flash_read8: address 1f400065, value 0x0
flash_read8: address 1f400067, value 0x0
flash_read8: address 1f400069, value 0x1
flash_read8: address 1f40006b, value 0x0
flash_read8: address 1f40006d, value 0x0
flash_read8: address 1f40006f, value 0x0
flash_read8: address 1f400071, value 0x0
flash_read8: address 1f400073, value 0x0
flash_read8: address 1f400075, value 0x0
flash_read8: address 1f400077, value 0x0
flash_read8: address 1f400079, value 0x0
device interface is 2
found port 2 chip 1 port 16 bits chip 8 bits
flash_read8: address 1f400087, value 0x31
flash_read8: address 1f400089, value 0x33
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 07 QRY.. at .....'6...
10 : 07 0a 00 03 05 04 00 17 02 00 05 00 02 07 00 20 ...............
20 : 00 7e 00 00 01 00 00 00 00 00 00 00 00 00 00 10 .~..............
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_read8: address 1f400001, value 0x0
flash_read8: address 1f400003, value 0x3f
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit
flash_read8: address 1f40009f, value 0x3
manufacturer is 2
manufacturer id is 0x0
device id is 0x3f
device id2 is 0x0
cfi version is 0x3133
size_ratio 1 port 16 bits chip 8 bits
found 2 erase regions
erase region 0: 0x0100007e
erase_region_count = 127 erase_region_size = 65536
erase region 1: 0x00200007
erase_region_count = 8 erase_region_size = 8192
fwc addr 1f400000 cmd f0 f0 8bit x 8 bit
fwc addr 1fbfe000 cmd 70 70 8bit x 8 bit
flash_read8: address 1fbfe000, value 0xe5
flash_read8: address 1fbfe000, value 0xe5
flash_is_busy: 0
Flash: 8 MiB
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
[not found] ` <AANLkTi=fsZXQjRFaZcB535n853WUxEicFqyzquWzMX41@mail.gmail.com>
@ 2011-02-11 3:24 ` Aaron Williams
2011-02-11 3:27 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-11 3:24 UTC (permalink / raw)
To: u-boot
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> On Thu, Feb 10, 2011 at 00:28, Aaron Williams
>
> <Aaron.Williams@caviumnetworks.com> wrote:
> >> I would suggest to make sure any caching/prefetching stuff is off,
> >> hardware is doing one flash bus access per CPU read/write.
> >>
> >> In cmdset_amd_read_jedec_ids() after this line:
> >>
> >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> >>
> >> add something like
> >>
> >> printf("test manf id word = %04x\n", *(volatile uint16_t *)0x1f400000);
> >> printf("test device id word = %04x\n", *(volatile uint16_t
> >> *)0x1f400002); printf("test device id word = %04x\n", *(volatile
> >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> >> *(volatile uint16_t *)0x1f40001e);
> >>
> >> and see what you get.
> >
> > fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> > flash_write16: address: 1f400000, value: 0xf0f0
> > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > flash_write16: address: 1f401554, value: 0xaaaa
> > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > flash_write16: address: 1f400aaa, value: 0x5555
> > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > flash_write16: address: 1f401554, value: 0x9090
> > flash_read8: address: 1f400001, value: 0x0
> > test manf id word = 1000
> > test device id word = 013f
> > test device id word = da6c
> > test device id word = 2926
>
> looks like garbage :-( What's in the flash at those addresses? Maybe
> something is happening to mess up the unlock sequence and you're
> reading the memory data instead of the device codes.
>
> It's odd that earlier in the sequence when the CFI query data is read
> the byte data is mirrored across both bytes of the response, here the
> two bytes are different.
I received an email back from Spansion about this problem. They suggested that
instead of the following:
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
flash_write16: Wrote 0xaaaa to address 1f401554
funlock writing 0xaa to address 0x555
fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
flash_write16: Wrote 0x5555 to address 1f400aaa
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_write16: Wrote 0x9090 to address 1f401554
to instead do the following:
write 0xAA to 0x1F400AAA
write 0x55 to 0x1F400555
write 0x90 to 0x1F400AAA
read 0x1F400001 returns 0x01
read 0x1F400003 returns 0x7e
This looks correct.
I found two things I need to do to work around the problem. First, in
flash_write_cmd I use info->chipwidth instead of info->portwidth for the write
commands, and second, in __flash_detect_cfi I don't modify the address in
compatibility mode. This works. If either of those steps are left out then
reading the manufacturer ID fails.
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-11 3:24 ` Aaron Williams
@ 2011-02-11 3:27 ` Aaron Williams
2011-02-11 4:05 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-11 3:27 UTC (permalink / raw)
To: u-boot
On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> >
> > <Aaron.Williams@caviumnetworks.com> wrote:
> > >> I would suggest to make sure any caching/prefetching stuff is off,
> > >> hardware is doing one flash bus access per CPU read/write.
> > >>
> > >> In cmdset_amd_read_jedec_ids() after this line:
> > >>
> > >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> > >>
> > >> add something like
> > >>
> > >> printf("test manf id word = %04x\n", *(volatile uint16_t
> > >> *)0x1f400000); printf("test device id word = %04x\n", *(volatile
> > >> uint16_t
> > >> *)0x1f400002); printf("test device id word = %04x\n", *(volatile
> > >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> > >> *(volatile uint16_t *)0x1f40001e);
> > >>
> > >> and see what you get.
> > >
> > > fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> > > flash_write16: address: 1f400000, value: 0xf0f0
> > > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > > flash_write16: address: 1f401554, value: 0xaaaa
> > > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > > flash_write16: address: 1f400aaa, value: 0x5555
> > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > flash_write16: address: 1f401554, value: 0x9090
> > > flash_read8: address: 1f400001, value: 0x0
> > > test manf id word = 1000
> > > test device id word = 013f
> > > test device id word = da6c
> > > test device id word = 2926
> >
> > looks like garbage :-( What's in the flash at those addresses? Maybe
> > something is happening to mess up the unlock sequence and you're
> > reading the memory data instead of the device codes.
> >
> > It's odd that earlier in the sequence when the CFI query data is read
> > the byte data is mirrored across both bytes of the response, here the
> > two bytes are different.
>
> I received an email back from Spansion about this problem. They suggested
> that instead of the following:
>
> fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> flash_write16: Wrote 0xaaaa to address 1f401554
> funlock writing 0xaa to address 0x555
> fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> flash_write16: Wrote 0x5555 to address 1f400aaa
> fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> flash_write16: Wrote 0x9090 to address 1f401554
>
> to instead do the following:
> write 0xAA to 0x1F400AAA
> write 0x55 to 0x1F400555
> write 0x90 to 0x1F400AAA
>
> read 0x1F400001 returns 0x01
> read 0x1F400003 returns 0x7e
>
> This looks correct.
>
> I found two things I need to do to work around the problem. First, in
> flash_write_cmd I use info->chipwidth instead of info->portwidth for the
> write commands, and second, in __flash_detect_cfi I don't modify the
> address in compatibility mode. This works. If either of those steps are
> left out then reading the manufacturer ID fails.
>
> -Aaron
It looks like I spoke too soon. It fixes the manufacturer problem but
everything else is now broken.
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-11 3:27 ` Aaron Williams
@ 2011-02-11 4:05 ` Aaron Williams
2011-02-12 0:15 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-11 4:05 UTC (permalink / raw)
To: u-boot
On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> > >
> > > <Aaron.Williams@caviumnetworks.com> wrote:
> > > >> I would suggest to make sure any caching/prefetching stuff is off,
> > > >> hardware is doing one flash bus access per CPU read/write.
> > > >>
> > > >> In cmdset_amd_read_jedec_ids() after this line:
> > > >>
> > > >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> > > >>
> > > >> add something like
> > > >>
> > > >> printf("test manf id word = %04x\n", *(volatile uint16_t
> > > >> *)0x1f400000); printf("test device id word = %04x\n", *(volatile
> > > >> uint16_t
> > > >> *)0x1f400002); printf("test device id word = %04x\n", *(volatile
> > > >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> > > >> *(volatile uint16_t *)0x1f40001e);
> > > >>
> > > >> and see what you get.
> > > >
> > > > fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> > > > flash_write16: address: 1f400000, value: 0xf0f0
> > > > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > > > flash_write16: address: 1f401554, value: 0xaaaa
> > > > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > > > flash_write16: address: 1f400aaa, value: 0x5555
> > > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > > flash_write16: address: 1f401554, value: 0x9090
> > > > flash_read8: address: 1f400001, value: 0x0
> > > > test manf id word = 1000
> > > > test device id word = 013f
> > > > test device id word = da6c
> > > > test device id word = 2926
> > >
> > > looks like garbage :-( What's in the flash at those addresses? Maybe
> > > something is happening to mess up the unlock sequence and you're
> > > reading the memory data instead of the device codes.
> > >
> > > It's odd that earlier in the sequence when the CFI query data is read
> > > the byte data is mirrored across both bytes of the response, here the
> > > two bytes are different.
> >
> > I received an email back from Spansion about this problem. They suggested
> > that instead of the following:
> >
> > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > flash_write16: Wrote 0xaaaa to address 1f401554
> > funlock writing 0xaa to address 0x555
> > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > flash_write16: Wrote 0x5555 to address 1f400aaa
> > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > flash_write16: Wrote 0x9090 to address 1f401554
> >
> > to instead do the following:
> > write 0xAA to 0x1F400AAA
> > write 0x55 to 0x1F400555
> > write 0x90 to 0x1F400AAA
> >
> > read 0x1F400001 returns 0x01
> > read 0x1F400003 returns 0x7e
> >
> > This looks correct.
> >
> > I found two things I need to do to work around the problem. First, in
> > flash_write_cmd I use info->chipwidth instead of info->portwidth for the
> > write commands, and second, in __flash_detect_cfi I don't modify the
> > address in compatibility mode. This works. If either of those steps are
> > left out then reading the manufacturer ID fails.
> >
> > -Aaron
>
> It looks like I spoke too soon. It fixes the manufacturer problem but
> everything else is now broken.
>
> -Aaron
It works now, but I had to hard-code cmdset_amd_read_jedec_ids for some
reason.
static void cmdset_amd_read_jedec_ids(flash_info_t *info)
{
ushort bankId = 0;
uchar manuId;
debug("In %s\n", __func__);
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_write_cmd(info, 0, 0x555, AMD_CMD_UNLOCK_START);
flash_write_cmd(info, 0, 0x2AA, AMD_CMD_UNLOCK_ACK);
flash_write_cmd(info, 0, 0x555, FLASH_CMD_READ_ID);
/*flash_unlock_seq(info, 0); */
/*flash_write_cmd(info, 0, info->addr_unlock1, FLASH_CMD_READ_ID);*/
With this, everything works with my mod to flash_write_cmd to use chipwidth
instead of portwidth.
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-11 4:05 ` Aaron Williams
@ 2011-02-12 0:15 ` Aaron Williams
2011-02-12 6:25 ` Albert ARIBAUD
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 0:15 UTC (permalink / raw)
To: u-boot
I think I found the problem. The cfi code does not work properly in x8 mode.
In x8 mode, according to the datasheet, the addresses should be doubled for
all of the commands. Additionally, according to my correspondence with
Spansion, there needs to be at least a 500ns delay after a reset command.
The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when
it is actually 8-bits. Currently things just happen to work because the bus is
being incorrectly detected as 16-bits,
The 16-bit bus detection, however, breaks in x8 mode when it issues the
commands for the manufacturer ID.
In this case, the following takes place:
In cmdset_amd_read_jedec_ids
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
flash_write16: Wrote 0xf0f0 to address 1f400000
funlock writing 0xaa to address 0xaaa
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
flash_write16: Wrote 0xaaaa to address 1f401554
funlock writing 0xaa to address 0x555
fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
flash_write16: Wrote 0x5555 to address 1f400aaa
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_write16: Wrote 0x9090 to address 1f401554
flash_read8: Read 0x0 from address 1f400001
flash_read8: Read 0x3f from address 1f400003
This does not work.
If the proper sequence is written, then it works fine.
The proper sequence, according to the datasheet, is to do the following:
write 0xf0 to address 0x0000
write 0xaa to address 0xaaa
write 0x55 to address 0x555
write 0x90 to address 0xaaa
read address 0 (returns 1 as expected)
read address 2 (returns 0x7e as expected)
...
So the cfi code is broken in the x8 case.
-Aaron Williams
On Thursday, February 10, 2011 08:05:37 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > > > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> > > >
> > > > <Aaron.Williams@caviumnetworks.com> wrote:
> > > > >> I would suggest to make sure any caching/prefetching stuff is off,
> > > > >> hardware is doing one flash bus access per CPU read/write.
> > > > >>
> > > > >> In cmdset_amd_read_jedec_ids() after this line:
> > > > >>
> > > > >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> > > > >>
> > > > >> add something like
> > > > >>
> > > > >> printf("test manf id word = %04x\n", *(volatile uint16_t
> > > > >> *)0x1f400000); printf("test device id word = %04x\n", *(volatile
> > > > >> uint16_t
> > > > >> *)0x1f400002); printf("test device id word = %04x\n", *(volatile
> > > > >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> > > > >> *(volatile uint16_t *)0x1f40001e);
> > > > >>
> > > > >> and see what you get.
> > > > >
> > > > > fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> > > > > flash_write16: address: 1f400000, value: 0xf0f0
> > > > > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > > > > flash_write16: address: 1f401554, value: 0xaaaa
> > > > > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > > > > flash_write16: address: 1f400aaa, value: 0x5555
> > > > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > > > flash_write16: address: 1f401554, value: 0x9090
> > > > > flash_read8: address: 1f400001, value: 0x0
> > > > > test manf id word = 1000
> > > > > test device id word = 013f
> > > > > test device id word = da6c
> > > > > test device id word = 2926
> > > >
> > > > looks like garbage :-( What's in the flash at those addresses?
> > > > Maybe something is happening to mess up the unlock sequence and
> > > > you're reading the memory data instead of the device codes.
> > > >
> > > > It's odd that earlier in the sequence when the CFI query data is read
> > > > the byte data is mirrored across both bytes of the response, here the
> > > > two bytes are different.
> > >
> > > I received an email back from Spansion about this problem. They
> > > suggested that instead of the following:
> > >
> > > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > > flash_write16: Wrote 0xaaaa to address 1f401554
> > > funlock writing 0xaa to address 0x555
> > > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > > flash_write16: Wrote 0x5555 to address 1f400aaa
> > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > flash_write16: Wrote 0x9090 to address 1f401554
> > >
> > > to instead do the following:
> > > write 0xAA to 0x1F400AAA
> > > write 0x55 to 0x1F400555
> > > write 0x90 to 0x1F400AAA
> > >
> > > read 0x1F400001 returns 0x01
> > > read 0x1F400003 returns 0x7e
> > >
> > > This looks correct.
> > >
> > > I found two things I need to do to work around the problem. First, in
> > > flash_write_cmd I use info->chipwidth instead of info->portwidth for
> > > the write commands, and second, in __flash_detect_cfi I don't modify
> > > the address in compatibility mode. This works. If either of those
> > > steps are left out then reading the manufacturer ID fails.
> > >
> > > -Aaron
> >
> > It looks like I spoke too soon. It fixes the manufacturer problem but
> > everything else is now broken.
> >
> > -Aaron
>
> It works now, but I had to hard-code cmdset_amd_read_jedec_ids for some
> reason.
>
> static void cmdset_amd_read_jedec_ids(flash_info_t *info)
> {
> ushort bankId = 0;
> uchar manuId;
>
> debug("In %s\n", __func__);
> flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
> flash_write_cmd(info, 0, 0x555, AMD_CMD_UNLOCK_START);
> flash_write_cmd(info, 0, 0x2AA, AMD_CMD_UNLOCK_ACK);
> flash_write_cmd(info, 0, 0x555, FLASH_CMD_READ_ID);
> /*flash_unlock_seq(info, 0); */
> /*flash_write_cmd(info, 0, info->addr_unlock1, FLASH_CMD_READ_ID);*/
>
> With this, everything works with my mod to flash_write_cmd to use chipwidth
> instead of portwidth.
>
> -Aaron
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 0:15 ` Aaron Williams
@ 2011-02-12 6:25 ` Albert ARIBAUD
2011-02-12 6:42 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Albert ARIBAUD @ 2011-02-12 6:25 UTC (permalink / raw)
To: u-boot
Le 12/02/2011 01:15, Aaron Williams a ?crit :
> I think I found the problem. The cfi code does not work properly in x8 mode.
>
> In x8 mode, according to the datasheet, the addresses should be doubled for
> all of the commands. Additionally, according to my correspondence with
> Spansion, there needs to be at least a 500ns delay after a reset command.
>
> The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when
> it is actually 8-bits. Currently things just happen to work because the bus is
> being incorrectly detected as 16-bits,
>
> The 16-bit bus detection, however, breaks in x8 mode when it issues the
> commands for the manufacturer ID.
>
> In this case, the following takes place:
>
> In cmdset_amd_read_jedec_ids
> fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> flash_write16: Wrote 0xf0f0 to address 1f400000
> funlock writing 0xaa to address 0xaaa
> fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> flash_write16: Wrote 0xaaaa to address 1f401554
> funlock writing 0xaa to address 0x555
> fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> flash_write16: Wrote 0x5555 to address 1f400aaa
> fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> flash_write16: Wrote 0x9090 to address 1f401554
> flash_read8: Read 0x0 from address 1f400001
> flash_read8: Read 0x3f from address 1f400003
>
> This does not work.
>
> If the proper sequence is written, then it works fine.
>
> The proper sequence, according to the datasheet, is to do the following:
>
> write 0xf0 to address 0x0000
> write 0xaa to address 0xaaa
> write 0x55 to address 0x555
> write 0x90 to address 0xaaa
> read address 0 (returns 1 as expected)
> read address 2 (returns 0x7e as expected)
> ...
>
> So the cfi code is broken in the x8 case.
Hmm... It would be surprising that the x8 CFI code be broken -- not
impossible, mind you -- because it was intensively used with a variety
of chips, and thus extensively checked for brokenness.
What *might* be at stake is the result of the width detection, because
many reputedly CFI compliant Flash devices are actually not compliant,
especially among the dual-width, x8/x16, ones. On my ED Mini V2, there
is a Macronix x8/x16 part which presents its CFI QRY response as a pure
x16 even though it is a x8/x16, thus tricking the width detection
mechanism into taking the wrong decision; I had to resort to using the
LEGACY feature of manually defining the widths.
Did you check the Flash part against the CFI specs, including the QRY
location and layout?
Can you boot into a RAM-baed u-boot and use its memory write and read
commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 6:25 ` Albert ARIBAUD
@ 2011-02-12 6:42 ` Aaron Williams
2011-02-12 7:01 ` Albert ARIBAUD
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 6:42 UTC (permalink / raw)
To: u-boot
On Friday, February 11, 2011 10:25:46 pm Albert ARIBAUD wrote:
> Le 12/02/2011 01:15, Aaron Williams a ?crit :
> > I think I found the problem. The cfi code does not work properly in x8
> > mode.
> >
> > In x8 mode, according to the datasheet, the addresses should be doubled
> > for all of the commands. Additionally, according to my correspondence
> > with Spansion, there needs to be at least a 500ns delay after a reset
> > command.
> >
> > The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT
> > when it is actually 8-bits. Currently things just happen to work because
> > the bus is being incorrectly detected as 16-bits,
> >
> > The 16-bit bus detection, however, breaks in x8 mode when it issues the
> > commands for the manufacturer ID.
> >
> > In this case, the following takes place:
> >
> > In cmdset_amd_read_jedec_ids
> > fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> > flash_write16: Wrote 0xf0f0 to address 1f400000
> > funlock writing 0xaa to address 0xaaa
> > fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> > flash_write16: Wrote 0xaaaa to address 1f401554
> > funlock writing 0xaa to address 0x555
> > fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> > flash_write16: Wrote 0x5555 to address 1f400aaa
> > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > flash_write16: Wrote 0x9090 to address 1f401554
> > flash_read8: Read 0x0 from address 1f400001
> > flash_read8: Read 0x3f from address 1f400003
> >
> > This does not work.
> >
> > If the proper sequence is written, then it works fine.
> >
> > The proper sequence, according to the datasheet, is to do the following:
> >
> > write 0xf0 to address 0x0000
> > write 0xaa to address 0xaaa
> > write 0x55 to address 0x555
> > write 0x90 to address 0xaaa
> > read address 0 (returns 1 as expected)
> > read address 2 (returns 0x7e as expected)
> > ...
> >
> > So the cfi code is broken in the x8 case.
>
> Hmm... It would be surprising that the x8 CFI code be broken -- not
> impossible, mind you -- because it was intensively used with a variety
> of chips, and thus extensively checked for brokenness.
>
> What *might* be at stake is the result of the width detection, because
> many reputedly CFI compliant Flash devices are actually not compliant,
> especially among the dual-width, x8/x16, ones. On my ED Mini V2, there
> is a Macronix x8/x16 part which presents its CFI QRY response as a pure
> x16 even though it is a x8/x16, thus tricking the width detection
> mechanism into taking the wrong decision; I had to resort to using the
> LEGACY feature of manually defining the widths.
>
> Did you check the Flash part against the CFI specs, including the QRY
> location and layout?
>
> Can you boot into a RAM-baed u-boot and use its memory write and read
> commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device?
>
> Amicalement,
I've placed the results of the scan below.
The problem is that in 8-bit mode the code that scans the CFI does not follow
the specification.
In the specification to read the CFI data you write 0x98 to address 0xAA, not
address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which
in this case is wrong and won't work. When it tries 16-bit mode then it writes
to address 0xAA which causes it to work.
-Aaron
Here's the results of the scan:
flash detect cfi
fwc addr 1f400000 cmd f0 f0 8bit x 8 bit
flash_write8: Wrote 0xf0 to address 1f400000
fwc addr 1f400055 cmd 98 98 8bit x 8 bit
flash_write8: Wrote 0x98 to address 1f400055
is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010
is= 0 51
flash_read8: Read 0x0 from address 1f400010
fwc addr 1f400000 cmd f0 f0 8bit x 8 bit
flash_write8: Wrote 0xf0 to address 1f400000
fwc addr 1f400555 cmd 98 98 8bit x 8 bit
flash_write8: Wrote 0x98 to address 1f400555
is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010
is= 0 51
flash_read8: Read 0x0 from address 1f400010
fwc addr 1f400000 cmd f0 f0 8bit x 8 bit
flash_write8: Wrote 0xf0 to address 1f400000
fwc addr 1f400000 cmd 98 98 8bit x 8 bit
flash_write8: Wrote 0x98 to address 1f400000
is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010
is= 0 51
flash_read8: Read 0x0 from address 1f400010
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
flash_write16: Wrote 0xf0f0 to address 1f400000
fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit
flash_write16: Wrote 0x9898 to address 1f4000aa
is= cmd 51(Q) addr 1f400020 flash_read16: Read 0x5151 from address 1f400020
is= 5151 5151
flash_read16: Read 0x5151 from address 1f400020
is= cmd 52(R) addr 1f400022 flash_read16: Read 0x5252 from address 1f400022
is= 5252 5252
flash_read16: Read 0x5252 from address 1f400022
is= cmd 59(Y) addr 1f400024 flash_read16: Read 0x5959 from address 1f400024
is= 5959 5959
flash_read16: Read 0x5959 from address 1f400024
flash_read8: Read 0x51 from address 1f400021
flash_read8: Read 0x52 from address 1f400023
flash_read8: Read 0x59 from address 1f400025
flash_read8: Read 0x2 from address 1f400027
flash_read8: Read 0x0 from address 1f400029
flash_read8: Read 0x40 from address 1f40002b
flash_read8: Read 0x0 from address 1f40002d
flash_read8: Read 0x0 from address 1f40002f
flash_read8: Read 0x0 from address 1f400031
flash_read8: Read 0x0 from address 1f400033
flash_read8: Read 0x0 from address 1f400035
flash_read8: Read 0x27 from address 1f400037
flash_read8: Read 0x36 from address 1f400039
flash_read8: Read 0x0 from address 1f40003b
flash_read8: Read 0x0 from address 1f40003d
flash_read8: Read 0x7 from address 1f40003f
flash_read8: Read 0x7 from address 1f400041
flash_read8: Read 0xa from address 1f400043
flash_read8: Read 0x0 from address 1f400045
flash_read8: Read 0x3 from address 1f400047
flash_read8: Read 0x5 from address 1f400049
flash_read8: Read 0x4 from address 1f40004b
flash_read8: Read 0x0 from address 1f40004d
flash_read8: Read 0x17 from address 1f40004f
flash_read8: Read 0x2 from address 1f400051
flash_read8: Read 0x0 from address 1f400053
flash_read8: Read 0x5 from address 1f400055
flash_read8: Read 0x0 from address 1f400057
flash_read8: Read 0x2 from address 1f400059
flash_read8: Read 0x7 from address 1f40005b
flash_read8: Read 0x0 from address 1f40005d
flash_read8: Read 0x20 from address 1f40005f
flash_read8: Read 0x0 from address 1f400061
flash_read8: Read 0x7e from address 1f400063
flash_read8: Read 0x0 from address 1f400065
flash_read8: Read 0x0 from address 1f400067
flash_read8: Read 0x1 from address 1f400069
flash_read8: Read 0x0 from address 1f40006b
flash_read8: Read 0x0 from address 1f40006d
flash_read8: Read 0x0 from address 1f40006f
flash_read8: Read 0x0 from address 1f400071
flash_read8: Read 0x0 from address 1f400073
flash_read8: Read 0x0 from address 1f400075
flash_read8: Read 0x0 from address 1f400077
flash_read8: Read 0x0 from address 1f400079
device interface is 2
found port 2 chip 1 port 16 bits chip 8 bits
__flash_detect_cfi: unlock addresses 0xaaa, 0x555, interface 2
flash_read8: Read 0x31 from address 1f400087
flash_read8: Read 0x33 from address 1f400089
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 07 QRY.. at .....'6...
10 : 07 0a 00 03 05 04 00 17 02 00 05 00 02 07 00 20 ...............
20 : 00 7e 00 00 01 00 00 00 00 00 00 00 00 06 d6 98 .~..............
In cmdset_amd_read_jedec_ids
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
flash_write16: Wrote 0xf0f0 to address 1f400000
funlock writing 0xaa to address 0xaaa
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
flash_write16: Wrote 0xaaaa to address 1f401554
funlock writing 0xaa to address 0x555
fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
flash_write16: Wrote 0x5555 to address 1f400aaa
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_write16: Wrote 0x9090 to address 1f401554
flash_read8: Read 0x0 from address 1f400001
flash_read8: Read 0x3f from address 1f400003
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
flash_write16: Wrote 0xf0f0 to address 1f400000
fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit
flash_write16: Wrote 0x9898 to address 1f4000aa
flash_read8: Read 0x3 from address 1f40009f
manufacturer is 2
manufacturer id is 0x0
device id is 0x3f
device id2 is 0x0
cfi version is 0x3133
size_ratio 1 port 16 bits chip 8 bits
found 2 erase regions
erase region 0: 0x0100007e
erase_region_count = 127 erase_region_size = 65536
erase region 1: 0x00200007
erase_region_count = 8 erase_region_size = 8192
fwc addr 1f400000 cmd f0 f0 8bit x 8 bit
flash_write8: Wrote 0xf0 to address 1f400000
fwc addr 1fbfe000 cmd 70 70 8bit x 8 bit
flash_write8: Wrote 0x70 to address 1fbfe000
flash_read8: Read 0x6f from address 1fbfe000
flash_read8: Read 0x6f from address 1fbfe000
flash_is_busy: 0
Flash: 8 MiB
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 6:42 ` Aaron Williams
@ 2011-02-12 7:01 ` Albert ARIBAUD
2011-02-12 7:06 ` Aaron Williams
2011-02-12 7:14 ` Aaron Williams
0 siblings, 2 replies; 26+ messages in thread
From: Albert ARIBAUD @ 2011-02-12 7:01 UTC (permalink / raw)
To: u-boot
Le 12/02/2011 07:42, Aaron Williams a ?crit :
> I've placed the results of the scan below.
>
> The problem is that in 8-bit mode the code that scans the CFI does not follow
> the specification.
>
> In the specification to read the CFI data you write 0x98 to address 0xAA, not
> address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which
> in this case is wrong and won't work. When it tries 16-bit mode then it writes
> to address 0xAA which causes it to work.
Let us see the specs, then. The specs I have (admittedly not necessarily
the latest: I use JESD 68.01, september 1999) state the following:
"Nonvolatile memory devices are assumed to power up in a read-only
state. Independent of that assumption, the Query structure contents must
be able to be read at the specific address locations following a single
system write cycle where: 1) a 98h Query command code is written to 55h
address location within the device?s address space (in maximum device
buswidth), and 2) the device is in any valid read state, such as ?Read
Array? or ?Read ID Data?.
I read "55h address location within the device?s address space (in
maximum device buswidth" as implying that 0x55 is the only address to
use but is in device bus terms, and that may mean different CPU
addresses for different devices types: for x8 devices, one should access
the byte address 0x55 because the device bus is in bytes, whereas for
x8/x16 and x16 devices, one should access byte address 0xAA because it
translates to x16 device bus address 0x55 -- regardless of actual x8 or
x16 mode.
Are we in sync here?
Now it's been a long time since I last looked at my ED Mini V2 Flash,
but I should be able to dig it up and do a test within one or two hours.
> -Aaron
>
> Here's the results of the scan:
Yes, that's what U-boot *CFI code* does, but I'd like to see what very
basic writes and reads give without any detection logic involved.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 7:01 ` Albert ARIBAUD
@ 2011-02-12 7:06 ` Aaron Williams
2011-02-12 7:14 ` Aaron Williams
1 sibling, 0 replies; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 7:06 UTC (permalink / raw)
To: u-boot
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> Le 12/02/2011 07:42, Aaron Williams a ?crit :
> > I've placed the results of the scan below.
> >
> > The problem is that in 8-bit mode the code that scans the CFI does not
> > follow the specification.
> >
> > In the specification to read the CFI data you write 0x98 to address 0xAA,
> > not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to
> > 0x55 which in this case is wrong and won't work. When it tries 16-bit
> > mode then it writes to address 0xAA which causes it to work.
>
> Let us see the specs, then. The specs I have (admittedly not necessarily
> the latest: I use JESD 68.01, september 1999) state the following:
>
> "Nonvolatile memory devices are assumed to power up in a read-only
> state. Independent of that assumption, the Query structure contents must
> be able to be read at the specific address locations following a single
> system write cycle where: 1) a 98h Query command code is written to 55h
> address location within the device?s address space (in maximum device
> buswidth), and 2) the device is in any valid read state, such as ?Read
> Array? or ?Read ID Data?.
>
> I read "55h address location within the device?s address space (in
> maximum device buswidth" as implying that 0x55 is the only address to
> use but is in device bus terms, and that may mean different CPU
> addresses for different devices types: for x8 devices, one should access
> the byte address 0x55 because the device bus is in bytes, whereas for
> x8/x16 and x16 devices, one should access byte address 0xAA because it
> translates to x16 device bus address 0x55 -- regardless of actual x8 or
> x16 mode.
>
> Are we in sync here?
>
> Now it's been a long time since I last looked at my ED Mini V2 Flash,
> but I should be able to dig it up and do a test within one or two hours.
>
> > -Aaron
>
> > Here's the results of the scan:
> Yes, that's what U-boot *CFI code* does, but I'd like to see what very
> basic writes and reads give without any detection logic involved.
>
> Amicalement,
I'm looking at the Spansion S29GL-N datasheet from 2008. Look at table 10.3 on
page 53.
http://www.spansion.com/Support/Datasheets/S29GL-N_01_12_e.pdf
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 7:01 ` Albert ARIBAUD
2011-02-12 7:06 ` Aaron Williams
@ 2011-02-12 7:14 ` Aaron Williams
2011-02-12 7:51 ` Albert ARIBAUD
1 sibling, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 7:14 UTC (permalink / raw)
To: u-boot
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> Le 12/02/2011 07:42, Aaron Williams a ?crit :
> > I've placed the results of the scan below.
> >
> > The problem is that in 8-bit mode the code that scans the CFI does not
> > follow the specification.
> >
> > In the specification to read the CFI data you write 0x98 to address 0xAA,
> > not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to
> > 0x55 which in this case is wrong and won't work. When it tries 16-bit
> > mode then it writes to address 0xAA which causes it to work.
>
> Let us see the specs, then. The specs I have (admittedly not necessarily
> the latest: I use JESD 68.01, september 1999) state the following:
>
> "Nonvolatile memory devices are assumed to power up in a read-only
> state. Independent of that assumption, the Query structure contents must
> be able to be read at the specific address locations following a single
> system write cycle where: 1) a 98h Query command code is written to 55h
> address location within the device?s address space (in maximum device
> buswidth), and 2) the device is in any valid read state, such as ?Read
> Array? or ?Read ID Data?.
>
> I read "55h address location within the device?s address space (in
> maximum device buswidth" as implying that 0x55 is the only address to
> use but is in device bus terms, and that may mean different CPU
> addresses for different devices types: for x8 devices, one should access
> the byte address 0x55 because the device bus is in bytes, whereas for
> x8/x16 and x16 devices, one should access byte address 0xAA because it
> translates to x16 device bus address 0x55 -- regardless of actual x8 or
> x16 mode.
>
> Are we in sync here?
This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode
according to the data sheet.
>
> Now it's been a long time since I last looked at my ED Mini V2 Flash,
> but I should be able to dig it up and do a test within one or two hours.
>
> > -Aaron
>
> > Here's the results of the scan:
> Yes, that's what U-boot *CFI code* does, but I'd like to see what very
> basic writes and reads give without any detection logic involved.
>
> Amicalement,
When I use the addresses and data shown in the datasheet, everything responds
as it should using mw.b and md.b.
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
Octeon ebb6300(ram)# md.b 0x1f400000 1
1f400000: 01 .
Octeon ebb6300(ram)# md.b 0x1f400002 1
1f400002: 7e ~
Octeon ebb6300(ram)# md.b 0x1f400004 1
1f400004: 00 .
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
Octeon ebb6300(ram)# md.b 0x1f400020
1f400020: 51 Q
Octeon ebb6300(ram)# md.b 0x1f400022
1f400022: 52 R
Octeon ebb6300(ram)# md.b 0x1f400024
1f400024: 59 Y
Octeon ebb6300(ram)# md.b 0x1f400026
1f400026: 02 .
Octeon ebb6300(ram)# md.b 0x1f400028
1f400028: 00 .
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 7:14 ` Aaron Williams
@ 2011-02-12 7:51 ` Albert ARIBAUD
2011-02-12 7:57 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Albert ARIBAUD @ 2011-02-12 7:51 UTC (permalink / raw)
To: u-boot
Le 12/02/2011 08:14, Aaron Williams a ?crit :
> On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
>> Le 12/02/2011 07:42, Aaron Williams a ?crit :
>>> I've placed the results of the scan below.
>>>
>>> The problem is that in 8-bit mode the code that scans the CFI does not
>>> follow the specification.
>>>
>>> In the specification to read the CFI data you write 0x98 to address 0xAA,
>>> not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to
>>> 0x55 which in this case is wrong and won't work. When it tries 16-bit
>>> mode then it writes to address 0xAA which causes it to work.
>>
>> Let us see the specs, then. The specs I have (admittedly not necessarily
>> the latest: I use JESD 68.01, september 1999) state the following:
>>
>> "Nonvolatile memory devices are assumed to power up in a read-only
>> state. Independent of that assumption, the Query structure contents must
>> be able to be read at the specific address locations following a single
>> system write cycle where: 1) a 98h Query command code is written to 55h
>> address location within the device?s address space (in maximum device
>> buswidth), and 2) the device is in any valid read state, such as ?Read
>> Array? or ?Read ID Data?.
>>
>> I read "55h address location within the device?s address space (in
>> maximum device buswidth" as implying that 0x55 is the only address to
>> use but is in device bus terms, and that may mean different CPU
>> addresses for different devices types: for x8 devices, one should access
>> the byte address 0x55 because the device bus is in bytes, whereas for
>> x8/x16 and x16 devices, one should access byte address 0xAA because it
>> translates to x16 device bus address 0x55 -- regardless of actual x8 or
>> x16 mode.
>>
>> Are we in sync here?
>
> This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode
> according to the data sheet.
Yes, but the 0xAA address is a byte address and the 0x55 address is a
word address, translating to byte address 0xAA as well.
On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte
location for a pure x8 device is 0x55, and 0xAA for a x16 device, both
in x16 or x8 mode (the difference is that byte mode will expect a byte
write of 0x98 where x16 mode will expect a word write of 0x0098).
This is in sync with my Macronix MX29LV400CB/CT spec.
>> Now it's been a long time since I last looked at my ED Mini V2 Flash,
>> but I should be able to dig it up and do a test within one or two hours.
>>
>>> -Aaron
>>
>>> Here's the results of the scan:
>> Yes, that's what U-boot *CFI code* does, but I'd like to see what very
>> basic writes and reads give without any detection logic involved.
>>
>> Amicalement,
>
> When I use the addresses and data shown in the datasheet, everything responds
> as it should using mw.b and md.b.
>
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
> Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
> Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
> Octeon ebb6300(ram)# md.b 0x1f400000 1
> 1f400000: 01 .
> Octeon ebb6300(ram)# md.b 0x1f400002 1
> 1f400002: 7e ~
> Octeon ebb6300(ram)# md.b 0x1f400004 1
> 1f400004: 00 .
>
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> Octeon ebb6300(ram)# md.b 0x1f400020
> 1f400020: 51 Q
> Octeon ebb6300(ram)# md.b 0x1f400022
> 1f400022: 52 R
> Octeon ebb6300(ram)# md.b 0x1f400024
> 1f400024: 59 Y
> Octeon ebb6300(ram)# md.b 0x1f400026
> 1f400026: 02 .
> Octeon ebb6300(ram)# md.b 0x1f400028
> 1f400028: 00 .
>
> -Aaron
The CFI query is normal for a x16 device: byte address 0xAA is word
address 0x55, which is what is expected from a x16 device in x8 mode as
in x16 mode.
Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 7:51 ` Albert ARIBAUD
@ 2011-02-12 7:57 ` Aaron Williams
2011-02-12 8:49 ` Albert ARIBAUD
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 7:57 UTC (permalink / raw)
To: u-boot
On Friday, February 11, 2011 11:51:24 pm Albert ARIBAUD wrote:
> Le 12/02/2011 08:14, Aaron Williams a ?crit :
> > On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> >> Le 12/02/2011 07:42, Aaron Williams a ?crit :
> >>> I've placed the results of the scan below.
> >>>
> >>> The problem is that in 8-bit mode the code that scans the CFI does not
> >>> follow the specification.
> >>>
> >>> In the specification to read the CFI data you write 0x98 to address
> >>> 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is
> >>> set to 0x55 which in this case is wrong and won't work. When it tries
> >>> 16-bit mode then it writes to address 0xAA which causes it to work.
> >>
> >> Let us see the specs, then. The specs I have (admittedly not necessarily
> >> the latest: I use JESD 68.01, september 1999) state the following:
> >>
> >> "Nonvolatile memory devices are assumed to power up in a read-only
> >> state. Independent of that assumption, the Query structure contents must
> >> be able to be read at the specific address locations following a single
> >> system write cycle where: 1) a 98h Query command code is written to 55h
> >> address location within the device?s address space (in maximum device
> >> buswidth), and 2) the device is in any valid read state, such as ?Read
> >> Array? or ?Read ID Data?.
> >>
> >> I read "55h address location within the device?s address space (in
> >> maximum device buswidth" as implying that 0x55 is the only address to
> >> use but is in device bus terms, and that may mean different CPU
> >> addresses for different devices types: for x8 devices, one should access
> >> the byte address 0x55 because the device bus is in bytes, whereas for
> >> x8/x16 and x16 devices, one should access byte address 0xAA because it
> >> translates to x16 device bus address 0x55 -- regardless of actual x8 or
> >> x16 mode.
> >>
> >> Are we in sync here?
> >
> > This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16
> > mode according to the data sheet.
>
> Yes, but the 0xAA address is a byte address and the 0x55 address is a
> word address, translating to byte address 0xAA as well.
>
> On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte
> location for a pure x8 device is 0x55, and 0xAA for a x16 device, both
> in x16 or x8 mode (the difference is that byte mode will expect a byte
> write of 0x98 where x16 mode will expect a word write of 0x0098).
>
> This is in sync with my Macronix MX29LV400CB/CT spec.
>
> >> Now it's been a long time since I last looked at my ED Mini V2 Flash,
> >> but I should be able to dig it up and do a test within one or two hours.
> >>
> >>> -Aaron
> >>
> >>> Here's the results of the scan:
> >> Yes, that's what U-boot *CFI code* does, but I'd like to see what very
> >> basic writes and reads give without any detection logic involved.
> >>
> >> Amicalement,
> >
> > When I use the addresses and data shown in the datasheet, everything
> > responds as it should using mw.b and md.b.
> >
> > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
> > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
> > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
> > Octeon ebb6300(ram)# md.b 0x1f400000 1
> > 1f400000: 01 .
> > Octeon ebb6300(ram)# md.b 0x1f400002 1
> > 1f400002: 7e ~
> > Octeon ebb6300(ram)# md.b 0x1f400004 1
> > 1f400004: 00 .
> >
> > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> > Octeon ebb6300(ram)# md.b 0x1f400020
> > 1f400020: 51 Q
> > Octeon ebb6300(ram)# md.b 0x1f400022
> > 1f400022: 52 R
> > Octeon ebb6300(ram)# md.b 0x1f400024
> > 1f400024: 59 Y
> > Octeon ebb6300(ram)# md.b 0x1f400026
> > 1f400026: 02 .
> > Octeon ebb6300(ram)# md.b 0x1f400028
> > 1f400028: 00 .
> >
> > -Aaron
>
> The CFI query is normal for a x16 device: byte address 0xAA is word
> address 0x55, which is what is expected from a x16 device in x8 mode as
> in x16 mode.
>
> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
>
> Amicalement,
You mean like this?
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
Octeon ebb6300(ram)# md.b 0x1f400000 0
Octeon ebb6300(ram)# md.b 0x1f400000 1
1f400000: 01 .
Octeon ebb6300(ram)# md.b 0x1f400002 1
1f400002: 7e ~
Octeon ebb6300(ram)# md.b 0x1f400004 1
1f400004: 00 .
Octeon ebb6300(ram)# md.b 0x1f400005 1
1f400005: 00 .
Octeon ebb6300(ram)# md.b 0x1f400006 1
1f400006: 1a .
Octeon ebb6300(ram)# md.b 0x1f400008 1
1f400008: 00 .
Octeon ebb6300(ram)# md.b 0x1f40000a 1
1f40000a: 00 .
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
Octeon ebb6300(ram)# md.b 0x1f400020
1f400020: 51 Q
Octeon ebb6300(ram)# md.b 0x1f400022
1f400022: 52 R
Octeon ebb6300(ram)# md.b 0x1f400024
1f400024: 59 Y
Octeon ebb6300(ram)# md.b 0x1f400026
1f400026: 02 .
Octeon ebb6300(ram)# md.b 0x1f400028
1f400028: 00 .
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 7:57 ` Aaron Williams
@ 2011-02-12 8:49 ` Albert ARIBAUD
2011-02-12 8:54 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Albert ARIBAUD @ 2011-02-12 8:49 UTC (permalink / raw)
To: u-boot
Le 12/02/2011 08:57, Aaron Williams a ?crit :
>> The CFI query is normal for a x16 device: byte address 0xAA is word
>> address 0x55, which is what is expected from a x16 device in x8 mode as
>> in x16 mode.
>>
>> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
>>
>> Amicalement,
> You mean like this?
>
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
> Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
> Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
> Octeon ebb6300(ram)# md.b 0x1f400000 0
> Octeon ebb6300(ram)# md.b 0x1f400000 1
> 1f400000: 01 .
> Octeon ebb6300(ram)# md.b 0x1f400002 1
> 1f400002: 7e ~
> Octeon ebb6300(ram)# md.b 0x1f400004 1
> 1f400004: 00 .
> Octeon ebb6300(ram)# md.b 0x1f400005 1
> 1f400005: 00 .
> Octeon ebb6300(ram)# md.b 0x1f400006 1
> 1f400006: 1a .
> Octeon ebb6300(ram)# md.b 0x1f400008 1
> 1f400008: 00 .
> Octeon ebb6300(ram)# md.b 0x1f40000a 1
> 1f40000a: 00 .
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> Octeon ebb6300(ram)# md.b 0x1f400020
> 1f400020: 51 Q
> Octeon ebb6300(ram)# md.b 0x1f400022
> 1f400022: 52 R
> Octeon ebb6300(ram)# md.b 0x1f400024
> 1f400024: 59 Y
> Octeon ebb6300(ram)# md.b 0x1f400026
> 1f400026: 02 .
> Octeon ebb6300(ram)# md.b 0x1f400028
> 1f400028: 00 .
>
> -Aaron
No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20'
once in CFI QRY mode, that is:
mw.b 0x1f400000 0xf0
mw.b 0x1f4000AA 0x98
md.b 0x1f400020 20
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 8:49 ` Albert ARIBAUD
@ 2011-02-12 8:54 ` Aaron Williams
2011-02-12 10:08 ` Albert ARIBAUD
0 siblings, 1 reply; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 8:54 UTC (permalink / raw)
To: u-boot
On Saturday, February 12, 2011 12:49:24 am Albert ARIBAUD wrote:
> Le 12/02/2011 08:57, Aaron Williams a ?crit :
> >> The CFI query is normal for a x16 device: byte address 0xAA is word
> >> address 0x55, which is what is expected from a x16 device in x8 mode as
> >> in x16 mode.
> >>
> >> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
> >>
> >> Amicalement,
> >
> > You mean like this?
> >
> > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
> > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
> > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
> > Octeon ebb6300(ram)# md.b 0x1f400000 0
> > Octeon ebb6300(ram)# md.b 0x1f400000 1
> > 1f400000: 01 .
> > Octeon ebb6300(ram)# md.b 0x1f400002 1
> > 1f400002: 7e ~
> > Octeon ebb6300(ram)# md.b 0x1f400004 1
> > 1f400004: 00 .
> > Octeon ebb6300(ram)# md.b 0x1f400005 1
> > 1f400005: 00 .
> > Octeon ebb6300(ram)# md.b 0x1f400006 1
> > 1f400006: 1a .
> > Octeon ebb6300(ram)# md.b 0x1f400008 1
> > 1f400008: 00 .
> > Octeon ebb6300(ram)# md.b 0x1f40000a 1
> > 1f40000a: 00 .
> > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> > Octeon ebb6300(ram)# md.b 0x1f400020
> > 1f400020: 51 Q
> > Octeon ebb6300(ram)# md.b 0x1f400022
> > 1f400022: 52 R
> > Octeon ebb6300(ram)# md.b 0x1f400024
> > 1f400024: 59 Y
> > Octeon ebb6300(ram)# md.b 0x1f400026
> > 1f400026: 02 .
> > Octeon ebb6300(ram)# md.b 0x1f400028
> > 1f400028: 00 .
> >
> > -Aaron
>
> No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20'
> once in CFI QRY mode, that is:
>
> mw.b 0x1f400000 0xf0
> mw.b 0x1f4000AA 0x98
> md.b 0x1f400020 20
>
> Amicalement,
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
Octeon ebb6300(ram)# md.b 0x1f400020 20
1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@....
1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07 ......''66......
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 8:54 ` Aaron Williams
@ 2011-02-12 10:08 ` Albert ARIBAUD
2011-02-12 12:06 ` Aaron Williams
0 siblings, 1 reply; 26+ messages in thread
From: Albert ARIBAUD @ 2011-02-12 10:08 UTC (permalink / raw)
To: u-boot
Le 12/02/2011 09:54, Aaron Williams a ?crit :
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> Octeon ebb6300(ram)# md.b 0x1f400020 20
> 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@....
> 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07 ......''66......
This, according to the CFI spec, gives us the proof that the Spansion
chip is a x16 device in x8 mode.
Can you now please, based on the knowledge that the device is x16 in x8
mode, go through the CFI detection sequence agin and determine which
line exactly fails to work as expected?
> -Aaron
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
2011-02-12 10:08 ` Albert ARIBAUD
@ 2011-02-12 12:06 ` Aaron Williams
0 siblings, 0 replies; 26+ messages in thread
From: Aaron Williams @ 2011-02-12 12:06 UTC (permalink / raw)
To: u-boot
On Saturday, February 12, 2011 02:08:00 am Albert ARIBAUD wrote:
> Le 12/02/2011 09:54, Aaron Williams a ?crit :
> > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> > Octeon ebb6300(ram)# md.b 0x1f400020 20
> > 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00
> > QQRRYY....@@.... 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07
> > 07 ......''66......
>
> This, according to the CFI spec, gives us the proof that the Spansion
> chip is a x16 device in x8 mode.
>
> Can you now please, based on the knowledge that the device is x16 in x8
> mode, go through the CFI detection sequence agin and determine which
> line exactly fails to work as expected?
>
> > -Aaron
>
> Amicalement,
I'll take a look at this next week. The problem with the current code is that
it detects the chip width of 8 but a port width of 16 which results in 16-bit
writes. This fails for obtaining the manufacturer ID.
-Aaron
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-02-12 12:06 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-28 0:24 [U-Boot] mtdparts fails with NAND >= 4GB Aaron Williams
2011-01-28 1:06 ` Scott Wood
2011-01-28 1:14 ` Aaron Williams
2011-01-28 1:43 ` [U-Boot] [PATCH 1/1] NAND " Aaron Williams
2011-01-31 23:15 ` Aaron Williams
2011-01-31 23:28 ` Scott Wood
2011-02-01 2:56 ` [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try Aaron Williams
2011-02-07 22:58 ` Scott Wood
2011-02-08 15:38 ` Andrew Dyer
2011-02-08 23:11 ` Aaron Williams
2011-02-09 1:56 ` Aaron Williams
[not found] ` <201102092228.40033.Aaron.Williams@caviumnetworks.com>
[not found] ` <AANLkTi=fsZXQjRFaZcB535n853WUxEicFqyzquWzMX41@mail.gmail.com>
2011-02-11 3:24 ` Aaron Williams
2011-02-11 3:27 ` Aaron Williams
2011-02-11 4:05 ` Aaron Williams
2011-02-12 0:15 ` Aaron Williams
2011-02-12 6:25 ` Albert ARIBAUD
2011-02-12 6:42 ` Aaron Williams
2011-02-12 7:01 ` Albert ARIBAUD
2011-02-12 7:06 ` Aaron Williams
2011-02-12 7:14 ` Aaron Williams
2011-02-12 7:51 ` Albert ARIBAUD
2011-02-12 7:57 ` Aaron Williams
2011-02-12 8:49 ` Albert ARIBAUD
2011-02-12 8:54 ` Aaron Williams
2011-02-12 10:08 ` Albert ARIBAUD
2011-02-12 12:06 ` Aaron Williams
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.