public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [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