Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp32: improve toolchain management #38540

Merged

Conversation

sylvioalves
Copy link
Collaborator

No description provided.

@github-actions
Copy link

github-actions bot commented Sep 14, 2021

The following west manifest projects have been modified in this Pull Request:

Name Old Revision New Revision Diff
hal_espressif zephyrproject-rtos/hal_espressif@0d30edf zephyrproject-rtos/hal_espressif@6cb3748 zephyrproject-rtos/hal_espressif@0d30edf0..6cb37487

Note: This message is automatically posted and updated by the Manifest GitHub Action.

@sylvioalves sylvioalves force-pushed the feature/improve_toolchain_path branch from e861c60 to 5ff9b24 Compare September 14, 2021 17:59
@sylvioalves
Copy link
Collaborator Author

Rebased to fix conflict. PR ready for review.

@sylvioalves sylvioalves requested a review from cfriedt September 14, 2021 18:00
@cfriedt
Copy link
Member

cfriedt commented Sep 18, 2021

@sylvioalves - I'm ok with this going in as there are no code changes and it is mainly toolchain-related. Have you run twister successfully with some representative hardware in the loop? I would like to know with some certainty that this change will not introduce any regressions not covered by CI.

Copy link
Member

@cfriedt cfriedt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine with me, as long as @sylvioalves can run twister to ensure we have test coverage on areas not covered by CI.

@cfriedt cfriedt added this to the v2.7.0 milestone Sep 18, 2021
@sylvioalves
Copy link
Collaborator Author

@sylvioalves - I'm ok with this going in as there are no code changes and it is mainly toolchain-related. Have you run twister successfully with some representative hardware in the loop? I would like to know with some certainty that this change will not introduce any regressions not covered by CI.

@cfriedt As far as I know, there is not CI for Espressif devices regarding hardware tests (yet). Zephyr's CI also does not run twister for variant espressif.

@cfriedt
Copy link
Member

cfriedt commented Sep 18, 2021

@cfriedt As far as I know, there is not CI for Espressif devices regarding hardware tests (yet). Zephyr's CI also does not run twister for variant espressif.

@sylvioalves Have you been able to test this out on hardware with fairly decent coverage? No compiler / linker bugs or things of that sort?

Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to avoid this being merged.
Will post comments soon.

Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small proposal that will make it possible to drop: a625c27

soc/riscv/esp32c3/Kconfig.defconfig Outdated Show resolved Hide resolved
cmake/toolchain/espressif/target.cmake Outdated Show resolved Hide resolved
@sylvioalves sylvioalves force-pushed the feature/improve_toolchain_path branch 2 times, most recently from c7502a4 to 8422b57 Compare September 20, 2021 16:14
@@ -51,21 +51,19 @@ On Linux and macOS:
.. code-block:: console

export ZEPHYR_TOOLCHAIN_VARIANT="espressif"
export ESPRESSIF_TOOLCHAIN_PATH="${HOME}/.espressif/tools/riscv32-esp-elf/1.24.0.123_64eb9ff-8.4.0/riscv32-esp-elf"
export ESPRESSIF_TOOLCHAIN_PATH="${HOME}/.espressif/tools/zephyr"
Copy link
Collaborator

@tejlmand tejlmand Sep 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious.

It seems the espressif toolchain is now expected to be installed under a different folder per default.
(/.espressif/tools/zephyr/riscv32-esp-elf/... vs. /.espressif/tools/riscv32-esp-elf/...)
Is that part of the espressif installer itself, or is there some missing doc update on toolchain installation ?

Also what about users already having the espressif toolchain installed ?
How will they be aware that they must now move their current
.espressif/tools/riscv32-esp-elf into .espressif/tools/zephyr/riscv32-esp-elf instead.

Also, is 1.24.0.123_64eb9ff-8.4.0 no longer part of the toolchain installation path ?

Copy link
Collaborator Author

@sylvioalves sylvioalves Sep 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tejlmand I have explained that already in this PR. Can you check previous comments? The main reason is having the same export PATH for Espressif toolchain to all SoCs, not depending on folder names and versioning as it is right now.

So, as you can see in the document update in this PR, no more 1.24.0.123_64eb9ff-8.4.0 or toolchain name explicit in folder path.

west espressif install is the download agent responsible to download and extract the toolchain in proper place (or user can manually download it as well).

Also what about users already having the espressif toolchain installed ?

When building, it will give them cmake error with a message to re-configure toolchain path.
Is there any recommendation on how to inform users about this change besides changing the ESP32 documentation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the output when running west espressif install. It also informs the user how to export path into the environment.

sylvio@pc:~/projects/espressif/zephyr/zephyr$ west espressif install
=== downloading ESP-IDF tools..
Installing tools: xtensa-esp32-elf, xtensa-esp32s2-elf, riscv32-esp-elf, openocd-esp32
Skipping xtensa-esp32-elf@esp-2020r3-8.4.0 (already installed)
Skipping xtensa-esp32s2-elf@esp-2020r3-8.4.0 (already installed)
Skipping riscv32-esp-elf@1.24.0.123_64eb9ff-8.4.0 (already installed)
Skipping openocd-esp32@v0.10.0-esp32-20200709 (already installed)
=== downloading ESP-IDF tools completed
The toolchain has been downloaded to /home/sylvio/.espressif/tools/zephyr
Export or set the following variables into the environment:
export ESPRESSIF_TOOLCHAIN_PATH="/home/sylvio/.espressif/tools/zephyr"
export ZEPHYR_TOOLCHAIN_VARIANT="espressif"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tejlmand I have explained that already in this PR.

If you refer to this comment #38540 (comment), then you only describe why, but my question was about who / how that path was ensured.
The installer or a guide ?

Now that question you answer with the west espressif install sentence.

Also what about users already having the espressif toolchain installed ?

When building, it will give them cmake error with a message to re-configure toolchain path.

No, you give them an error message requesting users to re-install something that is already installed.
I think we should ensure that if users have a setup with the old style then that will still be supported.

That will allow users to keep working and update the toolchain when a new revision is released and they update anyway.

By the way, your west espressif install fails on my machine.

west espressif install
=== downloading ESP-IDF tools..
/usr/bin/env: ‘python’: No such file or directory
FATAL ERROR: command exited with status 127: ./tools/idf_tools.py --tools-json=tools/zephyr_tools.json install

because I only have python3 and no python link.
Why not use the python that was already invoked with west ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then we can remove support for the old style at a later release, similar to what is done for other things we deprecate.

if(NOT CROSS_COMPILE_TARGET)
message(FATAL_ERROR
"Unable to find toolchain in ${TOOLCHAIN_HOME} "
"Run `west espressif install` to download it. Then, export to path accordingly.")
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tejlmand This is current error if toolchain not found by either missing its installation or having previous installation version.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I see that.
But this just ask user to re-install, but a user already having the toolchain installed should not need to re-install it.

@cfriedt
Copy link
Member

cfriedt commented Sep 21, 2021

Looks like this will likely be going into a dot release.

@sylvioalves
Copy link
Collaborator Author

Looks like this will likely be going into a dot release.

@cfriedt I am working on it. Hope there is still room for another round.

@sylvioalves sylvioalves force-pushed the feature/improve_toolchain_path branch 3 times, most recently from 14fdb5d to 8cc668a Compare September 22, 2021 00:35
@sylvioalves
Copy link
Collaborator Author

@tejlmand

I think we should ensure that if users have a setup with the old style then that will still be supported.

This update allows using already configured environment as you requested.

But this just ask user to re-install, but a user already having the toolchain installed should not need to re-install it.

I kept this message and it will only be displayed when no toolchain is exported into path.

because I only have python3 and no python link.
Why not use the python that was already invoked with west ?

I also added into this PR the necessary changes to use ${PYTHON_EXECUTABLE} as part of the scripts. There were a few places where python was hardcoded.

@cfriedt However, I had to update west.yml in order to get things in place in hal side. Now, #38543 needs to be merged before this MR. Once that gets merged, we can merge this. Do you think it can be accomplished before 2.7.0?

@cfriedt
Copy link
Member

cfriedt commented Sep 22, 2021

The release team says they would prefer it to go into a dot release.

@sylvioalves
Copy link
Collaborator Author

The release team says they would prefer it to go into a dot release.

Ok, so we wait. Thanks.

Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update, I think I spotted some flaws.

cmake/toolchain/espressif/generic.cmake Outdated Show resolved Hide resolved
cmake/toolchain/espressif/generic.cmake Outdated Show resolved Hide resolved
cmake/toolchain/espressif/generic.cmake Outdated Show resolved Hide resolved
@sylvioalves sylvioalves force-pushed the feature/improve_toolchain_path branch from 8cc668a to d88a130 Compare September 22, 2021 10:28
Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@cfriedt cfriedt added the DNM This PR should not be merged (Do Not Merge) label Sep 22, 2021
@cfriedt
Copy link
Member

cfriedt commented Sep 22, 2021

Added the DNM label just until we are out of the stabilization period

In order to retrieve TOOLCHAIN_NAME from Kconfig,
generic.cmake points to any toolchain as a
boilerplate implementation. Now, target.cmake file handles
proper toolchain selection.

Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Add toolchain path updates into documentation.

Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
This configures esptool, partition generator and
external bootloader build to use python tool defined
in Zephyr's context environment. This fixes error
regarding missing /usr/bin/python when python2.7 is not
installed in users's machine.

Partition table offset is also updated as part of
this change.

Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
@sylvioalves sylvioalves force-pushed the feature/improve_toolchain_path branch from d88a130 to 0c4917b Compare September 28, 2021 11:53
@github-actions github-actions bot removed the DNM This PR should not be merged (Do Not Merge) label Sep 28, 2021
@sylvioalves
Copy link
Collaborator Author

@cfriedt Only rebased to fix merge conflict.

@cfriedt cfriedt removed this from the v2.7.0 milestone Sep 28, 2021
@cfriedt cfriedt merged commit fd3696a into zephyrproject-rtos:main Sep 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants