2011-10-11 03:18:06     CORE B: error message type

2011-10-11 03:18:06     CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103777   

Hi,

I was loading the icc core as usual:

./icc_loader -l icc

This is a build of icc core and icc_loader from the latest svn update.

Normally it works fine but this time I've got an error when starting the session:

root:/> dhcpcd &                                                              

[1] 279 dhcpcd                                                                

root:/> smc91x smc91x.0: eth0: link down                                      

smc91x smc91x.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1              

                                                                              

root:/> tftp -g -r icc 10.1.1.100                                             

root:/> tftp -g -r icc_loader 10.1.1.100                                      

root:/> tftp -g -r test_ad1836_driver 10.1.1.100                              

root:/> chmod 777 icc_loader                                                  

root:/> ./icc_loader -l icc                                                   

writing to 0xfeb00000, 0x6934    bytes: OK                                    

writing to 0xff600000, 0xc4      bytes: OK                                    

root:/> COREB: @@@ gen pool create0                                           

COREB: @@@ gen pool create1                                                   

COREB: session table 3d00000                                                  

COREB: error messag type d3451993e                                            

COREB: error messag type dcf6ffc8e                                            

COREB: error messag type 67a98aace                                            

COREB: error messag type cf8aeb89e

Looking at the icc core this is triggered when the session id not valid:

        session = sm_index_to_session(index);

        if (!session) {

                coreb_msg("error messag type %08xe\n", msg->type);

                sm_message_dequeue(cpu, msg);

            return;

        }

Which mean the the session index = 0 returned by:

struct sm_session* sm_index_to_session(sm_uint32_t session_idx)

{

    struct sm_session *session;

        struct sm_session_table *table = coreb_info.icc_info.sessions_table;

        if (session_idx < 0 && session_idx >= MAX_SESSIONS)

                return NULL;

    if (!test_bit(session_idx, table->bits))

                return NULL;

        session = &table->sessions[session_idx];

        return session;

}

Why do I get this error, how do I fix it

Thanks,

William

QuoteReplyEditDelete

2011-10-11 04:02:50     Re: CORE B: error message type

steven miao (CHINA)

Message: 103785   

Hi William,

this error means it received unexpected message from L2 message queue, maybe some other program overwrite the L2 message queue(hdcpd or networking driver)

-steven

QuoteReplyEditDelete

2011-10-11 04:28:42     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103786   

Hi Steven,

What is the best way to stop my network driver.

Why this wasn't the case before, is the new icc version have a diferent memory structure than previously?

Thanks,

William

QuoteReplyEditDelete

2011-10-11 04:30:53     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103787   

as well, how can I make work my network driver in the same time as the icc multicore processes?

Is there is any tools I can use to debug and track those type of memory conflict?

Thanks,

William

QuoteReplyEditDelete

2011-10-11 04:40:33     Re: CORE B: error message type

steven miao (CHINA)

Message: 103788   

Hi William,

can you try make clean icc_core and rebuild it, the L2 message address is 0xFEB18000, you can check this memory region

with jtag tool.

btw, did you disable L2 cache in kernel config

  docs.blackfin.uclinux.org/doku.php?id=test_icc_on_bf561

-steven

QuoteReplyEditDelete

2011-10-11 06:03:29     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103789   

Hi Steven,

I did do a make clean of icc_core

I did disable L2 cache in the kernel config, here is the screen shot of my config to make sure (I'm using a previous kernel version thoughof a month and half old already load in my dev board):

      *** Cache Support ***                                        │ │

  │ │    [*] Enable ICACHE                                                │ │

  │ │    [*]   Enable ICACHE for external memory                          │ │

  │ │    [ ]   Enable ICACHE for L2 SRAM                                  │ │

  │ │    [*] Enable DCACHE                                                │ │

  │ │    [ ]   Enable only 16k BankA DCACHE - BankB is SRAM               │ │

  │ │    [*]   Enable DCACHE for external memory                          │ │

  │ │            External memory DCACHE policy (Write through)  --->      │ │

  │ │    [ ]   Enable DCACHE for L2 SRAM 

I have as well icc protocole enable:

--- icc driver                                                   │ │

  │ │    [*]   icc protocol

Just have seen an new option (icc_debug) I'm using the kernel version on my board:

Linux version 3.0.0-ADI-2011R1-pre-svn10064

in the kernel load I get:

Blackfin L1 Data A SRAM: 16 KB (16 KB free)                                   

Blackfin L1 Data B SRAM: 16 KB (16 KB free)                                   

Blackfin L1 Instruction SRAM: 16 KB (3 KB free)                               

Blackfin L2 SRAM: 128 KB (128 KB free)

Instruction Cache Enabled for CPU0                                            

  External memory: cacheable in instruction cache                             

  L2 SRAM        : uncacheable in instruction cache                           

Data Cache Enabled for CPU0                                                   

  External memory: cacheable (write-through) in data cache                    

  L2 SRAM        : uncacheable in data cache 

Memory map:                                                                   

  fixedcode = 0x00000400-0x00000490                                           

  text      = 0x00001000-0x00157830                                           

  rodata    = 0x00157830-0x001dd0a8                                           

  bss       = 0x001de000-0x001ee760                                           

  data      = 0x001ee760-0x00208000                                           

    stack   = 0x00206000-0x00208000                                           

  init      = 0x00208000-0x008ae000                                           

  available = 0x008ae000-0x03800000                                           

  DMA Zone  = 0x03f00000-0x04000000

When I kill dhcpd after upload of the icc and icc_loader via tftp I still have the same error.

is there is another program to kill for the ethernet driver?

I'v connect to my JTAG and run :

bfin-gdbproxy bfin

in one screen on my pc and

bfin-elf-gdb

in the other, but I'm not sur how to link to the kernel program or check the memory map. could you give me the set of instruction to do so.

Thanks,

William

QuoteReplyEditDelete

2011-10-11 06:30:04     Re: CORE B: error message type

steven miao (CHINA)

Message: 103790   

Hi William,

I tried the lastest kernel and icc_utils, this error didn't appears, I also used ethernet and tftp to load the images, so it wasn't caused by ethernet. Can you update your kernel to the lastest revision, and rebuild both kernel and icc(icc depends on kernel), the kernel should match with the icc.

If you want to use jtag debugger

1. bfin-gdbproxy bfin

2. bfin-elf-gdb

3. in gdb console, attach the targe board with "target remote :2000"

then you can check the memory by "x/64  0xFEB18000"

for details pls ref:

https://docs.blackfin.uclinux.org/doku.php?id=toolchain:debug:gdbproxy

-steven

QuoteReplyEditDelete

2011-10-11 09:03:13     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103792   

Hi Steven,

Yes that was it, my uCLinux kernel version was too old,

./icc_loader -l icc does load propely the core icc in the core B

However I have another problem now that must be related to my code (tell me if you prefer I create a new thread)

I've created a bare metal version of FreeRTOS converted from the VDSP version So I can run FreeRTOS under the Core B for my real time DSP operations.

so when I load my basic compiled application of FreeRTOS on core B I've got :

COREB: execption 26 addr 3c0045c                                              

COREB: execption 24 addr 3c0045c

I've look in the icc core code and it seem to be code by the assembler file via the function dump_execption:

ENTRY(_evt_evt3)

        [--sp] = SYSCFG;                                                      

        [--sp] = P0;        /*orig_p0*/                                       

        [--sp] = R0;        /*orig_r0*/                                       

        [--sp] = (R7:0,P5:0);                                                 

        P0.H = HI(0xFEB1FFFC);                                                

        P0.L = LO(0xFEB1FFFC);                                                

        r0 = SEQSTAT;                                                         

        r0 <<= 26;

        r0 >>= 26;                                                            

        r1 = retx;                                                            

        call _dump_execption;                                                 

        [P0] = r0;                                                            

        (R7:0,P5:0) = [SP++];                                                 

        sp += 8;        /* Skip orig_r0/orig_p0 */                            

        csync;                                                                

        SYSCFG = [sp++];                                                      

        csync;           

        rtx;                                                                  

ENDPROC(_evt_evt3)

Could you tell me what would be the reason that could trigger such error?

Looking at the processor doc, this is trigger due to a core exception (EVT3), what could trigger a core exception?

Thanks again for your help

William

QuoteReplyEditDelete

2011-10-11 22:05:53     Re: CORE B: error message type

steven miao (CHINA)

Message: 103797   

Hi William,

so you want to load freertos to coreB, how did you compile and link the freertos? And what is the file format of freertos image, is it a ELF format?

I've put a dum_exception function to dump exception cause code, you can ref "Program Sequencer" section of bf561 hrm for details, code 24 means Attempted misaligned data memory or data cache access while code 26 means Used by the MMU to signal a CPLB miss on a data access and the fault address is 0x3c0045c, you can check the code there might be a bad address around.

-steven

QuoteReplyEditDelete

2011-10-11 23:31:19     Re: CORE B: error message type

Sonic Zhang (CHINA)

Message: 103799   

Yes, please create new thread for new questions.