This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RVDS 3.1: Bug in Linker with complex scatter file?

Note: This was originally posted on 17th July 2009 at http://forums.arm.com

I'm encountering absolutely bizarre behaviour with a complex scatter file for an ARM968. The linker doesn't seem to be able reliably to create a workable image. The normal symptom is that it never gets past the ARM library code - it gets stuck there. In SoC Designer simulator, it proceeds to a certain point and then does an "ApplicationExit, stopping simulation", generally after reaching an endless loop in the ARM library. This seems to occur in that part of the library responsible for copying the image to ITCM and DTCM. It never branches to start.s or any of my boot code.

The central issue is that I've got memory-mapped devices that I need to fix in the memory map. These devices contain, among other things, large arrays (that are configured at boot time). I did some playing around and have found that the behaviour is extremely erratic, depending on the precise configuration of the scatter file and sources. Basically, I can sometimes get the code to work OK with different combinations of using separate .c files for some of the device addresses, .ARM.__at_xxx attributes for others. But there's no consistent pattern. In addition to the "standard pathology" some combinations give the "scatter-loading of section xxx will cause section yyy to be corrupted" message, even though the regions in question are completely separate in the memory map. I've managed to fix those by altering the size limits of other sections completely unrelated to either of the sections mentioned in the error. The whole thing appears to be a bug - at one point it claimed it couldn't fit a section that I'd set to be 0x1000 bytes long, stating that it was specified as 0 bytes long!

Something very strange is going on here - or I'm missing something very fundamental in the description of scatter files. At the end of the day, what I need to achieve is a way of specifiying the memory map so that multiple discontiguous devices are properly mapped, along with a special function that needs to go at a fixed location in the ITCM.

If no one has an obvious solution to this problem, I suggest that there is a severe bug in the linker. It's not interpreting scatter files correctly. ARM needs to fix this or at least note it.

For your reference, here is my scatter file at the moment (which is constantly in flux due to experimentation). Let me know if you need to see other files.

;; Embedded scatter file

ROM_LOAD 0xffff0000                      ;[load region], needs to be above 968 TCM memory

{

    ROM_EXEC 0xffff0000                  ;[exec region & root region]

    {

        start.o (start, +FIRST)          ; Core initialisation inc TCM enable

                                         ; hi_vectors.o (+RO)

        * (InRoot$$Sections)             ; all that should be placed in root region, detailed below

                                         ;__main.o                         ; C Library entry point, must be in a root region

                                         ;__scatter.o

                                         ;__scatter_copy.o

                                         ;__scatter_zi.o

                                         ;* (Region$$Table)                ; this section must be in a root region

                                         ;* (ZISection$$Table)            ; this section must be in a root region

    }

    VECTORS 0x0 0x100

    {

     vectors.o (Vect,+FIRST)

    }

    DIRQ 0x100 0xFF                      ; fixed region for the DIRQ. Must be no larger than 0xFF or cannot be addressed by a constant.

    {

        main.o (DIRQ,+FIRST)             ; DIRQ call

    }

    I-TCM 0x200 0x7E00                   ; [exec region], built at 0x100 to avoid vector space

    {                                                        ; assumes 32K I-TCM

        main.o (.text,+RO)

        * (+RO-CODE)                     ; any remaining code inc C lib.

    }

    D-TCM 0x0400000 0xE9C0               ; [exec region], beginning of data TCM at 64MB

    {

        dtcm_static.o (+RO,+RW,+ZI)      ;static data variables

        dtcm.o (+RO,+RW,+ZI)                  ;main data variables
        * (RO-DATA,+RW,+ZI)                   ;catch-all for everything else
    }

    ARM_LIB_STACK 0x40EFC0 EMPTY -0x600 ; 6 stacks, 64 entries each

    {                                    ; perfect memory packing would place it at 40EFC8.

    }

    ARM_LIB_HEAP +0 EMPTY 0x1000         ; heap offset just above the stack and grows upwards.

    {

    }



    VectorTable 0x410000 EMPTY -0x38   ; vector table at the top of DTCM

    {



    }



    ROUTERDF 0xf1000200 UNINIT 0x100
    {
     routerDgF.o(+RW,+RO,+ZI)

    }



    ROUTERDC 0xf1000300 UNINIT 0x100

    {

     routerDgC.o(+RW,+RO,+ZI)

    }



    ROUTERRTE 0xf1004000 UNINIT 0x4000

    {

     routerrte.o(+RW,+RO,+ZI)

    }



    ROUTERKEY 0xf1008000 UNINIT 0x4000

    {

     routerkey.o(+RW,+RO,+ZI)

    }



    ROUTERMSK 0xf100c000 UNINIT 0x4000

    {

     routermsk.o(+RW,+RO,+ZI)

    }



    ROUTERP2P 0xf1010000 UNINIT 0x10000

    {

     routerP2P.o(+RW,+RO,+ZI)

    }



;   ROUTER 0xf1000000 UNINIT 0x1000000          ; unbuffered router configuration access

;   {

;      *(.ARM.__at_0xf1000200)             ; diagnostic counters

;      *(.ARM.__at_0xf1000300)

;      *(.ARM.__at_0xf1004000)             ; keys

;      *(.ARM.__at_0xf1008000)             ; masks

;      *(.ARM.__at_0xf100c000)             ; routes

;      *(.ARM.__at_0xf1010000)             ; point-to-point entries

;   }

    SYS_CONTROL 0xf2000080 UNINIT 0xFFFF80

    {

       *(.ARM.__at_0xf2000080)

    }


    SDRAM 0x70000000 UNINIT 0x10000000    ;unbuffered access to the whole SDRAM.

    {

        sdram.o (+RO-DATA,+RW)
    }

    VIC 0xfffff100 UNINIT 0xEFF

    {

        *(.ARM.__at_0xfffff100)

        *(.ARM.__at_0xfffff200)

    }



    SRAM 0xf5000000 UNINIT 0x8000              ;unbuffered system ram 32k

    {

       sram.o (+RO-DATA,+RW)
    }



}