Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

Adding the device tree source file used.

Angelos Spanos wrote:

We are developping on a 3354-HX-X38-RC MitySOM. I am currently using the default am335x-mitysom.dts file, which has the partition options commented out as follows:

We are currently in the process of getting 3.14 support for our modules. We have tried and to a certain extent tested the 3.14 kernel with the 256MB Nand parts. We have not gotten to testing the 512 MB nand yet.

[...]

By comparing the memory-map described in this code with the memory-maps found at the https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/UBIFS_Nand_Boot#256MB-NAND, I suppose that this reflects the 256MByte memory layout.

The commented out section was copied from TI's evm device tree. I've attached a patch from our internal git which sets up 256MB nand according to the above mentioned memory layout. commit-299d705.patch. This hasn't been fully tested but appears to work.

My questions are:

1. Is there a am335x-mitysom.dts source file that has been tested on 512MByte model?

Not yet.

1. Can I re-enable these lines?

Yes see patch.

1. The option ti,nand-ecc-opt is set to bch8. However, I thought that the boot sequence as it is described here, (https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/UBIFS_Nand_Boot#Booting-from-Nand-2) disables NAND ECC checking.

ECC is critical for proper operation of Nand devices. The 512MB nand requires BCH16 to handle possible bitflips. I'm not sure what precisely your referring to. My only thought was that we disabled the "nandecc" command in u-boot since customers were setting the nand to the wrong ECC. U-boot now picks the ECC depending on how its compiled and will complain when built for the wrong NAND.

The latest 3.2 kernel auto chooses the correct ECC and nand layout. This is not possible with the new device tree system, so this will have to be worked around some other way. Multiple device tree files or changing the device tree on the fly in u-boot...

1. Can I just change the addresses to match the layout described here (https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/UBIFS_Nand_Boot#NAND-Partition-Table-2) or are there more changes that need to be done other than that.

That may be enough to get it working. My only other concern is if there is working BCH16 support in the 3.14 kernel for the 335x.

Many thanks for your time.

The commented out section was copied from TI's evm device tree. I've attached a patch from our internal git which sets up 256MB nand according to the above mentioned memory layout. commit-299d705.patch. This hasn't been fully tested but appears to work.
Could you attach the .dtb and .dts file as well? The dtc compiler breaks after I apply the patch.

One more question. Is the mmcblk0 partition in the .dts file? I can't find its definition in the am335x-mitysom.dts.

Angelos Spanos wrote:

The commented out section was copied from TI's evm device tree. I've attached a patch from our internal git which sets up 256MB nand according to the above mentioned memory layout. commit-299d705.patch. This hasn't been fully tested but appears to work.
Could you attach the .dtb and .dts file as well? The dtc compiler breaks after I apply the patch.

For simplicity sake, I've pushed the 256 MB NAND changes to the support site, along with the NOR changes

One more question. Is the mmcblk0 partition in the .dts file? I can't find its definition in the am335x-mitysom.dts.

The mmc1 bus becomes mmcblk0 device when no mmc0 is found.

I have created a DTS file for the 512MB NAND. It is described below. Could you please confirm that the

ti,nand-ecc-opt

&gpmc {
 status = "okay";
 pinctrl-names = "default", "sleep";
 pinctrl-0 = <&nandflash_pins_default>;
 pinctrl-1 = <&nandflash_pins_sleep>;
 ranges = <0 0 0x08000000 0x20000000>;
 nand@0,0 {
     reg = <0 0 0>;
     ti,nand-ecc-opt = "bch16";
     ti,elm-id = <&elm>;
     nand-bus-width = <8>;
     gpmc,device-width = <1>;
     gpmc,sync-clk-ps = <0>;
     gpmc,cs-on-ns = <0>;
     gpmc,cs-rd-off-ns = <44>;
     gpmc,cs-wr-off-ns = <44>;
     gpmc,adv-on-ns = <6>;
     gpmc,adv-rd-off-ns = <34>;
     gpmc,adv-wr-off-ns = <44>;
     gpmc,we-on-ns = <0>;
     gpmc,we-off-ns = <40>;
     gpmc,oe-on-ns = <0>;
     gpmc,oe-off-ns = <54>;
     gpmc,access-ns = <64>;
     gpmc,rd-cycle-ns = <82>;
     gpmc,wr-cycle-ns = <82>;
     gpmc,wait-on-read = "true";
     gpmc,wait-on-write = "true";
     gpmc,bus-turnaround-ns = <0>;
     gpmc,cycle2cycle-delay-ns = <0>;
     gpmc,clk-activation-ns = <0>;
     gpmc,wait-monitoring-ns = <0>;
     gpmc,wr-access-ns = <40>;
     gpmc,wr-data-mux-bus-ns = <0>;
     /* MTD partition table */
     /* All SPL-* partitions are sized to minimal length
      * which can be independently programmable. For
      * NAND flash this is equal to size of erase-block */
     #address-cells = <1>;
     #size-cells = <1>;
     partition@0 {
         label = "NAND.SPL";
         reg = <0x00000000 0x00040000>;
     };
     partition@1 {
         label = "NAND.SPL.backup1";
         reg = <0x00040000 0x00040000>;
     };
     partition@2 {
         label = "NAND.SPL.backup2";
         reg = <0x00080000 0x00040000>;
     };
     partition@3 {
         label = "NAND.SPL.backup3";
         reg = <0x000c0000 0x00040000>;
     };
    partition@4 {
        label = "NAND.u-boot";
        reg = <0x00100000 0x00200000>;
    };
    partition@5 {
        label = "NAND.u-boot-env";
        reg = <0x00300000 0x00040000>;
    };
     partition@6 {
         label = "NAND.kernel";
         reg = <0x00340000 0x00500000>;
     };
     partition@7 {
         label = "NAND.rootfs";
         reg = <0x00840000 0x1F7C0000>;
     };
 };
};

The boot sequence stops at the following line:

...
[    0.000000] Memory: 511768K/523264K available (4507K kernel code, 322K rwdata, 1368K rodata, 300K init, 240K bss,)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05c4f8c   (5876 kB)
[    0.000000]       .init : 0xc05c5000 - 0xc0610000   ( 300 kB)
[    0.000000]       .data : 0xc0610000 - 0xc0660b28   ( 323 kB)
[    0.000000]        .bss : 0xc0660b28 - 0xc069cc7c   ( 241 kB)
...
[    0.995701] Creating 8 MTD partitions on "omap2-nand.0":
[    1.001330] 0x000000000000-0x000000040000 : "NAND.SPL" 
[    1.007897] 0x000000040000-0x000000080000 : "NAND.SPL.backup1" 
[    1.015116] 0x000000080000-0x0000000c0000 : "NAND.SPL.backup2" 
[    1.022342] 0x0000000c0000-0x000000100000 : "NAND.SPL.backup3" 
[    1.029535] 0x000000100000-0x000000300000 : "NAND.u-boot" 
[    1.036512] 0x000000300000-0x000000340000 : "NAND.u-boot-env" 
[    1.043542] 0x000000340000-0x000000840000 : "NAND.kernel" 
[    1.051202] 0x000000840000-0x000020000000 : "NAND.rootfs" 
...
[    1.409487] UBIFS error (pid 1): ubifs_mount: cannot open "ubi0:rootfs", error -19
[    1.417570] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    1.425505] Please append a correct "root=" boot option; here are the available partitions:
[    1.434319] 1f00             256 mtdblock0  (driver?)
[    1.439658] 1f01             256 mtdblock1  (driver?)
[    1.444975] 1f02             256 mtdblock2  (driver?)
[    1.450309] 1f03             256 mtdblock3  (driver?)
[    1.455627] 1f04            2048 mtdblock4  (driver?)
[    1.460961] 1f05             256 mtdblock5  (driver?)
[    1.466278] 1f06            5120 mtdblock6  (driver?)
[    1.471613] 1f07          515840 mtdblock7  (driver?)
[    1.476927] b300         3872256 mmcblk0  driver: mmcblk
[    1.482537]   b301           72261 mmcblk0p1 00000000-01
[    1.488123]   b302          923737 mmcblk0p2 00000000-02
[    1.493728]   b303         2859570 mmcblk0p3 00000000-03
[    1.499335] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.508030] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

With the following bootargs I can enter the filesystem:

console=ttyO0,115200n8 root=/ rw ubi.mtd=7,4096 noinitrd rootfstype=ubifs rootwait=1 ip=none

Now the problem is that the ethernet device is not located. Could you please let me know which lines of the .dts files are responsible for the ethernet module?

Attaching the latest am335x-mitysom.dts file with support for 512MB NAND.

The problem as it is described on the subject of the ticket is now resolved.

I will probably open another ticket if I can't solve the MDIO-related problem.

Many thanks for your good help and support,

Angelos

Your welcome. I take this means you got 512MB Nand working. Were you able to use the bch16 ECC? It would be helpful if you could post your working dts file for future reference.

Now the problem is that the ethernet device is not located. Could you please let me know which lines of the .dts files are responsible for the ethernet module?

What version of the devkit are you using? The current device tree file is setup for the newer devkit Rev6A which has a different PHY and phy_id. I have not tried getting this to work on the old devkit yet.

Thanks Jonathan

Jonathan Cormier wrote:

Your welcome. I take this means you got 512MB Nand working. Were you able to use the bch16 ECC? It would be helpful if you could post your working dts file for future reference.

Correct. The DTS file has been uploaded in this comment. (https://support.criticallink.com/redmine/boards/28/topics/4481?r=4488#message-4488)

Now the problem is that the ethernet device is not located. Could you please let me know which lines of the .dts files are responsible for the ethernet module?

What version of the devkit are you using? The current device tree file is setup for the newer devkit Rev6A which has a different PHY and phy_id. I have not tried getting this to work on the old devkit yet.

Where is the Revision written? The Part Number is 80-00458RH-6

Thanks Jonathan

Angelos Spanos wrote:

Where is the Revision written? The Part Number is 80-00458RH-6

That is a Rev 6. So I'm not sure why your networking isn't working.

Hi Jonathan,

I have just fixed it. The following changes were done:

  cpsw_default: cpsw_default {
    pinctrl-single,pins = < 
      /* Slave 1 */
      0x110 (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxerr.mii1_rxerr */
      0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txen.mii1_txen */
      0x118 (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxdv.mii1_rxdv */
      0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd3.mii1_txd3 */
      0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd2.mii1_txd2 */
      0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd1.mii1_txd1 */
      0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd0.mii1_txd0 */
      0x12c (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_txclk.mii1_txclk */
      0x130 (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxclk.mii1_rxclk */
      0x134 (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxd3.mii1_rxd3 */
      0x138 (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxd2.mii1_rxd2 */
      0x13c (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxd1.mii1_rxd1 */
      0x140 (PIN_INPUT_PULLUP | MUX_MODE0)  /* mii1_rxd0.mii1_rxd0 */
    >;
  };  

  cpsw_sleep: cpsw_sleep {
    pinctrl-single,pins = < 
      /* Slave 1 reset value */
      0x110 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
      0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
    >;
  };  

&cpsw_emac0 {                                                                                                                                                                                                                                  
  phy_id = <&davinci_mdio>, <1>;
  phy-mode = "rgmii";
};

&cpsw_emac1 {
  phy_id = <&davinci_mdio>, <1>;
  phy-mode = "rgmii";
};

1. USB Working
2. Ethernet Working
3. 512MB NAND RAM with memory layout as described in (https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/UBIFS_Nand_Boot#512MB-NAND)

All the best,

Angelos