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. |
Changelog: Feature: Add
tricorecompiler architecture supportDocs: TODO
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.