The old lpc3130 port works the way you describe. The problem with it is that it is on a three year old u-boot. http://git.lpclinux.com/
It builds a single u-boot image and then slices the SPL piece off from the front of it. On Sat, Dec 17, 2011 at 12:38 AM, Simon Glass <s...@chromium.org> wrote: > Hi, > > On Fri, Dec 16, 2011 at 9:20 AM, jonsm...@gmail.com <jonsm...@gmail.com> > wrote: >> The CPU I'm working with, the LPC3130, is kind of an in-between CPU >> for SPL. Instead of a tightly constrained RAM of 16KB or so I have >> 96KB to work with. 96KB is enough room to support all of the various >> boot modes (uart, nand, spi, USB, etc) but not enough room for the >> full uboot command set. So I'm still stuck with the SPL model, but my >> constraints are much less. >> >> One example of a conflict with SPL is NAND support. With SPL you hard >> code in the NAND type. In my case I have enough room to do NAND type >> detection. So this has me modifying the #ifdefs in the makefiles to >> include the NAND detection code in my SPL loader. >> >> I'm wondering if SPL could be designed in a more generic manner. >> Another model would be to use SPL as the base layer for all u-boot >> builds. You would then start turning on features until full uboot >> capability was reached. An example of this would be NAND support, the >> default would be hard coded NAND for all u-boot builds, but turning on >> NAND detection would increase the size of the build and disable the >> hard coded support. Another default would be SPL chaining into the >> next image, turning on the u-boot UI would again make the code larger >> and disable auto-chaining. >> >> The concept is to remove SPL as a special class and turn it into the >> base layer that everything builds on. Changing the model in this was >> should make the config files easier to understand. Instead of having a >> single file combining SPL and full u-boot you'd have two independent >> ones. In my case I'd build one u-boot config that fits into 96K and >> another full 250K one. Of course the two config files could each >> include a common base config. >> >> Thoughts? > > That's one way to do it, and makes more and more sense as the amount > of available SRAM increases. Of course some SOCs can even set up their > SDRAM and read entire programs in, so there are no restrictions. But > for those with limitations, it makes sense to me to make SPL more a > cut down build of U-Boot than a special program that pulls in #ifdefed > code from various places. > > Another approach is to just have one U-Boot, but keep everything you > need to get started in the first 96KB. > > I have the beginnings of a patch which allows you to split U-Boot into > two parts: an initial part which is loaded first, and another part > which can be loaded later if needed. > > It works by telling the linker where to put the code and arranging > that everything you need early is at the start of the image. During my > recent forays into SPL I formed the view that it might be another way > to implement the SPL functionality. It is controlled by a config file > which specifies function symbols, object files or libraries to include > in the initial region. It can also work from a run-time profile. > > There are problems though. It is normally pretty easy to work out (or > profile) which code is executed, but it is harder to know which data > is needed. SPL solves this by linking and the resulting link errors > when you get it wrong are easy to spot. But I don't have a tool that > checks that all the code and data you need is within a certain region. > Static inline functions can be a pain since they appear repeated all > over the text area. Relocation data needs to stored with the loaded > section. > > In short this 'postload' feature is more complex, but more general. > Might be useful one day. > > Regards, > Simon > >> >> -- >> Jon Smirl >> jonsm...@gmail.com >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot -- Jon Smirl jonsm...@gmail.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
