Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 266 subscribers
  • Views 237 views
  • Users 0 members are here
Related

Open Source Linux In System QSPI Programming Tutorial Fails

Former Member

I just tried to follow the instructions in MicroZed_7020_Open_Source_Linux_In_System_QSPI_Programming_14_5_02-Tutorial.zip and everything ran perfectly when flashing the QSPI, but once I attempt to test the installed system I get the following:

U-Boot 2013.01-dirty (Jun 14 2013 - 16:25:48)

DRAM:  512 MiB
WARNING: Caches not enabled
MMC:   zynq_sdhci: 0
SF: Detected S25FL129P_64K with page size 64 KiB, total 16 MiB
In:    serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
Copying Linux from SD to RAM...
Card did not respond to voltage select!
Device: zynq_sdhci
Manufacturer ID: 0
OEM: 0
Name: Tran Speed: 0
Rd Block Len: 0
MMC version 0.0
High Capacity: No
Capacity: 0 Bytes
Bus Width: 1-bit
Loading bitstream from SD/MMC/eMMC to RAM..
Card did not respond to voltage select!
Device: zynq_sdhci
Manufacturer ID: 0
OEM: 0
Name: Tran Speed: 0
Rd Block Len: 0
MMC version 0.0
High Capacity: No
Capacity: 0 Bytes
Bus Width: 1-bit
Card did not respond to voltage select!
** Bad device mmc 0 **

  • 0

    Hi gpsat,

    I just tried this tutorial on my 7020 MicroZed and it worked okay for me to boot in QSPI mode.

    I did notice something about your terminal output that is different than mine.

    After the SF detect output, I get a warning from U-boot that a bad CRC is found on the U-boot environment storage area which is expected if you have never committed your U-boot environment settings to NV memory using the 'saveenv' command.

    SF: Detected S25FL129P_64K with page size 64 KiB, total 16 MiB
    *** Warning - bad CRC, using default environment

    Since I don't see that second message in the terminal output you posted above, perhaps you have committed some U-Boot environment settings to QSPI (including the macro too load files and continue booting from SD card) which I think would explain why your U-Boot seems to be attempting to load files from your SD card even when you are booting in QSPI mode.

    We use the flashcp tool in Linux to program the partitions as shown in the tutorial document so I would assume that flashcp erases the entire QSPI 'qspi-fsbl-uboot' partition but perhaps that assumption is incorrect and that flashcp only erases enough blocks to allow space for BOOT.BIN to fit?  Otherwise, if flashcp command really did erase the entire 'qspi-fsbl-uboot' partition then the U-Boot environment space at 0xe0000 should get overwritten.  Perhaps you have discovered a special feature of the flashcp tool?

    Anyways, if you want to completely wipe out your QSPI contents (including the space where U-boot environment is stored at QSPI 0xe0000) I have discovered that you can use the following U-boot commands to completely wipe everything from QSPI flash:

    zynq-uboot> sf probe (this selects the QSPI flash)
    zynq-uboot> sf erase 0 0x1000000 (takes a while to finish)

    I just tried this on my end and it appears to have cleared my saved U-Boot environment and everything else from QSPI.  So then I had to go back and reprogram QSPI using the SD card loaded with the files from the tutorial and everything appears to be working as expected now.

    Please try the same thing on your end and let me know if that works.

    Regards,

    -Kevin

  • 0

    Thank you, that does appear to have been the issue.

    Now onto that other thread :)