Actions
Forum Thread Details
  • State Not Answered
  • Replies 7 replies
  • Subscribers 354 subscribers
  • Views 827 views
  • Users 0 members are here
Related

Ultrazed "production" SOM doesn't boot

sonictai

Hello,

We've just received and powered on our brand new Ultrazed SOM, with "production" chips. But they don't boot, well they don't boot all the time...

We get some SD card access errors as SDHCI_send_command error.

Are there any differences between the ES1 and Production SOM, except for the Ethernet Phy Address that we already changed?

I saw on the SOM that the POR_OVERRIDE pull up/pull down resistors weren't in the same configuration. This remark is true looking at the broads, not at the schematics which are identical!?

May it have something to do with my boot difficulties?

Regards, Christophe

  • 0

    Hello Christophe,

    Are you using your own Linux? 

    If that is the case, please try using our factory Linux and report back wether or not you still experience the same issues.

    You can find the factory image here http://zedboard.org/support/design/17596/131 under the out of box section.

    Thank you,

    Josh

  • 0

    Hello Josh, Thank you for your response.

    Yes we're using our own LINUX on our own hardware so it seems difficult to test the factory Linux as you proposed.

    Actually there are two errors :

    The SDHCI_send_command as mentioned earlier, and the system that do not see the file system (that is located in our system on the SD card), so cannot boot.

    We've followed our tests and here are the last results :

    •   Adding the option "rootdelay = 2" in LINUX allows us to wait for 2 additional seconds. Then the system always see the file system and can boot,
    •   But we still have the SDHCI_send_command error! Is this error important because we saw it in the XILINX WIKI page dealing with the SD CARD controller...

    The impact of the rootdelay option tends to indicate that we're having a problem of timing during the boot sequence. Does it have something to do with the POR_OVERRIDE strap that I mentioned earlier? I could do the hardware modification changing the strap position on the Ultrazed but, well, even if I not bad at soldering, I'd preferred not to do it...

    Christophe

  • 0

    Hello Sonictai,

    We believe your issue may have to do with an issue that was present in the ES1 silicon in regards that we are not sure was fixed in the production silicon. The issue stems back to some registers that we had to modify in relation to the SD interfaces(eMMC and SD card). 

    In the link below is the bootloader patch that shows the register modifications we made to make sure the SDIO(SD card and eMMC) interfaces functioned properly. Please make the same changes to your build. Please let me know if this worked or did not work for you.

    https://avnet.egnyte.com/dl/K9wDICfoV1

    Regards,

    Josh

  • 0

    Hello Josh and thank you for the patch. We've implemented it in our build and the error seems to have disappeared. I won't be categoric because by the time this error came back from time to time...So I follow my development and I'll be back here to give a more definitive conclusion.

    Thank you again, regards, Christophe

  • 0

    Hello Josh,

    Last week I told you that the patch was working on my system. Actually, it works for "production" SOM but it doesn't work for "ES1" SOM, so my first "ES1" modules don't boot anymore...I have some internals error during the boot process.

    It's becoming complicated because I have some products with ES1 and Production SOMS so I can't have several FSBL so is there a workaround?

    Best regards, Christophe

  • 0

    Hello Christophe,

    The patch provided was initially what we used on our ES1 SOMs to solve our SDIO issues. So you stating that the patch fixed your Production SOMs and not your ES1 SOMs does not seem logical. Could you please run the factory test Linux i mentioned in the second post of this forum on your SOMs and tell me if you still encounter this issue.

    Thanks,

    Josh

  • 0

    Hello

    We have found some incoherence in our Linux environment (ie the uboot didn't match exactly with the kernel and the fsbl), and after correction the patch works both on the Production and ES1 platforms! So we follow the adventure!

    Thank you again for your help, Christophe