• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 923 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/AM5728: GC320 memory configuration

Linux/AM5728: GC320 driver CMEM issue

JOONHO LEE
Expert 1125 points
Part Number: AM5728

Tool/software: Linux

Hi. we still not resolve this problem as  gc320 create surfce importing cmem.

and then we attach example source.

2605.vivante_cmem.7z

you can see "#define OMK_CMEM_SUPPORT" at galRunTest2.c.

without OMK_CMEM_SUPPORT, it works well with omap memory.

I compiled as  make -f makefile.linux

our compile log is as following.

arm-linux-gnueabihf-gcc -c  -march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard --sysroot=/home/jhlee/AM5728_4.0/ti-processor-sdk-linux-am57xx-evm-04.00.00.04/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi -I/home/jhlee/AM5728_4.0/omk/lib/coresystem/src/hal_include/GC320 -DLINUX -Wall -D_REENTRANT -fno-strict-aliasing -mtune=arm920 -O2 -DUSE_VDK=0 -DgcdUSE_OPENCL=0 -DgcdSTATIC_LINK=0 -DgcdREGISTER_ACCESS_FROM_USER=1 -DgcdFPGA_BUILD=0 -DgcdPAGED_MEMORY_CACHEABLE=0 -DGC_ENABLE_LOADTIME_OPT=1 -DVIVANTE_PROFILER=1 -DVIVANTE_PROFILER_CONTEXT=1 -I/home/jhlee/AM5728_4.0/omk/lib/coresystem/src/hal_include/GC320 -DLINUX -Wall -D_REENTRANT -fno-strict-aliasing -mtune=arm920 -O2 -DUSE_VDK=0 -DgcdUSE_OPENCL=0 -DgcdSTATIC_LINK=0 -DgcdREGISTER_ACCESS_FROM_USER=1 -DgcdFPGA_BUILD=0 -DgcdPAGED_MEMORY_CACHEABLE=0 -DGC_ENABLE_LOADTIME_OPT=1 -DVIVANTE_PROFILER=1 -DVIVANTE_PROFILER_CONTEXT=1 -I/home/jhlee/AM5728_4.0/omk/lib/coresystem/src/hal_include/GC320 -DLINUX -Wall -D_REENTRANT -fno-strict-aliasing -mtune=arm920 -O2 -DUSE_VDK=0 -DgcdUSE_OPENCL=0 -DgcdSTATIC_LINK=0 -DgcdREGISTER_ACCESS_FROM_USER=1 -DgcdFPGA_BUILD=0 -DgcdPAGED_MEMORY_CACHEABLE=0 -DGC_ENABLE_LOADTIME_OPT=1 -DVIVANTE_PROFILER=1 -DVIVANTE_PROFILER_CONTEXT=1 -I/home/jhlee/AM5728_4.0/unittest/vivante_cmem/build/sdk/include/HAL -I/home/jhlee/AM5728_4.0/unittest/vivante_cmem/sdk/inc -I/home/jhlee/AM5728_4.0/unittest/vivante_cmem/test/hal/common/UnitTest/inc -I/home/jhlee/AM5728_4.0/opensource/libdrm/libdrm-2.4.70/include/drm -I/home/jhlee/AM5728_4.0/opensource/libdrm/libdrm-2.4.70/omap -o bin_r/galRunTest2.o galRunTest2.c

our board have error as following even if we apply that vivante hal needs 16  pixel alignment and  4 pixel alignment.

root@am57xx-evm:~/gc320_cmem# ./galRunTest2 -dst A8R8G8B8 1024x124
-dst A8R8G8B8 1024x124
DBG : width(1024) height(124)  at main
DBG : g_ContiguousSize(4194304) at Initialize
DBG : width(1024) stride1(1024) height(124) size(507904) at create_cmem_buffer
DBG : vaddr(0xb6854000) at create_cmem_buffer
DBG111 : g_Runtime.target(0x4d26c) sleep(5) at Initialize

[   78.213337] Backtrace:
[   78.215813] [<c021360c>] (dma_cache_maint_page) from [<c0213780>] (__dma_page_cpu_to_dev+0x30/0xb4)
[   78.224902]  r10:d36e0000 r9:00000000 r8:c1006184 r7:00001000 r6:00000000 r5:00000000
[   78.232766]  r4:d4a82400
[   78.235317] [<c0213750>] (__dma_page_cpu_to_dev) from [<c0213850>] (arm_dma_sync_single_for_device+0x4c/0x50)
[   78.245275]  r7:bf0270c8 r6:c0213804 r5:00000000 r4:00000000
[   78.251000] [<c0213804>] (arm_dma_sync_single_for_device) from [<bf02713c>] (platform_cache+0x74/0x5a8 [galcore])
[   78.261307]  r5:00000000 r4:00000000
[   78.264958] [<bf0270c8>] (platform_cache [galcore]) from [<bf021a30>] (gckOS_MapUserMemory+0x250/0xb58 [galcore])
[   78.275268]  r10:d36e0000 r9:c107e904 r8:c1006184 r7:bf0270c8 r6:d235c000 r5:00000000
[   78.283132]  r4:b6854000
[   78.285735] [<bf0217e0>] (gckOS_MapUserMemory [galcore]) from [<bf02a5d0>] (gckKERNEL_Dispatch+0xbb4/0x11a8 [galcore])
[   78.296480]  r10:00000000 r9:00000000 r8:ffffffff r7:00000001 r6:d3fc1d00 r5:00000000
[   78.304344]  r4:d235dd98
[   78.306947] [<bf029a1c>] (gckKERNEL_Dispatch [galcore]) from [<bf0266ac>] (drv_ioctl+0x128/0x294 [galcore])
[   78.316732]  r9:d235c000 r8:d235dd78 r7:d235c000 r6:00007530 r5:d2749fc0 r4:d3020600
[   78.324542] [<bf026584>] (drv_ioctl [galcore]) from [<c033eba8>] (do_vfs_ioctl+0xa8/0x7fc)
[   78.332845]  r9:d235c000 r8:becd68b8 r7:00000003 r6:d2605b40 r5:d37fcb58 r4:becd68b8
[   78.340625] [<c033eb00>] (do_vfs_ioctl) from [<c033f338>] (SyS_ioctl+0x3c/0x64)
[   78.347969]  r10:00000000 r9:d235c000 r8:becd68b8 r7:00007530 r6:d2605b40 r5:00000003
[   78.355832]  r4:d2605b40
[   78.358383] [<c033f2fc>] (SyS_ioctl) from [<c0207be0>] (ret_fast_syscall+0x0/0x34)
[   78.365988]  r9:d235c000 r8:c0207d84 r7:00000036 r6:00007530 r5:b6f64b3c r4:00002710
[   78.373767] Code: e3a02004 e1a02312 e2423001 e1c00003 (ee070f3a)

  • 0
    TI__Mastermind 22916 points

    I will look into this and get back to you.

  • 0 in reply to Manisha Agrawal
    TI__Mastermind 22916 points
    Hi Joonho,

    Where is CMEM region located? GC320 cannot map memory with physical address > 32 bits.

    Also, the from the logs shared, stride = width, and the buffer is of format ARGB8. Can you review this? Is the memory being allocated correctly?
  • 0 in reply to Manisha Agrawal
    Expert 1125 points

    Hi.

    CMEM region is 2.  you can see #define CMEM_BLOCKID 2 at galRunTest2.c of 2605.vivante_cmem.7z(above attached).

    of course, it must be defined as follow it(we used it currently). I think that you have understood cmem region.

    < ti-processor-sdk-linux-am57xx-evm-04.00.00.04\board-support\linux-4.9.28+gitAUTOINC+eed43d1050-geed43d1050\arch\arm\boot\dts\am57xx-evm-cmem.dtsi >

    / {
            reserved-memory {
                    #address-cells = <2>;
                    #size-cells = <2>;
                    ranges;

                    cmem_block_mem_0: cmem_block_mem@a0000000 {
                            reg = <0x0 0xa0000000 0x0 0x100000>;
                            no-map;
                            status = "okay";
                    };    
                   
        cmem_block_ocmc3: cmem_block_mem@40500000 {
          reg = <0x0 0x40500000 0x0 0x100000>;
          no-map;
          status = "okay";
        };
        
        cmem_block_mem_1: cmem_block_mem@a0100000 {
                            reg = <0x0 0xa0100000 0x0 0x12800000>;
                            no-map;
                            status = "okay";
                    };  
            };

            cmem {
                    compatible = "ti,cmem";
                    #address-cells = <1>;
                    #size-cells = <0>;

        #pool-size-cells = <2>;

                    status = "okay";

                    cmem_block_0: cmem_block@0 {
                            reg = <0>;
                            memory-region  = <&cmem_block_mem_0>;
                            cmem-buf-pools = <1 0x0 0x100000>;
                    };
                   
        cmem_block_1: cmem_block@1 {
          reg = <1>;
          memory-region = <&cmem_block_ocmc3>;
        };
        
        cmem_block_2: cmem_block@2 {
                            reg = <2>;
                            memory-region  = <&cmem_block_mem_1>;                       
                    };
            };
    };

    It mistake of printf that width == stride . then, program bug is not.

    you can modify printf as follow it.

    //printf("DBG : width(%d) stride1(%d) height(%d) size(%d) at %s\n", width, stride1, height, size, __PRETTY_FUNCTION__);
     printf("DBG : width(%d) stride(%d) height(%d) size(%d) at %s\n", width, bpr, height, size, __PRETTY_FUNCTION__);

    The memory is correctlyt allocated with no problem. we expect that you will resolve it(kernel die when GC320 driver access cmem).

    Thanks a lot.

  • 0 in reply to JOONHO LEE
    TI__Mastermind 22916 points
    Hi Joonho,

    I am out of office for next 3 weeks. I will look into this once I am back in office. Thank you for your patience .

    Regards,
    Manisha
  • 0 in reply to Manisha Agrawal
    Expert 1125 points
    Hi.
    we resolve it as gc320(vivante) use CMA not CMEM.
    i think that gc320(vivante) only support omap tiler and CMA when i use gcvPOOL_USER.
    The object of use CMEM is to overcome omap tiler limit is under 128MB.
    fortunately CMA have over 128MB. and then, we can use CMA.

    Thanks a lot.
  • 0 in reply to JOONHO LEE
    TI__Mastermind 22916 points

    Hi Joonho,

    I am glad that you are able to find workaround for the  issue at your end. 

    Since more people are going to read this post, I would like to point that GC320 driver shouldn't have issue using memory from CMEM pool as we have one out of box example application named video-graphics-test in Processor SDK in which the memory to GC320 is allocated from CMEM pool and that application works well. 

    There may be some bug or other issue either for corner case  in CMEM driver or GC320 driver or some constrain in it's usage that we need to look at and debug it. 

    Regards,

    Manisha