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.
Best regards, Marek Vasut