Wolfgang Denk a écrit :
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
Hmm... PIC is interesting only if you want the same binary to run from two places, like NOR then RAM, which is the case when U-boot is the code which gets run in NOR at power-up and ends up running in RAM later.
For NAND-based boards, the NAND bootloader will load U-boot to RAM, and U-boot will never run from anywhere else but its intended RAM location.
Why not make the same two-stage separation systematic, even on NOR-based devices and others where U-boot is currently the one executed at power-up? Split the current U-boot into a small primary bootloader (U1?) and a fuller secondary bootloader (U2?). U1 would initialize RAM (and a console?) and U2 would initialize everything else. Each stage would only run from a fixed location and type of memory, removing the need for PIC.
Comment given off the top of my head, so feel free to open fire. :)
Amicalement,