[U-Boot-Users] Mixing CFI and non-CFI flashs?

[Stefan Roese]

Hi Michael,

On Friday 02 November 2007, Michael Schwingen wrote:
> I am currently porting u-boot to multiple IXP425-based boards that have
> accumulated here over the time. One of them has a slight problem,
> because it uses a combination of two flash roms:
>  - one 8-bit SST 39VF020 boot flash on a 8-bit chip select as boot flash
>  - one 16-bit Intel 64MBit flash on a 16-bit chip select.
>
> The intel flash is CFI, while the SST flash is not.
> I want to use both flash roms, and I want to use as much of the existing
> flash code as possible. It seems that when using the CFI code, there is
> no easy way to add  a non-CFI flash - right?

Correct. This is currently known limitation.

> What would be the best way to use both flash roms? I have come up with:
>
> (1) provide a hook in cfi_flash.c to insert hardcoded values into the
> flash_info structure for the non-CFI flash rom. Due to differences
> between CFI-AMD and non-CFI AMD flash command cycles, I need to  add a
> new commandset (eg. CFI_CMDSET_AMD_LEGACY) plus a bit of handler code.
>
> (2) rename all external-visible functions in flash_cfi.c and add wrapper
> functions that call either the CFI code or my own code for the non-CFI
> flash. This has the disadvantage that I need to duplicate code that is
> already present in cfi_flash.c, but is not exported. I have ssen this
> done on one chip vendor's u-boot port, and it does not really look nice.
>
> (3) extend the code in cfi_flash.c so that external functions can be
> added via function pointers for non-CFI flashs. Same disadvantage as (2).
>
> I have implemented solution (1) now, and it seems to work quite well,
> with minimal code needed in the board-setup file, but maybe there are
> better ways to do this - comments?

I remember a discussion we had a while ago, about supporting non-CFI chips in 
a common driver, but I can't find the mails right now. IIRC, the idea was to 
add something close to the Linux JEDEC probe 
(drivers/mtd/chips/jedec_probe.c) for this.

I suggest that you post your current version for review. This sounds like a 
start in the correct direction.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================