Re: Support for ARMV5te
Hi, Linaro is NOT an alternative to the Yocto project; we are collaborating with them. For instance, there are recipes to build a Yocto distribution using Linaro packages (e.g. the toolchain). Regarding the support of armv5te, if you build your toolchain from the sources we provide, the support is included. It's also present in the binary toolchains we provide, but these ones default to generating code for armv7-a processors: you'll have to force -march=XXX or -mcpu=YYY on your command line. Christophe. On 28 June 2013 08:13, Ratheendran R wrote: > Hi All, > > I am new to linaro. so would like to know more about linaro. > > Is linero alternative to yocto project. > > does the tool chain support armv5te based SOC. > > Ratheendran > > > ___ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Support for ARMV5te
On Wed, 17 Jul 2013 16:52:49 +0200
Christophe Lyon wrote:
> Hi,
>
> Linaro is NOT an alternative to the Yocto project; we are
> collaborating with them. For instance, there are recipes to build a
> Yocto distribution using Linaro packages (e.g. the toolchain).
>
> Regarding the support of armv5te, if you build your toolchain from the
> sources we provide, the support is included.
> It's also present in the binary toolchains we provide, but these ones
> default to generating code for armv7-a processors: you'll have to
> force -march=XXX or -mcpu=YYY on your command line.
Are you sure about this? You can try to:
$ echo "int main(int argc,char *argv[]) {return 0xBADF00D/argc;}" >test.c
$ arm-linux-gnueabihf-gcc -march=armv5te -marm test.c
$ arm-linux-gnueabihf-objdump -d a.out
And then have a look at the nice __aeabi_idiv implementation which gets
linked in:
8408 <__aeabi_idiv>:
8408: 2900cmp r1, #0
840a: f000 813e beq.w 868a <.divsi3_skip_div0_test+0x27c>
840e <.divsi3_skip_div0_test>:
840e: ea80 0c01 eor.w ip, r0, r1
8412: bf48it mi
8414: 4249negmi r1, r1
8416: 1e4asubsr2, r1, #1
8418: f000 811f beq.w 865a <.divsi3_skip_div0_test+0x24c>
841c: 0003movsr3, r0
841e: bf48it mi
8420: 4243negmi r3, r0
8422: 428bcmp r3, r1
8424: f240 811e bls.w 8664 <.divsi3_skip_div0_test+0x256>
8428: 4211tst r1, r2
842a: f000 8123 beq.w 8674 <.divsi3_skip_div0_test+0x266>
842e: fab3 f283 clz r2, r3
8432: fab1 f081 clz r0, r1
8436: eba0 0202 sub.w r2, r0, r2
843a: f1c2 021f rsb r2, r2, #31
...
Or maybe you have some plans to eventually provide multiple libgcc
variants with the same binary toolchain, so that it can select the
right one based on -march/-mcpu options?
--
Best regards,
Siarhei Siamashka
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Overheating Pandas
Folks, I had my final round of tests and I can say that there is no final conclusion on why they fail, but they do failed under every scenario I could try them on. I've tested 3 identical boards (Panda-ES RevB2) with 5 different power supplies. Even at 920MHz, with decent power supplies (high-quality 5V/4A, the ones used in the lab) they fail at 70% of their target temperatures, at least since the last measurement (<1min before failing). So, unless they overheat in less than a minute, for no apparent reason, and get hot enough to make the plastic case be a nuisance to heat transfer, they're not really failing because of heat. Power supplies also very cool, so I doubt they're at fault. There isn't absolutely anything on the logs, no kernel panic, no error message, nothing. Since there is no indication that lowering the frequency to 700MHz will make any difference (heat issue was indeed very likely a red herring), I'm basically giving up on the Pandas. They were either not meant to run for long times at full capacity, or our kernel (Linaro 3.5.0-213-omap4) is not up to the task (which is worrying). But since I'm not a kernel engineer, there isn't much I can do from where I stand. If anyone want to continue the investigation, on a kernel level, I can help set up the boards, but now I need to re-focus on more pressing issues. cheers, --renato ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
