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