From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vipin KUMAR Date: Tue, 23 Mar 2010 11:24:28 +0530 Subject: [U-Boot] 8/16 bit support for NAND at runtime In-Reply-To: <20100321165040.E27B74C022@gemini.denx.de> References: <4B8F8C3F.6050703@st.com> <20100304122805.3F29D28BBC@gemini.denx.de> <4B908BC8.9030306@st.com> <20100321165040.E27B74C022@gemini.denx.de> Message-ID: <4BA85794.5000107@st.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >