[U-Boot-Users] [patch] do not use cmd_reset uninitialized in cfi_flash.c

[Stefan Roese <sr@denx.de>]

On Sunday 03 February 2008, Michael Schwingen wrote:
> Stefan Roese wrote:
> > But you need to know what FLASH chips you are using in this case (Intel
> > or AMD/Spansion). But you are right, they are not pin compatible, so it
> > should be fixed for one board and your solution should be ok. The board
> > config file just has to select CFG_FLASH_CFI_AMD_RESET is AMD/Spasion
> > style flash chips are used.
>
> Um - in the general case: no.
>
> I do have boards where there are alternative (overlapping) footprints
> for either AMD or Intel flash roms, which are connected to the same chip
> select line, and both versions are in production - I think either Intel
> or AMD has an application note on how to do this in the PCB layout.
>
> Also, having both alternatives on one board is not out of the question -
> AcTux-4 has a small 8-bit AMD bootflash, and a bigger 16-bit Intel flash
> on different chip selects. The AMD flash is non-CFI, but a CFI flash
> might be used in such a situation, which means a simple #define in the
> board config will not be sufficient.

OK, understood.

> >> the other option is to just not issue a reset ... when i looked at the
> >> kernel, it didnt seem to issue a reset in the cfi detection case
> >
> > Yes, this is probably an even better solution, since we have here a
> > chicken-egg-problem.
>
> This should work if the flash is correctly wired to a hardware reset,
> but there are flash roms which have no reset input. In general, on
> power-up this is no problem, but if some other part of the system
> (kernel or other application) leaves the flash in the middle of some
> command mode before jumping back to u-boot, we are in trouble.
>
> The safest method would be to run the CFI query twice, once for each
> type of reset command.
>
> However, I wonder if it would be possible to simply issue *both* reset
> commands - if the flash safely ignores the second (unknown) command,
> this should be fine, but it is relying on undocumented behaviour.

Good idea. Do you (or somebody else) have HW available to test such a change?

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