• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 103 subscribers
  • Views 1098 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.

DM814x + EZSDK 5.05.01.04 and 512MB RAM configuration

Andrea Scian
Intellectual 1000 points

Dear All,

I'm using EZSDK 5.05.01.04 on a custom DM8148 board, with 512MB of DDR2.

We have no problem with previous SDK, but with thisone, when loading HDVICP2 firmware by passing to firmwareloader the"mm_dm81xxbm_512M.bin" configuration I get a syslink error, as in the following dump (please note that some debugging stuff has been enabled inside firmware loader to dump memory regions)

root@dm814x-evm:~# /etc/init.d/load-hd-firmware.sh start
DM814X prcm_config_app version: 2.0.0.1
Doing PRCM settings...
        PRCM for IVHD0 is in Progress, Please wait.....
                        BW Phy Addr : 0x48180600 Data : 0x00000001
                        AW Phy Addr : 0x48180600 Data : 0x00000002
                        Phy Addr : 0x48180c04 Data : 0x00000037
                        BW Phy Addr : 0x48180620 Data : 0x00070000
                        AW Phy Addr : 0x48180620 Data : 0x00050002
                        BW Phy Addr : 0x48180624 Data : 0x00030000
                        AW Phy Addr : 0x48180624 Data : 0x00010002
                        Phy Addr : 0x48180600 Data : 0x00000102
                        BW Phy Addr : 0x48180c10 Data : 0x00000007
                        AW Phy Addr : 0x48180c10 Data : 0x00000003
                        Phy Addr : 0x48180c14 Data : 0x00000004
                        BW Phy Addr : 0x58088000 Data : 0x7a4ecf00
                        AW Phy Addr : 0x58088000 Data : 0xeafffffe
                        BW Phy Addr : 0x58098000 Data : 0x5c51bcd4
                        AW Phy Addr : 0x58098000 Data : 0xeafffffe
                        BW Phy Addr : 0x48180c10 Data : 0x00000003
                        AW Phy Addr : 0x48180c10 Data : 0x00000000
                        Phy Addr : 0x48180c14 Data : 0x00000007
        PRCM for IVHD0 is Done Successfully
PRCM Initialization completed
Loading syslink module
[  107.190000] SysLink version : 2.20.00.14
[  107.190000] SysLink module created on Date:Nov  9 2012 Time:16:32:42
Loading HDVICP2 Firmware
FIRMWARE: memory map bin file: /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm_512M.bin
FIRMWARE: isI2cInitRequiredOnM3: 0
Current FL_DEBUG = log
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
Total Memory segments: 4

Memory Segment : 0
===================
name                 : IPC_SR_VIDEO_M3_VPSS_M3
size                 : 1048576
seg_type             : 3
flags                : 0x0
system_addr          : 0x9a100000
slave_virtual_addr   : 0x9a100000
master_core_id       : 1
core_id_mask         : 0xe
cache_enable_mask    : 0x6
cache_operation_mask : 0x0
shared_region_id     : 1

Memory Segment : 1
===================
name                 : VPSS_M3_INT_HEAP_CACHED
size                 : 28311552
seg_type             : 2
flags                : 0x0
system_addr          : 0x9a200000
slave_virtual_addr   : 0x9a200000
master_core_id       : 255
core_id_mask         : 0x4
cache_enable_mask    : 0x0
cache_operation_mask : 0x0
shared_region_id     : 255

Memory Segment : 2
===================
name                 : VIDEO_M3_INT_HEAP_CACHED
size                 : 25165824
seg_type             : 2
flags                : 0x0
system_addr          : 0x9bd00000
slave_virtual_addr   : 0x9bd00000
master_core_id       : 255
core_id_mask         : 0x2
cache_enable_mask    : 0x1
cache_operation_mask : 0x0
shared_region_id     : 255

Memory Segment : 3
===================
name                 : IPC_SR_FRAME_BUFFERS
size                 : 197132288
seg_type             : 3
flags                : 0x0
system_addr          : 0xab000000
slave_virtual_addr   : 0xab000000
master_core_id       : 1
core_id_mask         : 0xe
cache_enable_mask    : 0x6
cache_operation_mask : 0x6
shared_region_id     : 2
Entered start_firmware
ProcMgr_attach: Success
ProcMgr_load: Success
Ipc_control: Success
Entering memstp_[  108.240000] Assertion at Line no: 452 in /sdk-5.05.01.04/component-sources/syslink_2_20_00_14/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/SharedRegionDrv.c: (status >= 0) : failed
createSr(0x40b9f010, 0xbe8d3a38)
Entered memstp_mapPhyAddr2UsrVirtual(0x9a100000, 1048576)
ProcMgr_map Success VirtAddr: 0x40f45000

ProcMgr_translateAddr Status [0x0] User Virtual Address [0x40f45000]
Leaving memstp_createSr, retVal: 0
Entering memstp_createSr(0x40b9f0d0, 0xbe8d3a38)
Entered memstp_mapPhyAddr2UsrVirtual(0xab000000, 197132288)
ProcMgr_map Success VirtAddr: 0x410ae000

ProcMgr_translateAddr Status [0x0] User Virtual Address [0x410ae000]
Leaving memstp_createSr, retVal: 0
FIRMWARE: Memory Configuration status : In Progress
FIRMWARE: 1 start Successful
Loading HDVPSS Firmware
FIRMWARE: memory map bin file: /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm_512M.bin
FIRMWARE: isI2cInitRequiredOnM3: 0
Current FL_DEBUG = log
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
Total Memory segments: 4

Memory Segment : 0
===================
name                 : IPC_SR_VIDEO_M3_VPSS_M3
size                 : 1048576
seg_type             : 3
flags                : 0x0
system_addr          : 0x9a100000
slave_virtual_addr   : 0x9a100000
master_core_id       : 1
core_id_mask         : 0xe
cache_enable_mask    : 0x6
cache_operation_mask : 0x0
shared_region_id     : 1

Memory Segment : 1
===================
name                 : VPSS_M3_INT_HEAP_CACHED
size                 : 28311552
seg_type             : 2
flags                : 0x0
system_addr          : 0x9a200000
slave_virtual_addr   : 0x9a200000
master_core_id       : 255
core_id_mask         : 0x4
cache_enable_mask    : 0x0
cache_operation_mask : 0x0
shared_region_id     : 255

Memory Segment : 2
===================
name                 : VIDEO_M3_INT_HEAP_CACHED
size                 : 25165824
seg_type             : 2
flags                : 0x0
system_addr          : 0x9bd00000
slave_virtual_addr   : 0x9bd00000
master_core_id       : 255
core_id_mask         : 0x2
cache_enable_mask    : 0x1
cache_operation_mask : 0x0
shared_region_id     : 255

Memory Segment : 3
===================
name                 : IPC_SR_FRAME_BUFFERS
size                 : 197132288
seg_type             : 3
flags                : 0x0
system_addr          : 0xab000000
slave_virtual_addr   : 0xab000000
master_core_id       : 1
core_id_mask         : 0xe
cache_enable_mask    : 0x6
cache_operation_mask : 0x6
shared_region_id     : 2
Entered start_firmware
ProcMgr_attach: Success
ProcMgr_load: Success
Ipc_control: Success
Entering memstp_createSr(0x4cc07010, 0xbebe0a38)
Entered memstp_mapPhyAddr2UsrVirtual(0x9a100000, 1048576)
ProcMgr_map Success VirtAddr: 0x40538000

ProcMgr_translateAddr Status [0x0] User Virtual Address [0x40538000]
Leaving memstp_createSr, retVal: 0
Entering memstp_createSr(0x4cc070d0, 0xbebe0a38)
Entered memstp_mapPhyAddr2UsrVirtual(0xab000000, 197132288)
ProcMgr_map Success VirtAddr: 0x40710000

ProcMgr_translateAddr Status [0x0] User Virtual Address [0x40710000]
Leaving memstp_createSr, retVal: 0
FIRMWARE: Memory Configuration status : In Progress
FIRMWARE: 2 start Successful

Even if the above error is present it seems that all stuff work correctly (e.g. runDecodeDisplayHDMI works).

Does anybody encountered a similar issue?

Will it be a problem? If so how can it be solved? Any clue?

Best Regards and Thanks in Advance,

Andrea

  • 0
    TI__Guru* 80190 points

    Hello,

    Is this issue still present?

    Are you follow this guide: http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Changing_Memory_Map_For_512MB_DM814x_Board
    Did you make changes to load-hd-firmware.sh?
    Best Regards,Margarita

  • 0 in reply to Margarita Gashova
    Intellectual 1000 points

    Yes, the issue is still present.


    I've follow that guide, in fact the previous SDK (sdk-5.04.00.11) does not show any issue when loading the firmware.

  • 0 in reply to Andrea Scian
    Genius 3055 points

    Just to be sure, as I myself already stumbled over that, by forgetting that part of preparation: Is the mem setting at your linux command line still correct (mem=176M at maximum)? Within the boot.cmd (and corresponding boot.scr) coming from a fresh EZSDK that value seems often to be preset higher. And then this of course first conflicts with IPC_SR_FRAME_BUFFERS beginning at 0xAB000000 (176M behind 0xA0000000 resp. 0x80000000).

    Regards,
    Joern.

    P.S. Sorry, if that was not the reason. Would have been too simple solution.

    P.P.S. Maybe you've already found, but within mm_dm81xxbm_512M.c of EZSDK 5.04.00.11 the base address for IPC_SR_FRAME_BUFFERS yet had been 0xB3D00000, whereas in mm_dm81xxbm_512M.c of EZSDK 5.0.5.01.04 it has been changed to 0xAB000000. This change might concern other components (with their own, very local memory settings), too.

  • 0 in reply to Joern
    Intellectual 1000 points

    Dear Joern,

    Joern said:

    Just to be sure, as I myself already stumbled over that, by forgetting that part of preparation: Is the mem setting at your linux command line still correct (mem=176M at maximum)? Within the boot.cmd (and corresponding boot.scr) coming from a fresh EZSDK that value seems often to be preset higher. And then this of course first conflicts with IPC_SR_FRAME_BUFFERS beginning at 0xAB000000 (176M behind 0xA0000000 resp. 0x80000000).

    I'm using the same kernel command line parameters as in the previous version of EZSDK

    Joern said:

    P.S. Sorry, if that was not the reason. Would have been too simple solution.

    No problem, thanks for the suggestion

    Joern said:

    P.P.S. Maybe you've already found, but within mm_dm81xxbm_512M.c of EZSDK 5.04.00.11 the base address for IPC_SR_FRAME_BUFFERS yet had been 0xB3D00000, whereas in mm_dm81xxbm_512M.c of EZSDK 5.0.5.01.04 it has been changed to 0xAB000000. This change might concern other components (with their own, very local memory settings), too.

    Yes, I already see that fix.

    Best Regards

    Andrea

  • 0 in reply to Andrea Scian
    Genius 3055 points

    Hi Andrea,

    Andrea Scian said:

    Just to be sure, as I myself already stumbled over that, by forgetting that part of preparation: Is the mem setting at your linux command line still correct (mem=176M at maximum)? Within the boot.cmd (and corresponding boot.scr) coming from a fresh EZSDK that value seems often to be preset higher. And then this of course first conflicts with IPC_SR_FRAME_BUFFERS beginning at 0xAB000000 (176M behind 0xA0000000 resp. 0x80000000).

    I'm using the same kernel command line parameters as in the previous version of EZSDK

    [/quote]

    If the memory block dedicated to Linux from your kernel command line has ended all the time lower or equal 176M than this should be no problem. I asked this only because I mean that the start address of  IPC_SR_FRAME_BUFFERS with the newer EZSDK changed to that lower start address 0xAB000000, which may have changed the situation, and because the conflict at your test occured shortly after some outputs around this IPC_SR_FRAME_BUFFERS.

    But however, in the meanwhile in this thread I gathered the experience, that sometimes it spares time to just try the newer component. Look at the syslink download page, there are some newer versions announced then your's, with a couple of bugs announced as fixed, maybe this solves your problem. (May be installed in parallel within EZSDK component sources directory, adapt Rules.make from the EZSDK root directory, rebuild syslink within the context of your EZSDK, install the new syslink.ko, rebuild your project.)

    Good luck,
    Joern.

  • 0 in reply to Joern
    Intellectual 1000 points

    Dear Joern,

    Joern said:

    But however, in the meanwhile in this thread I gathered the experience, that sometimes it spares time to just try the newer component. Look at the syslink download page, there are some newer versions announced then your's, with a couple of bugs announced as fixed, maybe this solves your problem. (May be installed in parallel within EZSDK component sources directory, adapt Rules.make from the EZSDK root directory, rebuild syslink within the context of your EZSDK, install the new syslink.ko, rebuild your project.)

    Good luck,
    Joern.

    Thank you very much for pointing out your thread. I'll read it carefully and check if updating components will solve my issue too

    Best Regards

    Andrea

  • 0 in reply to Andrea Scian
    Intellectual 1000 points

    Dear Joern,

    I've downloaded the latest syslink but the problem is still there

    Loading syslink module
    [   16.830000] SysLink version : 2.21.00.03
    [   16.830000] SysLink module created on Date:Dec  7 2012 Time:17:15:08
    Loading HDVICP2 Firmware
    FIRMWARE: memory map bin file: /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm_512M.bin
    FIRMWARE: isI2cInitRequiredOnM3: 0
    Current FL_DEBUG = error
    Allowed FL_DEBUG levels: error, warning, info, debug, log
    MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
    [   17.920000] Assertion at Line no: 452 in /home/shared/devel/dave/naon-DAA/sw/linux/sdk/sdk-5.05.01.04/component-sources/syslink_2_21_00_03/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/SharedRegionDrv.c: (status >= 0) : failed
    FIRMWARE: 1 start Successful
    Loading HDVPSS Firmware
    FIRMWARE: memory map bin file: /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm_512M.bin
    FIRMWARE: isI2cInitRequiredOnM3: 0
    Current FL_DEBUG = error
    Allowed FL_DEBUG levels: error, warning, info, debug, log
    MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
    FIRMWARE: 2 start Successful

    I'll try to update the other components too, to see if it can help in solve this issue

    Best Regards,

    Andrea
  • 0 in reply to Andrea Scian
    TI__Guru 59700 points

    Can you enable syslink trace by adding

    insmod syslink.ko TRACEENTER=1 TRACECLASS=3

    This will print lot of debug info and may give some clue to on the rootcause.

  • 0 in reply to Andrea Scian
    Genius 3055 points

    Hi Andrea,

    just to be sure, did you rebuild and reinstall the firmware loader, too? As it makes use of the syslink driver and links to an API for syslink, it might be that there something has been changed as well.

    Concerning the hint by Badri, usually I connect to my dm8148 board via LAN (ssh resp. telnet) - for more detailed log messages I always add a look into the serial port (f.e. via minicom) of my dm8148 test board. Sometimes the output from there clarifies things. And the settings suggested by Badri lead to significant more log output at the serial port, if I remember that right. In short: don't forget having a look at the serial port.

    Last not least: the memory map file. Until now I did not use the memory map file at all - instead the default settings from within the firmware loader (it falls back to these settings if no memory map file found). So I am not sure if the memory map changes brought by the current EZSDK are correctly reflected by the delivered memory map file, too.

    I am very curious what in the end will have been the reason for your problem... afterwards probably a memory-map-howto should be opened within the TI wiki :-/

    Best regards,
    Joern.

  • 0 in reply to Joern
    Intellectual 1000 points

    Joern said:

    Hi Andrea,

    just to be sure, did you rebuild and reinstall the firmware loader, too? As it makes use of the syslink driver and links to an API for syslink, it might be that there something has been changed as well.

    Yes, in fact if I don't rebuild firmware loader it crashes

    Joern said:

    Concerning the hint by Badri, usually I connect to my dm8148 board via LAN (ssh resp. telnet) - for more detailed log messages I always add a look into the serial port (f.e. via minicom) of my dm8148 test board. Sometimes the output from there clarifies things. And the settings suggested by Badri lead to significant more log output at the serial port, if I remember that right. In short: don't forget having a look at the serial port.

    I'm using only the serial port for the same reason (having kernel messages output)

    Here is what happens when I add the parameters Badri suggested (please note that kernel log level is 8, dmesg -n 8)

    Loading syslink module
    [   34.650000] SysLink version : 2.21.00.03
    [   34.650000] SysLink module created on Date:Dec  7 2012 Time:17:15:08
    [   34.660000] Trace entry/leave prints enabled
    [   34.670000] Trace class 3
    [   34.670000] PM: Adding info for No Bus:syslinkipc_Osal
    [   34.680000] PM: Adding info for No Bus:syslinkipc_Ipc
    [   34.680000] PM: Adding info for No Bus:syslinkipc_ProcMgr
    [   34.690000] PM: Adding info for No Bus:syslinkipc_Notify
    [   34.690000] PM: Adding info for No Bus:syslinkipc_MultiProc
    [   34.700000] PM: Adding info for No Bus:syslinkipc_NameServer
    [   34.710000] PM: Adding info for No Bus:syslinkipc_SharedRegion
    [   34.710000] PM: Adding info for No Bus:syslinkipc_HeapBufMP
    [   34.720000] PM: Adding info for No Bus:syslinkipc_HeapMemMP
    [   34.720000] PM: Adding info for No Bus:syslinkipc_ListMP
    [   34.730000] PM: Adding info for No Bus:syslinkipc_GateMP
    [   34.740000] PM: Adding info for No Bus:syslinkipc_MessageQ
    [   34.740000] PM: Adding info for No Bus:syslinkipc_SyslinkMemMgr
    [   34.750000] PM: Adding info for No Bus:syslinkipc_ClientNotifyMgr
    [   34.760000] PM: Adding info for No Bus:syslinkipc_FrameQBufMgr
    [   34.760000] PM: Adding info for No Bus:syslinkipc_FrameQ
    [   34.770000] PM: Adding info for No Bus:syslinkipc_RingIO
    [   34.770000] PM: Adding info for No Bus:syslinkipc_RingIOShm
    Loading HDVICP2 Firmware
    FIRMWARE: memory map bin file: /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm_512M.bin
    FIRMWARE: isI2cInitRequiredOnM3: 0
    Current FL_DEBUG = error
    Allowed FL_DEBUG levels: error, warning, info, debug, log
    MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
    [   35.830000] Assertion at Line no: 452 in /home/shared/devel/dave/naon-DAA/sw/linux/sdk/sdk-5.05.01.04/component-sources/syslink_2_21_00_03/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/SharedRegionDrv.c: (status >= 0) : failed
    FIRMWARE: 1 start Successful
    Loading HDVPSS Firmware
    FIRMWARE: memory map bin file: /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm_512M.bin
    FIRMWARE: isI2cInitRequiredOnM3: 0
    Current FL_DEBUG = error
    Allowed FL_DEBUG levels: error, warning, info, debug, log
    MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
    FIRMWARE: 2 start Successful

    Joern said:

    Last not least: the memory map file. Until now I did not use the memory map file at all - instead the default settings from within the firmware loader (it falls back to these settings if no memory map file found). So I am not sure if the memory map changes brought by the current EZSDK are correctly reflected by the delivered memory map file, too.

    I did something like that when using EZSDK 5.03, just for ignorance that I can pass a memory map from command line.

    Using a file is easier and allow more flexibility (user can choose some memory configuration on its own with out rebuilding the tool)

    Joern said:

    I am very curious what in the end will have been the reason for your problem... afterwards probably a memory-map-howto should be opened within the TI wiki :-/

    What about this page?

    Best Regards and thanks for your suggestions,


    Andrea

  • 0 in reply to Andrea Scian
    TI__Guru 59700 points

    Is this the only trace you are getting with TRACE enabled ? You should see huge amount of logs .How did you enable TRACE ?

  • 0 in reply to Badri Narayanan
    Intellectual 1000 points

    Dear Badri,

    Badri Narayanan said:

    Is this the only trace you are getting with TRACE enabled ? You should see huge amount of logs .How did you enable TRACE ?

    I was surprised too!

    I did:

    modprobe syslink TRACEENTER=1 TRACECLASS=3

    and, in fact, in the output I see now

    [  802.400000] SysLink version : 2.21.00.03
    [  802.400000] SysLink module created on Date:Dec  7 2012 Time:17:15:08
    [  802.410000] Trace entry/leave prints enabled
    [  802.410000] Trace class 3

    Maybe do I have to enable trace when building syslink?

    Best Regards,

    Andrea

  • 0 in reply to Andrea Scian
    TI__Guru 59700 points

    Some init script would do insmod syslink.You should enable trace when doing insmod syslink.ko TRACEENTER=1 TRACECLASS=3 TRACEFAILURE=1 TRACE=1.

    Can you check the sequence of steps you execute after bootup to check which script insmods syslink and enable trace there?

  • 0 in reply to Badri Narayanan
    Genius 3055 points

    Should have done earlier a look into my own load script - I always used TRACEFAILURE=1, TRACE=1, too - I think that alone will make the difference concerning the missed amount of trace outputs. For those looking for some background information, see Trace, debug and build configuration.

    Regards,
    Joern.

  • 0 in reply to Joern
    Expert 1935 points

    Has this issue been solved.  We see the same problem....

    -Mike

  • 0 in reply to Michael Williamson
    Intellectual 1000 points

    No Mike, I still have the same problem

    Regards,

    Andrea

    lliamsonchael said:

    Has this issue been solved.  We see the same problem....

    -Mike

  • 0 in reply to Andrea Scian
    Intellectual 1000 points

    I've found that the problem is into memory segment #2 (VIDEO_M3_INT_HEAP_CACHED)

    It has been changed in size from 5.04 to 5.05, but only the default memory configuration of firmware loader has been updated, the others (inside mm_host_util directory) has not been updated. I'm using those and passing -mmap parameter to firmware_loader.

    By removing -mmap parameter or by changing:

    Memory Segment : 2
    ===================
    name                 : VIDEO_M3_INT_HEAP_CACHED
    size                 : 25165824
    seg_type             : 2
    flags                : 0x0
    system_addr          : 0x9bd00000
    slave_virtual_addr   : 0x9bd00000
    master_core_id       : 255
    core_id_mask         : 0x2
    cache_enable_mask    : 0x1
    cache_operation_mask : 0x0
    shared_region_id     : 255


    to


    Memory Segment : 2
    ===================
    name : VIDEO_M3_INT_HEAP_CACHED
    size : 33554432
    seg_type : 2
    flags : 0x0
    system_addr : 0x9bd00000
    slave_virtual_addr : 0x9bd00000
    master_core_id : 255
    core_id_mask : 0x2
    cache_enable_mask : 0x1
    cache_operation_mask : 0x0
    shared_region_id : 255

    the warning dissapear

    I hope this can help others in solving similar issue.

    Regards,

    Andrea