Haavard Skinnemoen wrote:
> On Sat, 26 Jul 2008 14:29:35 -0700
> "J. William Campbell" <[EMAIL PROTECTED]> wrote:
>
>> Haavard Skinnemoen wrote:
>>
>>> On Fri, 25 Jul 2008 22:51:09 +0200
>>> kenneth johansson <[EMAIL PROTECTED]> wrote:
>>>
Can't see any reason for using this
On Sat, 26 Jul 2008 14:29:35 -0700
"J. William Campbell" <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
> > On Fri, 25 Jul 2008 22:51:09 +0200
> > kenneth johansson <[EMAIL PROTECTED]> wrote:
> >> Can't see any reason for using this flag over -fPIC for a program like
> >> u-boot.
> >>
Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 22:51:09 +0200
> kenneth johansson <[EMAIL PROTECTED]> wrote:
>
>
>>> Hmm...looks like linking with -pie (or --pic-executable) does
>>> something vaguely resembling the trick. But I don't know what vintage
>>> of ld you need for this to be availabl
On Sat, 26 Jul 2008 07:36:35 +0200
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> n message <[EMAIL PROTECTED]> you wrote:
> >
> > Ok, I'll stop the chest-beating now. But please stop trying to tell
> > people that adding a powerpc-specific option (which nobody seems to
> > know how really works) to t
On Fri, 25 Jul 2008 22:51:09 +0200
kenneth johansson <[EMAIL PROTECTED]> wrote:
> > Hmm...looks like linking with -pie (or --pic-executable) does
> > something vaguely resembling the trick. But I don't know what vintage
> > of ld you need for this to be available and actually work...
>
> Can't
oen
> Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme
>
> On 01:57 Sat 26 Jul , Grant Likely wrote:
> > On Fri, Jul 25, 2008 at 1:28 PM, kenneth johansson <[EMAIL PROTECTED]>
> > wrote:
> > > I was afraid that what was needed was more or less
On 01:57 Sat 26 Jul , Grant Likely wrote:
> On Fri, Jul 25, 2008 at 1:28 PM, kenneth johansson <[EMAIL PROTECTED]> wrote:
> > I was afraid that what was needed was more or less a complete linker but
> > it looks like if one generate the dynamic reloc table a much simpler
> > linker(relocation f
In message <[EMAIL PROTECTED]> you wrote:
>
> > Or why?
>
> If it turns out that is is not that complicated all architectures could
> do it in the same way.
That would require that all architectures implementrelocation in the
same way (or at all). Actually this is not the case.
Best regards,
W
In message <[EMAIL PROTECTED]> you wrote:
>
> You are completely right. For the purposes of this discussion, this
> is a powerpc-centric problem. The relocation code is written in
> assembly and is processor specific. Let the ARM folks make sure ARM
> relocation works (and I think it already do
On Sat, Jul 26, 2008 at 3:53 AM, kenneth johansson <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-07-26 at 01:48 -0400, Grant Likely wrote:
>> On Thu, Jul 24, 2008 at 2:09 PM, Kenneth Johansson <[EMAIL PROTECTED]> wrote:
>> > On Thu, 2008-07-24 at 10:37 -0700, vb wrote:
>> >> But as you pointed out, thi
On Sat, 2008-07-26 at 01:48 -0400, Grant Likely wrote:
> On Thu, Jul 24, 2008 at 2:09 PM, Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-07-24 at 10:37 -0700, vb wrote:
> >> But as you pointed out, this would work on ppc only (with a 'good'
> >> compiler), and still remains to be pro
On Sat, 2008-07-26 at 07:36 +0200, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > I know exactly what Grant did. But he is not using the elf relocation
> > information as that is simply not included in the data that is the
> > u-boot.bin file.
>
> So what? Is this a prob
On Sat, Jul 26, 2008 at 1:54 AM, vb <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 10:43 PM, Grant Likely
> <[EMAIL PROTECTED]> wrote:
>>
>> The problem is that the u-boot C runtime setup is insane and must be
>> fixed. Fix the C runtime and the problem goes away. The approach
>> being sugg
On Sat, Jul 26, 2008 at 2:06 AM, Grant Likely <[EMAIL PROTECTED]> wrote:
> BTW, searching for assignments to reloc_off in the source will tell
> you which platforms are broken.
Oops, actually I'm insane on this statement. Not setting reloc_off
could mean that relocation is simply not performed.
On Fri, Jul 25, 2008 at 2:50 PM, Haavard Skinnemoen
<[EMAIL PROTECTED]> wrote:
> Ok, I'll stop the chest-beating now. But please stop trying to tell
> people that adding a powerpc-specific option (which nobody seems to
> know how really works) to the command line will work on any other
> architectu
On Fri, Jul 25, 2008 at 1:28 PM, kenneth johansson <[EMAIL PROTECTED]> wrote:
> I was afraid that what was needed was more or less a complete linker but
> it looks like if one generate the dynamic reloc table a much simpler
> linker(relocation function) is needed. Still probably a lot more complex
On Fri, Jul 25, 2008 at 10:43 PM, Grant Likely
<[EMAIL PROTECTED]> wrote:
>
> The problem is that the u-boot C runtime setup is insane and must be
> fixed. Fix the C runtime and the problem goes away. The approach
> being suggested here would have us *preserve* the insane C runtime and
> actually
On Fri, Jul 25, 2008 at 10:36 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>
> Maybe I should have been more explicit right from the beginning. I
> repeat: forget it. This will *not* go into mainline. Zero chance.
>
well, it's your call, I'ill stick with
On Thu, Jul 24, 2008 at 2:09 PM, Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-24 at 10:37 -0700, vb wrote:
>> But as you pointed out, this would work on ppc only (with a 'good'
>> compiler), and still remains to be proven, I will get to it a bit
>> later.
>
> I have run u-boot wit
On Thu, Jul 24, 2008 at 2:45 AM, vb <[EMAIL PROTECTED]> wrote:
> Wolfgang, thank you for your reply, let me try to explain myself a bit
> clearer:
>
> On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]> you wrote:
>> If you invest time in sol
In message <[EMAIL PROTECTED]@transmode.se> you wrote:
>
> I think the best bet is to make -mrelocatable work for PPC. Question is how
> does the other arches do it? Do they include fixup ptrs by default or do
> they lack this functionality?
The question that needs to answered first is if any othe
In message <[EMAIL PROTECTED]> you wrote:
>
> Ok, I'll stop the chest-beating now. But please stop trying to tell
> people that adding a powerpc-specific option (which nobody seems to
> know how really works) to the command line will work on any other
> architectures than powerpc.
OK - then please
In message <[EMAIL PROTECTED]> you wrote:
>
> I know exactly what Grant did. But he is not using the elf relocation
> information as that is simply not included in the data that is the
> u-boot.bin file.
So what? Is this a problem? Why would we need to use XXX if we can
perform all we need to do
In message <[EMAIL PROTECTED]> you wrote:
>
> I think this discussion covers much more ground than needed: certainly
> the problem of running the same executable at different addresses has
> been solved many times over, for different architectures and file
> formats. The thing is that unless we wa
On Fri, 2008-07-25 at 20:35 +0200, Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 19:28:48 +0200
> kenneth johansson <[EMAIL PROTECTED]> wrote:
>
> > I was afraid that what was needed was more or less a complete linker but
> > it looks like if one generate the dynamic reloc table a much simpler
>
Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 19:28:48 +0200
> kenneth johansson <[EMAIL PROTECTED]> wrote:
>
>
>> I was afraid that what was needed was more or less a complete linker but
>> it looks like if one generate the dynamic reloc table a much simpler
>> linker(relocation function) is
Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 11:21:12 -0400
> Jerry Van Baren <[EMAIL PROTECTED]> wrote:
>
>> The relocation information is in the ELF file until and unless we remove
>> it. "Normal" ELF executables retain that relocation information... that
>> is exactly what the "L" (it) is
On Fri, 25 Jul 2008 11:21:12 -0400
Jerry Van Baren <[EMAIL PROTECTED]> wrote:
> The relocation information is in the ELF file until and unless we remove
> it. "Normal" ELF executables retain that relocation information... that
> is exactly what the "L" (it) is for. The linux loader (elf loader
On Fri, 25 Jul 2008 19:28:48 +0200
kenneth johansson <[EMAIL PROTECTED]> wrote:
> I was afraid that what was needed was more or less a complete linker but
> it looks like if one generate the dynamic reloc table a much simpler
> linker(relocation function) is needed. Still probably a lot more compl
On Fri, 2008-07-25 at 13:02 -0400, Jerry Van Baren wrote:
> kenneth johansson wrote:
> > On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote:
>
> [snip]
>
> >> There will obviously be a fair amount of arch-specific code required to
> >> make the actual relocation work though.
> >
> > So
kenneth johansson wrote:
> On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote:
[snip]
>> There will obviously be a fair amount of arch-specific code required to
>> make the actual relocation work though.
>
> So the gain of using dynamic relocation is that we have fever relocation
> type
Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 16:33:56 +0200
> kenneth johansson <[EMAIL PROTECTED]> wrote:
>
>
>> On Fri, 2008-07-25 at 14:19 +0200, Haavard Skinnemoen wrote:
>>
>>> On Fri, 25 Jul 2008 13:55:58 +0200
>>> kenneth johansson <[EMAIL PROTECTED]> wrote:
>>>
>>>
>
On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 16:33:56 +0200
> kenneth johansson <[EMAIL PROTECTED]> wrote:
> > now it works as follows. One final static link with all the .a files and
> > a specified start address for TEXT. result is a elf file with al symbols
vb wrote:
> On Fri, Jul 25, 2008 at 7:33 AM, kenneth johansson <[EMAIL PROTECTED]> wrote:
>
>> here is a patch to generate dynamic relocations in the elf file. What is
>> the next step? objcopy -j .rela.dyn -O binary u-boot dyn_reloc_table ??
>>
>>
>> --- config.mk
>> +++ config.
On Fri, 25 Jul 2008 16:33:56 +0200
kenneth johansson <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-07-25 at 14:19 +0200, Haavard Skinnemoen wrote:
> > On Fri, 25 Jul 2008 13:55:58 +0200
> > kenneth johansson <[EMAIL PROTECTED]> wrote:
> >
> > > > An ELF shared library has the dynamic relocations we
On Fri, Jul 25, 2008 at 7:33 AM, kenneth johansson <[EMAIL PROTECTED]> wrote:
>
> here is a patch to generate dynamic relocations in the elf file. What is
> the next step? objcopy -j .rela.dyn -O binary u-boot dyn_reloc_table ??
>
>
> --- config.mk
> +++ config.mk
> @@ -215,7 +21
On Fri, 2008-07-25 at 14:19 +0200, Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 13:55:58 +0200
> kenneth johansson <[EMAIL PROTECTED]> wrote:
>
> > > An ELF shared library has the dynamic relocations we need. So if we
> > > build u-boot as an .so file, it should work in theory on most
> > > ar
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Haavard Skinnemoen
> Sent: den 25 juli 2008 14:19
> To: kenneth johansson
> Cc: vb; u-boot-users@lists.sourceforge.net; Wolfgang Denk
> Subject: Re: [U-Boot-Users] Changing u-b
On Fri, 25 Jul 2008 13:55:58 +0200
kenneth johansson <[EMAIL PROTECTED]> wrote:
> > An ELF shared library has the dynamic relocations we need. So if we
> > build u-boot as an .so file, it should work in theory on most
> > architectures.
>
> well the elf binary of u-boot obviously has everything w
On Fri, 2008-07-25 at 11:10 +0200, Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 06:28:16 +0200
> Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>
> > In message <[EMAIL PROTECTED]> you wrote:
> > > We could build u-boot as a shared library I guess, but that feels a bit
> > > weird...
> >
> > Shared?
On Thu, 24 Jul 2008 19:12:20 +0200
Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> > We could build u-boot as a shared library I guess, but that feels a bit
> > weird...
>
> What do you mean by that ? u-boot is already compiled with the -fPIC
> option.
If that's sufficient, why would you need
On Fri, 25 Jul 2008 06:28:16 +0200
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > Plus it's only defined for PowerPC. What do we do on the 11 other
> > architectures?
>
> Fix them in the first place to do reloction at all?
Er. How? The only thing th
In message <[EMAIL PROTECTED]> you wrote:
>
> I have run u-boot with everything compiled with -mrelocatable and normal
> relocation fixup code removed so I know it works fine. So consider it
> proven. But since it apparently is a problem in some situation the best
> is probably to make it a config
In message <[EMAIL PROTECTED]> you wrote:
>
> Plus it's only defined for PowerPC. What do we do on the 11 other
> architectures?
Fix them in the first place to do reloction at all?
> We could build u-boot as a shared library I guess, but that feels a bit
> weird...
Shared? Shared by what?
Best
Dear Kenneth,
in message <[EMAIL PROTECTED]> you wrote:
>
> > It is standard, documented by the ABI, and works fine if done
> > correctly. We just don't do it correctly yet.
>
> Well the type of runtime relocation that we do in u-boot is not really
> specified in any documentation. What is in th
On Thu, 2008-07-24 at 11:26 -0700, vb wrote:
> On Thu, Jul 24, 2008 at 11:09 AM, Kenneth Johansson
> <[EMAIL PROTECTED]> wrote:
> >
>
> >
> > I have run u-boot with everything compiled with -mrelocatable and normal
> > relocation fixup code removed so I know it works fine. So consider it
> > prov
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of vb
> Sent: den 24 juli 2008 20:26
> To: Kenneth Johansson
> Cc: u-boot-users@lists.sourceforge.net; Haavard Skinnemoen; Wolfgang Denk
> Subject: Re: [U-Boot-Users] Changing u-b
On Thu, Jul 24, 2008 at 11:09 AM, Kenneth Johansson
<[EMAIL PROTECTED]> wrote:
>
>
> I have run u-boot with everything compiled with -mrelocatable and normal
> relocation fixup code removed so I know it works fine. So consider it
> proven. But since it apparently is a problem in some situation the
On Thu, 2008-07-24 at 10:37 -0700, vb wrote:
> On Thu, Jul 24, 2008 at 9:57 AM, Haavard Skinnemoen
> <[EMAIL PROTECTED]> wrote:
> > Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> >> you have to
> >> read the gcc code to understand what the -mrelocatable option really do.
> >
> > Plus it's only def
On Thu, Jul 24, 2008 at 9:57 AM, Haavard Skinnemoen
<[EMAIL PROTECTED]> wrote:
> Kenneth Johansson <[EMAIL PROTECTED]> wrote:
>> you have to
>> read the gcc code to understand what the -mrelocatable option really do.
>
> Plus it's only defined for PowerPC. What do we do on the 11 other
> architectu
On Thu, 2008-07-24 at 18:57 +0200, Haavard Skinnemoen wrote:
> Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> > you have to
> > read the gcc code to understand what the -mrelocatable option really do.
>
> Plus it's only defined for PowerPC. What do we do on the 11 other
> architectures?
Well oth
Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> you have to
> read the gcc code to understand what the -mrelocatable option really do.
Plus it's only defined for PowerPC. What do we do on the 11 other
architectures?
We could build u-boot as a shared library I guess, but that feels a bit
weird...
On Thu, 2008-07-24 at 15:01 +0200, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Quite frankly, GOT is also clumsy and even ugly IMHO - it requires a
> > lot of special treatment, explicit data definitions and linker
> > scripts, and does not work for arbitrary data as we sa
In message <[EMAIL PROTECTED]> you wrote:
>
> So, the value of 'pf' is equal to the address of do_ptrt() *before*
> relocation. The fact that there is a GOT and a sophisticated linker
> script did not prevent this from happening.
Yes, statically initialized function pointers are known to be not
r
On Thu, Jul 24, 2008 at 2:58 AM, Haavard Skinnemoen
<[EMAIL PROTECTED]> wrote:
>
> IMO, it's best to avoid such pointers in the first place, especially
> ones that are statically initialized.
>
> Haavard
>
On Thu, Jul 24, 2008 at 5:23 AM, Jerry Van Baren <[EMAIL PROTECTED]> wrote:
>
> OK, now I'm
On Thu, Jul 24, 2008 at 5:47 AM, Kenneth Johansson <[EMAIL PROTECTED]> wrote:
>
> What is missing right now is that to properly fix function pointers
> stored in data section we have to compile with -mrelocatable flag to get
> gcc to create a fixup table so we later at runtime can just go over that
On Thu, Jul 24, 2008 at 6:45 AM, Jon Loeliger <[EMAIL PROTECTED]> wrote:
>
> As an alternate approach, perhaps this is something
> that might be explored in the framework of the so-called
> "U-Boot V2" effort? Specifically, if you can demonstrate
> it working, that would hold much more weight. Yo
vb wrote:
>> What Grant suggests is the way to go. I do not think your approach has
>> chances for mainline.
>>
>
> I am sorry to hear this, especially since what I suggest would be
> completely compiler agnostic and would allow to avoid some of the
> limitations one must follow today while addin
On Wed, 2008-07-23 at 23:45 -0700, vb wrote:
> Wolfgang, thank you for your reply, let me try to explain myself a bit
> clearer:
>
> On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> > In message <[EMAIL PROTECTED]> you wrote:
> >
> >> some companies). If these added mo
vb wrote:
> Wolfgang, thank you for your reply, let me try to explain myself a bit
> clearer:
>
> On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]> you wrote:
>>
>>> some companies). If these added modules were not written in position
>>>
vb <[EMAIL PROTECTED]> wrote:
> > int (*pf)(struct cmd_tbl_s *, int, int, char *[]) = do_ptrt;
> >
> > int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> > {
> > printf ("pointer is %p\n", pf);
> > printf ("function is %p\n", do_ptrt);
> > return 0;
> > }
Just do
Wolfgang, thank you for your reply, let me try to explain myself a bit clearer:
On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>
>> some companies). If these added modules were not written in position
>> independent manner (nam
On Wed, Jul 23, 2008 at 10:39:00AM -0700, vb wrote:
> While this relocation is seamless for u-boot in its released form, it
> becomes a pain each time a module needs to be added (not necessarily
> for following release to the Open Source community, for instance used
> for inhouse installations whic
In message <[EMAIL PROTECTED]> you wrote:
>
> > What is a module?
>
> for the purposes of this discussion any .o file or any library of .o files.
Neither of these is executable - you either have to link these with
the U-Boot code or into a standalone application - and in both cases
none of the p
In message <[EMAIL PROTECTED]> you wrote:
>
> I wonder if you would consider (and accept a patch) changing the
> u-boot architecture as described below.
Consider: always. Accept: if it makes more sense than the current
implementation.
> As we all are well aware u-boot is a great software package
Jerry, thank you for your reply, please see below:
On Wed, Jul 23, 2008 at 2:46 PM, Jerry Van Baren <[EMAIL PROTECTED]> wrote:
> vb wrote:
>> One thing which (IMO anyway) slows down
>> its acceptance is the way it handles relocating of itself into an
>> arbitrary DRAM area. (Arbitrary meaning tha
vb wrote:
> Wolfgang,
>
> I wonder if you would consider (and accept a patch) changing the
> u-boot architecture as described below.
>
> As we all are well aware u-boot is a great software package which
> speeds up bringing up new hardware immensely, its popularity is
> obviously growing very fas
Wolfgang,
I wonder if you would consider (and accept a patch) changing the
u-boot architecture as described below.
As we all are well aware u-boot is a great software package which
speeds up bringing up new hardware immensely, its popularity is
obviously growing very fast. One thing which (IMO an
68 matches
Mail list logo
