Dear Joakim Tjernlund,
In message OF3EBC8B6E.2C26AE15-ONC12576A0.003379DE-C12576A0.0039F518@transmode.se you wrote:
Will such changes be needed to all functions that work on (constant?) strings? Or why here?
Only those that work on constant strings before relocation to RAM. One alternative is to change all call sites to puts(LINK_OFF(s)).
Well, I understand this is not only puts(), but also all places where a constant strings are used. And this is a lot of places and a lot of functions.
Yet another of these really, really invasive changes. Is this really unavoidable?
Yes, global data and strings accessed before relocation to RAM needs to be wrapped with LINK_OFF to calculate the real address.
Ouch.
I selected the changes I needed to for my 83xx board and then some. I don't think serial.c needs any more changes.
Understood. But that means we don't see the real scope of this change yet, as adapting a new board to use this featue will become a trial-and-error procedure, adding incrementally more and more of these changes (unless someone performs a thorough review and catches most of these places in an initial commit).
Remember you only have to consider code that uses global data and is executed before relocation to RAM and that limits the scope quite a lot. The places to look at you find by following board.c's init_sequence. I think my changes are fairly complete for PowerPC,83xx. There are missing bits to do, mainly in other archs I think, but boards that doesn't need/want this functionality don't have to change anything.
I have to admit that I dislike the impact of this change, and I'm not sure if we really want to take this route.
Comments from others are welcome and needed here!
I think as follows:
In the past, the majority of systems supported by U-Boot where booting from NOR flash or other memory devices. This made it easy to use common code (like library functions) both before and after relocation to the final location in RAM. For your current changes this means that we have a large number of places where we have to add this LINK_OFF stuff. This makes the code harder to read, much harder to understand (especially if it's not working during the initial bringup on new hardware), and harder to debug in general.
If I try to see trends in the development of U-Boot I notice a growing number of systems that boot from NAND flash, DataFlash or that come with on-chip ROM code to load images from SDCard and other storage media. Such systems cannot make real benefit from the original design of U-Boot, as here U-Boot is inherently a second-stage boot loader which gets loaded by some other means. Even for NAND booting systems where we have the NAND boot code included within the U-Boot source tree we often cannot share much of the code between the primary and the secondary loader stages as there are usually tight restrictions on the maximum size for the primary loader image. Here a sharper separation of "primary" and "secondary" boot code within U-Boot would be benefical.
I feel (but this is really just a feeling, and I definitely would like to hear what others think about this!) your PIC changes would be (or have been) useful for the former usage mode, but they come at a pretty heavy cost as they are really invasive to the code. For the second usage mode they are not usable, or at least not useful. This makes me wonder if we really should continue to work in this direction.
Comments welcome...
Best regards,
Wolfgang Denk