eMMC not found on PicoZed Rev E board (Rev C board works)

Hi Matt, 

Are you aware of the Rev E changes? In the Rev E SOM we removed the MUX that connected between either the eMMC or the Pmod. It is now by default set to eMMC. Did you take this into consideration?

Thanks,

Josh

Hi Josh-

I appreciate the response!

Yes, I am aware of the Rev E changes, but I was under the impression that there would be no change to the software, since we were using the mux in its default state (enabling the eMMC) and want to continue to use the eMMC in the same way.

I know the eMMC part changed from a v4.41 to v5 interface and from 4 GB to 8 GB of capacity, but I'm not aware of any software changes I need to support that.

Am I missing something?

I am still struggling with this issue, and hoping someone has other suggestions. We've done some investigation since Monday, and here's a summary of what we know:

•   The same firmware image running on a Rev C board can access the eMMC
•   The QSPI (which we boot from) is working, so the power rails and reset line should be working for the eMMC too
•   During boot, we see several clock pulses on the clock line to the eMMC, but all other IO lines are high with no transisitions
•   We have tried two Rev E boards now and they behave the same
•   On Rev C boards the mux defaulted to select the eMMC, and on the Rev E board the jumpers are hardwired to select the eMMC, so there should be no additional actions needed to use the eMMC

Our board house is nearly out of Rev C boards, so we are running out of time to resolve this issue -- any help or suggestions is greatly appreciated! Thanks!

Hello Matt,

I will speak with out Software Engineering group first thing tomorrow morning and get back to you.

Thank,

Josh

Hi Matt,

I am working to track down why your Linux image built for the Rev C PicoZed SOM won't boot on the Rev E SOM.  In the meantime would you be willing to test either of our posted BSPs for the PZ7020 and FMC v2 carrier that were built with the PetaLinux and Vivado 2017.4 tools and tested on my Rev E SOM?:
http://zedboard.org/sites/default/files/design/pz7020_fmc2_2017_4_0.zip

http://zedboard.org/sites/default/files/design/pz7020_fmc2_sd_oob_2017_4_0.zip

Thanks!

Tom

Hi Matt,

Any update on this issue?  Were you able to try one of the BSPs that Tom mentioned?

http://zedboard.org/sites/default/files/design/pz7020_fmc2_2017_4_0.zip

When I boot a PicoZed Rev. E using the 2017.4 BSP that Tom mentioned, I can see the system comes up and that the eMMC device is found:

sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on e0100000.sdhci [e0100000.sdhci] using ADMA
mmc1: SDHCI controller on e0101000.sdhci [e0101000.sdhci] using ADMA
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NET: Registered protocol family 10
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20161123 t)
can: netlink gateway (rev 20130117) max_hops=1
Registering SWP/SWPB emulation handler
hctosys: unable to open rtc device (rtc0)
of_cfs_init
of_cfs_init: OK
ALSA device list:
  No soundcards found.
Freeing unused kernel memory: 1024K (c0900000 - c0a00000)
mmc1: new high speed MMC card at address 0001
mmcblk1: mmc1:0001 Q2J55L 7.09 GiB
mmcblk1boot0: mmc1:0001 Q2J55L partition 1 16.0 MiB

INIT: mmcblk1boot1: mmc1:0001 Q2J55L partition 2 16.0 MiB
mmcblk1rpmb: mmc1:0001 Q2J55L partition 3 4.00 MiB
mmcblk1: p1 p2
version 2.88 booting

If that same BSP works on your Rev. E then that would give us a data point to begin dividing and conquering this issue.

Can you elaborate on which tools you are using for Vivado and PetaLinux?

Best Regards,

-Kevin

Kevin and Tom-

Thanks for getting back to me -- our board house was able to locate enough Rev C SOMs to avert the immediate crisis, so I was pulled away dealing with suddenly-more-immediate issues, but I'm back and looking at this again.

The product we use picoZed on was developed in 2015, so we were using PetaLinux 2014.4 running in a Ubuntu 2014.4 VM. I tried installing the BSP Tom linked in the 2014.4 environment but it failed almost immedately -- I've now got Petalinux 2017.4 installed in a Ubuntu 16.04.1 VM, and when I got the project created I saw the images directory containing pre-built images. I was able to load the BOOT_QSPI.bin file using Xilinx SDK 2014.4, and it came up without issue (this is on the Rev E SOM attached to our custom carrier board).

Interestingly mmc0 isn't present, but an mmc1 device is, here's some relevant snips from dmesg:

I still don't have an answer to this, but I noticed that the kernel config option in 2017.4, CONFIG_MMC_SDHCI_OF_XILINX_PS, isn't available in 2014.4, which uses CONFIG_MMC_SDHCI_OF_ARASAN. Everything else looks similar, and I modified my device tree to enable both SDHCI devices in the same way Tom's example does -- still nothing.

At this point, it looks like I'll need to migrate my code to 2017.4 in order to use the Rev E boards. Please let me know if I'm mistaken.

-Matt

Hi Matt,

Looking through my old notes from hockeyman on this, based upon development work done with older PetaLinux builds, the following were recommended when using eMMC devices:

1) Set device tree property "broken-mmc-highspeed" in the sdhci node.

2) Set the "max-frequency" property to 25000000.

I don't have 2014.4 tools setup to experiment with these settings, but perhaps you can check to see if that enables you to continue using 2014.4 builds on Rev. E?

Best Regards,

-Kevin

&sdhci1 {
status = "okay";
clock-frequency = <25000000>;
xlnx,has-cd = <0x1>;
xlnx,has-power = <0x0>;
xlnx,has-wp = <0x1>;
non-removable;
broken-mmc-highspeed;
};