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