-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/28/2013 01:50 PM, Marek Vasut wrote:
Dear Tom Rini,
On Tue, Feb 26, 2013 at 12:33:52PM +0100, Beno??t Th??baudeau wrote:
On Tuesday, February 26, 2013 8:19:42 AM, Marek Vasut wrote:
Dear Beno??t Th??baudeau,
Dear Scott Wood,
On Tuesday, February 26, 2013 12:07:25 AM, Scott Wood wrote:
On 02/25/2013 05:03:30 PM, Marek Vasut wrote: > Dear Scott Wood, > >> So maybe we need a more general (but optional) >> CONFIG_BUILD_TARGET. > > Can you elaborate?
Same as CONFIG_SPL_TARGET, but not SPL-specific. Basically a way for a board config file to add to $(ALL-y).
>> So each one would set the appropriate >> CONFIG_BUILD_TARGET for > > whatever > >> needs to get built, and then something like >> CONFIG_NAND_IMAGE could hold the image name that >> should be linked to produce a standard >> u-boot-nand.bin output. > > Yea, sounds reasonable. But why call it CONFIG_ , it > can't be stored in the board.h files, it has to be > somewhere in the Makefile hierarchy.
Why can't it go in the board.h files?
We could do all that, but should we? As I said to Marek, I think that it's a big mistake to omit the SPL here. The only other solution to get a reliable boot would be the DBBT, but it's very hard to use in real life, away from a production line. The SPL is really easy to enable here, and it's only a matter of time before someone gets bitten by this lack of reliability, so why not just do things right? The boot time and footprint of an SPL would really be negligible, and it's not because other implementations omit both SPL and a valid DBBT that U-Boot should do the same.
I'm not against SPL, but then we're starting to drift away from the whole idea of generating u-boot-nand.bin or similar image. Being able to generate u-boot- nand.bin or u-boot-sd.bin etc ... on a per-CPU basis (since this is CPU specific) is the ultimate goal here, whatever is embedded in the image.
OK, I didn't know that this was your goal here. If the contents of the image do not matter, then my u-boot-with-nand-spl.imx could be renamed into your u-boot-nand.bin with the appropriate FCB header, and CONFIG_SPL_TARGET could be changed to something more generic as Scott explained.
I wonder how the rules start looking. In the end, some way to say "Here is the image to write to NAND, called u-boot-nand.bin" which will have whatever board needs (say spl/u-boot-spl.bin + some header attached followed by pad, followed by u-boot.img). And also allow for u-boot-nand.bin to be what someone else needs (say a different header on u-boot-spl.bin), etc.
They'd be CPU specific rules, so that depends on the CPU really.
Yes, they'd have to have a level of granularity (and cross-sharability) to them. Which is why I wonder how it would all look, since it needs to look on the clean side. I'm expressing a desire to use these rules on non-Freescale parts right away, so long as the infrastructure is done right.
- -- Tom