Actions
Forum Thread Details
  • State Verified Answer
  • Replies 9 replies
  • Subscribers 270 subscribers
  • Views 1764 views
  • Users 0 members are here
Related

Can't boot from eMMC in Standard Speed Mode at -30degC

Former Member

At -15degC its ok but it needs to boot at -30degC.

I have at least 2 rev C Picozed 7030's with this problem and have complied with the advisory note by operating in standard speed mode at 25MHz (section 3.7 in the Avnet Errata).  Signal eMMC_CLK has been measured at 25MHz to verify this.

Do I have faulty boards, or is there anything else I've overlooked ?

I can provide screen dumps from the serial port or other information as required.

Please advise.

  • 0

    There are 3 requirements for properly implementing Standard Speed Mode on PicoZed:

    1.   Adjust the system clock frequency
    2.   Set the Zynq-7000 SDIO controller to Standard Speed Mode
    3.   Set the eMMC to Standard Speed Mode

    It sounds like you have done #1 above, but what about #2 or #3? The full solution is implemented in PetaLinux 2016.2 BSPs that puts U-boot and PetaLinux both into SDIO Standard Speed Mode for the eMMC, which uses the Zynq PS SD1 controller on PicoZed. Please check out these updated BSPs, posted on the PicoZed Carrier FMC-V2 page: http://picozed.org/support/design/13076/106

    Your other option is to use the Revision E PicoZed, which does not have this problem.

    Bryan

  • 0

    Hi Bryan,

    Thanks for the reply. We aren’t using PetaLinux, we’re using bitbake and the meta-xilinx Yocto recipe layers to build Linux and U-Boot. Please could you point us to the source code and/or configuration files that apply these settings to U-Boot and Linux (patches will do).

    Regards,

    Robert

  • 0

    Any update to my last posting please ?

    We can't switch to the rev E Picozed 7030 as I'm told that there are none in stock in the UK or USA. Our next shipment (large piece of kit) is in danger of being delayed if we can't resolve this.

    Regards,

    Robert

  • 0

    Hi Robert,

    Please refer to your Private messages at the bottom of the page. I will message you shortly.

    -Josh

  • 0

    Hi robertdf,

    I will strongly reinforce what emphasize the recommendation that @fletch suggested above for switching to Rev. E hardware, it is the best way to correct for the cold boot issue on older PicoZed boards.

    Take a look at this thread for additional details:

    http://picozed.org/content/picozed-fails-load-os-emmc-low-temp

    In the meantime, I hope the changes I list below will allow you to test out Standard Speed Mode with your version of U-boot and PetaLinux.  The line numbers referenced below are for the 2015.4 versions of U-Boot code that we modified under the hood of PetaLinux tools to validate the change to slower speed and Standard Mode will positively affect the colder temperature boot conditions for board revisions prior to Rev. E hardware.


    U-boot mmc.c file:

    1) Comment out lines 1444-1446 which are:

    if (mmc->card_caps & MMC_MODE_HS_52MHz)
    mmc->tran_speed = 52000000;
    else

    2) Add the following lines after line 1451, which is:

    mmc_set_clock(mmc, mmc->tran_speed);
    err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 0);
    if (err)
    printf("Error setting STD Speed Mode
    ");
    else
    printf("-----------Set EMMC to Standard Speed Mode
    ");

    U-boot zynq_sdhci.c file:

    1) Add the following lines after lines 28-29, which are:

    host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_BROKEN_R1B;
    #ifdef CONFIG_ZYNQ_HISPD_BROKEN
    host->quirks ^= SDHCI_QUIRK_NO_HISPD_BIT;
    printf("------ SDIO Controller set to Standard Speed Mode
    ");
    #endif


    U-boot platform-top.h (or any other convenient location)

    1) Define the following parameter:

    #define CONFIG_ZYNQ_HISPD_BROKEN 1

    For PetaLinux configuration:

    1) Set device tree property 'broken-mmc-highspeed' in the sdhci node
    2) Set the u201Cmax-frequencyu201D property to 25000000

    This should then set the PicoZed to operate the SDIO interface to the eMMC in Standard Speed Mode, which is also called u201Cbackward-compatible card interface timing.u201D The best practice here would be for you to probe the signals going to and from the eMMC with an oscilloscope and you would see that CMD and IO transition on the falling edge of the clock.  If you see this happening, then you know that the correct settings for the host SD controller are in place.

    I am not sure how this would translate to the meta-xilinx Yocto recipe layers you are using to build Linux and U-Boot, but if you are using later versions of U-Boot and Linux Kernel (post 2016.2 PetaLinux release), then the patches posted here might provide some additional guidance on where to implement the appropriate changes:

    https://github.com/Avnet/software/tree/master/petalinux/configs/u-boot

    Specifically, these patches should be relevant:

    https://github.com/Avnet/software/blob/master/petalinux/configs/u-boot/mmc.c.emmc_boot.patch
    https://github.com/Avnet/software/blob/master/petalinux/configs/u-boot/platform-auto.h.emmc_boot.patch

    Plus this devicetree:

    https://github.com/Avnet/software/blob/master/petalinux/configs/device-tree/system-conf.dtsi.pz

    Keep in mind, a slower eMMC interface does affect your boot time by increasing it.  The best solution is to use Rev. E PicoZed hardware at full eMMC clock rate.

    Please feel free to give this a try on your end and let us know how it goes.

    Best Regards,

    -Kevin

  • 0 in reply to Former Member

    Standard lead-time on the PicoZed is 21 weeks. It looks like we are ~8 weeks away from having stock on the 7030. You can email customize@avnet.com or work with your local sales office to get a specific date.

     

    Are you able to do a limited amount of testing with the smaller Rev E PicoZed 7015? Those are in stock now.

    https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-z7pz-7z015-som-i-g-3074457345635221635/

     

    Bryan

  • 0
    Thanks to everyone for their help.
    We have had success on 2 fronts:
    1). Rev E Picozed
    I was able to borrow a rev E 7030 Picozed from another project and sure enough it boots at -30degC as advertised.The 'other project' is expecting another 2 rev E Picozeds shortly as they were ordered some time ago.
    2). Rev C Picozed
    Our software Engineer applied the changes described by 'Zedhed'. The rev C Picozed now boots ok at -30degC.
    The code modifications didn't match up exactly which I assume is due to the different versions but we are pretty sure we've done all the changes for SSM.
     
    If possible we'll ship the rev E Picozed per your earlier advice.
     
    Was the cold boot fix entirely due to the replacement of the 2:1 mux with resistor links per your document PCN17003 ?
  • 0

    Was the cold boot fix entirely due to the replacement of the 2:1 mux with resistor links per your document PCN17003 ?

    Yes

     

    Very glad to hear the Rev E is working for you.

     

    Bryan

  • 0

    Hi robertdf,

    Thank you for the feedback on this!

    Yes, since it is open source code you are modifying and subject to change by the community at any point, it is very likely that the code changes will not line up line for line with the changes we prescribe for 2015.4 source code snapshots.  It sounds like they are close enough that the differences were not too difficult to translate so that is some good news, thank you again!

    Yes, if you read PCN you can see that the multiplexer on the SDIO interface was removed to improve the timing budget and there is not an easy way to document the timing budget analysis without risk of making the multiplexer look like a bad part.

    The multiplexer is in fact not a bad part, it simply was not the best choice for an eMMC interface running at 50MHz across temperature range with a single clock driving the round trip timing budget for SDIO transactions.  For the purpose of restoring the higher value feature (the 50MHz eMMC operation) on all boards with the only tradeoff being the lack of dynamically selecting between SDIO and GPIO functions for those MIO pins, the tough design decision was made to remove the Mux for Rev. E and maximize the timing budget across for the SDIO interface across operating temperature range so that reliability can be achieved for all PicoZed flavors 7010/7015/7020/7030.

    Likewise, the software fix for Rev. C and earlier does improve the timing budget by decreasing the clock frequency and changing the clock edge upon which the data is latched against.

    I cross linked this thread against the Xilinx thread which has additional info that may be useful to others that stumble across this legacy feature in the future:

    https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-SDIO-max-clock-speed/td-p/861548

    Also note that Rev. E eMMC hardware is upgraded from v4.41 4GB to v5.0 8GB MTFC8GAKAJCN-4M IT devices.

    Best Regards,

    -Kevin