8 Replies Latest reply on Jan 27, 2020 1:26 PM by devincody2

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

    rkopka

      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

        • Hello Reinhard,
          jafoste4

          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

          • RE: SDcard not writeable on PicoZed Rev E board (Rev C board wor
            zedhed

            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

              • I'm booting Linux version 3
                rkopka

                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;
                };
                 

              • Solution - partly
                rkopka

                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

                • RE: Solution - partly
                  zedhed

                  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

                    • I don't know if this
                      rkopka

                      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

                    • Re: SDcard not writeable on PicoZed Rev E board (Rev C board works) ?
                      devincody2

                      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.