Am 29.10.2010 17:38, schrieb Albert ARIBAUD:
> Sorry, I meant the ELF u-boot binary, not the ELF object file of nand. I
> need all the relocation information to be sure, and it can only be found
> in the full ELF binary.
Done through other ways. Not that someone else gets the idea I'm
distributi
Le 29/10/2010 17:32, Alexander Holler a écrit :
>>
>> The assemble is better, but now I see that objdump does not show all of
>> the code, particularly not all of the literals. Can you provide the ELF
>> binary (not the pure binary) for both cases? This way I can readelf and
>> objdump, plus I can
>
> The assemble is better, but now I see that objdump does not show all of
> the code, particularly not all of the literals. Can you provide the ELF
> binary (not the pure binary) for both cases? This way I can readelf and
> objdump, plus I can compare this to my own builds.
I've just seen that t
Le 29/10/2010 17:05, Alexander Holler a écrit :
> Am 29.10.2010 16:54, schrieb Albert ARIBAUD:
>> Le 29/10/2010 16:37, Alexander Holler a écrit :
>>> Hello,
>>>
>>> I don't quote the rest, just read the mails before. ;)
>>>
>>>
>>> Here is the what I've done with the current head and the resulting
Am 29.10.2010 16:54, schrieb Albert ARIBAUD:
> Le 29/10/2010 16:37, Alexander Holler a écrit :
>> Hello,
>>
>> I don't quote the rest, just read the mails before. ;)
>>
>>
>> Here is the what I've done with the current head and the resulting
>> output:
>> ---
Am 29.10.2010 16:50, schrieb Reinhard Meyer:
> Dear Alexander Holler,
>> U-Boot 2010.12-rc1-9-g27b7641-dirty (Oct 29 2010 - 15:58:59)
>> Seagate-DockStar
>>
>> U-Boot code: 0070 -> 0075A210 BSS: -> 007A0300
>> SoC: Kirkwood 88F6281_A0
>> monitor len: 000A0300
>> ramsize: 0800
>> TL
Le 29/10/2010 16:37, Alexander Holler a écrit :
> Hello,
>
> I don't quote the rest, just read the mails before. ;)
>
>
> Here is the what I've done with the current head and the resulting output:
>
The generated assembler co
Am 29.10.2010 16:44, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<4ccadc10.9010...@ahsoftware.de> you wrote:
>>
> ...
>> U-Boot code: 0070 -> 0075A210 BSS: -> 007A0300
>> SoC: Kirkwood 88F6281_A0
>> monitor len: 000A0300
>> ramsize: 0800
>
> That's 128 MB...
>
>> TLB
Dear Alexander Holler,
> U-Boot 2010.12-rc1-9-g27b7641-dirty (Oct 29 2010 - 15:58:59)
> Seagate-DockStar
>
> U-Boot code: 0070 -> 0075A210 BSS: -> 007A0300
> SoC: Kirkwood 88F6281_A0
> monitor len: 000A0300
> ramsize: 0800
> TLB table at: 07ff
> Top of RAM usable for U-Boot at:
Dear Alexander Holler,
In message <4ccadc10.9010...@ahsoftware.de> you wrote:
>
...
> U-Boot code: 0070 -> 0075A210 BSS: -> 007A0300
> SoC: Kirkwood 88F6281_A0
> monitor len: 000A0300
> ramsize: 0800
That's 128 MB...
> TLB table at: 07ff
> Top of RAM usable for U-Boot at: 07ff
Hello,
I don't quote the rest, just read the mails before. ;)
Here is the what I've done with the current head and the resulting output:
dockstar2 u-boot.git # vim drivers/mtd/nand/nand.c (adding printf)
dockstar2 u-boot.gi
Le 29/10/2010 15:50, Alexander Holler a écrit :
> Am 29.10.2010 15:37, schrieb Albert ARIBAUD:
>> Le 29/10/2010 14:31, Alexander Holler a écrit :
>>
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT,
the start.S code clears the relocated BSS. Are we in a case where y
Am 29.10.2010 15:37, schrieb Albert ARIBAUD:
> Le 29/10/2010 14:31, Alexander Holler a écrit :
>
>>> Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT,
>>> the start.S code clears the relocated BSS. Are we in a case where you
>>> prevent part of the relocation process, such as
Le 29/10/2010 14:31, Alexander Holler a écrit :
>> Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT,
>> the start.S code clears the relocated BSS. Are we in a case where you
>> prevent part of the relocation process, such as by using
>> CONFIG_SKIP_RELOCATE_UBOOT?
>
> The (w
Am 29.10.2010 14:08, schrieb Albert ARIBAUD:
with -pie in LDFLAGS, which I don't understand (does not mean I have
much experience how the compiler and linker are working in regard to
relocatable code).
>>
>>> That needs some more analysis.
>>>
>>> -fPIC without GOT relocation d
Le 29/10/2010 13:56, Alexander Holler a écrit :
> Am 29.10.2010 11:19, schrieb Albert ARIBAUD:
>> Hi all,
>>
>> Le 29/10/2010 10:50, Alexander Holler a écrit :
>>> Hello again,
>>>
>>> I'm leaving the problem description below, what fixed it all here was to
>>> add -fPIC to the CFLAGS to instruct t
Am 29.10.2010 11:19, schrieb Albert ARIBAUD:
> Hi all,
>
> Le 29/10/2010 10:50, Alexander Holler a écrit :
>> Hello again,
>>
>> I'm leaving the problem description below, what fixed it all here was to
>> add -fPIC to the CFLAGS to instruct the compiler to generate relocatable
>> code (again).
>>
>
Le 28/10/2010 13:38, Wolfgang Denk a écrit :
>>> CONFIG_RELOC_FIXUP_WORKS
>>
>> Not needed for ARM when ELF relocation is used. I don't know whether other
>> architectures still need it. Do NOT set it on ARM or you get in trouble by
>> some addresses being relocated twice.
>
> Sure? My understand
Hi all,
Le 29/10/2010 10:50, Alexander Holler a écrit :
> Hello again,
>
> I'm leaving the problem description below, what fixed it all here was to
> add -fPIC to the CFLAGS to instruct the compiler to generate relocatable
> code (again).
>
> This flag was replaced in commit 92d5ecba47feb9961c3b75
Hello again,
I'm leaving the problem description below, what fixed it all here was to
add -fPIC to the CFLAGS to instruct the compiler to generate relocatable
code (again).
This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5
with -pie in LDFLAGS, which I don't understand
Dear Wolfgang Denk,
>>> CONFIG_RELOC_FIXUP_WORKS
>> Not needed for ARM when ELF relocation is used. I don't know whether other
>> architectures still need it. Do NOT set it on ARM or you get in trouble by
>> some addresses being relocated twice.
>
> Sure? My understanding is that it MUST be set s
Dear Reinhard Meyer,
In message <4cc95b9e.3040...@emk-elektronik.de> you wrote:
>
> > I've got confused by that too. Currently there are 3 defines in regard
> > to relocation:
> >
> > CONFIG_SYS_ARM_WITHOUT_RELOC
>
> Introduced by Heiko as a try to unbreak old boards that are not converted to
>
Dear Alexander Holler,
> Am 28.10.2010 10:39, schrieb Wolfgang Denk:
>> Dear Heiko Schocher,
>>
>> In message<4cc914d8.4070...@denx.de> you wrote:
>>> Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
>>> obsolete?
>> sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT
Hello,
Am 28.10.2010 10:39, schrieb Wolfgang Denk:
> Dear Heiko Schocher,
>
> In message<4cc914d8.4070...@denx.de> you wrote:
>>
>> Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
>> obsolete?
>
> sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and
> CONFIG_SYS_A
Hello,
Am 27.10.2010 09:26, schrieb Darius Augulis:
> the code for clearing bss section for most ARM cores looks like this
> or very similar:
... [some code from start.S]
Currently I'm analyzing the same problem (on a kirkwood based hw). It
turns out not to be a problem of clear_bss, but a p
Am 28.10.2010 11:03, schrieb Alexander Holler:
> Hello,
>
> Am 27.10.2010 09:26, schrieb Darius Augulis:
>
> > the code for clearing bss section for most ARM cores looks like this
> > or very similar:
>
> ... [some code from start.S]
>
> Currently I'm analyzing the same problem (on a kirkwood bas
Hello Wolfgang,
Wolfgang Denk wrote:
> Dear Heiko Schocher,
>
> In message <4cc914d8.4070...@denx.de> you wrote:
>> Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
>> obsolete?
>
> sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and
> CONFIG_SYS_ARM_WITHOUT_RELO
Dear Heiko Schocher,
In message <4cc914d8.4070...@denx.de> you wrote:
>
> Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
> obsolete?
sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and
CONFIG_SYS_ARM_WITHOUT_RELOC related to each other?
Best regards,
Wolfgang
Dear Darius Augulis,
In message <4cc91e8e.8030...@gmail.com> you wrote:
>
> Are we going to drop possibility to avoid relocation at all? In spite of
Yes, definitely.
We will keep the handling of the special case thatthe relocation
offset is zero, so that an additional copy can be avoided, but t
Dear Reinhard Meyer,
In message <4cc919e4.6010...@emk-elektronik.de> you wrote:
> Dear Heiko Schocher,
> > Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
> > obsolete?
> Why don't we remove ALL that dead code ASAP from ARM start.S and board.c
> files?
>
> All unmaintained ARM b
On 10/28/2010 09:36 AM, Reinhard Meyer wrote:
> Dear Heiko Schocher,
>> Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
>> obsolete?
> Why don't we remove ALL that dead code ASAP from ARM start.S and board.c
> files?
>
> All unmaintained ARM boards are now broken anyway, and those
Dear Heiko Schocher,
> Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not
> obsolete?
Why don't we remove ALL that dead code ASAP from ARM start.S and board.c files?
All unmaintained ARM boards are now broken anyway, and those that are fixed are
using elf relocation.
(I know that th
Hello Reinhard,
Reinhard Meyer wrote:
> On 28.10.2010 08:20, Reinhard Meyer wrote:
>> On 28.10.2010 08:17, Heiko Schocher wrote:
>>> Hello Reinhard,
>>>
>>> Reinhard Meyer wrote:
Dear Darius,
>> Now running in RAM - U-Boot at: 57fbe000
>> NAND: raise: Signal # 8 caught
>> raise:
On 28.10.2010 08:20, Reinhard Meyer wrote:
> On 28.10.2010 08:17, Heiko Schocher wrote:
>> Hello Reinhard,
>>
>> Reinhard Meyer wrote:
>>> Dear Darius,
> Now running in RAM - U-Boot at: 57fbe000
> NAND: raise: Signal # 8 caught
> raise: Signal # 8 caught
> raise: Signal # 8 caught
On 28.10.2010 08:17, Heiko Schocher wrote:
> Hello Reinhard,
>
> Reinhard Meyer wrote:
>> Dear Darius,
Now running in RAM - U-Boot at: 57fbe000
NAND: raise: Signal # 8 caught
raise: Signal # 8 caught
raise: Signal # 8 caught
>>> This looks suspect to me. Seems to me some early
Hello Reinhard,
Reinhard Meyer wrote:
> Dear Darius,
>>> Now running in RAM - U-Boot at: 57fbe000
>>> NAND: raise: Signal # 8 caught
>>> raise: Signal # 8 caught
>>> raise: Signal # 8 caught
>> This looks suspect to me. Seems to me some early init
>> (pin setup? clocks?) is not OK. If you have ea
Hello Darius,
Darius Augulis wrote:
> the code for clearing bss section for most ARM cores looks like this
> or very similar:
>
> clear_bss:
> #ifndef CONFIG_PRELOADER
> ldr r0, _bss_start_ofs
> ldr r1, _bss_end_ofs
> ldr r3, _TEXT_BASE /* Text base */
Dear Darius,
>> Now running in RAM - U-Boot at: 57fbe000
>> NAND: raise: Signal # 8 caught
>> raise: Signal # 8 caught
>> raise: Signal # 8 caught
>
> This looks suspect to me. Seems to me some early init
> (pin setup? clocks?) is not OK. If you have early inits,
> you must do that now in board_ea
Hello Darius,
Darius Augulis wrote:
> On 10/27/2010 06:12 PM, Eric Cooper wrote:
>> On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
>>> Maybe it could be reason why I'm facing strange problem, when after
>>> relocating uboot with nand_spl no one command is not working. I
>>> debug
Hi Eric,
On 10/27/2010 06:12 PM, Eric Cooper wrote:
> On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
>> Maybe it could be reason why I'm facing strange problem, when after
>> relocating uboot with nand_spl no one command is not working. I
>> debugged that command table is empty.
On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
> Maybe it could be reason why I'm facing strange problem, when after
> relocating uboot with nand_spl no one command is not working. I
> debugged that command table is empty.
Maybe this is the same problem I reported here (commands
Dear Darius Augulis,
In message <4cc80609.6040...@gmail.com> you wrote:
>
> > Maybe, maybe not. The preloader is usually very simple and may not be
> > clever enough to adjust the oad address to the avalable memory and
> > such; also, U-Boot features like protected RAM, shared video buffers
> > or
On 10/27/2010 01:40 PM, Wolfgang Denk wrote:
> Dear Darius Augulis,
>
> In message you
> wrote:
>>
>>> I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with
>>> relocation enabled unless we ensure that the TEXT_BASE would be same
>>> as the relocation address.
>>
>> in case of nand_spl you
Dear Darius Augulis,
In message you
wrote:
>
> > I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with
> > relocation enabled unless we ensure that the TEXT_BASE would be same
> > as the relocation address.
>
> in case of nand_spl you don't need to to relocation twice because it's
> done
On Wed, Oct 27, 2010 at 12:09 PM, Sughosh Ganu wrote:
> On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote:
>
>> No, there could be several different relocation methods - with and
>> without preloader etc.
>> There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes
>> boot s
On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote:
> No, there could be several different relocation methods - with and
> without preloader etc.
> There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes
> boot sequence dramatically.
> And it isn't CONFIG_SYS_ARM_WITHOUT_RE
On Wed, Oct 27, 2010 at 11:54 AM, Sughosh Ganu wrote:
> hi,
>
> On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote:
>> Hi,
>>
>> On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu
>> wrote:
>
>> >
>> > Not sure which core are you referring to. I checked for arm926ejs,
>> > and we have c
hi,
On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote:
> Hi,
>
> On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu
> wrote:
> >
> > Not sure which core are you referring to. I checked for arm926ejs,
> > and we have conditional code inclusion based on the definition of
> > CONFIG_SY
Hi,
On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu wrote:
> hi,
>
> On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
>
>> IMO, if relocation is skipped, r4 should be loaded with value of
>> _TEXT_BASE, not reloc address?
>> It seems like r3 is prepared for this but, it's somehow mis
hi,
On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
> IMO, if relocation is skipped, r4 should be loaded with value of
> _TEXT_BASE, not reloc address?
> It seems like r3 is prepared for this but, it's somehow missing? It's
> not used at all.
> Maybe it could be reason why I'm faci
Hi list,
the code for clearing bss section for most ARM cores looks like this
or very similar:
clear_bss:
#ifndef CONFIG_PRELOADER
ldr r0, _bss_start_ofs
ldr r1, _bss_end_ofs
ldr r3, _TEXT_BASE /* Text base */
mov r4, r7 /*
51 matches
Mail list logo
