Wolfgang Denk wrote on 2010/10/04 23:10:31:
>
> Dear Joakim Tjernlund,
>
> In message 0066d...@transmode.se> you wrote:
> >
> > :), actually it wasn't that bad. Wolfgang nearly accepted the code even :)
>
> Yes, I was really tempted because I do appreciate the value of such a
> feature.
>
> > Mai
Le 04/10/2010 18:31, Stefan Roese a écrit :
> On Monday 04 October 2010 17:24:09 Albert ARIBAUD wrote:
>>> Excellent work! Congratulations!
>>
>> Thanks, but I'd suggest to wait for congrats until ethernet works --
>> tough I've got a clue, I think; it may have to do with the core
>> activating its
Dear Joakim Tjernlund,
In message
you
wrote:
>
> :), actually it wasn't that bad. Wolfgang nearly accepted the code even :)
Yes, I was really tempted because I do appreciate the value of such a
feature.
> Mainly, I had to wrap code that accessed global data with a LINK_OFF()
> function
> th
"J. William Campbell" wrote on 2010/10/04
19:59:47:
> On 10/4/2010 10:06 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4ca9f294.8080...@comcast.net> you wrote:
>
> Yes, I think Wolfgang is correct. This is not going to be easy to do in
> general. To run anywhere, the c
On 10/4/2010 10:06 AM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message<4ca9f294.8080...@comcast.net> you wrote:
Yes, I think Wolfgang is correct. This is not going to be easy to do in
general. To run anywhere, the code must be true Position Independent
code. If you intend to use
Dear Graeme Russ,
In message you
wrote:
>
> > That means you need to build all of U-Boot that way, because
> > significant parts of the code already run before relocation
> > (including all clocks and timers setup, console setup, printf and all
> > routines these pull in).
>
> Have a look at x8
Dear "J. William Campbell",
In message <4ca9f294.8080...@comcast.net> you wrote:
>
> Yes, I think Wolfgang is correct. This is not going to be easy to do in
> general. To run anywhere, the code must be true Position Independent
> code. If you intend to use any C code in the initialization, this
On Monday, October 4, 2010, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <4ca999ee.5030...@free.fr> you wrote:
>>
>> Note however that linking for base address 0 is not mandatory for
>> achieving true position independence. What is required is that the code
>> which runs from power-u
On Monday 04 October 2010 17:24:09 Albert ARIBAUD wrote:
> > Excellent work! Congratulations!
>
> Thanks, but I'd suggest to wait for congrats until ethernet works --
> tough I've got a clue, I think; it may have to do with the core
> activating its caches and the driver doing DMA. :)
Yes. Very l
Le 04/10/2010 17:28, J. William Campbell a écrit :
> On 10/4/2010 3:13 AM, Wolfgang Denk wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4ca999ee.5030...@free.fr> you wrote:
>>> Note however that linking for base address 0 is not mandatory for
>>> achieving true position independence. What is requi
On 10/4/2010 3:13 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4ca999ee.5030...@free.fr> you wrote:
>> Note however that linking for base address 0 is not mandatory for
>> achieving true position independence. What is required is that the code
>> which runs from power-up until
Le 04/10/2010 16:25, Rogan Dawes a écrit :
> On 2010/10/04 4:17 PM, Albert ARIBAUD wrote:
>> At this point I have an ARM926, ELF-relocating, u-boot reaching prompt.
>>
>> Environment is correctly read and can be modified (did not try saving
>> though).
>>
>> Flash operations work (flinfo, erase, cp
On 2010/10/04 4:17 PM, Albert ARIBAUD wrote:
> At this point I have an ARM926, ELF-relocating, u-boot reaching prompt.
>
> Environment is correctly read and can be modified (did not try saving
> though).
>
> Flash operations work (flinfo, erase, cp.b).
>
> Ethernet does not work, however -- pin
Le 04/10/2010 10:57, Heiko Schocher a écrit :
>> ./MAKEALL edminiv2 results:
>>
>> text databssdechexfilename
>> 141376 4388 16640 162404 27a64./u-boot (for GOT
>> reloc)
>> 150160 3819 16640 170619 29a7b./u-
Le 04/10/2010 11:58, Graeme Russ a écrit :
> On 04/10/10 19:28, Albert ARIBAUD wrote:
>> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>>> Dear Albert ARIBAUD,
Right now I can build (not run, mind you) u-boot for edminiv2 without
-fPIC/-fPIE, with -pie and a modified u-boot.lds and s
>
> Le 04/10/2010 10:57, Heiko Schocher a écrit :
>
> >> ./MAKEALL edminiv2 results:
> >>
> >> text databssdechexfilename
> >> 141376 4388 16640 162404 27a64./u-boot (for GOT
> >> reloc)
> >> 150160 3819 16640 170619
On 04/10/10 19:28, Albert ARIBAUD wrote:
> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>> Dear Albert ARIBAUD,
>>>
>>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
Any reason to do it in assembl
Le 04/10/2010 09:27, Reinhard Meyer a écrit :
> Dear Albert ARIBAUD,
>>
>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
>> of the .rel.dyn fixup entries are type 23, that is, relative to the base
>>
Albert ARIBAUD wrote on 2010/10/04 10:33:05:
>
> Le 04/10/2010 10:28, Joakim Tjernlund a écrit :
> >>
> >> Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
> >>
> >>> However, I think we will loose the possibility to add "link once, burn and
> >> run anywhere"
> >>> feature I impl. once(but it was
Le 04/10/2010 08:40, Albert ARIBAUD a écrit :
> Right now I can build (not run, mind you) u-boot for edminiv2 without
> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
> of the .rel.dyn fixup entries are type 23, that is, relative to the base
> address, which is good. Howe
Dear Joakim Tjernlund,
In message
you
wrote:
>
> However, I think we will loose the possibility to add "link once, burn and
> run anywhere"
> feature I impl. once(but it was at the time deemed to intrusive) if
> we skip -fPIC and go for the linker -pie relocation.
>
> I would suggest to leave
Dear Albert ARIBAUD,
>
> Right now I can build (not run, mind you) u-boot for edminiv2 without
> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
> of the .rel.dyn fixup entries are type 23, that is, relative to the base
> address, which is good. However, here are about
Dear Albert ARIBAUD,
In message <4ca999ee.5030...@free.fr> you wrote:
>
> Note however that linking for base address 0 is not mandatory for
> achieving true position independence. What is required is that the code
> which runs from power-up until relocation be able to run anywhere, i.e.,
> this
Le 04/10/2010 10:28, Joakim Tjernlund a écrit :
>>
>> Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
>>
>>> However, I think we will loose the possibility to add "link once, burn and
>> run anywhere"
>>> feature I impl. once(but it was at the time deemed to intrusive) if
>>> we skip -fPIC and go f
Dear Peter Tyser,
In message <1286167382.22760.19.ca...@ptyser-laptop> you wrote:
>
> > Peter, could you please fill in the details of that old story?
>
> I haven't been following the ARM relocation thread very closely, but a
> summary of the PPC relocation is:
> - Prior to commit 858290178f222d
Le 04/10/2010 10:52, Joakim Tjernlund a écrit :
> Albert ARIBAUD wrote on 2010/10/04 10:33:05:
>>
>> Le 04/10/2010 10:28, Joakim Tjernlund a écrit :
Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
> However, I think we will loose the possibility to add "link once, burn and
Hello Albert,
Albert ARIBAUD wrote:
> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>> Dear Albert ARIBAUD,
>>>
>>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
>>> of the .rel.dyn fixup entries a
Le 04/10/2010 08:08, Heiko Schocher a écrit :
> Hello Albert,
>
> Albert ARIBAUD wrote:
>> Le 03/10/2010 20:03, Wolfgang Denk a écrit :
>>
>>> Dear Reinhard Meyer,
>>>
>>> In message<4ca6e8e5.2090...@emk-elektronik.de> you wrote:
> And yes, this means the content arrays of pointers such as in
>
> Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
>
> > However, I think we will loose the possibility to add "link once, burn and
> run anywhere"
> > feature I impl. once(but it was at the time deemed to intrusive) if
> > we skip -fPIC and go for the linker -pie relocation.
>
> On ARM at least,
Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
> However, I think we will loose the possibility to add "link once, burn and
> run anywhere"
> feature I impl. once(but it was at the time deemed to intrusive) if
> we skip -fPIC and go for the linker -pie relocation.
On ARM at least, I don't think
>
> Hi Wolfgang,
>
>
>
> > Well, please keep in mind that all this code is working find on
> > PowerPC, which has been using relocation right from the beginning.
> >
> > It is my understanding that we don't suffer from this issue any more
> > on PPC - Peter Tyser posted relocation fixup patches fo
Hello Albert,
Albert ARIBAUD wrote:
> Le 03/10/2010 20:03, Wolfgang Denk a écrit :
>
>> Dear Reinhard Meyer,
>>
>> In message<4ca6e8e5.2090...@emk-elektronik.de> you wrote:
And yes, this means the content arrays of pointers such as init_sequence
is not relocated. Been there, done that,
Hello Wolfgang,
Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message <4ca79896.2010...@emk-elektronik.de> you wrote:
>> I agree here. _If_ relocation, it should work without hand-adding
>> fixup stuff to all functions using initialized data with pointers.
>> Even Wolfgang forgot to fixup hi
Hello Albert,
Albert ARIBAUD wrote:
> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>
>> And as an idea, if position independent code is used, only pointers
>> in initialized data need adjustment. Cannot the linker emit a table
>> of addresses that need fixing?
>
> IIU Bill C, yes the linker can
Hi Wolfgang,
> Well, please keep in mind that all this code is working find on
> PowerPC, which has been using relocation right from the beginning.
>
> It is my understanding that we don't suffer from this issue any more
> on PPC - Peter Tyser posted relocation fixup patches for PPC about a
> y
Le 03/10/2010 20:54, J. William Campbell a écrit :
> Agreed. This should be possible to do now that there is a better
> understanding of the ELF format by the u-boot community. Perhaps the
> place to start would be trying to port what Graeme has done to ARM or
> perhaps better yet, PPC. Since lots
On 10/3/2010 11:29 AM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4ca79896.2010...@emk-elektronik.de> you wrote:
>> I agree here. _If_ relocation, it should work without hand-adding
>> fixup stuff to all functions using initialized data with pointers.
>> Even Wolfgang forgot to f
On 10/3/2010 11:14 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ca75bfb.5030...@comcast.net> you wrote:
> And I think there are more places of this type in u-boot...
Yes, maybe. But relocation as I did for arm, also works
on m68k, sparc, mips, avr32 and th
Dear Albert ARIBAUD,
In message <4ca8ccc1.2010...@free.fr> you wrote:
>
> > Well, please keep in mind that all this code is working find on
> > PowerPC, which has been using relocation right from the beginning.
>
> I don't mean to say that PPC relocation does not work; I mean to say
> that a m
Dear "J. William Campbell",
In message <4ca8a2e0.7090...@comcast.net> you wrote:
>
> executable instructions than programs compiled without these options.
> The program will also contain more data space for the got. If -fPIC
> actually produced a fully position-independent executable, the extra
>
Le 03/10/2010 20:03, Wolfgang Denk a écrit :
> Dear Reinhard Meyer,
>
> In message<4ca6e8e5.2090...@emk-elektronik.de> you wrote:
>>
>>> And yes, this means the content arrays of pointers such as init_sequence
>>> is not relocated. Been there, done that, can give you one of the
>>> tee-shirts I g
Dear Reinhard Meyer,
In message <4ca79896.2010...@emk-elektronik.de> you wrote:
>
> I agree here. _If_ relocation, it should work without hand-adding
> fixup stuff to all functions using initialized data with pointers.
> Even Wolfgang forgot to fixup his 2nd level command table in
> cmd_nvedit.c ;
Dear Reinhard Meyer,
In message <4ca77afa.2090...@emk-elektronik.de> you wrote:
>
> My AT91 boards will not use relocation for the time being, and if
> relocation is god-like enforced I will find a way not to use it.
> I don't need to spend 10% more code for all that trouble.
Please see
http://a
Dear "J. William Campbell",
In message <4ca75bfb.5030...@comcast.net> you wrote:
>
> >>> And I think there are more places of this type in u-boot...
> >> Yes, maybe. But relocation as I did for arm, also works
> >> on m68k, sparc, mips, avr32 and they must do also this
> >> fixups, so for common f
Dear Albert ARIBAUD,
In message <4ca6fb7e.3070...@free.fr> you wrote:
>
> >>> Short answer - the relocation process does not handle pointers inside
> >>> data structures.
> >>>
> >>> And yes, this means the content arrays of pointers such as init_sequence
> >>> is not relocated. Been there, done
Dear Albert ARIBAUD,
In message <4ca6ec99.5080...@free.fr> you wrote:
>
> There are two ways to fix that:
...
We should find the third way, which is that the tools actually
incude these pointers into the GOT so they get relocated
automatically.
Best regards,
Wolfgang Denk
--
DENX Software Eng
Dear Reinhard Meyer,
In message <4ca6e8e5.2090...@emk-elektronik.de> you wrote:
>
> > And yes, this means the content arrays of pointers such as init_sequence
> > is not relocated. Been there, done that, can give you one of the
> > tee-shirts I got :)
It should work.
Eventually we need to find o
Le 03/10/2010 18:47, Albert ARIBAUD a écrit :
> But the .rel.dyn generated by the linker section does not provide
> symbols to mark its start and end, and I have found no documentation in
> binutils ld which would describe how to rewrite the .rel.dyn section and
> add these symbols myself.
>
> How
Le 03/10/2010 17:36, J. William Campbell a écrit :
> Hi All,
> It is for sure that -fPIC/-fPIE programs will contain more executable
> instructions than programs compiled without these options.
> The program will also contain more data space for the got. If -fPIC
> actually produced a fully positi
On 10/3/2010 1:58 AM, Albert ARIBAUD wrote:
> Le 03/10/2010 10:44, Graeme Russ a écrit :
>
>>> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
>>> for relocation. You seem to imply it actually is... In my experience,
>>> -fPIC and-fPIE do increase code by adding GOT relocat
Le 03/10/2010 10:44, Graeme Russ a écrit :
>> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
>> for relocation. You seem to imply it actually is... In my experience,
>> -fPIC and-fPIE do increase code by adding GOT relocation to symbols that
>> need fixing, so they would in
On 03/10/10 18:10, Albert ARIBAUD wrote:
> Le 03/10/2010 01:07, Graeme Russ a écrit :
>> On 03/10/10 08:09, Albert ARIBAUD wrote:
>>> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>>>
And as an idea, if position independent code is used, only pointers
in initialized data need adjustment.
Le 03/10/2010 01:07, Graeme Russ a écrit :
> On 03/10/10 08:09, Albert ARIBAUD wrote:
>> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>>
>>> And as an idea, if position independent code is used, only pointers
>>> in initialized data need adjustment. Cannot the linker emit a table
>>> of addresses
On 03/10/10 08:09, Albert ARIBAUD wrote:
> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>
>> And as an idea, if position independent code is used, only pointers
>> in initialized data need adjustment. Cannot the linker emit a table
>> of addresses that need fixing?
>
> IIU Bill C, yes the linker
Le 02/10/2010 22:39, Reinhard Meyer a écrit :
> And as an idea, if position independent code is used, only pointers
> in initialized data need adjustment. Cannot the linker emit a table
> of addresses that need fixing?
IIU Bill C, yes the linker can emit the information and the startup code
coul
Dear J. William Campbell,
> On 10/2/2010 3:17 AM, Joakim Tjernlund wrote:
>>> Hello Reinhard,
>>>
>>> Reinhard Meyer wrote:
Dear Albert ARIBAUD,
>> I try to understand how the relocation process could handle pointers (to
>> functions or other data) in const or data sections.
>> You
Dear all,
thanks for all the info.
My AT91 boards will not use relocation for the time being, and if
relocation is god-like enforced I will find a way not to use it.
I don't need to spend 10% more code for all that trouble.
Reinhard
___
U-Boot mailing
On 10/2/2010 3:17 AM, Joakim Tjernlund wrote:
Hello Reinhard,
Reinhard Meyer wrote:
Dear Albert ARIBAUD,
I try to understand how the relocation process could handle pointers (to
functions or other data) in const or data sections.
Your code cannot know what is data and what is a pointer that n
> Hello Reinhard,
>
> Reinhard Meyer wrote:
> > Dear Albert ARIBAUD,
> >>> I try to understand how the relocation process could handle pointers (to
> >>> functions or other data) in const or data sections.
> >>> Your code cannot know what is data and what is a pointer that needs
> >>> adjustment?
>
Le 02/10/2010 11:08, Heiko Schocher a écrit :
>>> Short answer - the relocation process does not handle pointers inside
>>> data structures.
>>>
>>> And yes, this means the content arrays of pointers such as init_sequence
>>> is not relocated. Been there, done that, can give you one of the
>
> The
Hello Reinhard,
Reinhard Meyer wrote:
> Dear Albert ARIBAUD,
>>> I try to understand how the relocation process could handle pointers (to
>>> functions or other data) in const or data sections.
>>> Your code cannot know what is data and what is a pointer that needs
>>> adjustment?
>>>
>>> Best Reg
Le 02/10/2010 10:10, Reinhard Meyer a écrit :
> Dear Albert ARIBAUD,
>>> I try to understand how the relocation process could handle pointers (to
>>> functions or other data) in const or data sections.
>>> Your code cannot know what is data and what is a pointer that needs
>>> adjustment?
>>>
>>> B
Dear Albert ARIBAUD,
>> I try to understand how the relocation process could handle pointers (to
>> functions or other data) in const or data sections.
>> Your code cannot know what is data and what is a pointer that needs
>> adjustment?
>>
>> Best Regards,
>> Reinhard
>
> Hi Reinhart,
>
> Short an
Le 02/10/2010 09:15, Reinhard Meyer a écrit :
> Hello Heiko,
>
> I try to understand how the relocation process could handle pointers (to
> functions or other data) in const or data sections.
> Your code cannot know what is data and what is a pointer that needs
> adjustment?
>
> Best Regards,
> Rei
Hello Heiko,
I try to understand how the relocation process could handle pointers (to
functions or other data) in const or data sections.
Your code cannot know what is data and what is a pointer that needs
adjustment?
Best Regards,
Reinhard
___
U-Boot m
65 matches
Mail list logo
