Add contribution to support PSOC Edge E84 AI Kit#1
Conversation
…ifact compatibility
…SDK 1.0.1 uses picolibc)
… macOS, and Windows
…verification and improved commands
…Windows to ensure proper execution and add error handling for unsigned bootloader packaging
… in kit_pse84_ai_pse846gps2dbzc4a_m33
…n on kit_pse84_ai_pse846gps2dbzc4a_m33
…during build process
…_AI and remove unused sketch header validation
…-{build.variant}.hex
michal-gora
changed the title
michal-gora
changed the title
| - name: zephyr | ||
| remote: arduino | ||
| revision: zephyr-arduino-v4.2.0 | ||
| remote: zephyrproject-rtos |
There was a problem hiding this comment.
One Question before review:
Are we aiming to produce a one-off proof of concept, or are we looking to maintain it long-term and even contributing to the upstream project?
The current patch script method makes it difficult to review and submit changes to upstream. ( also hard to pull from upstream...)
In view of this change in west.yml, I was thinking whether it would be better to include all these patch scripts, or to consolidate some of the changes into a self-hosted Zephyr branch.
For example, Infineon/Zephyr, or Infineon/Zephyr-Arduino.
There was a problem hiding this comment.
The short term goal is to create value with this by releasing a usable product.
We currently need to patch certain parts as we can not influence external dependencies and e.g. the PSOC Edge Zephyr port is too new to be supported in the Arduino Zephyr Core.
When the development around the PSOC Edge Zephyr port and the Arduino Zephyr Core settle a bit more we will be able to updates the dependencies in this port and remove the patches.
Then we will also consider upstreaming to the forked project (https://github.com/arduino/ArduinoCore-zephyr).
There was a problem hiding this comment.
Yes, but can’t we host an Arduino Zephyr Core ourselves?
Like https://github.com/arduino/zephyr. We could fork https://github.com/zephyrproject-rtos/zephyr and make some modifications there. So, a similar process to what was done with the Arduino target (Renesas...).
That way, it will be easier update to the upstream version later on.
And also better for manually review...
There was a problem hiding this comment.
example:
- name: zephyr-arduino
remote: infineon
revision: main
There was a problem hiding this comment.
Wouldn't it make more sense then to directly use https://github.com/Infineon/ifx-zephyr ?
There was a problem hiding this comment.
make ofc more sense. I am not aware of this repo.
- name:ifx-zephyr
remote: infineon
revision: arduino-v0.0.1
```
There was a problem hiding this comment.
One Question before review: Are we aiming to produce a one-off proof of concept, or are we looking to maintain it long-term and even contributing to the upstream project?
The current patch script method makes it difficult to review and submit changes to upstream. ( also hard to pull from upstream...)
In view of this change in west.yml, I was thinking whether it would be better to include all these patch scripts, or to consolidate some of the changes into a self-hosted Zephyr branch. For example, Infineon/Zephyr, or Infineon/Zephyr-Arduino.
The patch script method is explicitly for an issue that arises from Zephyr upstream (not ArduinoCore-zephyr), since there is an issues I could only solve by modifying the Zephyr source code, i.e. the clock divider for i2c and spi. These changes are infineon specific, so could be fixed in a future release of Zephyr. There are additional patches which I decided to implement using the existing patch structure used by the necessary patch, because of flexibility in the decision what to do about it.
It's up for question how to handle these patches in the future. E.g. the python package installation can be moved into the ArduinoCore-zephyr fork, but would make integration for a Pull Request to upstream more difficult.
It's a balance between making it work and keeping it upstream-conform for a possible PR. However at this moment PR is not possible anyways due to the older version of zephyr used upstream.
There was a problem hiding this comment.
Wouldn't it make more sense then to directly use https://github.com/Infineon/ifx-zephyr ?
Yes, I agree, that should also be possible. Just create new branch and apply the patches there, and link this fork to that repo&branch, no?
There was a problem hiding this comment.
Wouldn't it make more sense then to directly use https://github.com/Infineon/ifx-zephyr ?
Yes, I agree, that should also be possible. Just create new branch and apply the patches there, and link this fork to that repo&branch, no?
We can even create a PR there and have it reviewed by the IFX Zephyr team. Can you do that with your patch? You can fork the repo from your account and open a PR to https://github.com/Infineon/ifx-zephyr
This can happen in parallel and shouldn't block the remaining review here though @LinjingZhang @jaenrig-ifx
There was a problem hiding this comment.
It is fine to stay with patches for now. In the long term, ideally these things are fixed in the original repos.
So we should try to raise the issue or PR in those projects. And let's see how effective that is.
jaenrig-ifx
left a comment
jaenrig-ifx
left a comment
There was a problem hiding this comment.
@ederjc there is not much I can judge from this implementation at this moment, as I am not familiar with the internal of the Arduino Zephyr core, and the PSE Zephyr enablement.
I will try to install this branch as user. Any additional considerations other than following the README and existing docs?
@michal-gora
I see we have the package/config.yml and package_infineon_pse84_index.template.json, but I did not see if they are actually being used for creating the release package.
I am therefore wondering if this port can reuse these arduino-devops packager and release workflows.
Another topic. I would favor less scripting directly in the workflows .yml and calls to scripts which can also be also be evaluated eventually locally. But I might be talking to early, as I would like to better understand the design patterns and approaches of this Arduino Zephyr Core.
| echo EXTRA_ZEPHYR_MODULES="$(pwd)/$MODULE_PATH" >> $GITHUB_ENV | ||
|
|
||
| - name: Build fade | ||
| - name: Apply Zephyr patches |
There was a problem hiding this comment.
I wonder the scope of build check for this build.yml workflow. It looks like an arbitrary set of checks for boards and examples.
How this should look when contributing to the official repo?
| unoq.bootloader.tool.default=remoteocd | ||
| unoq.bootloader.file=zephyr-{build.variant}.elf | ||
| unoq.bootloader.target=stm32u585zitxq | ||
| # giga.name=Arduino Giga R1 |
There was a problem hiding this comment.
Why are the other boards commented out?
| - name: zephyr | ||
| remote: arduino | ||
| revision: zephyr-arduino-v4.2.0 | ||
| remote: zephyrproject-rtos |
There was a problem hiding this comment.
It is fine to stay with patches for now. In the long term, ideally these things are fixed in the original repos.
So we should try to raise the issue or PR in those projects. And let's see how effective that is.
4 participants
By creating this pull request you agree to the terms in CONTRIBUTING.md.
https://github.com/Infineon/.github/blob/master/CONTRIBUTING.md
--- DO NOT DELETE ANYTHING ABOVE THIS LINE ---
CONTRIBUTING.md also tells you what to expect in the PR process.