[ECOS] redboot elf loader

[ECOS] redboot elf loader

[Artur Lipowski]

Hi,

The problem is that I try use different LMA and VMA values in linker 
script and it seems that redboot loader uses (IMHO wrong) VMA instead of 
LMA as a destination address.

The result I want to achieve is to put some code (ISR) in fast internal 
uC memory but because it cannot be done directly during code loading 
phase I do it "manually" by relocating code from initial loading address 
(LMA) to destination address (VMA).
After I change a few lines of loader source (it now uses LMA address as 
a destination) all works (for me) very well but I am not sure if it is 
right solution.

Regards,
-- 
Artur Lipowski


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Gary Thomas]

On Mon, 2003-09-29 at 04:52, Artur Lipowski wrote:
> Hi,
> 
> The problem is that I try use different LMA and VMA values in linker 
> script and it seems that redboot loader uses (IMHO wrong) VMA instead of 
> LMA as a destination address.
> 
> The result I want to achieve is to put some code (ISR) in fast internal 
> uC memory but because it cannot be done directly during code loading 
> phase I do it "manually" by relocating code from initial loading address 
> (LMA) to destination address (VMA).
> After I change a few lines of loader source (it now uses LMA address as 
> a destination) all works (for me) very well but I am not sure if it is 
> right solution.
> 

Please show us what you've done (as is, this sounds like Fermat's last
theorem!)  I'd like to understand why you think the current behaviour
is wrong and how it should behave.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Gary Thomas]

Please copy your replies to the mailing list so that everyone can
benefit.

On Mon, 2003-09-29 at 06:37, Artur Lipowski wrote:
> Gary Thomas wrote:
> 
> > Please show us what you've done (as is, this sounds like Fermat's last
> > theorem!)  I'd like to understand why you think the current behaviour
> > is wrong and how it should behave.
> 
> I have following definitions in the linker script:
> ........
> MEMORY
> {
>      sram : ORIGIN = 0, LENGTH = 8K
>      ram : ORIGIN = 0x02000000, LENGTH = 512K
> }
> .....
> /* here are standard (GCC) sections */
> ......
> . = ALIGN(4);
> _end = .; PROVIDE (end = .);
> .vectors 0x0 : AT ( _end )
>      	{
> 		_v_start = .;
>      		*(.vectors)
> 	} > sram
> _v_end = .;
> ....
> 
> I wrote some assembler routines and place them in section ".vectors". My 
> startup code performs copying from address _v_start to address 0.
> 
> Without changes in load.c the redboot loader reports error which says 
> that it cannot load code at address 0 because it is outside of the RAM 
> region. It is true but it also means that the loader does not respect 
> load address embedded in the elf binary.

Sorry, but it's supposed to work this way.  I would entertain patches 
that allow for a switch to override this (checking) behaviour, but 
simply disabling it is not acceptable.

Also, there have been recent changes to RedBoot which would allow for
your SRAM section to be defined as a usable memory region that fixes
this problem.  This is done on a platform basis - look at the MOAB 
(PowerPC) platform for an example.

> Output of the "arm-elf-objdump -h" shows that there are proper values of 
> the LMA and VMA in the elf image:
> hello.elf:     file format elf32-littlearm
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>    0 .text         000068f8  02010000  02010000  00000080  2**2
>                    CONTENTS, ALLOC, LOAD, CODE
>    1 .data         00000da8  020168f8  020168f8  00006978  2**2
>                    CONTENTS, ALLOC, LOAD, DATA
>    2 .bss          00000224  020176a0  020176a0  00007720  2**5
>                    ALLOC
>    3 .vectors      00000094  00000000  020178c4  00007720  2**2
>                    CONTENTS, ALLOC, LOAD, CODE
> 
> Changes I made in load.c are very simple, instead of using the p_vaddr 
> field I use the p_paddr filed of the Elf32_Phdr structure in the 
> load_elf_image function.

How about sending a patch which shows this more fully?

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Artur Lipowski]

Gary Thomas wrote:
...
> Also, there have been recent changes to RedBoot which would allow for
>  your SRAM section to be defined as a usable memory region that fixes
>  this problem.  This is done on a platform basis - look at the MOAB 
> (PowerPC) platform for an example.
Not exactly, because this region cannot be loaded (written) by redboot
(AFAIK there are ISR vectors and redboot data). After my program takes 
control it destroys it at all.

I am not sure if we really think about the same - my poor Eglish, sorry 
for that 8-)
During startup I want to put (relocate) some code at address 0 which not 
available during program loading phase, so I declare (in linker script) 
that virtual addres of the section is 0 and load address is somewhere 
after BSS section in conventional RAM. Now I expect that elf loader 
place my code at the load address (LMA) _not_ at virtual address (VMA). 
And even more, I think that loader cannot efectively check VMA ranges 
because of MMU and other things. It can and should check only load 
addresses.
Am I right?

> How about sending a patch which shows this more fully?
No problem, below patch against version included in eCos 2.0

--- ecos/packages/redboot/current/src/load.c        2003-09-29
09:41:47.858057600 +0200
+++ dropzone/load.c     2003-09-29 14:13:38.000000000 +0200
@@ -340,8 +333,8 @@
          // Set address offset based on lowest address in file.
          addr_offset = 0xFFFFFFFF;
          for (phx = 0;  phx < ehdr.e_phnum;  phx++) {
-            if (phdr[phx].p_vaddr < addr_offset) {
-                addr_offset = phdr[phx].p_vaddr;
+            if (phdr[phx].p_paddr < addr_offset) {
+                addr_offset = phdr[phx].p_paddr;
              }
          }
          addr_offset = (unsigned long)base - addr_offset;
@@ -351,7 +344,7 @@
      for (phx = 0;  phx < ehdr.e_phnum;  phx++) {
          if (phdr[phx].p_type == PT_LOAD) {
              // Loadable segment
-            addr = (unsigned char *)phdr[phx].p_vaddr;
+            addr = (unsigned char *)phdr[phx].p_paddr;
              len = phdr[phx].p_filesz;
              if ((unsigned long)addr < lowest_address) {
                  lowest_address = (unsigned long)addr;

Regards,
-- 
Artur Lipowski


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Gary Thomas]

On Mon, 2003-09-29 at 07:36, Artur Lipowski wrote:
> Gary Thomas wrote:
> ...
> > Also, there have been recent changes to RedBoot which would allow for
> >  your SRAM section to be defined as a usable memory region that fixes
> >  this problem.  This is done on a platform basis - look at the MOAB 
> > (PowerPC) platform for an example.
> Not exactly, because this region cannot be loaded (written) by redboot
> (AFAIK there are ISR vectors and redboot data). After my program takes 
> control it destroys it at all.
> 
> I am not sure if we really think about the same - my poor Eglish, sorry 
> for that 8-)
> During startup I want to put (relocate) some code at address 0 which not 
> available during program loading phase, so I declare (in linker script) 
> that virtual addres of the section is 0 and load address is somewhere 
> after BSS section in conventional RAM. Now I expect that elf loader 
> place my code at the load address (LMA) _not_ at virtual address (VMA). 
> And even more, I think that loader cannot efectively check VMA ranges 
> because of MMU and other things. It can and should check only load 
> addresses.
> Am I right?

It may not even be possible for this to work at all, since that memory
may be actively used by the loader (hence the checks).

I'd suggest that you leave this to your startup code.  Have it copy the
data from the VMA to the LMA - that's how we handle it in eCos.

> 
> > How about sending a patch which shows this more fully?
> No problem, below patch against version included in eCos 2.0
> 
> --- ecos/packages/redboot/current/src/load.c        2003-09-29
> 09:41:47.858057600 +0200
> +++ dropzone/load.c     2003-09-29 14:13:38.000000000 +0200
> @@ -340,8 +333,8 @@
>           // Set address offset based on lowest address in file.
>           addr_offset = 0xFFFFFFFF;
>           for (phx = 0;  phx < ehdr.e_phnum;  phx++) {
> -            if (phdr[phx].p_vaddr < addr_offset) {
> -                addr_offset = phdr[phx].p_vaddr;
> +            if (phdr[phx].p_paddr < addr_offset) {
> +                addr_offset = phdr[phx].p_paddr;
>               }
>           }
>           addr_offset = (unsigned long)base - addr_offset;
> @@ -351,7 +344,7 @@
>       for (phx = 0;  phx < ehdr.e_phnum;  phx++) {
>           if (phdr[phx].p_type == PT_LOAD) {
>               // Loadable segment
> -            addr = (unsigned char *)phdr[phx].p_vaddr;
> +            addr = (unsigned char *)phdr[phx].p_paddr;
>               len = phdr[phx].p_filesz;
>               if ((unsigned long)addr < lowest_address) {
>                   lowest_address = (unsigned long)addr;
> 
> Regards,
> -- 
> Artur Lipowski
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Mark Salter]

>>>>> Gary Thomas writes:

> I'd suggest that you leave this to your startup code.  Have it copy the
> data from the VMA to the LMA - that's how we handle it in eCos.

Actually, we copy LMA to VMA. That is, for ROM startup the .data section
has a VMA in RAM and an LMA in ROM. I tend to believe that the ELF loader
should indeed be using LMA addresses.

--Mark

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Gary Thomas]

On Mon, 2003-09-29 at 08:00, Mark Salter wrote:
> >>>>> Gary Thomas writes:
> 
> > I'd suggest that you leave this to your startup code.  Have it copy the
> > data from the VMA to the LMA - that's how we handle it in eCos.
> 
> Actually, we copy LMA to VMA. That is, for ROM startup the .data section
> has a VMA in RAM and an LMA in ROM. I tend to believe that the ELF loader
> should indeed be using LMA addresses.
> 

How could this work for this example - loading via LMA into memory
that RedBoot clearly needs while running?

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Artur Lipowski]

Gary Thomas wrote:
> It may not even be possible for this to work at all, since that memory
> may be actively used by the loader (hence the checks).
But problem(?) is that checks are performed on the VMA instead of LMA 
(as I expected).

> I'd suggest that you leave this to your startup code.  Have it copy the
> data from the VMA to the LMA - that's how we handle it in eCos.
It also exactly is what I do now, but it cannot be done with existing 
(redboot) code because loader prohibits definition of the VMA at the 
unknown (to the redboot) address.

Regards,
-- 
Artur Lipowski


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Mark Salter]

>>>>> Gary Thomas writes:

> On Mon, 2003-09-29 at 08:00, Mark Salter wrote:
>> >>>>> Gary Thomas writes:
>> 
>> > I'd suggest that you leave this to your startup code.  Have it copy the
>> > data from the VMA to the LMA - that's how we handle it in eCos.
>> 
>> Actually, we copy LMA to VMA. That is, for ROM startup the .data section
>> has a VMA in RAM and an LMA in ROM. I tend to believe that the ELF loader
>> should indeed be using LMA addresses.
>> 

> How could this work for this example - loading via LMA into memory
> that RedBoot clearly needs while running?

If that is the case, then the example is broken. My reading was that
the VMA was 0x0 and LMA was somewhere where the other parts of the
program lives. My point is that the LMA is where a loader should put
sections (Load Memory Address) and VMA is where the running program
actually accesses the sections.

--Mark



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Artur Lipowski]

Mark Salter wrote:
>>>>>>Gary Thomas writes:
...
>>How could this work for this example - loading via LMA into memory
>>that RedBoot clearly needs while running?
> 
> If that is the case, then the example is broken. My reading was that
> the VMA was 0x0 and LMA was somewhere where the other parts of the
> program lives. My point is that the LMA is where a loader should put
...
Exactly what I need.

Regards,
-- 
Artur Lipowski


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Gary Thomas]

On Mon, 2003-09-29 at 08:17, Mark Salter wrote:
> >>>>> Gary Thomas writes:
> 
> > On Mon, 2003-09-29 at 08:00, Mark Salter wrote:
> >> >>>>> Gary Thomas writes:
> >> 
> >> > I'd suggest that you leave this to your startup code.  Have it copy the
> >> > data from the VMA to the LMA - that's how we handle it in eCos.
> >> 
> >> Actually, we copy LMA to VMA. That is, for ROM startup the .data section
> >> has a VMA in RAM and an LMA in ROM. I tend to believe that the ELF loader
> >> should indeed be using LMA addresses.
> >> 
> 
> > How could this work for this example - loading via LMA into memory
> > that RedBoot clearly needs while running?
> 
> If that is the case, then the example is broken. My reading was that
> the VMA was 0x0 and LMA was somewhere where the other parts of the
> program lives. My point is that the LMA is where a loader should put
> sections (Load Memory Address) and VMA is where the running program
> actually accesses the sections.
> 

Agreed, and if LMA != VMA, then it would be up to the code (loaded 
program) to relocate it as appropriate.  So, the real question becomes
is the LMA stored in the p_paddr field (just making sure I understand
the terminology)?  If so, then the patch from Artur would be the correct
solution.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Mark Salter]

>>>>> Gary Thomas writes:

> On Mon, 2003-09-29 at 08:17, Mark Salter wrote:
>> >>>>> Gary Thomas writes:
>> 
>> > On Mon, 2003-09-29 at 08:00, Mark Salter wrote:
>> >> >>>>> Gary Thomas writes:
>> >> 
>> >> > I'd suggest that you leave this to your startup code.  Have it copy the
>> >> > data from the VMA to the LMA - that's how we handle it in eCos.
>> >> 
>> >> Actually, we copy LMA to VMA. That is, for ROM startup the .data section
>> >> has a VMA in RAM and an LMA in ROM. I tend to believe that the ELF loader
>> >> should indeed be using LMA addresses.
>> >> 
>> 
>> > How could this work for this example - loading via LMA into memory
>> > that RedBoot clearly needs while running?
>> 
>> If that is the case, then the example is broken. My reading was that
>> the VMA was 0x0 and LMA was somewhere where the other parts of the
>> program lives. My point is that the LMA is where a loader should put
>> sections (Load Memory Address) and VMA is where the running program
>> actually accesses the sections.
>> 

> Agreed, and if LMA != VMA, then it would be up to the code (loaded 
> program) to relocate it as appropriate.  So, the real question becomes
> is the LMA stored in the p_paddr field (just making sure I understand
> the terminology)?  If so, then the patch from Artur would be the correct
> solution.

Yes, VMA == p_vaddr and LMA == p_paddr.

--Mark



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot elf loader

[Gary Thomas]

On Mon, 2003-09-29 at 08:43, Mark Salter wrote:
> >>>>> Gary Thomas writes:
> 
> > On Mon, 2003-09-29 at 08:17, Mark Salter wrote:
> >> >>>>> Gary Thomas writes:
> >> 
> >> > On Mon, 2003-09-29 at 08:00, Mark Salter wrote:
> >> >> >>>>> Gary Thomas writes:
> >> >> 
> >> >> > I'd suggest that you leave this to your startup code.  Have it copy the
> >> >> > data from the VMA to the LMA - that's how we handle it in eCos.
> >> >> 
> >> >> Actually, we copy LMA to VMA. That is, for ROM startup the .data section
> >> >> has a VMA in RAM and an LMA in ROM. I tend to believe that the ELF loader
> >> >> should indeed be using LMA addresses.
> >> >> 
> >> 
> >> > How could this work for this example - loading via LMA into memory
> >> > that RedBoot clearly needs while running?
> >> 
> >> If that is the case, then the example is broken. My reading was that
> >> the VMA was 0x0 and LMA was somewhere where the other parts of the
> >> program lives. My point is that the LMA is where a loader should put
> >> sections (Load Memory Address) and VMA is where the running program
> >> actually accesses the sections.
> >> 
> 
> > Agreed, and if LMA != VMA, then it would be up to the code (loaded 
> > program) to relocate it as appropriate.  So, the real question becomes
> > is the LMA stored in the p_paddr field (just making sure I understand
> > the terminology)?  If so, then the patch from Artur would be the correct
> > solution.
> 
> Yes, VMA == p_vaddr and LMA == p_paddr.
> 

Fair enough - I've made this change.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss