• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 865 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

Linux/AM3359: icss-emac test on custom board with linux uio_module_drv

Linux/AM3359: ICSS EMAC LLD issue

Stefan Mätje
Prodigy 70 points
Part Number: AM3359


Tool/software: Linux

Hello,

I would like to report some issues with the icss-emac-lld-test application at first, but I still have some questions about the dts I cloned from am335x-pru-uio.dtsi.
I am on a yocto-sumo setup using the meta-ti repository on the thud branch.

I tried to get icss-emac-lld-test up and running on my custom board. At first the application consistently crashed with a segmentation fault. I checked with valgrind and found an issue in the icss-emac-lld driver itself (src/icss_emacDrv.c) and another one in the test program (test/src/test_common_utils.c). There have been used some memory cells without initialization (random content). I would supply patches suitable for "git am" but I don't know how to append these to this forum post. After applying these patches my self-built icss_emacMainTest_am335x.out doesn't crash any more.

But I still have a problem to understand the dts file I needed to create for my custom board. I'm using the uio-module-drv to access the PRU from user space. I derived my custom dts from the am335x-pru-uio.dtsi of the yocto meta-ti layer here: 

The part of the file (quoted below) which I don't understand is the base address and size allocation for the OCMC RAM of the am335x device:

uio_pruss_mem2: uio_pruss_mem2 {
	compatible = "ti,uio-module-drv";
	mem = <0x4a328000 0xd4>,
	      <0x4a330000 0x174>,
	      <0x4a332400 0x90>,
	      <0x40302000 0x0e000>;
	mem-names = "uart", "ecap", "mdio", "ocmc";
	status = "okay";
};

This assigns a base address for the OCMC of 0x2000 bytes above the real hardware address and cuts the size down from the real 0x10000 to 0xE000. I would suspect that this a bug. Especially when I'm looking at the line below in firmware/icss_dualemac/config/icss_emacFwConfig.h of the icss-emac driver package, which is beyond the size of 0xe000:

#define ICSS_EMAC_FW_P0_COL_BUFFER_OFFSET        (0xEE00U) /* 1536 byte collision buffer for port 0 send queue  */

And the icss_emacFwDynamicCfg structure from icss_emacFwConfig.c is used unchanged in the icss-emac-lld-test application. Therefore I think the line for the memory configuration for OCMC should supply a base address of 0x40300000 and a size of 0x10000. This configuration I used successfully.

Please advise which version I should use and why.

Best regards,

    Stefan Mätje

  • 0
    TI__Guru** 105450 points

    Hello Stefan,

    What version of software is this?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 70 points

    Hello Nick,

    sorry for not being clear on the used versions of the relevant software. Used versions so far are:

    • icss-emac-lld: 01.00.00.15A
    • uio-module-drv: 2.2.1.0+gitAUTOINC+bda9260f22
    • linux-ti-staging-rt: 4.14.79+gitAUTOINC+aab33cfa0d-r22c

    Find below the exact versions including the corresponding git hashes from the meta layers and recipes I'm using:

    ==========================================================================
icss-emac-lld                       :01.00.00.15A-r0.0
icss-emac-lld-rtos                  :01.00.00.15A-r0.0
icss-emac-lld-test                  :01.00.00.15A-r0.0

=== Matching recipes: ===
icss-emac-lld:
  meta-ti-thud         01.00.00.15A

# Quote from "meta-ti-thud/recipes-bsp/icss-emac-lld/icss-emac-lld.inc"
ICSS_EMAC_LLD_GIT_URI = "git://git.ti.com/keystone-rtos/icss-emac.git"
:
ICSS_EMAC_LLD_GIT_BRANCH = "master"
ICSS_EMAC_LLD_GIT_DESTSUFFIX = "git/ti/drv/icss_emac"

# Below commit ID corresponds to "DEV.ICSS_EMAC_LLD.01.00.00.15A"
ICSS_EMAC_LLD_SRCREV = "94536e4f3087b87e0787f00637b00878ee085d1d"
:
# The LLD version
PV = "01.00.00.15A"

# The FW version(s)
PV_DUALEMAC_FW = "5.2.7"


==========================================================================
uio-module-drv                      :2.2.1.0+gitAUTOINC+bda9260f22-r22d                          
uio-module-drv-test                 :2.2.1.0+gitAUTOINC+bda9260f22-r1

=== Matching recipes: ===
uio-module-drv:
  meta-ti-thud         2.2.1.0+gitAUTOINC+bda9260f22

# Quote from "meta-ti-thud/recipes-bsp/uio-module-drv/uio-module-drv.inc"
BRANCH = "master"
# This corresponds to version 02.02.01.00
UIO_MODULE_DRV_SRCREV = "bda9260f2220840a60ec0fbc8011cbadf3cf1b91"

PV = "2.2.1.0+git${SRCPV}"

UIO_MODULE_DRV_GIT_URI = "git://git.ti.com/keystone-linux/uio-module-drv.git"



==========================================================================
linux-ti-staging-rt                 :4.14.79+gitAUTOINC+aab33cfa0d-r22c

linux-ti-staging-rt:
  meta-esd             4.14.79+gitAUTOINC+aab33cfa0d

# Quote from "meta-esd/recipes-kernel/linux/linux-ti-staging-rt_4.14.bb"
BRANCH = "ti-rt-linux-4.14.y"

SRCREV = "aab33cfa0d3aed1fb463f6a6e62236db6b04fc5f"
PV = "4.14.79+git${SRCPV}"

    I hope that this makes it clear.

    Best regards,

        Stefan

  • 0 in reply to Stefan Mätje
    TI__Guru** 105450 points

    Hello Stefan,

    I will check on the memory allocation question. FYI, I believe you should be able to attach files (including patch files) to posts with the paperclip "insert file" icon.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 70 points

    Hello Nick,

    I did already solve the memory allocation / undefined variable issue. I will attach some patches to this post. I'm more interested in the question regarding the base address and size of the OCMC RAM that is specified via the device tree. Why the OCMC address has the offset of 0x2000 from the real hardware address specified in am335x-pru-uio.dtsi.

    This is a patch for the icss-emac-lld-test program that avoids a crash. The allocation uses now calloc() for handle->hwAttrs which is needed because 24 lines below this code

        if(NULL == ((ICSS_EmacHwAttrs*)handle->hwAttrs)->emacBaseAddrCfg) {

    checks if the ICSS_EmacBaseAddressHandle_T object needs to be allocated. If it is not done a random pointer will be used then.

    /cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_Fix_2D00_crash_2D00_by_2D00_zero_2D00_initialization_2D00_of_2D00_allocated_2D00_struct.txt

    This is a patch for the icss-emac-lld that takes care of using pacingMode only if pacingEnabled is set by the application program. The icss-emac-lld-test program does not initialize the pacingMode variable.

    /cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_Fix_2D00_access_2D00_to_2D00_possibly_2D00_uninitialized_2D00_variable_2D00_and_2D00_co.txt

  • 0 in reply to Stefan Mätje
    TI__Guru** 105450 points

    Hello Stefan,

    It looks like the first 0x2000 of OCMC is used for power management for AM3. So we have a shift of 0x2000 bytes with a reduced size.

     

    From arch/arm/boot/dts/am33xx.dtsi:

                    ocmcram: ocmcram@40300000 {

                            compatible = "mmio-sram";

                            reg = <0x40300000 0x10000>; /* 64k */

                            ranges = <0x0 0x40300000 0x10000>;

                            #address-cells = <1>;

                            #size-cells = <1>;

     

                            pm_sram_code: pm-sram-code@0 {

                                    compatible = "ti,sram";

                                    reg = <0x0 0x1000>;

                                    protect-exec;

                            };

     

                            pm_sram_data: pm-sram-data@1000 {

                                    compatible = "ti,sram";

                                    reg = <0x1000 0x1000>;

                                    pool;

                            };

                    };

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 70 points

    Hello Nick,

    thank you for your response. I'll understand now why the offset of 0x2000 is used now for the OCMC allocation for the EMAC-LLD. I'll adjust my board's DTS accordingly. 

  • 0 in reply to Stefan Mätje
    TI__Guru** 105450 points

    Hello Stefan,

    Sounds good! By the way, thank you for reporting the other ICSS_EMAC issues you observed. I am sharing your patches with our development team now.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 105450 points

    Hello Stefan,

    Final follow-up: Thanks again for reporting the ICSS_EMAC issues and fixes.

    your patch "Fix crash by zero initialization of allocated structures" is addressed by the following patch in our soon-to-be-released July SDK:

        /* LLD attributes mallocs */
    handle->object = (ICSS_EmacObject*)malloc(sizeof(ICSS_EmacObject));
+   memset((void*)handle->object, 0, sizeof(ICSS_EmacObject));
    handle->hwAttrs= (ICSS_EmacHwAttrs*)malloc(sizeof(ICSS_EmacHwAttrs));
+   memset((void*)handle->hwAttrs, 0, sizeof(ICSS_EmacHwAttrs));

    I submitted your patch "Fix access to possibly uninitialized variable and compiler warnings" for our Fall SDK release.

    Regards,

    Nick