-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRL6exAAoJENk4IS6UOR1WR60QAJ8UGeXt1xe/bAOYQkacmgSK g03ZEWFIRZiQIogcnR7hzk2eiIb2zqCPHRtpnEIumOVpaOMISN/DKKeI5XbyQIiA GOW8UgTnqQ0Inr6Uoo2gwRqsPS3G9qDVPd3ZeZXo1rU48h+j3jAH5feelcwmVaFx koef5+5GpQUsaah203w5g6PSDz/+r2unud5ZptK+Fzw4yQmBHgnOET99tlRtg/pQ v0pOKDDtwh+Y/xyhV56iZrchnGBIfL05w1O2Urb+SDFvwZLyNjO4bmh4ZuNH+v1c z2dxDWo+V57hfqKiqeQwT3Bz55WiUMGamMSW13xyK0vuNZz+m66PpF9tOdUUizlt lkn2U1O++KPi+POXWzu9ILD00U2m5K5fHhMmfVCP+hJuJu26ada5rFaufkYqDU0p ksxcPmvH+9gz4swc+fNGONQGNcGLde2x1nboLVYn8Gfh0Ckcc8Bhh6aJt4VOU0ID LLVay1vbq5uCe1MPX2uHkZ5ZZrgms5L8ZFwWcjG2K/BnbA7Rg4pri/SOICiH27P9 B8qKb8myhKrtup91wHnCeCKi7PSY69kZRpKevkrFirdq4rY5XDVBlSeCGlfvMk49 i5gi6vov1BclBRIgIh1+fUIN8R6Cg7Eo30j9ptitzM9R6V7sLTu3CMl+GvCTHWwN E44z2bb+9GJyB1M/+ZVL =SxUx -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot