* [U-Boot] NAND 16 bit buswidth issue
@ 2010-08-19 13:07 Pete Murray
2010-08-19 19:27 ` Scott Wood
0 siblings, 1 reply; 4+ messages in thread
From: Pete Murray @ 2010-08-19 13:07 UTC (permalink / raw)
To: u-boot
I am running U-boot 2009.08 on a sequoia based custom board. The board
has a Micron 29F2G16AAD nand chip. This chip is a large page device
with a 16 bit buswidth. I have an issue in nand_base.c in the
nand_get_flash_type function where the check for buswidth fails, causing
the print out -
printk(KERN_WARNING "NAND bus width %d instead %d bit\n",
(chip->options & NAND_BUSWIDTH_16) ? 16 : 8,
busw ? 16 : 8);
The busw is read from the nand chip and is correct, but the
chip->options is incorrect. I don't see where this gets set to the
options shown in nand_ids.c. I see that here:
/* Lookup the flash id */
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
if (dev_id == nand_flash_ids[i].id) {
type = &nand_flash_ids[i];
break;
}
}
type gets the correct values from nand_ids, should the value of
type->options be assigned to chip->options? Or am I missing something
and need to set chip->options somewhere in my board specific files?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] NAND 16 bit buswidth issue
2010-08-19 13:07 [U-Boot] NAND 16 bit buswidth issue Pete Murray
@ 2010-08-19 19:27 ` Scott Wood
2010-08-19 20:22 ` Pete Murray
0 siblings, 1 reply; 4+ messages in thread
From: Scott Wood @ 2010-08-19 19:27 UTC (permalink / raw)
To: u-boot
On Thu, 19 Aug 2010 09:07:48 -0400
Pete Murray <pmurray@dawning.com> wrote:
> I am running U-boot 2009.08 on a sequoia based custom board. The board
> has a Micron 29F2G16AAD nand chip. This chip is a large page device
> with a 16 bit buswidth. I have an issue in nand_base.c in the
> nand_get_flash_type function where the check for buswidth fails, causing
> the print out -
>
> printk(KERN_WARNING "NAND bus width %d instead %d bit\n",
> (chip->options & NAND_BUSWIDTH_16) ? 16 : 8,
> busw ? 16 : 8);
>
> The busw is read from the nand chip and is correct, but the
> chip->options is incorrect. I don't see where this gets set to the
> options shown in nand_ids.c. I see that here:
>
> /* Lookup the flash id */
> for (i = 0; nand_flash_ids[i].name != NULL; i++) {
> if (dev_id == nand_flash_ids[i].id) {
> type = &nand_flash_ids[i];
> break;
> }
> }
>
>
> type gets the correct values from nand_ids, should the value of
> type->options be assigned to chip->options? Or am I missing something
> and need to set chip->options somewhere in my board specific files?
The controller driver is supposed to set chip->options.
-Scott
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] NAND 16 bit buswidth issue
2010-08-19 19:27 ` Scott Wood
@ 2010-08-19 20:22 ` Pete Murray
2010-08-19 20:46 ` Scott Wood
0 siblings, 1 reply; 4+ messages in thread
From: Pete Murray @ 2010-08-19 20:22 UTC (permalink / raw)
To: u-boot
The controller driver being used is ndfc.c, it doesn't set the
options though. From what I can tell, nand.c calls nand_scan without
actually setting the nand options. I have been setting chip->options to
include NAND_BUSWIDTH_16, but want to move all my changes back to board
specific code to eventually submit for review.
/* Lookup the flash id */
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
if (dev_id == nand_flash_ids[i].id) {
type = &nand_flash_ids[i];
break;
}
}
if (!type)
return ERR_PTR(-ENODEV);
if (!mtd->name)
mtd->name = type->name;
chip->chipsize = type->chipsize << 20;
Since type is set to the options read from nand_flash_ids in the
nand_get_flash_type function, would it be appropriate to just set
chip->options to type->options as is done with the chipsize? If not,
what would be the most acceptable way to do this?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] NAND 16 bit buswidth issue
2010-08-19 20:22 ` Pete Murray
@ 2010-08-19 20:46 ` Scott Wood
0 siblings, 0 replies; 4+ messages in thread
From: Scott Wood @ 2010-08-19 20:46 UTC (permalink / raw)
To: u-boot
On Thu, 19 Aug 2010 16:22:40 -0400
Pete Murray <pmurray@dawning.com> wrote:
>
> The controller driver being used is ndfc.c, it doesn't set the
> options though. From what I can tell, nand.c calls nand_scan without
> actually setting the nand options. I have been setting chip->options to
> include NAND_BUSWIDTH_16, but want to move all my changes back to board
> specific code to eventually submit for review.
>
>
>
> /* Lookup the flash id */
> for (i = 0; nand_flash_ids[i].name != NULL; i++) {
> if (dev_id == nand_flash_ids[i].id) {
> type = &nand_flash_ids[i];
> break;
> }
> }
>
> if (!type)
> return ERR_PTR(-ENODEV);
>
> if (!mtd->name)
> mtd->name = type->name;
>
> chip->chipsize = type->chipsize << 20;
>
>
> Since type is set to the options read from nand_flash_ids in the
> nand_get_flash_type function, would it be appropriate to just set
> chip->options to type->options as is done with the chipsize? If not,
> what would be the most acceptable way to do this?
The controller driver isn't sufficiently board-specific, so you want to
change the generic code instead? :-)
The problem with autodetection is that you need to issue accesses to
the chip in order to read the ID data. What word size are you going
to use to make *those* accesses? Maybe doing 8-bit accesses happens to
work well enough for ID on your 16-bit chip and controller combination,
but that's not something we can assume generically.
Find a way to have your board config file tell the controller driver
what bus width to specify.
-Scott
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-08-19 20:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-19 13:07 [U-Boot] NAND 16 bit buswidth issue Pete Murray
2010-08-19 19:27 ` Scott Wood
2010-08-19 20:22 ` Pete Murray
2010-08-19 20:46 ` Scott Wood
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox