From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Roese <sr@denx.de>
Date: Sat, 7 Oct 2006 16:15:55 +0200
Subject: [U-Boot-Users] nand flash controller on 440ep/epx
In-Reply-To: <1628E43D99629C46988BE46087A3FBB9729A91@ep-01.EmbeddedPlanet.local>
References: <1628E43D99629C46988BE46087A3FBB9729A91@ep-01.EmbeddedPlanet.local>
Message-ID: <200610071615.55429.sr@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Jeff,

On Friday 06 October 2006 22:51, Jeff Mann wrote:
> > It seems to me that we are missing a board/cpu specific function to
> > select a different NAND chip, when the device is changed via the "nand
> > device x" command.This 440EP(x) specific function would then setup the
> > NDFC configuration register (NDFC0_CR) to enable the desired NAND chip
> > select.
>
> This seems simple enough. In addition to "nand device x" switching, it
> would need to be incorporated into nand_init_chip(...) in nand.c before
> it calls nand_scan(...).

Yes.

> I do not think it has to be board specific, but 
> rather processor specific.

This depends. In your case (440EPx) it is cpu specific, in some other cases it 
could be board specific.

> > And to make it easy I suggest that NAND device 0 represents chips
> > select 0 and so on... So no need for additional config options or config
> > arrays.
>
> I origionally consitered this approach. However, as nand would rarely be
> on CS 0,

For NAND booting, it _has_ to be on CS0.

> it seemed to have additional problems. For example, I have 
> FLASH on CS 0, a CPLD on CS 3 and NAND on 1 and 3. So, doing
> nand_scan(..) at boot would cause problems if all four chip selects were
> scanned. On the other hand, a config option like #define
> CONFIG_NAND_CS0, etc. could solve this problem.
>
> So, we will need the configuration options:
> CONFIG_USE_PPC440_NDFC to select the use of the nand flash controller on
> ppc440ep/x/gp boards

Hmmm. Do we really need this? Right now this is selected by configuring 
CFG_CMD_NAND. This, and the correct CPU definition, will enable the NDFC cpu 
specific driver.

> CONFIG_NAND_CS0, CONFIG_NAND_CS1, CONFIG_NAND_CS2, CONFIG_NAND_CS3 or
> CONFIG_NAND_CS { ...} to select which chip selects to use
>
> Then we need to assumme that all nand chips use the address set for the
> nand controller in
> #define CFG_NAND_BASE CFG_NAND_ADDR
>
> We will either need to set CFG_MAX_NAND_DEVICE to four (if assuming all
> CS might me used) or somehow each of the devices in the nand_chip struct
> array will need to be identified with a cs. I origionally recommended
> adding a variable in the struct for identifying the chip select, but
> there are other ways around this.

How about this approach (please keep in mind that this is a CPU specific 
approach):

Use the least significant 2 bit's in the CFG_NAND_BASE_LIST to select the CS. 
In your case this would look like this:

#define CFG_NAND_BASE_LIST	{ CFG_NAND_BASE + 1, CFG_NAND_BASE + 2 }

The driver could then configure the correct CS in the new device select 
function, and would of course mask the least significant 2 bit's in the 
IO_ADDR_W/_R accesses.

Is this too "hackish"?

> So, Stefan, (or Wolfgang) which approach would you prefer I take. I
> think that the AMCC sequoia is the only board so far that uses the nand
> controller so it is the only board that will need changes.

Correct.

Best regards,
Stefan