[U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Dan Murphy <dmurphy@ti.com>]

Tom
On 06/06/2013 11:24 AM, Dan Murphy wrote:
> On 06/06/2013 11:20 AM, Tom Rini wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 06/06/2013 12:18 PM, Dan Murphy wrote:
>>> On 06/06/2013 10:31 AM, Tom Rini wrote:
>>>> On Wed, Jun 05, 2013 at 09:39:47AM -0500, Dan Murphy wrote:
>>>>> Update the EXTRA_ENV_SETTING for the dra7xx. The console needs 
>>>>> to be set to ttyO0 and the findfdt needs to be updated to load 
>>>>> the dra7xx-evm.dtb file.
>>>>>
>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>> Did you run-time test this?  I'm a little concerned about the 
>>>> include order, but that might turn out alright.  But I think:
>>> I compile and boot tested this on OMAP5.
>> OK, thanks.
>>
>>>>> +		"if test -z ${fdtfile}; then " \
>>>> Really needs to be: if test -z "${fdtfile}"; then...
>>>>
>>>> So that it doesn't become: if test -z; then when fdtfile isn't 
>>>> set and we get a parse error there.
>>>>
>>>> Thanks!
>>>>
>>> OK I will update again once I get other comments.  Although I am 
>>> not sure why we really need to protect someone putting the wrong 
>>> uBoot on their device unless we have a single uboot for all 
>>> devices.  I think we are being over protective here.
>> This is omap5_common.h tho.  You ran into the problem of findfdt ran,
>> didn't set an fdtfile, then we tried to bootz ${loadaddr} - ${fdtaddr}
>> which complained about not having a valid device tree.  This should
>> make it clearer on the next omap5_common.h using board where to fix
>> things so that their fdt is set right, automatically.
>>
>> - -- 
>> Tom
> OK sounds sane to me.

So this check does not work at all.  I could never get the -z to show that the arg was not defined.
Even if I defined fdtfile=\0 the variable indicates that is is still undefined.

And I cannot add in the "" because the compiler bonks thinking the macro line is completed.

So what I am going to do is pull this out of this patch completely because this has no impact on the intent of the patch.
I will then go ahead and fix the omap4_common, omap5_common and the am335 common in a separate patch.

Thoughts?

Dan

>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJRsLbgAAoJENk4IS6UOR1Wmj0P/jt1CPAtkqTImYnL1077CyC0
>> yR4sUcSodiSwR5TlXiEiOJveOYvYjVpcLvH4byH/0Yv9yVnVdoG4+j82QUV7I8zU
>> YjkuusbfGP5rQNlUcE0bWdUGalTUMrlTbnxMJ13q2dDIr4naqMPGLetO3wdpWYKJ
>> fdHBRz0phr1k2+OvbAoWEtsjxCj8XBv32yqRj+zZX3ErNcZWsBslRz7QUyDLQU1E
>> FGBRUAzb7tw0N0VbR+mwg9nuqu2/cBM5hprpsiZ6NfrtuLMP89ucIh61xsXf97K5
>> T4VFWKZhBHU2Fa2udLBHizJOLlW6NLwNpGD8ac7j9aVC2TKxdgHMtFeho6br/8sA
>> YkWvL5h/1E4i/qzO3MxuuAakTjhf0P4KU2U7UolH2A707sIKeII2L8ppSiT4cF6w
>> zB+uN9WgFDTZYYmTxXneD4fy/YWWooZtmCUvDS/7fOCvxGhJKehnwrO18LoCSrYZ
>> iIMpzB59dfWlYBg64zw6dbmQxgsYUUW7s7xpLi4m+8JnVdJCeArrRAq/9x69Dp18
>> OywMxiZuPNnDGC9XB5wAimyW3ygvXr4HG4WD4Uv/sw7Uhp6cxz04mzyAVlWeKeGO
>> 0aoUra34tutMQjyqtomqpA7EegwXG0UvAM2XEZi5o8DzeMVwnkZXMxwe/lPE4g8u
>> hJklyBClfW1nvEIsYgAV
>> =HAAX
>> -----END PGP SIGNATURE-----
>


-- 
------------------
Dan Murphy