Add Tricore options to arch list #16317
Conversation
|
|
|
Thanks for your contribution @photex You are right, adding the settings is the first thing. But I also think that it would be good to have at least a check that it works for at least the basic CMake integration:
|
|
Is there another common library used for testing baremetal toolchains? I haven't tried zlib yet, but Aurix (tricore) is an embedded platform and I don't know if zlib is expected to work there. I'll give it a shot regardless. |
Not really, actually zlib is kind of an ubiquitous library that is likely to be buildable in most of the platforms, and not affected much by architectures or other platform specifics, this is why it is a good candidate for testing things. |
|
Alrighty, I'm able to build zlib using one of the tricore archs: Profile used: Command line used: Output: |
|
That looks good. If this works out of the box with the current CMake integration, it would be good enough to be merged in the default settings, and probably add some pointers or minimal guide in the docs. |
I was just wondering about that. I'll see what I can dig up! |
|
Ok, this was the best idea I had at the moment: |
Not bad, but not enough detail about the architecture in particular apparently. Of course running some executable in the actual HW would validate things, are you planning some kind of a full "hello world" full proof of concept involving the real HW? |
|
That's a good idea. I bet I could adapt the blinky example from https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Blinky_LED_1_KIT_TC397_TFT Qemu might be an option, it has some early tricore support. |
|
Ok, a hello world project will definitely take me some time that I don't have (for the moment, due to other work priorities). In the meantime though I did realize that I can use tricore-elf-readelf: I've also built my firmware using my branch and updated profiles to include the arch. And I still have to be sure and wiggle the Which makes me wonder whether other arch settings would work the same? For example: armv7hf, is there logic elsewhere in the Conan CMake tools that handle setting the relevant target flags for the toolchain? Or is it expected to be handled by profiles or developers every time? |
|
Now I see: |
|
Oh no... I closed on accident. 😬 |
|
Don't worry, PRs can be re-opened, done :)
This is exactly what I was thinking of. Sometimes it is not enough to define the architecture, but some flags or something must be added to the build system integrations, typically in the toolchains (CMakeToolchain, AutotoolsToolchain, MesonToolchain,...), and some of these toolchains might use conan/tools/build/flags.py, for some common functionality so adding it there might help, but this is something to check in different build systems. At the moment given the nature of the compiler, I would focus on autotools and CMake, the others can wait for a second iteration. |
|
I've pushed the little package I'm using to test with: https://github.com/photex/conan-tricore-test I've included a It's placed in this separate repo currently because I'm not yet certain how to integrate with the Conan testsuite properly (given that there isn't a toolchain for the arch on conancenter yet). I have updated the flags, and the cmake toolchain generator. In the generated conan_toolchain files I see the correct values for the system: set(CMAKE_SYSTEM_NAME Generic-ELF)
set(CMAKE_SYSTEM_PROCESSOR tricore)And the arch flags are generated correctly as well. For example: string(APPEND CONAN_CXX_FLAGS " -mtc131")
string(APPEND CONAN_C_FLAGS " -mtc131")
string(APPEND CONAN_SHARED_LINKER_FLAGS " -mtc131")
string(APPEND CONAN_EXE_LINKER_FLAGS " -mtc131") |
- Added arch target flags to conan/tools/build/flags.py - Updated cmake/toolchain/blocks.py to reflect the expected system name and processor
photex
force-pushed
the
dev/chip/tricore-arch
branch
from
a47a58a to
a36536d
Compare
There was a problem hiding this comment.
This is looking good, I think it will be possible to merge it as it is low risk.
It would be good to add a couple of "unittest" tests:
- One for CMakeToolchain in https://github.com/conan-io/conan/blob/develop2/test/unittests/tools/cmake/test_cmaketoolchain.py
- Another for AutotoolsToolchain: https://github.com/conan-io/conan/blob/develop2/test/unittests/tools/gnu/autotoolschain_test.py
If you need help with the tests, just let me know, I can contribute those tests too.
|
Thank you @memsharded I'll get those started asap. |
|
There were some conflict with recent CMakeToolchain changes, I have tried to fix it. Also updated the first comment to include the Changelog line and reference the issue. |
|
Just checking in real quick: work picked up but I'm still intending to add these unit tests once things cool down. |
Don't worry, no hurries, just let me know when you can do it and we'll have a look and try to help to get this merged. |
|
Just had to jog my memory, the current profiles in my test repo don't use those lines: https://github.com/photex/conan-tricore-test I think I removed those when I switched to Generic-ELF. |
|
Output from conan new: Output of conan create: Did you need these with my tc16* profiles? |
Yes, please, sorry I wasn't explicit about this, with your tricore profiles, thanks! 🙂 |
|
Ok, this uses the following build profile: [settings]
os=baremetal
arch=tc162
compiler=gcc
compiler.version=11
compiler.cppstd=20
compiler.libcxx=libstdc++11
[conf]
tools.build:compiler_executables={"c":"tricore-elf-gcc","cpp":"tricore-elf-g++"}
tools.cmake.cmake_layout:build_folder=build/tc162
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
# I have to do this, otherwise zlib tries to use fPIC which isn't supported by tricore.
[options]
*:shared=False
*:fPIC=False |
|
I have one concern in the output logs:
It seems the right flag is not being defined?
And see what it has as flags there? |
|
It seems the reason is that you swapped the profiles, the Use instead: |
|
Hrm yeah, in my script in the test repo I'm using -pr:h... and I did switch it here because it was trying to build and link the tests, which won't work without a linker script to setup the exception tables and stuff... |
|
Here we go, this looks better (test still won't link as is however): |
|
Generated toolchain looks correct now too: ########## 'arch_flags' block #############
# Define C++ flags, C flags and linker flags from 'settings.arch'
message(STATUS "Conan toolchain: Defining architecture flag: -mtc162")
string(APPEND CONAN_CXX_FLAGS " -mtc162")
string(APPEND CONAN_C_FLAGS " -mtc162")
string(APPEND CONAN_SHARED_LINKER_FLAGS " -mtc162")
string(APPEND CONAN_EXE_LINKER_FLAGS " -mtc162") |
|
Thanks for the feedback!
But why? What is it missing for this to link correctly? I think we should be able to correctly build the executable .elf with those commands and the right profile. |
|
The test wants to enable exceptions, but you'd have to provide a linker script to set that up if I'm understanding this correctly. Maybe disabling exceptions would be ok? |
|
Relevant section of my firmwares linker script: |
I think we should have kind of "default" setup that is relatively straightforward and can build such library packages and consume them to form an executable, in a kind of "built-in" way. Having to manually provide a linker script seems a bit too manual. Is this linker script something quite standard that Conan should/could provide?
Is disabling exceptions kind of "default" or at least the "most popular" approach when building tricore libraries and executables? If that is the case, maybe yes, we could disable exceptions. Ideally the "onboarding experience" of using tricore compiler should be as straightforward as possible, this is why I was focusing on the |
|
The linker script is specific to your target board and tricore chip. We could provide a default using one of the devkit scripts that are openly available possibly. NM: that's a script for the Tasking compiler not GCC. But I think there are some for tricore-gcc available. |
|
Sorry, I misread the question. No you wouldn't provide a linker script to compile a library. This only applies to the test executable. |
Yes, but I think the default functionality should probably also allow to link executables, that is, if I did a: should I be able to do a I don't know about the tricore ecosystem, but I would expect that somehow the toolchain can be kind of automatically defined in someway. What would be the way to inject/define those linker scripts in the build, so the applications also link? |
|
Tricore-gcc certainly doesn’t have a default linker script in the sources I built from. For the commercial versions (Hitec) perhaps but I still doubt it. The pattern of use is largely that they provide an eclipse spin that will stamp out a linker script for your targets and generate makefiles etc. Once you leave that you’re on your own. But this is more or less the same for Armv7 isn’t it? I’ve had to provide a linker script for my SK344 chips (or one was provided by zephyr or nuttx for a common devkit). In any case, I could specify the linker script in the profile right? It’s gcc so -Tfoo.ld is all I’m doing but I set it up with cmake at the moment. |
|
One catch is that the test target would have to define some conventional entry points for tricore. Normally Core0_Main, Core1_Main, … CoreN_Main. I number of things tend to be setup using Infineons iLLD library so I’m still not sure you can link an elf for tricore without some extra steps. |
I think this is a good hint: you are doing it in your CMakeLists.txt, but obviously the default
Yes, that is fine, there can be extra steps or things to do. I am just trying to learn what are those, and how they could be defined in Conan mechanisms, for the documentation. |
|
We are closing the 2.7.0 release now, I will merge this anyway because it is good even if I don't know those details yet, and we can complete the documentation later if necessary. |
|
Thank you for all the help with this. I have the test repo, and I am happy to modify this to have the linker script defined by the profile. In fact, my goal is to leverage conan for as much as we can for our firmware build. The iLLD library is release under the Boost Software License, so my hope is to actually provide packages for some devkits (I have a couple to test with). They release several variations for specific chips. Same for the tricore-gcc toolchain which is GPL. Currently we've built this by hand and created a basic internal conan package to provide it, but it would be great to make that a proper package. |
Sounds good.
Sounds good, we might have a place that could be good to share toolchain and other special recipes that might not be great for ConanCenter, please open a new ticket if you would like to share some of this later down the road, and we will guide you. Many thanks! |
I would be happy to help with the docs.
That's great. My first step will be to convert our internal package to properly package the toolchain. I need to refer to some other toolchain packages for this I think. Currently I just scoop up the binaries I have built and copy them. |
|
I have added PR to the docs in conan-io/docs#3819 with some very basic and introductory example, leaving the cmake_exe case for later. If you could please review it and see if it is correct, for the 2.7 release, feel free to fix, suggest or complete whatever you feel. Thanks! |
Changelog: Feature: Add
tricorecompiler architecture support.Docs: conan-io/docs#3819
Docs: conan-io/docs#3851
Close #16318
Hello! I'd like to start the process here in adding support (whatever that might mean) for tricore-gcc. Currently I'm not able to use the settings.arch to specify the actual arch I'm using, and I assume this probably goes a bit deeper than just updating the yaml file.
For the most part I'm building my firmware by hook and by crook without this support. But It would be nice to learn how to do things properly.
Unlike some other proprietary toolchains that target Aurix devices, tricore-gcc can be built yourself: https://github.com/EEESlab/tricore-gcc-toolchain-11.3.0
I already have a Conan package for this which I'm using, but it's held together with duct-tape and wishful thinking still.
Changelog: Feature: Describe here your pull request
Docs: https://github.com/conan-io/docs/pull/XXXX
developbranch, documenting this one.