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: [EMAIL PROTECTED] ===================================================================== ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
