Dear Eric, In message <513d18f3.2010...@boundarydevices.com> you wrote: > > I understand the point, but think the pain is manageable and > mostly ours.
When I say it doesn't scale, I'm not only thinking about yourown efforts, and your customers. I also think about things like the increase of build and test time for _everybody_ who performs tests on U-Boot - instead of one board, we now have to build - how many? 6? - configurations. If we allow this now, others will copy this approach (and we cannot really reject it then). I really would like to avoid setting such a precedent here. > While we'd like to snap our fingers and have a "does everything > right" boot loader, that will take a while ;) I'm well aware of this. > Well, at least the use of i.MX plugins to do the job. The general > response was something along the lines of: > > **if** we want to support multiple CPU variants in > a single binary, then it should be done with SPL. This may or mayu not make sense. It certainly depends on the specific requirements of the SoC / architecture in question. > This patch set is the simplest implementation we can think > of that still allows a single board file and directory to > support multiple CPU options and memory configurations. I agree that supporting multiple SoCs indeed adds complexity. However, supporting different memory sizes has been supported by U-Boot (and actually already by PPCBoot) since day one, so this is not really considered rocket science. Also, SPL is not exactly new technology any more. > This step has broken things up into parts so that we > **can** express multiple memory configurations within > a single board directory, and I hope it moves the ball > forward a step or two. It does. But source base is one thing. Havnig to deal with a large number of configurations to build and test is another one, and here you put additional burdon on a large number of prople. > Our hope in getting this main-lined was that other upcoming > Solo and Dual-Lite platforms could share some of the bits. Understood and appreciated. But I also see this ias a strong reason to come up with a clean design, and not create bad examples which others without doubt will interpret as persuasive precedent. > I'm sorry if I sound frustrated. You don't, and if you did I could very well understand how you feel. I hope you can understand my position, too. > This is feedback I'd hoped to get to the RFC version back in January, Sorry I missed it then. > and it will be some time before we're in a position to add SPL into the mix. > > I'll wait for further feedback before determining if a V3 patch > is warranted. I would also apprciate if others could comment - Stefano? Albert? Tom? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I program, therefore I am. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
