Le 16/09/2010 23:26, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4c927c0c.1080...@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.
They key here is 'usually'; see the orion5x case for instance. >> 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 am looking at code which was in effect until Heiko's patches; this is barely 'old, obsolete code', and I am precisely discussing the fact that Heiko's patches break building this code for orion5x, and require replacing a simple process with quite a complicated one. >>> [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. 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 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. >> 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. 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 I am not willing to inflict on people who want to use u-boot on arm926ejs if I know a way to avoid it, and I know one which indeed requires a bit more effort but for me only, and will be just as (in)sensitive to things moving under feet. >>> 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... Patches for both timer and board.c coming in soon. :) >> 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. 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. Since enforcing these two constaints will fix the problem I have with (wrongly) running u-boot from any FLASH location, I'll happily cease arguing for it if so ordered; but as long as I can, I'll continue making sure changes made to u-boot avoid breaking this if they can. (and I'll be sure to address the requirement that u-boot be linked for an address in flash which contains its entry point in my upcoming patch for using the last 64 KB of flash on orion5x) Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
