[U-Boot] [PATCH 1/4] common: imx: Implement generic u-boot.nand target

[Tom Rini]

-----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-----