[U-Boot] [PATCH 12/26] ARM: add relocation support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4C927C0C.1080007 at free.fr> you wrote:
>
> I did not write 'the goal of using fPIC in u-boot', I wrote 'the goal of 
> fPIC', and as such, I think I read it right. I do agree though (and I 
> think I made it clear further in my post) that u-boot images are linked 
> for a fixed location and that their entry point is at the first address 
> of this location.

Wrong. Their entry point is whereever the reset vector happens to be,
and this is usually NOT at offset 0 into the text segment.

> However, I disagree with the fact that u-boot's link address would 
> always be the reset vector location. This is not generally true, and 
> this is especially not true for the orion5x, which is linked for its RAM 
> location, not for its FLASH location, and for which the image is flashed 

You are probably looking at old, obsolete code.  Please check out the
"next" branch, which has Heiko's ARM rework patches applied.

> > [I'm giving the generic, architecture independent view of U-Boot
> > here. Actual implementations for some processors may behave
> > differently, but this is nothing you should build on.]
> 
> [Except when working with these processors. :) ]

Not even then, because things might change under your feet - as just
happened.

> As for what I am trying to do: ironically, I am trying to find a way 
> that the entry point of u-boot be at the reset vector location, just as 
> it should.

There it is.

> As for you suggestion of arranging the code so that the entry point ends 
> up at 0xffff0000, it requires much more than a little tuning of the 
> linker script. This tuning is actually a long and suboptimal process 
> akin to the bin packing problem, where you'd have to split sections, 
> notably .text, and then shuffle sections in memory areas while hoping 
> that no section is going to grow bigger than the memory region it was 
> assigned to. And then, change one thing in the config, and you may need 
> to solve the problem yet again.

If you can live with the wasted 64 kB of empty space "behind" the
reset vector, then it is not worse than counting the number of flash
sectors needed for the image (which you have to do anyway to
determine the TEXT_BASE). And moving a number of static,
never-changing objects into that free area is no real rocket science
either.  Say, half an hour of efforts including basic testing.

> > Hm... I don;t see global variables being used in timer_init() in
> > "arch/arm/cpu/arm926ejs/orion5x/timer.c" - which exact code are you
> > referring to?
> 
> (*)
> 
> timer_init() ends up calling reset_timer_masked(), which writes into 
> static variables timestamp and lastdec.

This is indeed broken and needs to be fixed.

> This is true, and reinforces my point that the comment in board.c is out 
> of sync with what is really going on, as it explicitely says the pointer 
> is passed as an argument to the init functions (lines 241 and 242 in 
> 'next') whereas it is not.

Patch welcome...

> I still think that with -fPIC u-boot should be able to run until at 
> least the end of board_init_f from anywhere in FLASH. And if all it 
> takes to get there is making sure that board_init_f-called code uses 
> only consts, then I think it would be worth asking board maintainers to 
> go check this while they're testing Heiko's relocation patches.

We use PIC to make U-Boot relocatable to any RAM address, so we can
auto-adjust to actual RAM sizes and always copy U-Boot to the
(dynamically determined) end of RAM location.  When running from
flash, U-Boot is linked to a fixed address map, which includes the
(fix) reset vector as single entry point.

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
Our management frequently gets lost in thought.   That's because it's
unfamiliar territory.