[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

Hi,

I recently try to port our board code to new uboot, which has been
changed to use new relocation scheme.
But I found a very strange thing, that is if the uboot is loaded to
the TEXT_BASE address, it could run without
problem. But if it is loaded to a different place, it fail to boot up...

I check the code, and found that in the board_init_f, it calls the
init_sequence which is stored as a data sector
in the u-boot.bin file. While the new scheme use the fPIC, the code
could locate the GOT table correctly,
and it seem to forgot what the GOT table stores is context that is
meaningful in TEXT_BASE, not the loaded base.
That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
0x500000, I found the GOT table also filled
with 0xf0****, not the 0x50****. This leads the cpu loading wrong
function address in the init_sequence table, and
cause pc become invalid...

Am I missing something to switch to the new relocation scheme?

Thanks,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Graeme Russ]

On 09/10/10 16:50, Lei Wen wrote:
> Hi,
> 
> I recently try to port our board code to new uboot, which has been
> changed to use new relocation scheme.
> But I found a very strange thing, that is if the uboot is loaded to
> the TEXT_BASE address, it could run without
> problem. But if it is loaded to a different place, it fail to boot up...
> 
> I check the code, and found that in the board_init_f, it calls the
> init_sequence which is stored as a data sector
> in the u-boot.bin file. While the new scheme use the fPIC, the code
> could locate the GOT table correctly,
> and it seem to forgot what the GOT table stores is context that is
> meaningful in TEXT_BASE, not the loaded base.
> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
> 0x500000, I found the GOT table also filled
> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
> function address in the init_sequence table, and
> cause pc become invalid...
> 
> Am I missing something to switch to the new relocation scheme?
> 

The ARM relocation schemes (there are two being evaluated - one which uses
.got and another .rel.dyn) are both designed to relocate from TEXT_BASE to
an upper memory location determined during DRAM init

x86 is the only arch that I know implements what you are describing (in a
patch series in u-boot-x86/master but not yet in mainline)

Regards,

Graeme

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

On Sat, Oct 9, 2010 at 2:27 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> On 09/10/10 16:50, Lei Wen wrote:
>> Hi,
>>
>> I recently try to port our board code to new uboot, which has been
>> changed to use new relocation scheme.
>> But I found a very strange thing, that is if the uboot is loaded to
>> the TEXT_BASE address, it could run without
>> problem. But if it is loaded to a different place, it fail to boot up...
>>
>> I check the code, and found that in the board_init_f, it calls the
>> init_sequence which is stored as a data sector
>> in the u-boot.bin file. While the new scheme use the fPIC, the code
>> could locate the GOT table correctly,
>> and it seem to forgot what the GOT table stores is context that is
>> meaningful in TEXT_BASE, not the loaded base.
>> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
>> 0x500000, I found the GOT table also filled
>> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
>> function address in the init_sequence table, and
>> cause pc become invalid...
>>
>> Am I missing something to switch to the new relocation scheme?
>>
>
> The ARM relocation schemes (there are two being evaluated - one which uses
> .got and another .rel.dyn) are both designed to relocate from TEXT_BASE to
> an upper memory location determined during DRAM init
>
> x86 is the only arch that I know implements what you are describing (in a
> patch series in u-boot-x86/master but not yet in mainline)
>
Glad to know this info here. :-)
But it let the uboot lose a good feature that let it boot itself to
debug a new feature.
In original scheme, the relocate operation is done before calling the
init_sequence,
so the problem here was gone.

So for the new relocation scheme currently on mainline code, we only could load
the u-boot.bin to the TEXT_BASE in ram and transfer the control to it?
And if do this, the relocate seems has no meaning here, since in the
past experience
we need the relocation for we need copy the rest of uboot code to the TEXT_BASE
when start up at a different place at the very beginning.

Thanks,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Wolfgang Denk]

Dear Lei Wen,

In message <AANLkTi==rkiYsGNFYiy2nO_w4uSw=Da8stZjcHt14Q9J@mail.gmail.com> you wrote:
>
> But it let the uboot lose a good feature that let it boot itself to
> debug a new feature.

This has never been supported, and never been working reliably, not
across acrchitectures, and not on all ARM systems.

> In original scheme, the relocate operation is done before calling the
> init_sequence,
> so the problem here was gone.

No. Before, There was no relocation done at all, because U-Boot was
linked to a fixed RAM address, and was simply copied there.

You ware just lucky when you were able to start U-Boot from an already
running system.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

Hi Wolfang,

On Sun, Oct 10, 2010 at 1:50 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Lei Wen,
>
> In message <AANLkTi==rkiYsGNFYiy2nO_w4uSw=Da8stZjcHt14Q9J@mail.gmail.com> you wrote:
>>
>> But it let the uboot lose a good feature that let it boot itself to
>> debug a new feature.
>
> This has never been supported, and never been working reliably, not
> across acrchitectures, and not on all ARM systems.
>
>> In original scheme, the relocate operation is done before calling the
>> init_sequence,
>> so the problem here was gone.
>
> No. Before, There was no relocation done at all, because U-Boot was
> linked to a fixed RAM address, and was simply copied there.
>
> You ware just lucky when you were able to start U-Boot from an already
> running system.
>
Well, I think I also think I am lucky enough. :)
But I am still a little confussed, even for the new scheme, at the end
of board_init_f, there is a relocate_code, which is
the exactly as original "simply copied" code.
What the relocation in new scheme is different with the old simply
copy, has more feature, or could fix some bug?

Thanks,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD]

Le 10/10/2010 06:33, Lei Wen a ?crit :

> But I am still a little confussed, even for the new scheme, at the end
> of board_init_f, there is a relocate_code, which is
> the exactly as original "simply copied" code.
> What the relocation in new scheme is different with the old simply
> copy, has more feature, or could fix some bug?

Before relocation, for ARM926 we used to put in TEXT_BASE the RAM 
address where we wanted u-boot to end up at once relocated, and the 
first thing we did was initalize RAM, move the code and jump there; so 
we did not really relocate the code, just move it -- no fixups.

The new relocation allows putting u-boot as high in RAM as possible 
without computing this location by hand (which would be tedious for 
fixed-size RAM targets) or impossible (for targets with variable amount 
of RAM). But this meant u-boot might run at different places, which in 
turns meant truly relocating -- with fixups.

In the process, TEXT_BASE for ARM went back to what is should have been 
all along in order to converge with other platforms, i.e. the FLASH, not 
RAM, target address.

The general goal is to be able to have a single binary running on 
several HW variants.

> Thanks,
> Lei

You're welcome.

Amicalement,
-- 
Albert.

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Wolfgang Denk]

Dear Lei Wen,

In message <AANLkTi=-Ppr=4eCqT2gkpp8Tb4XrtdWNyuauD-5xzj4w@mail.gmail.com> you wrote:
> 
> Well, I think I also think I am lucky enough. :)
> But I am still a little confussed, even for the new scheme, at the end
> of board_init_f, there is a relocate_code, which is
> the exactly as original "simply copied" code.
> What the relocation in new scheme is different with the old simply
> copy, has more feature, or could fix some bug?

Just read the mail archives, or the commit messages, or read
http://elinux.org/CELF_Project_Proposal/Rework_ARM_architecture_support_in_U-Boot

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced  technology  is  indistinguishable  from  a
rigged demo.                              - Andy Finkel, computer guy

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

On Sun, Oct 10, 2010 at 2:50 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Lei Wen,
>
> In message <AANLkTi=-Ppr=4eCqT2gkpp8Tb4XrtdWNyuauD-5xzj4w@mail.gmail.com> you wrote:
>>
>> Well, I think I also think I am lucky enough. :)
>> But I am still a little confussed, even for the new scheme, at the end
>> of board_init_f, there is a relocate_code, which is
>> the exactly as original "simply copied" code.
>> What the relocation in new scheme is different with the old simply
>> copy, has more feature, or could fix some bug?
>
> Just read the mail archives, or the commit messages, or read
> http://elinux.org/CELF_Project_Proposal/Rework_ARM_architecture_support_in_U-Boot
>
Got it. :)

Thanks,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD]

Le 09/10/2010 07:50, Lei Wen a ?crit :
> Hi,
>
> I recently try to port our board code to new uboot, which has been
> changed to use new relocation scheme.
> But I found a very strange thing, that is if the uboot is loaded to
> the TEXT_BASE address, it could run without
> problem. But if it is loaded to a different place, it fail to boot up...
>
> I check the code, and found that in the board_init_f, it calls the
> init_sequence which is stored as a data sector
> in the u-boot.bin file. While the new scheme use the fPIC, the code
> could locate the GOT table correctly,
> and it seem to forgot what the GOT table stores is context that is
> meaningful in TEXT_BASE, not the loaded base.
> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
> 0x500000, I found the GOT table also filled
> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
> function address in the init_sequence table, and
> cause pc become invalid...
>
> Am I missing something to switch to the new relocation scheme?
>
> Thanks,
> Lei

Can you indicate which hardware (architecture, cpu, SoC, etc) you're 
running this code on?

Amicalement,
-- 
Albert.

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

Hi Albert,

On Sat, Oct 9, 2010 at 3:43 PM, Albert ARIBAUD <albert.aribaud@free.fr> wrote:
> Le 09/10/2010 07:50, Lei Wen a ?crit :
>> Hi,
>>
>> I recently try to port our board code to new uboot, which has been
>> changed to use new relocation scheme.
>> But I found a very strange thing, that is if the uboot is loaded to
>> the TEXT_BASE address, it could run without
>> problem. But if it is loaded to a different place, it fail to boot up...
>>
>> I check the code, and found that in the board_init_f, it calls the
>> init_sequence which is stored as a data sector
>> in the u-boot.bin file. While the new scheme use the fPIC, the code
>> could locate the GOT table correctly,
>> and it seem to forgot what the GOT table stores is context that is
>> meaningful in TEXT_BASE, not the loaded base.
>> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
>> 0x500000, I found the GOT table also filled
>> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
>> function address in the init_sequence table, and
>> cause pc become invalid...
>>
>> Am I missing something to switch to the new relocation scheme?
>>
>> Thanks,
>> Lei
>
> Can you indicate which hardware (architecture, cpu, SoC, etc) you're
> running this code on?
>
I am running the code on Marvell aspen soc, which is arm926ejs compatible core.

Best regards,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD]

Le 09/10/2010 09:53, Lei Wen a ?crit :
> Hi Albert,
>
> On Sat, Oct 9, 2010 at 3:43 PM, Albert ARIBAUD<albert.aribaud@free.fr>  wrote:
>> Le 09/10/2010 07:50, Lei Wen a ?crit :
>>> Hi,
>>>
>>> I recently try to port our board code to new uboot, which has been
>>> changed to use new relocation scheme.
>>> But I found a very strange thing, that is if the uboot is loaded to
>>> the TEXT_BASE address, it could run without
>>> problem. But if it is loaded to a different place, it fail to boot up...
>>>
>>> I check the code, and found that in the board_init_f, it calls the
>>> init_sequence which is stored as a data sector
>>> in the u-boot.bin file. While the new scheme use the fPIC, the code
>>> could locate the GOT table correctly,
>>> and it seem to forgot what the GOT table stores is context that is
>>> meaningful in TEXT_BASE, not the loaded base.
>>> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
>>> 0x500000, I found the GOT table also filled
>>> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
>>> function address in the init_sequence table, and
>>> cause pc become invalid...
>>>
>>> Am I missing something to switch to the new relocation scheme?
>>>
>>> Thanks,
>>> Lei
>>
>> Can you indicate which hardware (architecture, cpu, SoC, etc) you're
>> running this code on?
>>
> I am running the code on Marvell aspen soc, which is arm926ejs compatible core.

For arm926, TEXT_BASE should be the FLASH location (if booting from NOR) 
or a location in DRAM (for NAND and other methods).

I have had little difficulty in running the .got relocation code in a 
Marvell oront5x (arm926ejs too), except for some functions called from 
board_init_f which did not respect the general rule that code run before 
relocation should only access gd; one place in orion5x wrote to global 
variables, which always was a no-no and only happened to work because 
the arm926ejs init sequence did not run in proper order.

However, .got relocation has shortcomings of its own; mainly, it 
requires manual fixups in many places within the code. I have provided 
patches which replace .got relocation with ELF relocation (look up 
[ELF-RELOC] tags in the posts), which eliminates the need for any manual 
fixup; you may want to try this, as it might eventually replace the .got 
patches.

> Best regards,
> Lei

Amicalement,
-- 
Albert.

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD]

Le 09/10/2010 10:10, Albert ARIBAUD a ?crit :

(one coffe later)

> For arm926, TEXT_BASE should be the FLASH location (if booting from NOR)
> or a location in DRAM (for NAND and other methods).

... or a location in DRAM awa from top of RAM; relocation can be from 
RAM to RAM, as long as you define CONFIG_SKIP_LOWLEVEL_INIT and as long 
as you don't try to relocate to an overlapping area.

Amicalement,
-- 
Albert.

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

On Sat, Oct 9, 2010 at 4:10 PM, Albert ARIBAUD <albert.aribaud@free.fr> wrote:
> Le 09/10/2010 09:53, Lei Wen a ?crit :
>>
>> Hi Albert,
>>
>> On Sat, Oct 9, 2010 at 3:43 PM, Albert ARIBAUD<albert.aribaud@free.fr>
>> ?wrote:
>>>
>>> Le 09/10/2010 07:50, Lei Wen a ?crit :
>>>>
>>>> Hi,
>>>>
>>>> I recently try to port our board code to new uboot, which has been
>>>> changed to use new relocation scheme.
>>>> But I found a very strange thing, that is if the uboot is loaded to
>>>> the TEXT_BASE address, it could run without
>>>> problem. But if it is loaded to a different place, it fail to boot up...
>>>>
>>>> I check the code, and found that in the board_init_f, it calls the
>>>> init_sequence which is stored as a data sector
>>>> in the u-boot.bin file. While the new scheme use the fPIC, the code
>>>> could locate the GOT table correctly,
>>>> and it seem to forgot what the GOT table stores is context that is
>>>> meaningful in TEXT_BASE, not the loaded base.
>>>> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
>>>> 0x500000, I found the GOT table also filled
>>>> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
>>>> function address in the init_sequence table, and
>>>> cause pc become invalid...
>>>>
>>>> Am I missing something to switch to the new relocation scheme?
>>>>
>>>> Thanks,
>>>> Lei
>>>
>>> Can you indicate which hardware (architecture, cpu, SoC, etc) you're
>>> running this code on?
>>>
>> I am running the code on Marvell aspen soc, which is arm926ejs compatible
>> core.
>
> For arm926, TEXT_BASE should be the FLASH location (if booting from NOR) or
> a location in DRAM (for NAND and other methods).

Yeah, got that. The TEXT_BASE of 0xf00000 in my case is the exactly what I want
to uboot run during its run time.

>
> I have had little difficulty in running the .got relocation code in a
> Marvell oront5x (arm926ejs too), except for some functions called from
> board_init_f which did not respect the general rule that code run before
> relocation should only access gd; one place in orion5x wrote to global
> variables, which always was a no-no and only happened to work because the
> arm926ejs init sequence did not run in proper order.

Have you tried load the uboot to different place with tftp or something else?
When I load the uboot to the TEXT_BASE and run, there is also no issue...

>
> However, .got relocation has shortcomings of its own; mainly, it requires
> manual fixups in many places within the code. I have provided patches which
> replace .got relocation with ELF relocation (look up [ELF-RELOC] tags in the
> posts), which eliminates the need for any manual fixup; you may want to try
> this, as it might eventually replace the .got patches.

Glad to hear this. :-) But my problem is before relocating, the new scheme call
the init_sequence in board_init_f, while the TEXT_BASE keep the function entry
as static value during compile time. Does the ELF relocation could bring us
a relative jump when call the init_sequence table?

Thanks,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD]

Le 09/10/2010 10:24, Lei Wen a ?crit :

>> For arm926, TEXT_BASE should be the FLASH location (if booting from NOR) or
>> a location in DRAM (for NAND and other methods).
>
> Yeah, got that. The TEXT_BASE of 0xf00000 in my case is the exactly what I want
> to uboot run during its run time.

Watch out: TEXT_BASE does not define where u-boot will run, only where 
it will *start running*. With relocation, u-boot will run as high in RAM 
as can be.

>> I have had little difficulty in running the .got relocation code in a
>> Marvell oront5x (arm926ejs too), except for some functions called from
>> board_init_f which did not respect the general rule that code run before
>> relocation should only access gd; one place in orion5x wrote to global
>> variables, which always was a no-no and only happened to work because the
>> arm926ejs init sequence did not run in proper order.
>
> Have you tried load the uboot to different place with tftp or something else?
> When I load the uboot to the TEXT_BASE and run, there is also no issue...

Not sure I understand what you mean here. U-boot is assumed to *start* 
located at TEXT_BASE, then moved up in RAM, so there should *never* be 
issues with starting u-boot at its TEXT_BASE.

>> However, .got relocation has shortcomings of its own; mainly, it requires
>> manual fixups in many places within the code. I have provided patches which
>> replace .got relocation with ELF relocation (look up [ELF-RELOC] tags in the
>> posts), which eliminates the need for any manual fixup; you may want to try
>> this, as it might eventually replace the .got patches.
>
> Glad to hear this. :-) But my problem is before relocating, the new scheme call
> the init_sequence in board_init_f, while the TEXT_BASE keep the function entry
> as static value during compile time. Does the ELF relocation could bring us
> a relative jump when call the init_sequence table?

Short answer is relocation brings a way to fix all the code and data for 
correct relocation.

Note however, that when board_init_f runs, relocation has not happened 
yet, but OTOH, board_init_f is running at TEXT_BASE, so no relocation is 
needed yet. We need relocation fixup only once the code is moved to top 
of DRAM, and we want to execute board_init_r there.

If you flash u-boot at its TEXT_BASE intended NOR FLASH location, then 
any issue within board_init_f will probably be caused by the code trying 
to write to a global other than gd.

> Thanks,
> Lei

You're welcome.

Amicalement,
-- 
Albert.

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Lei Wen]

On Sat, Oct 9, 2010 at 4:57 PM, Albert ARIBAUD <albert.aribaud@free.fr> wrote:
> Le 09/10/2010 10:24, Lei Wen a ?crit :
>
>>> For arm926, TEXT_BASE should be the FLASH location (if booting from NOR)
>>> or
>>> a location in DRAM (for NAND and other methods).
>>
>> Yeah, got that. The TEXT_BASE of 0xf00000 in my case is the exactly what I
>> want
>> to uboot run during its run time.
>
> Watch out: TEXT_BASE does not define where u-boot will run, only where it
> will *start running*. With relocation, u-boot will run as high in RAM as can
> be.
>
>>> I have had little difficulty in running the .got relocation code in a
>>> Marvell oront5x (arm926ejs too), except for some functions called from
>>> board_init_f which did not respect the general rule that code run before
>>> relocation should only access gd; one place in orion5x wrote to global
>>> variables, which always was a no-no and only happened to work because the
>>> arm926ejs init sequence did not run in proper order.
>>
>> Have you tried load the uboot to different place with tftp or something
>> else?
>> When I load the uboot to the TEXT_BASE and run, there is also no issue...
>
> Not sure I understand what you mean here. U-boot is assumed to *start*
> located at TEXT_BASE, then moved up in RAM, so there should *never* be
> issues with starting u-boot at its TEXT_BASE.
>
>>> However, .got relocation has shortcomings of its own; mainly, it requires
>>> manual fixups in many places within the code. I have provided patches
>>> which
>>> replace .got relocation with ELF relocation (look up [ELF-RELOC] tags in
>>> the
>>> posts), which eliminates the need for any manual fixup; you may want to
>>> try
>>> this, as it might eventually replace the .got patches.
>>
>> Glad to hear this. :-) But my problem is before relocating, the new scheme
>> call
>> the init_sequence in board_init_f, while the TEXT_BASE keep the function
>> entry
>> as static value during compile time. Does the ELF relocation could bring
>> us
>> a relative jump when call the init_sequence table?
>
> Short answer is relocation brings a way to fix all the code and data for
> correct relocation.
>
> Note however, that when board_init_f runs, relocation has not happened yet,
> but OTOH, board_init_f is running at TEXT_BASE, so no relocation is needed
> yet. We need relocation fixup only once the code is moved to top of DRAM,
> and we want to execute board_init_r there.

Ok, I know what the difference between our opinion now...
You means the uboot should always loaded to TEXT_BASE(for nand case,
as you said).
So when we run to board_init_f, we don't need any relocation.

I am just feel put the code arrange like this would lose a good
feature as original, tftp the uboot to
a different place and use the go command to debug it.

Another question here, why the original implementation now call as
CONFIG_SYS_ARM_WITHOUT_RELOC?
I think CONFIG_SYS_ARM_WITH_RELOC is correct, for it do the relocation
at the very begining. :-p
>
> If you flash u-boot at its TEXT_BASE intended NOR FLASH location, then any
> issue within board_init_f will probably be caused by the code trying to
> write to a global other than gd.

Best regards,
Lei

[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD]

Le 09/10/2010 11:08, Lei Wen a ?crit :

> Ok, I know what the difference between our opinion now...
> You means the uboot should always loaded to TEXT_BASE(for nand case,
> as you said).
> So when we run to board_init_f, we don't need any relocation.
>
> I am just feel put the code arrange like this would lose a good
> feature as original, tftp the uboot to
> a different place and use the go command to debug it.

This does not lose said feature. You can still disable relocation 
altogether by defining CONFIG_SKIP_RELOCATE_UBOOT (watch out then; 
you're responsible for linking u-boot for its intended *final* location).

> Another question here, why the original implementation now call as
> CONFIG_SYS_ARM_WITHOUT_RELOC?

Means "this ARM build is without relocation", which is what the option does.

> I think CONFIG_SYS_ARM_WITH_RELOC is correct, for it do the relocation
> at the very begining. :-p

Read the code carefully. You'll see that the old code is used when 
CONFIG_SYS_ARM_WITHOUT_RELOC is defined, and the new (reloc) code used 
when CONFIG_SYS_ARM_WITHOUT_RELOC is not define.

> Best regards,
> Lei

Amicalement,
-- 
Albert.