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, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
