From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Mon, 11 Mar 2013 12:15:30 +0100 Subject: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards In-Reply-To: <513D18F3.2010802@boundarydevices.com> References: <1362873856-14785-1-git-send-email-eric.nelson@boundarydevices.com> <20130310075948.035BA200642@gemini.denx.de> <513CA21E.1040608@boundarydevices.com> <20130310154511.C066D2010CD@gemini.denx.de> <513CB3F2.6080604@boundarydevices.com> <20130310220352.ED5432010CD@gemini.denx.de> <513D18F3.2010802@boundarydevices.com> Message-ID: <20130311111530.B709220013A@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Eric, In message <513D18F3.2010802@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: wd at denx.de I program, therefore I am.