All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] nand flash controller on 440ep/epx
Date: Sat, 7 Oct 2006 16:15:55 +0200	[thread overview]
Message-ID: <200610071615.55429.sr@denx.de> (raw)
In-Reply-To: <1628E43D99629C46988BE46087A3FBB9729A91@ep-01.EmbeddedPlanet.local>

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

  reply	other threads:[~2006-10-07 14:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 20:51 [U-Boot-Users] nand flash controller on 440ep/epx Jeff Mann
2006-10-07 14:15 ` Stefan Roese [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-10-09 14:15 Jeff Mann
2006-10-09 15:14 ` Stefan Roese
2006-10-06 17:56 Jeff Mann
2006-10-06 19:40 ` Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610071615.55429.sr@denx.de \
    --to=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.