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

[Michael Schwingen <rincewind@discworld.dascon.de>]

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.

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

cu
Michael