[U-Boot] 8/16 bit support for NAND at runtime

[U-Boot] 8/16 bit support for NAND at runtime

[Vipin KUMAR]

Hi All,

This query is wrt NAND 8/16 bit device support at runtime. Currently,
the u-boot code can support only one of these at a time.

Although the NAND device in itself can be recognized by reading the
device id, the NAND controllers may need different platform specific
initializations for different device attached.

The current u-boot is written in such a way that
1. Initializes chip->options for a particular buswidth option
2. calls board_nand_init once and proceeds to read the device id

Although it matches the buswidth selected through chip->options and the
the buswidth of device id it reads and returns an error if they don't 
match, probably a better way can be to reinitialize NAND controller 
based on 16 bit device and re-read the device id.

This way both type of devices can be supported at runtime

Please let me know your opinion on this.
Please also let me know if I am missing something

Regards
Vipin

[U-Boot] 8/16 bit support for NAND at runtime

[Wolfgang Denk]

Dear Vipin KUMAR,

In message <4B8F8C3F.6050703@st.com> you wrote:
> 
> This query is wrt NAND 8/16 bit device support at runtime. Currently,
> the u-boot code can support only one of these at a time.

Yes, indeed. I have yet to see a piece of hardware which implements
both 8 and 16 bit interfaces on a single board. Hardware designers
often have funny ideas, but this seems to be too weird even for them
;-)

> Although it matches the buswidth selected through chip->options and the
> the buswidth of device id it reads and returns an error if they don't 
> match, probably a better way can be to reinitialize NAND controller 
> based on 16 bit device and re-read the device id.

Why would that be needed? Do you really expect to see both types of
interfaces on the same piece of hardware?


Otherwise you just have misconfigured your board, and fixing the
configuration should all that is needed to make the code work.  Or am
I missing something?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A little suffering is good for the soul.
	-- Kirk, "The Corbomite Maneuver", stardate 1514.0

[U-Boot] 8/16 bit support for NAND at runtime

[Vipin KUMAR]

On 3/4/2010 5:58 PM, Wolfgang Denk wrote:
> Dear Vipin KUMAR,
> 
> In message <4B8F8C3F.6050703@st.com> you wrote:
>>
>> This query is wrt NAND 8/16 bit device support at runtime. Currently,
>> the u-boot code can support only one of these at a time.
> 
> Yes, indeed. I have yet to see a piece of hardware which implements
> both 8 and 16 bit interfaces on a single board. Hardware designers
> often have funny ideas, but this seems to be too weird even for them
> ;-)
> 
>> Although it matches the buswidth selected through chip->options and the
>> the buswidth of device id it reads and returns an error if they don't 
>> match, probably a better way can be to reinitialize NAND controller 
>> based on 16 bit device and re-read the device id.
> 
> Why would that be needed? Do you really expect to see both types of
> interfaces on the same piece of hardware?
> 

Yes, that's precisely the case with Spear SoC. It has an FSMC controller
embedded in it. FSMC can support 8 as well as 16 bit devices(off-course
with different initializations) for different banks

> 
> Otherwise you just have misconfigured your board, and fixing the
> configuration should all that is needed to make the code work.  Or am
> I missing something?
> 

I could make the code work with both 8 as well as 16 bit devices. The
only thing is that I have to make a few changes and rebuild the uboot
for a particular interface

> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] 8/16 bit support for NAND at runtime

[Wolfgang Denk]

Dear Vipin KUMAR,

In message <4B908BC8.9030306@st.com> you wrote:
>
> > Why would that be needed? Do you really expect to see both types of
> > interfaces on the same piece of hardware?
> 
> Yes, that's precisely the case with Spear SoC. It has an FSMC controller
> embedded in it. FSMC can support 8 as well as 16 bit devices(off-course
> with different initializations) for different banks

The fact that it _can_ support different bus widths does not mean that
anybody would go on and use both at the same time on the same board.

Do you really have any proof that ther eexisits any piece of hardware
that has both an 8 bit and a 16 bit NAND flash on it?

> > Otherwise you just have misconfigured your board, and fixing the
> > configuration should all that is needed to make the code work.  Or am
> > I missing something?
> 
> I could make the code work with both 8 as well as 16 bit devices. The
> only thing is that I have to make a few changes and rebuild the uboot
> for a particular interface

It seems to be no real problem to me when you have to reconfigure
U-Boot and build another image when switching to another piece of
hardware that is incompatible enough to use different bus widths.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Witch!  Witch!  They'll burn ya!
	-- Hag, "Tomorrow is Yesterday", stardate unknown

[U-Boot] 8/16 bit support for NAND at runtime

[Swarthout Edward L-SWARTHOU]

From: Wolfgang Denk
> 
> Dear Vipin KUMAR,
> 
> In message <4B908BC8.9030306@st.com> you wrote:
> >
> > > Why would that be needed? Do you really expect to see 
> > > both types of interfaces on the same piece of hardware?
> > 
> > Yes, that's precisely the case with Spear SoC. It has an FSMC 
> > controller embedded in it. FSMC can support 8 as well as 16 bit 
> > devices(off-course with different initializations) for 
> > different banks
> 
> The fact that it _can_ support different bus widths does not 
> mean that anybody would go on and use both at the same time 
> on the same board.
> 
> Do you really have any proof that ther exisits any piece of 
> hardware that has both an 8 bit and a 16 bit NAND flash on it?

Our internal 85xx system test boards (CTS) have a mux for the
local-bus controller chip-select 0 to enable switching between
8-bit and 16-bit NAND devices.

> It seems to be no real problem to me when you have to 
> reconfigure U-Boot and build another image when switching to 
> another piece of hardware that is incompatible enough to use 
> different bus widths.

Yeh, that is what I do now, but it would be nice to have a
single image.

-EdS

[U-Boot] 8/16 bit support for NAND at runtime

[Vipin KUMAR]

On 3/21/2010 10:20 PM, Wolfgang Denk wrote:
> Dear Vipin KUMAR,
> 
> In message <4B908BC8.9030306@st.com> you wrote:
>>
>>> Why would that be needed? Do you really expect to see both types of
>>> interfaces on the same piece of hardware?
>>
>> Yes, that's precisely the case with Spear SoC. It has an FSMC controller
>> embedded in it. FSMC can support 8 as well as 16 bit devices(off-course
>> with different initializations) for different banks
> 
> The fact that it _can_ support different bus widths does not mean that
> anybody would go on and use both at the same time on the same board.
> 
> Do you really have any proof that ther eexisits any piece of hardware
> that has both an 8 bit and a 16 bit NAND flash on it?
> 

I agree with the above point. This is a board configuration but I am
tempted to make a single image because it can be done in the software

>>> Otherwise you just have misconfigured your board, and fixing the
>>> configuration should all that is needed to make the code work.  Or am
>>> I missing something?
>>
>> I could make the code work with both 8 as well as 16 bit devices. The
>> only thing is that I have to make a few changes and rebuild the uboot
>> for a particular interface
> 
> It seems to be no real problem to me when you have to reconfigure
> U-Boot and build another image when switching to another piece of
> hardware that is incompatible enough to use different bus widths.
> 

Again, the board config way is also fine with me. I was just thinking
that it can be done at runtime also which obviates the need of a different
configurations for a NAND device change

> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] 8/16 bit support for NAND at runtime

[Scott Wood]

On Thu, Mar 04, 2010 at 04:02:31PM +0530, Vipin KUMAR wrote:
> Hi All,
> 
> This query is wrt NAND 8/16 bit device support at runtime. Currently,
> the u-boot code can support only one of these at a time.
> 
> Although the NAND device in itself can be recognized by reading the
> device id, the NAND controllers may need different platform specific
> initializations for different device attached.
> 
> The current u-boot is written in such a way that
> 1. Initializes chip->options for a particular buswidth option
> 2. calls board_nand_init once and proceeds to read the device id
> 
> Although it matches the buswidth selected through chip->options and the
> the buswidth of device id it reads and returns an error if they don't 
> match, probably a better way can be to reinitialize NAND controller 
> based on 16 bit device and re-read the device id.

At some point I'd like to see u-boot transition to a more flexible NAND init
such as what Linux has (nand_scan_ident/nand_scan_tail).  These are actually
in u-boot now, but they're covered up by less flexible init wrapper code.

That way, it would be up to the controller driver to manage this process. 
It could try different options if it wants, and only record the successful
one in nand_info[].  It could also make changes between the ident phase and
the bbt scan based on what the ident reveals, such as page size.

-Scott