Amit,
If you can, place a SPI protocol analyzer on the bus and trace its transactions.
I recently debugged a similar symptom and discovered that I was not driving the Tx FIFO consistently enough to maintain the appearance of a single transaction on the ID request to the flash.
How is your SPI device (flash, right?) being selected? If via a GPIO, are you sure you are driving it properly? If it is directly using a controller's slave-select line, you may need to ensure a full Tx FIFO for both the write and response.
HTH, jdl
On Sat, May 24, 2014 at 12:15 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Sat, May 24, 2014 at 10:27 PM, Amit Mahadik amitmahadik35@yahoo.com wrote:
Hello All, I am using a custom ARM based development board running u-boot from PNOR memory. However, it does not have support for the Micron SPI flash memory (N25Q064A). I have added support for the micron memory in drivers/mtd/spi/stmicro.c file and included the flag CONFIG_SPI_FLASH_STMICRO in the config file and recompiled the u-boot source source. Then, ran it directly through RAM memory. The new u-boot ran from RAM. Now when I run sf probe 0 command I get the following output Got Idcodes 000000: 00 00 00 00 and the code hangs after this.
Looks like your driver itself is not returning any proper idcode.
What id details you added - I think you're using old u-boot no stmicro.c in current u-boot, please re-base to master and try.
thanks!
Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot