• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 2842 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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?

AlexRast
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)                    
    }

            

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

    I've worked with the armlink for sometime.  On many occassions I have cursed it, but usually turns out to be my mistake not its.  I do not see anything wrong with the scatter file as such - but I'd need the objects to be able see what it does.  As I guess you won't want to post them to a public forum I'd suggest contacting ARM's support group (support@arm.com).  Be prepared, they will probably ask for a test case.


    Here is the source code, including the makefile. It's pretty complex, so here's a bit of explanation: Directory Common holds sources that are common across different chip instantiations. There are, in fact, multiple such instantiations, but to simplify things enough to understand them, I've used the specific one I've been using to try to debug the problems. Code specific to that instantiation is in ThresholdInput. Each directory has its associated Inc and Src folders which should be self-explanatory.

    You can probably guess this, but the chip itself has, in addition to the ARM itself, several other devices: an interrupt controller, a DMA controller, a packet-based communications controller, 2 different external memories (a global SRAM and DRAM), and a packet router. It works in the context of a multiprocessor system designed to do neural networks.

    Most of the instantiation-specific code is in main.c. There are 3 additional object definition source files for the 3 sources of data memory: DTCM, SDRAM, and SRAM. Sources in the common directory, meanwhile, handle such things as service routines, interrupts, a bit of device driver-like functionality, and some static DTCM variables.

    Don't worry about any run-time bugs you may encounter if you can get the thing to create a loadable, bootable configuration. What I'm interested at at this point is simply to know why it doesn't seem to create a bootable image and what workarounds are necessary to fix that problem.

    Again, I'll mention that I *have*, on random occasions, managed to create a bootable image that loads and even appears to run correctly. What's frustrating is, now I need to make modifications to add additional functionality and I can't seem to find a consistent process that lets me do that. In that context I also ought to emphasize that you can't assume, if you make some modifications and it works, that you've *fixed* the problem, only that you've found one particular combination of source code, scatter file, and compiler/linker settings, that happens to work. Any change to the source could be enough to break it again. So I need not just an empirical solution but some sort of systematic explanation of what's going on.
  • Arm Employee Badge
    Note: This was originally posted on 17th July 2009 at http://forums.arm.com

    I've worked with the armlink for sometime.  On many occassions I have cursed it, but usually turns out to be my mistake not its.  I do not see anything wrong with the scatter file as such - but I'd need the objects to be able see what it does.  As I guess you won't want to post them to a public forum I'd suggest contacting ARM's support group (support@arm.com).  Be prepared, they will probably ask for a test case.