Dear Albert ARIBAUD,
In message 4C9365E7.50505@free.fr you wrote:
- 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
"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.
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".
- 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.
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.
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...
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.
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.
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