1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

linking and loading images

Discussion in 'Embedded' started by Bahadir Balban, Nov 14, 2006.

  1. Hi,

    I would like to have your suggestions on how to achieve the following
    in the simplest, cleanest way.

    I have images A and B (and possibly C, D, ... ) to be loaded in
    physical memory one after the other. Each have .text, .data, .bss
    sections. B should be linked at the next page after A ends (so it must
    know where A ends at its link time), also the code in A, should be
    able to know/discover where B is going to be loaded and where it ends
    at its runtime.

    My possible solutions:

    1) If I build A and B as separate images, by first building and
    linking A, the page at which B would start (i.e. the next page after
    A) can be determined. I can easily filter objdump output for A to find
    out where it ends, and include B's start address in B's linker script
    before building it. But I have already built A, so there's the problem
    of patching A's image to insert B's start and end address somewhere,
    and this might be tedious.

    2) I could link the two together using a single linker script. Then
    where each image is loaded would be determined at link time, and each
    image can be aware of where the other is, by simply reading
    linker-defined variables. The problem with this is these are actually
    two different images, objects in them have no relation, also each
    needs to have its own _start address, so that will probably be
    ambiguous. Furthermore, I may need to have images C, D and more. So it
    would quickly get tedious to maintain a single linker script for
    multiple images meant to be independent.

    3) After all images are built, I could compile a data structure with
    all image information, and load that in a predefined region in memory.
    At runtime image A or whoever image wants to discover about the others
    would read this structure from a predefined location.

    Do you have any cleaner, simpler solutions?

    Many thanks,
    Bahadir
     
    Bahadir Balban, Nov 14, 2006
    #1
    1. Advertisements

  2. Bahadir Balban

    johnspeth Guest

    I would like to have your suggestions on how to achieve the following
    I had to deal with similar problem once. I quickly decided on
    something like your #3 solution because it was straightforward and not
    too hard to implement.

    You're right about tedious hand manipulations of linker control files
    based on previous link outputs: after a few rounds of doing that and
    maybe even after dealing with a few hair pulling mistakes, you'll
    eventually end up using your automatic/programmatic solution and never
    regret your final choice.

    JJS
     
    johnspeth, Nov 14, 2006
    #2
    1. Advertisements

  3. Bahadir Balban

    John B Guest

    Yes, use a boot loader.
     
    John B, Nov 14, 2006
    #3
  4. Bahadir Balban

    Tauno Voipio Guest

    If you're using the GNU linker, you could possibly use a combination
    of A) and B).

    First, link the images separately, but so that the output is
    still relocatable.

    Second, locate the images to an output image with a special
    linker script. The script can recognize the modules (A or B)
    in addition to the sections of the input files and locate them
    according to instructions in the script.

    HTH
     
    Tauno Voipio, Nov 14, 2006
    #4
  5. Or use an MMU.
    Assum you have 'n' bytes of memory.
    Allocate 'n' bytes in the page table for image A,
    and 'n' bytes in the page table for image B.

    You now know that Image A starts at address 0 and image B
    starts at address B.
    Allocate physical memory as needed for the two images.


    A simpler alternative is to let image B call a subroutine in image A.
    The subroutine needs to be at a fixed address which is never changed.
    The parameters of the subroutine should be the info A needs to know about B,
    and maybe also include the address of a subroutine in B, so that A
    can return the favour.


    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
     
    Ulf Samuelsson, Nov 14, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.