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 <[email protected]> wrote: > On Sat, May 24, 2014 at 10:27 PM, Amit Mahadik <[email protected]> > 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 > [email protected] > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
