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

[Wolfgang Grandegger]

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.