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.

Detecting AM1808 with/without DSP

Other Parts Discussed in Thread: AM1808, OMAPL138I would like to be able to detect if a DSP is present as some of our products use an OMAP L138 and some use a AM1808. We use the DSP to improve performance on the products but we can operate without it.

Is there a way I can tell on the ARM core from linux userland program or a kernel module if there is a DSP present?

  • Hi Roger,

    Currently I don't have a AM1808 board with me to test.

    NMI pin is the difference between AM1808 & OMAPL138.

    How did you connect the NMI pin ?

    Try to do something with NMI pin.

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/99335/347816.aspx#347816

  • The NMI pin is pulled up to 3v3 with a 10k resistor.

    I was hoping to be able to read a register or memory etc to find a different id. We have a board-id set on GPIO pins that I can get updated but thought ir wold be good to be able to check the silicon itself.

  • Never done this myself. In theory the ARM can try to write to the DSP L2 RAM at address 0x11800000. If the DSP is there, is will be successful. A bit of a danger, on a system with a DSP, it could corrupt the whatever is running on the DSP.

  • Thanks for the suggestion, I just tried using a userland program and mmap'ing the DSP L2 RAM
    roger # ./detect-omap 
    fd=3 offset=0x11800000 len=1024 (0x00000400)
    mem=0xb6efd000
    old=e0f9e752 new=01234567 val=01234567
    
    and it appears to remember the value I write - this is on a AM1808 The code I used is
    /*
     * detect omap (dsp) verion of AM1808 by writing and reading from the
     * DSP RAM at address 0x11800000
     */
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    
    int main(int argc, char *argv[])
    {
        off_t offset = 0x11800000;          // DSP L2 RAM
        int len = 1024;
    
        int fd = open("/dev/mem", O_SYNC | O_RDWR);
        printf("fd=%d offset=0x%08x len=%d (0x%08x)\n", fd, (unsigned int)offset, len, len);
        unsigned int * mem = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, offset);
        if (!mem) {
            printf("Can't map memory - %d %s\n", errno, strerror(errno));
            return 1;
        }
        printf("mem=%p\n", mem);
    
        unsigned int v = 0x1234567;
        unsigned int old = *mem;
        *mem = v;
        unsigned int new = *mem;
    
        printf("old=%08x new=%08x val=%08x\n", old, new, v);
        return 0;
    }
    
  • Well that is surprising. Implies bonus SRAM on the AM1808.

    Your test code might be optimizing the write and read operations. Try putting a "volatile" on the declaration of "mem". Or try the command "devmem". It does the same thing as your test code but is just reads or it just writes. Compiler cannot optimize out the accesses.

  • Here are some more results incl. a walking bit. This also shows that the 01234567 was written as when I run it again it is there. The code is compiled with no optimisation, but just in case I added the volatile.

    Looks like I have some bonus memory... :-)

    rrc-roger # ./detect-omap 
    fd=3 offset=0x11800000 len=1024 (0x00000400)
    mem=0xb6f9e000
    old=01234567 new=01234567 val=01234567
    b=00000001 mem=00000001
    b=00000002 mem=00000002
    b=00000004 mem=00000004
    b=00000008 mem=00000008
    b=00000010 mem=00000010
    b=00000020 mem=00000020
    b=00000040 mem=00000040
    b=00000080 mem=00000080
    b=00000100 mem=00000100
    b=00000200 mem=00000200
    b=00000400 mem=00000400
    b=00000800 mem=00000800
    b=00001000 mem=00001000
    b=00002000 mem=00002000
    b=00004000 mem=00004000
    b=00008000 mem=00008000
    b=00010000 mem=00010000
    b=00020000 mem=00020000
    b=00040000 mem=00040000
    b=00080000 mem=00080000
    b=00100000 mem=00100000
    b=00200000 mem=00200000
    b=00400000 mem=00400000
    b=00800000 mem=00800000
    b=01000000 mem=01000000
    b=02000000 mem=02000000
    b=04000000 mem=04000000
    b=08000000 mem=08000000
    b=10000000 mem=10000000
    b=20000000 mem=20000000
    b=40000000 mem=40000000
    b=80000000 mem=80000000
    
    /*
     * detect omap (dsp) verion of AM1808 by writing and reading from the
     * DSP RAM at address 0x11800000
     */
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    
    int main(int argc, char *argv[])
    {
        off_t offset = 0x11800000;          // DSP L2 RAM
        int len = 1024;
    
        int fd = open("/dev/mem", O_SYNC | O_RDWR);
        printf("fd=%d offset=0x%08x len=%d (0x%08x)\n", fd, (unsigned int)offset, len, len);
        volatile unsigned int * mem = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, offset);
        if (mem == NULL) {
            printf("Can't map memory - %d %s\n", errno, strerror(errno));
            return 1;
        }
        printf("mem=%p\n", mem);
    
        unsigned int v = 0x1234567;
        unsigned int old = *mem;
        *mem = v;
        unsigned int new = *mem;
        printf("old=%08x new=%08x val=%08x\n", old, new, v);
    
        unsigned int b;
        for (b = 1; b != 0; b <

  • Hmmm....makes me wonder if the AM1808 is an OMAP-L148 with a DSP that failed tests and the C6748 is an OMAP-L148 with an ARM that failed tests. I wonder if that is what the DEVIDR0 is the same for all three families and derivatives. Anyhow, TI could take away the bonus SRAM at anytime and it doesn't not solve your problem. That's all I got.