All,
I need to supply a Linaro toolchain "aligned" (same source code) bare-metal compiler to a group doing benchmarking on A15.
First off my assumption is that we will write our own boot and semi hosting code. (semi-hosting for TI emulators/simulators is different than ARM RDI semi-hosting.)
I was planning on looking at the two toolchains here[1] and here [2]: [1] https://launchpad.net/linaro-toolchain-binaries [2] https://launchpad.net/gcc-arm-embedded
I was then going to build a hybrid that was newlib based but appropriate for armv7-a (instead of cortext-m3) and maybe even -mtune'ed for A15.
However looking at the gcc-arm-embedded release more[3] I see that it supports ARMv7-R. It supports both thumb and non-thumb modes, both softfp and hardfp ABIs.
What would I really gain by building my own? For app code the user should be able to add -mtune=cortex-a15 and still be compatible with the pre-built R4/R5 libraries. The only performance difference should be in the library code and that should be only pipeline tuning if I understand the difference between armv7-a and armv7-r correctly.
Am I missing something? Should I build my hybrid anyway?
[1] https://launchpadlibrarian.net/88152755/readme.txt
[BTW: has the below project been obsoleted by the gcc-arm-embedded one? Perhaps gcc-arm-embedded should be referenced in the description of the page below. https://launchpad.net/linaro-toolchain-unsupported ]
Thanks, Bill
Can someone point me to bare metal example using GNU toolchain.
Regds Rks
On Mar 8, 2012, at 10:51 AM, "William Mills" wmills@ti.com wrote:
All,
I need to supply a Linaro toolchain "aligned" (same source code) bare-metal compiler to a group doing benchmarking on A15.
First off my assumption is that we will write our own boot and semi hosting code. (semi-hosting for TI emulators/simulators is different than ARM RDI semi-hosting.)
I was planning on looking at the two toolchains here[1] and here [2]: [1] https://launchpad.net/linaro-toolchain-binaries [2] https://launchpad.net/gcc-arm-embedded
I was then going to build a hybrid that was newlib based but appropriate for armv7-a (instead of cortext-m3) and maybe even -mtune'ed for A15.
However looking at the gcc-arm-embedded release more[3] I see that it supports ARMv7-R. It supports both thumb and non-thumb modes, both softfp and hardfp ABIs.
What would I really gain by building my own? For app code the user should be able to add -mtune=cortex-a15 and still be compatible with the pre-built R4/R5 libraries. The only performance difference should be in the library code and that should be only pipeline tuning if I understand the difference between armv7-a and armv7-r correctly.
Am I missing something? Should I build my hybrid anyway?
[1] https://launchpadlibrarian.net/88152755/readme.txt
[BTW: has the below project been obsoleted by the gcc-arm-embedded one? Perhaps gcc-arm-embedded should be referenced in the description of the page below. https://launchpad.net/linaro-toolchain-unsupported ]
Thanks, Bill
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
+++ Singh, Ravi Kumar (Ravi) [2012-03-08 22:28 +0530]:
Can someone point me to bare metal example using GNU toolchain.
Hector Oron has played with this:
here is a makefile for building some simple code either with bare-metal compiler of linux/libc compiler (in practice the latter worked as well or better so the actual need for a bare-metal compiler seems to me to be unclear in most cases): http://git.emdebian.org/?p=upstream/cortex-examples.git%3Ba=blob%3Bf=05_blin...
and here is a makefile for building bare-metal (from upstreams, not in debian packaging form):
http://balloonboard.org/trac/browser/balloon/branches/menuconfig2/package/to...
I'm not quite sure which of those (if either) you were looking for an example of?
Wookey
On 03/08/2012 12:16 PM, Wookey wrote:
+++ Singh, Ravi Kumar (Ravi) [2012-03-08 22:28 +0530]:
Can someone point me to bare metal example using GNU toolchain.
Hector Oron has played with this:
here is a makefile for building some simple code either with bare-metal compilerof linux/libc compiler
[snip, reorder]
http://git.emdebian.org/?p=upstream/cortex-examples.git%3Ba=blob%3Bf=05_blin...
Yes, that looks like a good resource. Might be a bit HW specific for some but still useful.
(in practice the latter worked as well or better so the actual need for a bare-metal compiler seems to me to be unclear in most cases):
I suspect you actually know the answer to that Wookey and your comment is more of a value choice. However for any other readers out there ...
Yes, you can certainly target non Linux user space ABI environments with a Linux user space ABI compiler. The kernel itself is a great example of this. However, the kernel includes its own copies of the libgcc equivalent functions, its own implementation of memcpy, and its own printf equivalent in printk.
The value of a bare metal compiler is it makes all this easier. You can divide a 64 bit integer, call memcpy, and get most of a printf implementation. If some one supplies some board specific boot code, a few low level i/o functions, and a link template, it lets multiple people create simple main() applications like this one: http://git.emdebian.org/?p=upstream/cortex-examples.git%3Ba=blob%3Bf=08_sym/...
compared to the typical no library program which usually looks like: http://git.emdebian.org/?p=upstream/cortex-examples.git%3Ba=tree%3Bf=05_blin...
[BTW: I don't think blinky's use of cs3.h is legally correct.]
Bill
On Fri, Mar 9, 2012 at 5:51 AM, William Mills wmills@ti.com wrote:
All,
I need to supply a Linaro toolchain "aligned" (same source code) bare-metal compiler to a group doing benchmarking on A15.
First off my assumption is that we will write our own boot and semi hosting code. (semi-hosting for TI emulators/simulators is different than ARM RDI semi-hosting.)
I was planning on looking at the two toolchains here[1] and here [2]: [1] https://launchpad.net/linaro-toolchain-binaries [2] https://launchpad.net/gcc-arm-embedded
I was then going to build a hybrid that was newlib based but appropriate for armv7-a (instead of cortext-m3) and maybe even -mtune'ed for A15.
However looking at the gcc-arm-embedded release more[3] I see that it supports ARMv7-R. It supports both thumb and non-thumb modes, both softfp and hardfp ABIs.
What would I really gain by building my own? For app code the user should be able to add -mtune=cortex-a15 and still be compatible with the pre-built R4/R5 libraries. The only performance difference should be in the library code and that should be only pipeline tuning if I understand the difference between armv7-a and armv7-r correctly.
Am I missing something? Should I build my hybrid anyway?
[1] https://launchpadlibrarian.net/88152755/readme.txt
[BTW: has the below project been obsoleted by the gcc-arm-embedded one? Perhaps gcc-arm-embedded should be referenced in the description of the page below. https://launchpad.net/linaro-toolchain-unsupported ]
Hi William. I recommend using the exact same tools we use for building the binary toolchains but reconfiguring for a baremetal build. That way you can get the Cortex-A15 improvements that we've been doing in a simple to make binary toolchain.
I wrote some brief instructions on this yesterday at: https://wiki.linaro.org/WorkingGroups/ToolChain/BinaryBuild
Also see the building from source section in the README: https://launchpadlibrarian.net/93804205/README.txt
The extra steps are to tune for the Cortex-A15 by default and use a baremetal instead of prebuilt sysroot.
gcc-arm-embedded is from our friends at ARM's Cortex-R&M group. We share the same requirements and build tools but have a different focus - they're a long term supported build of FSF 4.6 for the Cortex-R&M while we're the latest performance on Cortex-A.
The linaro-toolchain-unsupported builds are the Linaro toolchain in a baremetal Cortex-M configuration. I've been doing these on my own time as I have a personal STM32 project I'm working on.
Hope that helps,
-- Michael
On 03/08/2012 03:51 PM, Michael Hope wrote:
On Fri, Mar 9, 2012 at 5:51 AM, William Millswmills@ti.com wrote:
All,
I need to supply a Linaro toolchain "aligned" (same source code) bare-metal compiler to a group doing benchmarking on A15.
Hi William. I recommend using the exact same tools we use for building the binary toolchains but reconfiguring for a baremetal build. That way you can get the Cortex-A15 improvements that we've been doing in a simple to make binary toolchain.
I wrote some brief instructions on this yesterday at: https://wiki.linaro.org/WorkingGroups/ToolChain/BinaryBuild
Also see the building from source section in the README: https://launchpadlibrarian.net/93804205/README.txt
Thanks for the recommendation Michael. I will do it this way.
The extra steps are to tune for the Cortex-A15 by default and use a baremetal instead of prebuilt sysroot.
gcc-arm-embedded is from our friends at ARM's Cortex-R&M group. We share the same requirements and build tools but have a different focus
- they're a long term supported build of FSF 4.6 for the Cortex-R&M
while we're the latest performance on Cortex-A.
Ahh. I did not realize this was a different source base.
The linaro-toolchain-unsupported builds are the Linaro toolchain in a baremetal Cortex-M configuration. I've been doing these on my own time as I have a personal STM32 project I'm working on.
Yes, now I understand the difference.
Hope that helps,
-- Michael
Yes, Thanks, -- Bill
On 03/08/2012 04:07 PM, William Mills wrote:
On 03/08/2012 03:51 PM, Michael Hope wrote:
On Fri, Mar 9, 2012 at 5:51 AM, William Millswmills@ti.com wrote:
All,
I need to supply a Linaro toolchain "aligned" (same source code) bare-metal compiler to a group doing benchmarking on A15.
Hi William. I recommend using the exact same tools we use for building the binary toolchains but reconfiguring for a baremetal build. That way you can get the Cortex-A15 improvements that we've been doing in a simple to make binary toolchain.
I wrote some brief instructions on this yesterday at: https://wiki.linaro.org/WorkingGroups/ToolChain/BinaryBuild
Also see the building from source section in the README: https://launchpadlibrarian.net/93804205/README.txt
Thanks for the recommendation Michael. I will do it this way.
As a first step I tried to rebuild the same linaro-arm-linux-gnueabi version you guys publish following a flow similar to the wiki page you show above. I used the 2012.02 tarballs from the https://launchpad.net/linaro-toolchain-binaries for src and crosstool-NG.
I followed the host setup instructions in the README.txt but then followed the wiki build instructions using a config of "linaro-arm-linux-gnueabi"
My machine is Ubuntu 10.04 32 bit as suggested in README.txt and /bin/sh is bash.
The build errored out in PPL with some errors deep in the c++ STL templates of the lsbcc.
I next cleaned and reran you config again but then ran ct-ng menuconfig to deselect using the lsbcc compiler and just use the host gcc. The build finished OK this way.
Do you guys still use 10.04 32 bit as the reference OS or have you moved on?
The extra steps are to tune for the Cortex-A15 by default and use a baremetal instead of prebuilt sysroot.
I have not tried adjusting the target config yet.
On 10 March 2012 10:49, William Mills wmills@ti.com wrote:
On 03/08/2012 04:07 PM, William Mills wrote:
On 03/08/2012 03:51 PM, Michael Hope wrote:
On Fri, Mar 9, 2012 at 5:51 AM, William Millswmills@ti.com wrote:
All,
I need to supply a Linaro toolchain "aligned" (same source code) bare-metal compiler to a group doing benchmarking on A15.
Hi William. I recommend using the exact same tools we use for building the binary toolchains but reconfiguring for a baremetal build. That way you can get the Cortex-A15 improvements that we've been doing in a simple to make binary toolchain.
I wrote some brief instructions on this yesterday at: https://wiki.linaro.org/WorkingGroups/ToolChain/BinaryBuild
Also see the building from source section in the README: https://launchpadlibrarian.net/93804205/README.txt
Thanks for the recommendation Michael. I will do it this way.
As a first step I tried to rebuild the same linaro-arm-linux-gnueabi version you guys publish following a flow similar to the wiki page you show above. I used the 2012.02 tarballs from the https://launchpad.net/linaro-toolchain-binaries for src and crosstool-NG.
I followed the host setup instructions in the README.txt but then followed the wiki build instructions using a config of "linaro-arm-linux-gnueabi"
My machine is Ubuntu 10.04 32 bit as suggested in README.txt and /bin/sh is bash.
The build errored out in PPL with some errors deep in the c++ STL templates of the lsbcc.
I next cleaned and reran you config again but then ran ct-ng menuconfig to deselect using the lsbcc compiler and just use the host gcc. The build finished OK this way.
Do you guys still use 10.04 32 bit as the reference OS or have you moved on?
Yip, it's all as documented. We use a EC2 cloud instance to build.
The problem is we need to patch the LSB headers and tools to wrok around some issues in the other tools configurery. The result is still LSB compatible. contrib/linaro/build.mk does this automatically by calling contrib/linaro/lsb/make-lsb.sh and then putting the result in the path.
Short story: what you did is right.
-- Michael
On 03/11/2012 03:52 PM, Michael Hope wrote:
On 10 March 2012 10:49, William Millswmills@ti.com wrote:
Do you guys still use 10.04 32 bit as the reference OS or have you moved on?
Yip, it's all as documented. We use a EC2 cloud instance to build.
The problem is we need to patch the LSB headers and tools to wrok around some issues in the other tools configurery. The result is still LSB compatible. contrib/linaro/build.mk does this automatically by calling contrib/linaro/lsb/make-lsb.sh and then putting the result in the path.
Short story: what you did is right.
Thanks Michael. I see now. I have verified that I can build with LSB if I use the make -f contrib/linaro/build.mk procedure. This will be important to me as the user base for my work is mostly on RHEL4 or SUSE 10.
Now on to the actual task ...
-- Bill
On 13 March 2012 12:00, William Mills wmills@ti.com wrote:
On 03/11/2012 03:52 PM, Michael Hope wrote:
On 10 March 2012 10:49, William Millswmills@ti.com wrote:
Do you guys still use 10.04 32 bit as the reference OS or have you moved on?
Yip, it's all as documented. We use a EC2 cloud instance to build.
The problem is we need to patch the LSB headers and tools to wrok around some issues in the other tools configurery. The result is still LSB compatible. contrib/linaro/build.mk does this automatically by calling contrib/linaro/lsb/make-lsb.sh and then putting the result in the path.
Short story: what you did is right.
Thanks Michael. I see now. I have verified that I can build with LSB if I use the make -f contrib/linaro/build.mk procedure. This will be important to me as the user base for my work is mostly on RHEL4 or SUSE 10.
Good to hear. RHEL 4 is getting back there - it went EOL on the 29th of February.
I've made a couple of changes for next time. The samples don't use the LSB compilers and should work out of the box. The README includes a note about the patched LSB and how to recreate it.
-- Michael
linaro-toolchain@lists.linaro.org
-
Michael Hope -
Singh, Ravi Kumar (Ravi) -
William Mills -
Wookey