SDcard not writeable on PicoZed Rev E board (Rev C board works) ?

We just got the first RevE 7020 module. With the RevC everything works.

We install the QSPI and eMMC through booting a small LINUX from SDcard.
With RevE the Linux boot stops with a Kernel panic or a maintenance request, when write access to the SD card is needed. It finds errors in the filesystem which are cleaned up with RevC. With RevE it just complains that no Write is possible and stops.

I tried to write something to the SDcard in UBOOT and that seems to work. Of course the SDcard is writeable in other computers.

Reinhard

0 jafoste4 over 7 years ago

Hello Reinhard,
Please try using our newest Petalinux BSP 2017.4 located on this page
http://picozed.org/support/design/13076/106
This has been documented to work with our Rev E SOMs. Please verify that it does on yours as well.

Thanks,
Josh
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 zedhed over 7 years ago

Hi Reinhard,

Which Linux are you booting from the SD card?

I am booting our PetaLinux 2017.4 image on Rev. E hardware without issues. I am wondering if the write protect bit is not getting set properly within the devicetree and that is resulting in what you are seeing when moving from Rev. C to Rev. E?

http://zedboard.org/content/emmc-not-found-picozed-rev-e-board-rev-c-board-works

Best Regards,

-Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 7 years ago in reply to zedhed

I'm booting Linux version 3.19.0-xilinx
I tried the Pulsar Linux Image which works. But it uses another file system (btrfs). I tried the dtb entries from the Pulsar Image, but they differ too much from ours and only lead to other failures.
Our dtb:
ps7-sdio@e0100000 {
clock-names = "clk_xin", "clk_ahb", "ref_clk", "aper_clk";
clocks = <0x2 0x15 0x2 0x20 0x2 0x15 0x2 0x20>;
clock-frequency = <0x2faf080>;
compatible = "arasan,sdhci-8.9a", "arasan,sdhci", "generic-sdhci", "xlnx,ps7-sdio-1.00.a";
interrupt-parent = <0x3>;
interrupts = <0x0 0x18 0x4>;
reg = <0xe0100000 0x1000>;
xlnx,has-cd = <0x1>;
xlnx,has-power = <0x0>;
xlnx,has-wp = <0x0>;
};

ps7-sdio@e0101000 {
clock-names = "clk_xin", "clk_ahb", "ref_clk", "aper_clk";
clocks = <0x2 0x16 0x2 0x21 0x2 0x16 0x2 0x21>;
clock-frequency = <0x1312d00>;
compatible = "arasan,sdhci-8.9a", "arasan,sdhci", "generic-sdhci", "xlnx,ps7-sdio-1.00.a";
interrupt-parent = <0x3>;
interrupts = <0x0 0x2f 0x4>;
reg = <0xe0101000 0x1000>;
xlnx,has-cd = <0x1>;
xlnx,has-power = <0x0>;
xlnx,has-wp = <0x1>;
non-removable;
disable-hispd;
};
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 7 years ago

I found the reason for our problem. The FSBL was made by a third party. It uses 0 for the selection of WP (not used) to MIO0. That is OK for RevC, because it has jumper resistors, which give a stable voltage. The RevE has nothing connected to MIO0 and the floating(?) voltage is wrong. If I connect it to Gnd, it works.
I still have to find out, why an image copy from SDcard to eMMC needs twice the time as before.
Reinhard
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 zedhed over 7 years ago

Hello Reinhard,

Thank you for posting your partial solution!

I did not realize that some designers might depend upon MIO0 for WP signaling and I am not sure that possibility was taken into consideration when migrating from Rev. C to Rev. E designs.

Are the devicetree settings you posted above your settings or are they the ones from Pulsar Linux?

That "disable-hispd" property was introduced for early revisions of PicoZed due to the timing limitations imposed by the MUX at lower temperatures.

Best Regards,

-Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 7 years ago in reply to zedhed

I don't know if this selection of MIO0 was intended or if the register value was just set to 0(default?) because WP is nothing to be used and it accidentally worked.
The devicetree settings are from our system with Debian. Yes we have had the thermal problem, therfore tried every setting and finally changed the driver. We haven't decided if we will change it to the intended use(HSM) with RevE and how because of the existing RevC modules.
Reinhard
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 7 years ago in reply to Former Member

The eMMC speed problem was my fault. I tried a lot of settings with the dtb file and continued testing with the wrong values. With the original correct values everything is fine. The dd command we use is even about 25% faster with RevE (no HS).

Reinhard
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 devincody2 over 5 years ago

For anyone else that had this problem with the Avnet Rev E SOM with the Avnet FMC modules (v1 and v2). We fixed this problem by adding "wp-inverted;" to the sdhci entry in the device tree.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel