[U-Boot] [RFC/PATCH 1/4] Enable multi chip support in the NAND layer

Wolfgang Grandegger
2009-01-19T19:50:23Z

Hi Stefan,

Stefan Roese wrote:
> On Monday 19 January 2009, Scott Wood wrote:
>>>> Actually, none of the boards use multi-chip support (NAND_MAX_CHIPS >
>>>> 1). The bamboo and the DU440 define
>>>>
>>>> #define NAND_MAX_CHIPS CONFIG_SYS_MAX_NAND_DEVICE
>>>>
>>>> but that's bogus and did not work yet anyhow.
>>> Not sure what you mean by this. Bamboo has 2 NAND chips and U-Boot can
>>> access both chips.
>> Are they accessed as 2 NAND controllers, or 2 chips on one controller?
>
> 2 chips on one controller.
>
>> We can make it "#define NAND_MAX_CHIPS 2" if that's appropriate, but
>> defining it to CONFIG_SYS_MAX_NAND_DEVICE doesn't seem to make sense.
>
> OK with me.

NAND_MAX_CHIPS should be set to 1!

NAND_MAX_CHIPS defines the number of NAND chips (or dies) *per* NAND
device (or bank) meaning two or more identical NAND chips can be mapped
to one device. So far this was not supported, because nand_scan() was
always called with maxchips=1 in nand_init_chip:

$ cat drivers/mtd/nand/nand.c:
...
static void nand_init_chip(struct mtd_info *mtd, struct nand_chip *nand,
ulong base_addr)
{
mtd->priv = nand;

nand->IO_ADDR_R = nand->IO_ADDR_W = (void __iomem *)base_addr;
if (board_nand_init(nand) == 0) {
if (nand_scan(mtd, 1) == 0) {
^^^^^^^^^^^^^^^^^
if (!mtd->name)
mtd->name = (char *)default_nand_name;
} else
mtd->name = NULL;
} else {
mtd->name = NULL;
mtd->size = 0;
}
}

Furthermore, the callback chip->select_chip() must be provided by the
NAND driver to select the chips properly. It's seems not to be
implemented for NDFC and therefore you do not have this choice.
Therefore NAND_MAX_CHIPS should be set to 1 for the Bamboo.

Wolfgang.