[U-Boot-Users] nand flash controller on 440ep/epx

[U-Boot-Users] nand flash controller on 440ep/epx

[Jeff Mann]

Stefan:

>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"?

That would work. Is simple, and would work for initialization. It would
involve using a proper mask for nand_baseaddr[..] when setting the
location of the nand read/write/control registers to ignore the CS data.


So.....

Nand_init(...) calls nand_init_chip(...) which then calls
board_nand_init(...)
I think the most appropriate place to select the proper Chip select is
in the board_nand_init() function. This function is only passed an
address of the chip nand_chip struct address. So I still think that an
entry in the nand_chip struct should be used for tracking the chip
select to keep the chip select code out of nand.c and keep the code as
simple as possible. 

So, I like the 
#define CFG_NAND_BASE_LIST	{ CFG_NAND_BASE + 1, CFG_NAND_BASE + 2 }

configuration method, but I still think that the struct nand_chip needs
a chip select variable. 

Do we assume the use of the nand flash controller on PPC 440 EP, Epx,
GP, and GPx processors by default (unless still using the legacy drivers
like the bamboo board)?

What do you think?

-Jeff

[U-Boot-Users] nand flash controller on 440ep/epx

[Stefan Roese]

On Monday 09 October 2006 16:15, Jeff Mann wrote:
> That would work. Is simple, and would work for initialization. It would
> involve using a proper mask for nand_baseaddr[..] when setting the
> location of the nand read/write/control registers to ignore the CS data.

OK.

> Nand_init(...) calls nand_init_chip(...) which then calls
> board_nand_init(...)
> I think the most appropriate place to select the proper Chip select is
> in the board_nand_init() function.

No. It should be a function called from the following functions:
- board_nand_init()
- do_nand() (in the "device" part)

Something like:

void nand_select_chip(struct nand_chip *nand)
{
	int cs = nand->IO_ADDR_R & 0x3
	...
}

This should do it. Or did I miss something?

> This function is only passed an 
> address of the chip nand_chip struct address. So I still think that an
> entry in the nand_chip struct should be used for tracking the chip
> select to keep the chip select code out of nand.c and keep the code as
> simple as possible.

Hmmm. Is something missing in my example above?

> So, I like the
> #define CFG_NAND_BASE_LIST	{ CFG_NAND_BASE + 1, CFG_NAND_BASE + 2 }
>
> configuration method, but I still think that the struct nand_chip needs
> a chip select variable.

Please explain why.

> Do we assume the use of the nand flash controller on PPC 440 EP, Epx,
> GP, and GPx processors by default (unless still using the legacy drivers
> like the bamboo board)?

For now yes. It's very unlikely that a board with a PPC with an embedded NAND 
controller like 440EP/GR/EPx/GRx will implement a NAND interface in a 
different way. If such a board will appear we can still add some 
configuration method for this.

Best regards,
Stefan

[U-Boot-Users] nand flash controller on 440ep/epx

[Jeff Mann]

>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(...). I do not think it has to be board specific, but
rather processor 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, 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
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. 

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.

-Jeff
Embedded Planet

[U-Boot-Users] nand flash controller on 440ep/epx

[Stefan Roese]

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

[U-Boot-Users] nand flash controller on 440ep/epx

[Jeff Mann]

It appears that the nand flash controller support recently added to
u-boot for the ppc400ep/epx only supports the use of a single nand chip.
The nand flash controller supports up to four devices using chip selects
0-3. I am working on making two devices work right now for my use, but I
would like to update the flash-controller support. I am open for
comments on this.

What I think I need to do is add an #config CFG_440_USENANDCONTROLLER
option and an entry into the nand_chip struct for holding the chip
select numbers for each chip. Then in addition to configuring an array
of nand bases {CFG_NAND_BASE} (which would all be the same address
because it is the address of the nand controller), the chip selects are
put in a configured array and put into the nand_chip nand struct. The
read and write functions would then need to be updated to enable the
right chip select in the nand controller config register too. 

Comments? Suggestions? What am I missing?

-Jeff 

[U-Boot-Users] nand flash controller on 440ep/epx

[Stefan Roese]

Hi Jeff,

On Friday 06 October 2006 19:56, Jeff Mann wrote:
> It appears that the nand flash controller support recently added to
> u-boot for the ppc400ep/epx only supports the use of a single nand chip.

Yes. That's the current status.

> The nand flash controller supports up to four devices using chip selects
> 0-3. I am working on making two devices work right now for my use, but I
> would like to update the flash-controller support. I am open for
> comments on this.
>
> What I think I need to do is add an #config CFG_440_USENANDCONTROLLER
> option and an entry into the nand_chip struct for holding the chip
> select numbers for each chip. Then in addition to configuring an array
> of nand bases {CFG_NAND_BASE} (which would all be the same address
> because it is the address of the nand controller), the chip selects are
> put in a configured array and put into the nand_chip nand struct. The
> read and write functions would then need to be updated to enable the
> right chip select in the nand controller config register too.
>
> Comments? Suggestions? What am I missing?

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. 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.

What do you think?

Best regards,
Stefan