ARM: add relocation support

Le 11/08/2010 20:16, Heiko Schocher a ?crit :

Quoted 4 lines

arch/arm/lib/board.c +0 -0

index 54519b0..88c6427 100644

Quoted 1 line

+init_fnc_t *init_sequence[] = {

Tested this code tonight, and I noticed that if the image is run from another location than the one it was linked for, then access to init_sequence is not made at the right location. To get correct access regardless of the image location, init_sequence has to be defined const.

I suspect that the same applies to all globals used by any function called during board_init_f execution.

Hmm.. at this place code is not relocated! So it should be executed on the right address.

One of the things I love(d) with u-boot (at least the ARM one) is that I could place it in flash at any address and it would just work. So when I have a new binary I first write it to another flash sector and "go" to it. Only if it works I flash at offset 0. Sure I test in RAM

first, but since writing the ram image to flash is not uncommon, the final test for me has always been in flash -- also for other reasons.

Is there any chance we could go on testing on a different flash address without relinking in-between (with the risk of mismatching the two images?)

Dear Alessandro Rubini,

I agree that it would be nice to have U-Boot completely position- independent and completelky restartable, but this would be a new feature, which newer existed before.

tftp 6000000 u-boot.bin
go 6000000

Quoted 5 lines

I agree that it would be nice to have U-Boot completely position- independent and completelky restartable, but this would be a new feature, which newer existed before.

x86 has a nice feature whereby I can build two images that differ only by TEXT_BASE. I can build using TEXT_BASE somewhere in low memory, tftp the image and the 'go' directly to the base address of the image

This works because the x86 reset vector is at top of memory (0xfffffff0), not bottom (0x00000000) so the very first bytes of u-boot.bin are not the reset vector, but rather where the reset vector jumps to after performing some very low-level hardware init

As long as I do not mess with the low-level init code, I can be confident that an image that 'boots' using the 'go' command will boot from Flash

Dear Graeme Russ,

Quoted 9 lines · In message <[email protected]> you…

Quoted 5 lines

I agree that it would be nice to have U-Boot completely position- independent and completelky restartable, but this would be a new feature, which newer existed before.

x86 has a nice feature whereby I can build two images that differ only by TEXT_BASE. I can build using TEXT_BASE somewhere in low memory, tftp the image and the 'go' directly to the base address of the image

You can build such images for any architecture, but usually they will not work.

The code assumes to be started at the reset vector, and to find a CPU with all peripherals and registers in virgine state which is only present after a reset.

On many processors there are certain steps that are irreversiable by software - there are write-once registers, there are memory controller registers which change the behaviour of the memory controller when the are written for the first time, etc.

Quoted 5 lines

This works because the x86 reset vector is at top of memory (0xfffffff0), not bottom (0x00000000) so the very first bytes of u-boot.bin are not the reset vector, but rather where the reset vector jumps to after performing some very low-level hardware init

The actual position of the reset vector in the address space has nothing to do with that isse. It's other things like register states

or mode of operation of certain units (memory controller, MMU etc.) that are different when coming frash out of reset versus when coming from a running U-Boot systems.

Quoted 3 lines

As long as I do not mess with the low-level init code, I can be confident that an image that 'boots' using the 'go' command will boot from Flash

This _may_ work on certain boards and processors, but it does not (and I think it cannot) work in general.

I have a 'cold-boot' parameter which is set by the reset vector code. I can use this to selectively skip 'once-only' initialisation

I don't doubt that you are entirely correct. But there are many ways to skin a cat. My problem was to reduce the build->burn->boot development time where the burn phase was the longest. The low level boot and device initialisation all works and hasn't changed in quite a while, so I can rely on what is on my (nearly a year) old image.

A common framework (within the bounds of cross-architecture limitations) would be nice

[...]

Quoted 2 lines

I have a 'cold-boot' parameter which is set by the reset vector code. I can use this to selectively skip 'once-only' initialisation

[...]

Quoted 5 lines

I don't doubt that you are entirely correct. But there are many ways to skin a cat. My problem was to reduce the build->burn->boot development time where the burn phase was the longest. The low level boot and device initialisation all works and hasn't changed in quite a while, so I can rely on what is on my (nearly a year) old image.

I see this feature not only nice to speed up development, sometimes it also comes in really handy for production, too - if you have to struggle with debugging tools that are either plain too stupid to program some flash devices or are much slower than U-Boot, you can simply run a specially built version from RAM and/or provide it with an environment in RAM to do all the actual flashing for the board production.

Quoted 2 lines

A common framework (within the bounds of cross-architecture limitations) would be nice

For some targets, there may be fragments present in the code when searching for CONFIG_MONITOR_IS_IN_RAM, which statically disables all the low-level initialization to allow U-Boot being loaded from a first-stage loader or debugger. But beware, it is not always functional out-of-the-box.

I see this feature not only nice to speed up development, sometimes it also comes in really handy for production, too - if you have to

struggle with debugging tools that are either plain too stupid to program some flash devices or are much slower than U-Boot, you can simply run a specially built version from RAM and/or provide it with an environment in RAM to do all the actual flashing for the board production.

For some targets, there may be fragments present in the code when searching for CONFIG_MONITOR_IS_IN_RAM, which statically disables all the low-level initialization to allow U-Boot being loaded from a first-stage loader or debugger. But beware, it is not always functional out-of-the-box.

Dear Wolfgang Wegner,

In message <[email protected]> you wrote:

Quoted 5 lines

struggle with debugging tools that are either plain too stupid to program some flash devices or are much slower than U-Boot, you can simply run a specially built version from RAM and/or provide it with an environment in RAM to do all the actual flashing for the board production.

Note the "specially built version". My understanding is that this "special building" cannot be avoided in general.

Quoted 5 lines

For some targets, there may be fragments present in the code when searching for CONFIG_MONITOR_IS_IN_RAM, which statically disables all the low-level initialization to allow U-Boot being loaded from a first-stage loader or debugger. But beware, it is not always functional out-of-the-box.

True. And the image configured that way is not the same binary image that you normally load into flash.

Hello Albert,

Quoted 9 lines · Albert ARIBAUD

Le 11/08/2010 20:16, Heiko Schocher a ?crit :

Quoted 6 lines

arch/arm/lib/board.c +1 -0

index 54519b0..88c6427 100644
 
+init_fnc_t *init_sequence[] = {

Quoted 4 lines

Tested this code tonight, and I noticed that if the image is run from another location than the one it was linked for, then access to init_sequence is not made at the right location. To get correct access regardless of the image location, init_sequence has to be defined const.

Hmm.. at this place code is not relocated! So it should be executed on the right address. Don;t know, if this would be the only problem, if you run this code from another address ...

Well, the main goal of -fPIC is that the code should be able to run from anywhere, so it should be able to run from anywhere in FLASH. Besides,

that can be useful for designs where two (possibly differently built) images of u-boot are located in FLASH and some mechanism allows booting from either.

(I personally have another motive for having at least the _f part of u-boot able to run fully PIC, as I want to implement direct-to-u-boot resetting on targets that have a reset vector rather far away from the end of the addressable space but too near to fit u-boot in, e.g. the orion5x which resets as 0xffff0000: 64 KB is too small for u-boot. I have submitted a patch for this then withdrawn it because of the relocation patches; however for this conversation, we can keep this point aside)

As for what would or would not work, ATM it boils down to 'access to const variables will be position-independent, access to others will not'. Non-initialized as well as initialized-but-not-const globals are always accessed at their link location before and after relocation, and thus will work only if you're running the image at its linked location.

This means that non-const data obviously can't work when the image is linked to FLASH; and they can even wreak havoc if the image linked for RAM and relocated near, but not exactly at, its linked location. The

fact that it did not break so far in u-boot without reloc (and yes, several drivers do access globals during in-FLASH board init) is due to the fact that DRAM is already initialized when drivers access these globals at their linked location; this breaks when the image is linked for a location in FLASH.

Of course solving the init data issue (by making them const) will not solve the issue of rw data. For this one I see two solutions:

1) forbid using such data in drivers during _f phase if that is

possible. For instance, in the timer.c driver of orion5x, the timer_init code accesses two writable variables because it wants to have a first reference for rollover detection; this can obviously be postponed to the _r init phase.

2) in case where the _f phase *has* to store data in globals, then this data should go to the globals space allocated below the stack, where gd also resides, and be later copied to usual globals if reqired.

BTW, the comments in board.c say that the _f init functions receive a pointer to gd; actually they dont, they're int (*) (void). Were the comments always out-of-sync with the code, or was there a removal of the gd argument for some reason?

Dear Albert ARIBAUD,

Quoted 3 lines · In message<[email protected]> you wrote:

Well, the main goal of -fPIC is that the code should be able to run from anywhere, so it should be able to run from anywhere in FLASH. Besides,

You misread that. We actually make no attempts that the code can be run from any arbitrary address. On contrary - we explicitly link it for a fixed address map, which is defined by the location of the reset vector, which is the one and only defined entry point into U-Boot.

[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.]

Quoted 3 lines

that can be useful for designs where two (possibly differently built) images of u-boot are located in FLASH and some mechanism allows booting from either.

The only reasonable use cases for such a szenario that I am aware of would be best implemented in hardware, by being able to toggle between two banks of flash memory, selecting one or the other as boot device. Then you can even use the same U-Boot binary images, which is a good thing in such setups. [eventualkly you want to store the environment somewhere else, say in some storage device on the backplane, so all instances of U-Boot refer to the same data.]

Quoted 8 lines

(I personally have another motive for having at least the _f part of u-boot able to run fully PIC, as I want to implement direct-to-u-boot resetting on targets that have a reset vector rather far away from the end of the addressable space but too near to fit u-boot in, e.g. the orion5x which resets as 0xffff0000: 64 KB is too small for u-boot. I have submitted a patch for this then withdrawn it because of the relocation patches; however for this conversation, we can keep this point aside)

I do not understand this what you mean by that, or what the problem might be. It is trivial to arrange the code such that no significant gaps remain. This requires just a little tuning of the linker script.

Quoted 5 lines

As for what would or would not work, ATM it boils down to 'access to const variables will be position-independent, access to others will not'. Non-initialized as well as initialized-but-not-const globals are always accessed at their link location before and after relocation, and thus will work only if you're running the image at its linked location.

Again, please keep in mind that (1) this depends on the linker script, and (2) that before relocation to RAM _all_ access to global variables is extremely limited as we have only a read-only data segment and no BSS segment at all.

Quoted 3 lines

This means that non-const data obviously can't work when the image is linked to FLASH; and they can even wreak havoc if the image linked for RAM and relocated near, but not exactly at, its linked location. The

I don't understand what you mean. Are you aware of the restrictions of the execution environment before relocation to RAM?

Quoted 5 lines

fact that it did not break so far in u-boot without reloc (and yes, several drivers do access globals during in-FLASH board init) is due to the fact that DRAM is already initialized when drivers access these globals at their linked location; this breaks when the image is linked for a location in FLASH.

If any drivers do such things, and if these drivers are used before relocation to RAM, these are serious bugs that must be fixed.

If you are aware of such bugs please post this information, so people can start working on fixes.

Quoted 4 lines

Of course solving the init data issue (by making them const) will not solve the issue of rw data. For this one I see two solutions:

1) forbid using such data in drivers during _f phase if that is

This is, and has always been, the case.

Quoted 4 lines

possible. For instance, in the timer.c driver of orion5x, the timer_init code accesses two writable variables because it wants to have a first reference for rollover detection; this can obviously be postponed to the _r init phase.

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?

Quoted 3 lines

2) in case where the _f phase *has* to store data in globals, then this data should go to the globals space allocated below the stack, where gd also resides, and be later copied to usual globals if reqired.

It seems you really minunderstand the excution environment before relocation. Ther eis also no steck there, and of course no "globals space allocated below the stack", because we don't even have the RAM initialized yet.

Quoted 4 lines

BTW, the comments in board.c say that the _f init functions receive a pointer to gd; actually they dont, they're int (*) (void). Were the comments always out-of-sync with the code, or was there a removal of the gd argument for some reason?

Please read the code, and the README. Please pay special attention to section "Initial Stack, Global Data:".

In short: the pointer to the global data is passed in a register, which we reserve for this purpose.

Best regards,

Wolfgang Denk

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.

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

Quoted 3 lines

[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. :) ]

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.

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.

Quoted 3 lines

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 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.

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.

Dear Albert ARIBAUD,

Quoted 1 line · In message<[email protected]> you wrote:

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

[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.

Quoted 3 lines

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.

Quoted 8 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 4 lines

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...

Quoted 5 lines

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.

Things do change indeed, hence my attempt ? 1) making sure I detect the change, 2) design things so that they are as resilient to change as possible. One example of such a resilience is making sure the u-boot code designed to run in FLASH can run *anywhere* in FLASH.

Quoted 5 lines

Quoted 3 lines

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.

Yes. And you are opposing this, which I do not understand since I'm trying to make this SoC/board perform exactly as you specify while maintaining balance with the hardware's constraints.

Quoted 6 lines

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.

Precisely, I do not want to live with wasting 64 out of 512 KB of FLASH.

Regarding counting the flash sectors for mapping u-boot to flash to determine TEXT_BASE, I never had to, thanks to u-boot being (albeit accidentally) able to run from anywhere in FLASH (I can't help seeing irony in the fact that this ability was broken by adding a flag which is supposed to allow running from anywhere).

As for the half-hour of effort, the half-hour part is an assumption which would need supporting, and even if it is only half an hour, it is half an hours for each person configuring u-boot for arm; a burden that

This statement does not contradict the proposal that U-boot, despite being linked for some address in FLASH, should be able to run, from _start to relocation, at any FLASH location at least for architectures, CPUs, SoCs or boards which trivially allow this. I do believe this requirement is both reasonable and useful.

Anyway: there is a bottom line on which I think we agree now:

1) init_sequence is a constant array and should thus be qualified 'const';

2) any data accessed between _start and relocation should be const as well.

Dear Albert ARIBAUD,

Quoted 5 lines · In message<[email protected]> you wrote:

Things do change indeed, hence my attempt ? 1) making sure I detect the change, 2) design things so that they are as resilient to change as possible. One example of such a resilience is making sure the u-boot code designed to run in FLASH can run *anywhere* in FLASH.

As for 1), just follow the postings on this mailing list.

As for 2), you need to implement the following features (none of which are supported yet, AFAICT):

[This is based on the assumption that you want to use the very same binary image fom different addresses]

- The code must be completely position-independent.

- You need a way to detect if you are running on a virgin CPU fresh out of reset or on a pre-initialized system.
- You need to isolate parts in the initialization sequence that must not be repeated.
- You must make sure such steps are not re-run on a pre-initialized system.

- You need to implement a way with the different behaviour in terms of resources.

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 3 lines

Yes. And you are opposing this, which I do not understand since I'm trying to make this SoC/board perform exactly as you specify while maintaining balance with the hardware's constraints.

I do not understand what you mean. Unless loaded by some other mechanism (like when booting from NAND flash etc.), the entry point to U-Boot *is* of course at the reset vector location - or how would the CPU be able to execute the code?

Quoted 8 lines

Quoted 6 lines

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.

Precisely, I do not want to live with wasting 64 out of 512 KB of FLASH.

OK, se put a few objects in that "hole" to fill it.

Quoted 5 lines

Regarding counting the flash sectors for mapping u-boot to flash to determine TEXT_BASE, I never had to, thanks to u-boot being (albeit accidentally) able to run from anywhere in FLASH (I can't help seeing irony in the fact that this ability was broken by adding a flag which is supposed to allow running from anywhere).

I lost you. If you put the U-Boot image at an arbitrary location in flash, the CPU will not start it because the CPU begins execution at the reset vector.

Quoted 3 lines

As for the half-hour of effort, the half-hour part is an assumption which would need supporting, and even if it is only half an hour, it is half an hours for each person configuring u-boot for arm; a burden that

No. Only for those who have a system with such a reset vector location,

and I seriously doubt that any of these changes to the linker script have to be board specific.

That means you just need to
perform this task once to improve the platform-specific linker script, and it will automatically work for all other users of that architecture as well.

Quoted 5 lines

This statement does not contradict the proposal that U-boot, despite being linked for some address in FLASH, should be able to run, from _start to relocation, at any FLASH location at least for architectures, CPUs, SoCs or boards which trivially allow this. I do believe this requirement is both reasonable and useful.

If you know how to implement this in a clean way, then please go forward and do it. Patches are welcome. All I can say is that I don't know how to do that, but then, I'm not an ARM expert. Eventually it might be easier on ARM than on PowerPC, where we don't have this feature yet either.

Quoted 5 lines

Anyway: there is a bottom line on which I think we agree now:

1) init_sequence is a constant array and should thus be qualified 'const';

2) any data accessed between _start and relocation should be const as well.

I think you mean the right thing, but the wording is wrong again.

You can fully access (read and write) data in the special "global data" or "initial data" structure.

You can perform read-accesses to
any data in the text and/or data segments. You cannot write to data in the the text and/or data segments. You must not attempt to access any data in the bss segment because this does not even exist, so you're accessing random addresses.

Best regards,

Wolfgang Denk

Quoted 7 lines

- You need a way to detect if you are running on a virgin CPU fresh out of reset or on a pre-initialized system.
- You need to isolate parts in the initialization sequence that must not be repeated.
- You must make sure such steps are not re-run on a pre-initialized system.

This is not required per se to 'start from any location'. It is required to 'start in any state', which is another requirement -- also

commandable since it increases resilience to varying conditions. I think the 'start from anywhere' requirement can be fulfilled without fulfilling (yet) the 'start in any state' one.

Quoted 2 lines

- You need to implement a way with the different behaviour in terms of resources.

This requirement sounds very general; can you be more precise on it?

Now, for arm926ejs, it so happens that prior to Heiko's relocation patches, u-boot's startup code *was* position-independent, and is not any more, but that making init_sequence (and other data read during startup) onst makes it p-i again.

Quoted 3 lines

I lost you. If you put the U-Boot image at an arbitrary location in flash, the CPU will not start it because the CPU begins execution at the reset vector.

You're mistaking "putting the image anywhere in FLASH" and "putting _start anywhere in FLASH".

Quoted 6 lines

Quoted 3 lines

As for the half-hour of effort, the half-hour part is an assumption which would need supporting, and even if it is only half an hour, it is half an hours for each person configuring u-boot for arm; a burden that

No. Only for those who have a system with such a reset vector location,

That is, all people using orion5x for instance.

Quoted 2 lines

and I seriously doubt that any of these changes to the linker script have to be board specific.

I did not say board-specific, I said config-specific.

Only for a given u-boot configuration. Change it, and that changes the image content, thus the mapping, and you've got to fix _start again.

Dear Albert ARIBAUD,

Quoted 8 lines · In message<[email protected]> you wrote:

Quoted 7 lines

- You need a way to detect if you are running on a virgin CPU fresh out of reset or on a pre-initialized system.
- You need to isolate parts in the initialization sequence that must not be repeated.
- You must make sure such steps are not re-run on a pre-initialized system.

Quoted 2 lines

This is not required per se to 'start from any location'. It is required to 'start in any state', which is another requirement -- also

"start in any state" is only possible by going through the hardware reset.

There are messed up situations where you cannot recover the processor any more by software.

You probably mean "virgin state after reset" versus "some other, but sane state, for example while running U-Boot". You cannot separate these.

If you want to start from another location, you must run some other code before that (as the CPU will always start from the boot vector only), so your system state has been changed.

Quoted 3 lines

commandable since it increases resilience to varying conditions. I think the 'start from anywhere' requirement can be fulfilled without fulfilling (yet) the 'start in any state' one.

But not without being able to "start in another, non-virgin state".

Quoted 4 lines

Quoted 2 lines

- You need to implement a way with the different behaviour in terms of resources.

This requirement sounds very general; can you be more precise on it?

After reset you have no RAM, no stack, no BSS, no writable data segment, etc. etc. When starting from some other code, conditions may be different.

Quoted 4 lines

Now, for arm926ejs, it so happens that prior to Heiko's relocation patches, u-boot's startup code *was* position-independent, and is not any more, but that making init_sequence (and other data read during startup) onst makes it p-i again.

OK.

Quoted 6 lines

Quoted 3 lines

I lost you. If you put the U-Boot image at an arbitrary location in flash, the CPU will not start it because the CPU begins execution at the reset vector.

You're mistaking "putting the image anywhere in FLASH" and "putting _start anywhere in FLASH".

_start is integral part of the U-Boot image...

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

As for the half-hour of effort, the half-hour part is an assumption which would need supporting, and even if it is only half an hour, it is half an hours for each person configuring u-boot for arm; a burden that

No. Only for those who have a system with such a reset vector location,

That is, all people using orion5x for instance.

Quoted 4 lines

Quoted 2 lines

and I seriously doubt that any of these changes to the linker script have to be board specific.

I did not say board-specific, I said config-specific.

It does not depend on board configuration or such. It depends only on your system's memory map (location of the reset vector), and this is constant - for example - for all orion5x boards.

Quoted 2 lines

Only for a given u-boot configuration. Change it, and that changes the image content, thus the mapping, and you've got to fix _start again.

Why should I?

Did you not state that the reset vector is at a fixed
location? Then we can use constant data (comon to all board configurations) to fill the gap between there and end of physical memory space.

Best regards,

Wolfgang Denk

Depends on the processor I guess; but still, my point is that "start at any location" does not require that you detect whether you are fresh out of reset or not.

Reminder: here we're talking about fitting a >64 KB u-boot in flash, with _start at the reset vector (0xffff0000 on orion5x), without wasting the space above the reset vector (64 KB on orion5x) and with minimal waste in the rest of the mapping.

You suggested tweaking the linker file to manually place the _start symbol at the reset location, and then bin-pack the rest of the code -- some of which will have to go above _start, some below. This can only be achieved by defining 'MEMORY' regions in the linker file, and then you

This is why I say that the proposed solution of manually tweaking the linker file is sensitive to configuration changes.

Quoted 4 lines

Quoted 2 lines

Only for a given u-boot configuration. Change it, and that changes the image content, thus the mapping, and you've got to fix _start again.

Why should I?

Your change may overfill one of the 'MEMORY' regions that would have to be defined to get _start mapped to the reset vector location. Personally, I hate it when I enable some configuration option and it results in a link-time mapping error.

Quoted 3 lines

location? Then we can use constant data (comon to all board configurations) to fill the gap between there and end of physical memory space.

That will not fill it properly and consistently unless that constant data is 1) really constant across all configuration option choices for all boards and 2) nicely filling the gap up to 64 KB.

As I said, I have a solution for my problem which puts _start at the reset vector location without changing the linker file at all, and with little, contained and controlled changes to the start.S file. I will post this as a [PATCH][NEXT] ([RFC] also if you will), clearly exposing the issue it addresses and the solution it uses, and we can discuss its merit then.

Dear Albert ARIBAUD,

Quoted 4 lines

Reminder: here we're talking about fitting a>64 KB u-boot in flash, with _start at the reset vector (0xffff0000 on orion5x), without wasting the space above the reset vector (64 KB on orion5x) and with minimal waste in the rest of the mapping.

We do similar things on several boards to align the environment with special, small flash sectors that happen to lie in the middle of the image.

Your case is the same - you would align the _start such that it is located right in the middle of the image: not on a specific flash sector, but at the reset vector.

Quoted 4 lines

You suggested tweaking the linker file to manually place the _start symbol at the reset location, and then bin-pack the rest of the code -- some of which will have to go above _start, some below. This can only be achieved by defining 'MEMORY' regions in the linker file, and then you

This is not needed.

Quoted 2 lines

This is why I say that the proposed solution of manually tweaking the linker file is sensitive to configuration changes.

Yes, it is. I do not deny that. But this is not a real problem. If the configuration grows such that you need an additional flash sector, you will have to adjust TEXT_BASE. This does not happen frequently.

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

Only for a given u-boot configuration. Change it, and that changes the image content, thus the mapping, and you've got to fix _start again.

Why should I?

Quoted 4 lines

Your change may overfill one of the 'MEMORY' regions that would have to be defined to get _start mapped to the reset vector location. Personally, I hate it when I enable some configuration option and it results in a link-time mapping error.

The "upper part", for reset vector to end of address space, would never change.

Quoted 7 lines

Quoted 3 lines

location? Then we can use constant data (comon to all board configurations) to fill the gap between there and end of physical memory space.

That will not fill it properly and consistently unless that constant data is 1) really constant across all configuration option choices for all boards and 2) nicely filling the gap up to 64 KB.

See for example the TQM860L board configuration - it uses an embedded flash sector, with manual tweaking in the linker script.

u-boot.map for this board shows:

...
arch/powerpc/lib/cache.o(.text)
.text 0x40007c20 0x64 arch/powerpc/lib/cache.o

                 0x40007c20                flush_cache
                 0x00008000                . = DEFINED (env_offset)?env_offset:.
  *fill*         0x40007c84      0x37c 00
  common/env_embedded.o(.ppcenv)
  .ppcenv        0x40008000     0x8000 common/env_embedded.o
                 0x40008000                environment
                 0x4000c000                redundand_environment
  *(.text)
  .text          0x40010000        0x4 common/env_embedded.o
                 0x40010000                env_size

.text 0x40010004 0x0 lib/libgeneric.a(ctype.o)
...

So we are "wasting" 0x37c = 892 bytes of memory for an unused gap. The last changes where the object placing had to be changed due to code size etc. were commit 32482be6 (Feb 19, 2009), and before that fe57bb19 (Sep 18, 2002). Having to tweak this file every 7 years or so is something I'm considering to be acceptable. YMMV...

Quoted 6 lines

As I said, I have a solution for my problem which puts _start at the reset vector location without changing the linker file at all, and with little, contained and controlled changes to the start.S file. I will post this as a [PATCH][NEXT] ([RFC] also if you will), clearly exposing the issue it addresses and the solution it uses, and we can discuss its merit then.

I'm looking forward to seeing your patches.

Best regards,

Wolfgang Denk

Quoted 16 lines

u-boot.map for this board shows:

...
arch/powerpc/lib/cache.o(.text)
.text 0x40007c20 0x64 arch/powerpc/lib/cache.o

                 0x40007c20                flush_cache
                 0x00008000                . = DEFINED (env_offset)?env_offset:.
  *fill*         0x40007c84      0x37c 00
  common/env_embedded.o(.ppcenv)
  .ppcenv        0x40008000     0x8000 common/env_embedded.o
                 0x40008000                environment
                 0x4000c000                redundand_environment
  *(.text)
  .text          0x40010000        0x4 common/env_embedded.o
                 0x40010000                env_size

Quoted 8 lines

.text 0x40010004 0x0 lib/libgeneric.a(ctype.o)
...

So we are "wasting" 0x37c = 892 bytes of memory for an unused gap. The last changes where the object placing had to be changed due to code size etc. were commit 32482be6 (Feb 19, 2009), and before that fe57bb19 (Sep 18, 2002). Having to tweak this file every 7 years or so is something I'm considering to be acceptable. YMMV...

This is a simple alignment. I do not need to align code, I need to map *one* symbol, namely _start, at a given location, here 0xffff0000, so that the 64 KB sector which contains start is not wasted and the image resides in as few sectors as possible.

Dear Albert ARIBAUD,

Quoted 25 lines · In message<[email protected]> you wrote:

Quoted 16 lines

u-boot.map for this board shows:

...
arch/powerpc/lib/cache.o(.text)
.text 0x40007c20 0x64 arch/powerpc/lib/cache.o

                  0x40007c20                flush_cache
                  0x00008000                . = DEFINED (env_offset)?env_offset:.
   *fill*         0x40007c84      0x37c 00
   common/env_embedded.o(.ppcenv)
   .ppcenv        0x40008000     0x8000 common/env_embedded.o
                  0x40008000                environment
                  0x4000c000                redundand_environment
   *(.text)
   .text          0x40010000        0x4 common/env_embedded.o
                  0x40010000                env_size

Quoted 8 lines

.text 0x40010004 0x0 lib/libgeneric.a(ctype.o)
...

So we are "wasting" 0x37c = 892 bytes of memory for an unused gap. The last changes where the object placing had to be changed due to code size etc. were commit 32482be6 (Feb 19, 2009), and before that fe57bb19 (Sep 18, 2002). Having to tweak this file every 7 years or so is something I'm considering to be acceptable. YMMV...

Quoted 4 lines

This is a simple alignment. I do not need to align code, I need to map *one* symbol, namely _start, at a given location, here 0xffff0000, so that the 64 KB sector which contains start is not wasted and the image resides in as few sectors as possible.

And I map *one* symbol, namely environment, at a given location, here 0x40008000.

It seems you are not willing or trying or able to understand. I give up here.

Viele Gr??e,

Wolfgang Denk