[U-Boot] [PATCH] imx:mx6 fix return value of mxc_get_clock
mxc_get_clock's return type is unsigned int. 'return -1' is same with
'return 0x', so 0 should be used as the return value when
unsupported mxc_clock type is passed to mxc_get_clock.
Also include an err message when unsupported mxc_clock type is passed
to mxc_get_clock.
Signed-off-by: Peng Fan
---
arch/arm/cpu/armv7/mx6/clock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 80b11aa..99dba07 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -738,10 +738,11 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
case MXC_SATA_CLK:
return get_ahb_clk();
default:
+ printf("Unsupported MXC CLK: %d\n", clk);
break;
}
- return -1;
+ return 0;
}
/*
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot build issue
Dear Lalitkumar Choudhary, In message you wrote: > > As you have suggested to use eldk3.1 tool chain to compile > u-boot(1.1.2). We have installed eldk3.1 tool chain. > > However during installation we have given i686 as a command line I wonder why you did that. The documentation does not mention anything like that. Please make sure _NOT_ to use any ELDK v5.x related documentation; ELDK v5.x is totally different fromolder versions of the ELDK like the v3.1.1 you are using here. > argument to install script in that case it was throwing the message > All the targets must be ppc architecture. To proceed further we > have removed the command line argument related to host and run the > install script. Installation has started after that. During > installation we have observed an error message "failed to stat .gvfs > file" . This message can safely be ifnored. > Though toolchain get installed. But while compiling the code it gives > below error: > > (ppc-linux-gcc: cannot execute binary file) > > /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: > /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute > binary file Please read the documentation; the DULG (see for example [1]) shows you how to use the ELDK. The files in the /opt/eldk/ppc_6xx directory make up the root file system for the PowerPOC target; thi sis NOT the cross tool chain. [1] http://www.denx.de/wiki/view/DULG/ELDKUsage > It seems installed toolchain ppc-6xx, can compile the file only on > ppc architecture. But we want to compile the source on above > mentioned architecure(i686). Please suggest how we can proceed > further or where we went wrong. You are just using he wrong files. Please make sure to set your PATH an the other environment variables as documented. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] set and test a local variable in a script
Dear Andreas,
In message <5470d48c.1080...@gmx.at> you wrote:
>
> i'm trying to set a local variable and test the variable in an
> if-then-else script ...
> but it's somehow a bit weird!?
Not really weird; you just have to be a bit careful about quoting
rules...
> - set variable "nea" to 0
> - create a script "x" and run OK
> - modify variable "nea" to 1
> - run script "x" again ... NOK?!
>
> ... what i'm doing wrong - the behavior is the same with 2013.10 and
> 2014.01
...and it would be the same if you were testing with a regular shell on
the Linux command line.
Actually this is something I always recommend: if you see some strange
behaviour, first try to do the same in a standard shell environment,
and debug it there.
> >U-Boot# nea=0
> >U-Boot# setenv x "if itest 1 -eq $nea; then echo var1; else echo var0;
> fi;"
It would have been a good idea here todo a "printenv x" to check what
was actually stored in the variable - this would have shown your
problem. The thing is, you want to keep the '$nea' notation in the
variable, so you can evaluate the variable when you run that macro.
However, inside double quotes (") variable substitution takes place,
so above command is equivalent to
setenv x "if itest 1 -eq 0; then echo var1; else echo var0; fi;"
> >U-Boot# run x
> >var0
> >U-Boot# nea=1
> >U-Boot# run x
> >var0<- so now i should get the "var1" as a result
> >U-Boot# echo $nea
> >1
Use printenv to verify what is stored in the variable x, and you will
understand this.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Today is the yesterday you worried about tomorrow.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] set and test a local variable in a script
hi, i'm trying to set a local variable and test the variable in an if-then-else script ... but it's somehow a bit weird!? - set variable "nea" to 0 - create a script "x" and run OK - modify variable "nea" to 1 - run script "x" again ... NOK?! ... what i'm doing wrong - the behavior is the same with 2013.10 and 2014.01 >U-Boot# nea=0 >U-Boot# setenv x "if itest 1 -eq $nea; then echo var1; else echo var0; fi;" >U-Boot# run x >var0 >U-Boot# nea=1 >U-Boot# run x >var0<- so now i should get the "var1" as a result >U-Boot# echo $nea >1 >U-Boot# setenv x "if itest 1 -eq $nea; then echo var1; else echo var0; fi;" >U-Boot# run x >var1 <--- after i set the script "x" again it's working ... ?! br & thx for any hint, Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot build issue
Dear Sir, Thanks for quick response. As you have suggested to use eldk3.1 tool chain to compile u-boot(1.1.2). We have installed eldk3.1 tool chain. However during installation we have given i686 as a command line argument to install script in that case it was throwing the message “All the targets must be ppc architecture”. To proceed further we have removed the command line argument related to host and run the install script. Installation has started after that. During installation we have observed an error message "failed to stat .gvfs file" . Though toolchain get installed. But while compiling the code it gives below error: (ppc-linux-gcc: cannot execute binary file) /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute binary file make[1]: Entering directory `/svn/lalith/Cashel_Modular_SVN/bootloader/tools' make[1]: `.depend' is up to date. make[1]: Leaving directory `/svn/lalith/Cashel_Modular_SVN/bootloader/tools' /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute binary file /bin/sh: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin/ppc-linux-gcc: cannot execute binary file dirname: missing operand Try `dirname --help' for more information. /bin/sh: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin/ppc-linux-gcc: cannot execute binary file dirname: missing operand Try `dirname --help' for more information. make[1]: Entering directory `/svn/lalith/Cashel_Modular_SVN/bootloader/examples' make[1]: `.depend' is up to date. make[1]: Leaving directory `/svn/lalith/Cashel_Modular_SVN/bootloader/examples' /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute binary file make[1]: Entering directory `/svn/lalith/Cashel_Modular_SVN/bootloader/post' make[1]: `.depend' is up to date. make[1]: Leaving directory `/svn/lalith/Cashel_Modular_SVN/bootloader/post' /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute binary file make[1]: Entering directory `/svn/lalith/Cashel_Modular_SVN/bootloader/post/cpu' make[1]: `.depend' is up to date. make[1]: Leaving directory `/svn/lalith/Cashel_Modular_SVN/bootloader/post/cpu' make -C tools all /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute binary file make[1]: Entering directory `/svn/lalith/Cashel_Modular_SVN/bootloader/tools' gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -c -o img2srec.o img2srec.c gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -o img2srec img2srec.o strip img2srec gcc -g -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -c mkimage.c gcc -g -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -c crc32.c gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -o mkimage mkimage.o crc32.o strip mkimage gcc -g -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -c envcrc.c gcc -g -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -c environment.c gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -o envcrc envcrc.o crc32.o environment.o gcc -g -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -c gen_eth_addr.c gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -o gen_eth_addr gen_eth_addr.o strip gen_eth_addr gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -c -o bmp_logo.o bmp_logo.c gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0xfff0 -DUSE_HOSTCC -O -o bmp_logo bmp_logo.o strip bmp_logo ./bmp_logo logos/denx.bmp >/svn/lalith/Cashel_Modular_SVN/bootloader/include/bmp_logo.h make[1]: Leaving directory `/svn/lalith/Cashel_Modular_SVN/bootloader/tools' make -C examples all /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin//ppc-linux-gcc: cannot execute binary file /bin/sh: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin/ppc-linux-gcc: cannot execute binary file dirname: missing operand Try `dirname --help' for more information. /bin/sh: /opt/eldk_new_image_21Nov/ppc_6xx/usr/bin/ppc-linux-gcc: cannot execute binary file dirname: missing operand Try `dirname --help' for more informat Please find the below environment details, may be it will help you to understand the problem statement. Host machine architecture : 2.6.38.6-26.rc1.fc15.i686.PAE Build Machine architecture : 2.6.38.6-26.rc1.fc15.i686.PAE Target machine architecture : 2.6.10_mvl401-8272ads__Mode-INF__Patch_ver-1.15(powerpc). It seems installed toolchain ppc-6xx, can compile the file only on ppc architecture. But we wan
Re: [U-Boot] [PATCH 2/3] mxs_ocotp: check for errors from the OTP controller after writing
On Sat, Nov 22, 2014 at 5:29 PM, Fabio Estevam wrote:
> On Fri, Nov 21, 2014 at 4:04 PM, Hector Palacios
> wrote:
>
>>> What about doing this instead?
>>>
>>>/* Check for errors */
>>>ret = readl(&ocotp_regs->hw_ocotp_ctrl) & OCOTP_CTRL_ERROR);
>>>if (ret) {
>>>printfs("Failed writing the fuses: %d\n", ret);
>>>goto fail;
>>>}
>>>
>>
>> Although the code looks nicer you are not returning a meaningful error code,
>> just a
>> mask value (and yes, I know the error code does not get anywhere, but still).
>
> I am just returning the real error code, not a 'fake' one :-)
Actually your code is correct and I misread it. Sorry about that.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mxs_ocotp: check for errors from the OTP controller after writing
On Fri, Nov 21, 2014 at 2:54 PM, Hector Palacios wrote: > The write operation may fail when trying to write to a locked area. In > this case the ERROR bit is set in the CTRL register. Check for that > condition and return an error. > > Signed-off-by: Hector Palacios Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mxs_ocotp: check for errors from the OTP controller after writing
On Fri, Nov 21, 2014 at 4:04 PM, Hector Palacios
wrote:
>> What about doing this instead?
>>
>>/* Check for errors */
>>ret = readl(&ocotp_regs->hw_ocotp_ctrl) & OCOTP_CTRL_ERROR);
>>if (ret) {
>>printfs("Failed writing the fuses: %d\n", ret);
>>goto fail;
>>}
>>
>
> Although the code looks nicer you are not returning a meaningful error code,
> just a
> mask value (and yes, I know the error code does not get anywhere, but still).
I am just returning the real error code, not a 'fake' one :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning
Hello Lukasz, On Sat, 22 Nov 2014 07:56:35 +0100, Lukasz Majewski wrote: > > Agreed in general, but not for this one, since "fixing" is the > > carpet, > > I assume that you are presenting below an answer to a "general" case. > > However, as Thomas pointed out earlier, this "fix" is perfectly safe > regarding the underlying kwbimage code. Jeroen and I (full disclaimer: we have discussed the topic on IRC) do not contend that the proposed fix would be unsafe; it *is* safe, i.e. it does not adversely affect the code behavior in any measurable way. What we contend is that the fix be the /right/ fix (although Jeroen and I have slightly differing criteria for defining what "the right fix" would be). > > > and > > > the only justification I see as acceptable for doing so is when > > > leaving the warning enabled would cause an obnoxiously high number > > > of false positives. > > > > Well let me add, if "fixing the warning" causes real error > > to be hidden, we shouldn't "fix" the warnings by modifying > > valid code. > > Each subsequent "fix" for this kind of warning should be considered > case by case IMHO, therefore I agree with Albert. Jeroen also agreed on IRC that disabling the compiler warning is not the right fix either; and I agreed that there had to be a better fix than pseudo-initializing headersz. I therefore suggested refactoring kwbimage_set_header in order to ensure gcc does not emit the warning, but without resorting to non-functional code such as a functionally meaningless initialization. Problem is, to refactor the code, one needs a gcc which emits the warnig. I tried various versions of gcc (4.7.4, 4.8.3, 4.9.1) and all remained silent when compiling tools/kwbimage.c. Hence my request: Lukasz, which toolchain are you using exactly? Where can we download it from? > > Regards, > > Jeroen > > Best regards, > Lukasz Majewski Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning
Hi Jeroen > Hello Albert, > > On 21-11-14 16:30, Albert ARIBAUD wrote: > > On Fri, 21 Nov 2014 13:34:41 +0100, Jeroen Hofstee > > wrote: > > > But oh well, if it fixes a warning :-) > >>> I didn't claim that there is a bug in the code :-). > >>> > >>> I just get annoying when on my continuous integration script I > >>> see the same warning for all cross compiled boards. > >> Wouldn't it be better to simply disable the -Wmaybe-uninitialized > >> for gcc? > > Disabling a warning is hiding potential dust under the carpet IMO > > Agreed in general, but not for this one, since "fixing" is the > carpet, I assume that you are presenting below an answer to a "general" case. However, as Thomas pointed out earlier, this "fix" is perfectly safe regarding the underlying kwbimage code. > as far a I can tell. This is roughly the case which causes > the warning e.g. (and variant like this with a switch, etc): > > -- > char *a; > > if (something) > a = something_valid > > [...] > > if (something) > *a = 1; > -- > > Some gcc versions start complaining about the second instance, > that it _might_ be used uninitialized. > > With the "fix" this will no longer warn: > > -- > char *a = 0; /* not valid, just set to stop gcc from complaining */ > > *a = 1; // paved away _error_, to suppress an invalid warning.. > > if (something) > a = something_valid > > > > if (something) > *a = 1; > -- > > Since 0 is a perfectly valid address in u-boot it should emit > no warning whatsoever, just crash at runtime. I got your point. > > > and > > the only justification I see as acceptable for doing so is when > > leaving the warning enabled would cause an obnoxiously high number > > of false positives. > > Well let me add, if "fixing the warning" causes real error > to be hidden, we shouldn't "fix" the warnings by modifying > valid code. Each subsequent "fix" for this kind of warning should be considered case by case IMHO, therefore I agree with Albert. > > Regards, > Jeroen Best regards, Lukasz Majewski signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
