cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mnsgs
Observer
Observer
191 Views
Registered: ‎05-23-2017

Zynq 7000 Support for eMMC Physical Partitions (eGPP)

Hi,

I have a WD emmc (SDINBDA6-256G-ZA) that is physically partitioned with enhanced general purpose partitions (eGPP) using mmc-utils (https://manpages.debian.org/unstable/mmc-utils/mmc.1.en.html) according to:

 

// Define first EUDA size of 63736MB
mmc enh_area set -c 0 65265664 /dev/mmcblk0

// Define then the first eGPP of 4GB
mmc gp create -c 4194304 1 1 0 /dev/mmcblk0

// Define then the second eGPP of 4GB (and set finalization bit)
mmc gp create -y 4194304 2 1 0 /dev/mmcblk0

 

Unfortunately, the two eGPPs are not detected on a Zynq 7020 based Zedboard Running Linux 5.4 (https://github.com/Xilinx/linux-xlnx/tree/xlnx_rebase_v5.4)

 

root@nanomind-z7020-zed:~# uname -a
Linux nanomind-z7020-zed 5.4.0-xilinx-v2020.2 #1 SMP PREEMPT Tue May 11 12:13:13 UTC 2021 armv7l GNU/Linux

root@nanomind-z7020-zed:~# dmesg | grep -i mmc
mmc0: SDHCI controller on e0100000.mmc [e0100000.mmc] using ADMA
mmc_attach_mmc
mmc0: AUTO_BKOPS_EN bit is set
mmc0: Command Queue supported depth 32
mmc0: new high speed MMC card at address 0001
mmcblk0: mmc0:0001 DA6256 62.2 GiB
mmcblk0boot0: mmc0:0001 DA6256 partition 1 4.00 MiB
mmcblk0boot1: mmc0:0001 DA6256 partition 2 4.00 MiB
mmcblk0rpmb: mmc0:0001 DA6256 partition 3 4.00 MiB, chardev (246:0)
mmcblk0: p1 p2 p3 p4 p5 p6

 

Communication with the eMMC works just fine when not applying the physical partitions.

As recommended by the WD FAE, the eMMC is connected through http://www.allsocket.com/En/ProductView.asp?ID=10 and when connected to a Raspberry Pi 3b+, the partitions are successfully detected:

 

pi@raspberrypi:~$ dmesg | grep mmc0
mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
mmc0: new high speed MMC card at address 0001
mmcblk0: mmc0:0001 DA6256 62.2 GiB
mmcblk0boot0: mmc0:0001 DA6256 partition 1 4.00 MiB
mmcblk0boot1: mmc0:0001 DA6256 partition 2 4.00 MiB
mmcblk0gp0: mmc0:0001 DA6256 partition 4 4.00 GiB
mmcblk0gp1: mmc0:0001 DA6256 partition 5 4.00 GiB
mmcblk0rpmb: mmc0:0001 DA6256 partition 3 4.00 MiB, chardev (245:0)

 

hence I believe the partitioning is correct and successful (also confirmed by the WD FAE).

I wonder whether, there is a known limitation for Zynq-7000 regarding this?

I don't see anything related from neither https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842090/SD+controller nor https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/mmc/arasan%2Csdhci.yaml , but I noticed https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf p. 368:

"The core also supports up to seven functions in SD1, SD4, but does not support SPI mode. The Zynq-7000 SoC is expected to work with eMMC devices because the protocol is the same as SD, but this has not been extensively verified."

We have brought the topic to the WD FAE, who responds:

"If the host controller has been implemented hard-coded commands, it might not contain the switch command. The vendor of the SoC/FPGA should be aware. A modern mmc host controller IP should not contain any limitation.
If the one you are using is designed strictly for SD cards, that could miss hard-coded commands required for eMMC physical partitions manipulation.

So, I guess you need to verify if there are no software aspects limiting the partition switch commands. If you don't see any obvious limitation in the uboot and kernel, you can then ask the SoC vendor to see if the SD/MMC controller is not limited to a certain set of hard-coded commands."

Hoping someone can clarify, whether I have missed a required configuration or if there might be a known limitation of the SoC about this?

 

Thanks,

Martin

0 Kudos
0 Replies