Re: PATCH BFD section load page support

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Fri, 14 Jan 2000 17:15:46 -0500
   From: Timothy Wall <twall@tiac.net>

I still don't fully understand this load page stuff.  I will make
series of statements.  Please tell me if any are false:

* Each section in a fully linked file has a VMA, and LMA, and a load
  page number.
* The VMA is 32 bits.
* The LMA is 32 bits.
* The load page number is 8 bits.
* Object files do not have an LMA or a load page number.  They only
  have a VMA.  The load page number field in the object file is always
  0.
* You have changed the linker MEMORY command.  You have changed it to
  add a load page number for each memory region.  The effect of the
  change is that each output section which is placed in a specific
  memory region inherits the load page number of that memory region.
  Sections which are not placed in a memory region (which is all
  sections if the MEMORY command is not used) get a load page number
  of 0.

Now, here's something I don't understand.  How does the chip address
physical memory?  Does it send out a 32 bit address along with an 8
bit load page?  That is, does it effectively have a 40 bit physical
address?

   In general, the linker uses the memory pages when allocating sections in
   memory; two sections targeted for different memory pages may have the same
   memory address (which is usually how vma allocation works).  Run-time (vma)
   pages are ignored by the linker since they don't really matter until runtime;
   the lma pages are what is stored (load_page) with each section so that A)
   they can be put in the appropriate location (or omitted) when building a ROM
   image or B) put in the appropriate place by a run-time loader or debugger.

You seem to be describing a system in which the load page is
effectively part of the physical memory address--the LMA.

   Typical usage has page 0 correspond to PROG space on TI devices, and page 1
   to DATA space (the 'c54x and several other chips have a dual, orthogonal
   address space).  Up to 256 distinct pages are allowed;  typically target
   designs provide a method for switching among pages.

Switching between pages makes it sound like overlays.  What happens if
an object loaded into 1 page refers to an object loaded in another
page?  How does the linker handle such a relocation?  How does the
chip implement it?

   The TI COFF output stores a "memory page" field in the section header; there
   is no documentation and the interpretation as the "load-time page" of the
   section comes from examining how it is actually used by TI's tools

Is the memory page field used in object files?  In files produced by
ld -r?  Or only in fully linked files?

I note that include/coff/tic80.h has a s_mempage field in
external_scnhdr.  However, it is not used by the code.  It is actually
zeroed out, because coffswap.h assumes that the s_flags field is 4
bytes long, not 2 bytes as in tic80.h.

   Date: Fri, 14 Jan 2000 17:29:32 -0500
   From: Timothy Wall <twall@tiac.net>

   As a "memory page", it is indeed "general" information (there are many DSPs
   which use multiple memory pages).  In the linker, I simply called the field
   "page" where it was added to the output section structures.

I guess I don't understand what a memory page means in an input file.

In an output file, it might mean something, in an environment which
used an unusual object file format (such as yours) which could
represent it.  I suspect that most environment for which this is
meaningful simply use bits in the LMA.  Otherwise, you can not
generate S-record or binary files, and it generally becomes more
difficult to use common tools.

   Date: Fri, 14 Jan 2000 21:54:20 -0500
   From: Timothy Wall <twall@tiac.net>

   Program memory (PAGE 0)
   0x0000-0x007F external
   0x0080-0x13FF on-chip DARAM
   0x1400-0x8FFF external
   0x9000-0xFF7F ROM
   0xFF80-0xFFFF interrupt vectors

   Data memory (PAGE 1)
   0x0000-0x005F memory-mapped registers
   0x0060-0x007F scratch-pad DARAM
   0x0080-0x13FF on-chip DARAM
   0x1400-0xDFFF external
   0xE000-0xFEFF on-chip ROM
   0xFF00-0xFFFF reserved

This makes it seem as though the LMA is only 16 bits, implying that
the physical address is 24 bits.  In this case, we can simply use the
upper bits of BFDs lma field to hold the load page.

But I somehow doubt it's that simple.

Ian