|
West 0.7.0 released, requires manual intervention on Ubuntu
Bolivar, Marti
Hello,
West 0.7.0 has been released. The main new feature since 0.6.x is the addition of "manifest imports", which let you pull in west.yml files from elsewhere into your own manifest file. You can upgrade in the usual ways: pip3 install west==0.7.0 # Windows and macOS pip3 install --user west==0.7.0 # Linux Please note that there is a problem with the upgrade on the version of pip3 which ships with Ubuntu 18.04. Other Linux distributions, macOS, and Windows are all upgrading successfully. On Ubuntu only, you will need to choose from one of the following workarounds to upgrade west: 1. Remove the old west before upgrading, like this: $ pip3 show west | grep Location: | cut -f 2 -d ' ' /home/foo/.local/lib/python3.6/site-packages $ rm -r /home/foo/.local/lib/python3.6/site-packages/west $ pip3 install --user west==0.7.0 2. Install west in a virtual environment using a more recent version of pip3, e.g. using the venv module: https://docs.python.org/3/library/venv.html Further details in this issue: https://github.com/zephyrproject-rtos/west/issues/373 And in particular, this comment: https://github.com/zephyrproject-rtos/west/issues/373#issuecomment-583489272 Thanks, Marti
|
|
|
|
Re: clang toolchain doesn't failing to compile properly
Sigvart Hovland
https://github.com/zephyrproject-rtos/zephyr/blob/e3d39032eb91973c6fc696696d442fa0f61f92c4/arch/arm/core/aarch32/thread.c#L449
toggle quoted messageShow quoted text
Pretty sure it was around here. Could be that I'm wrong(haven't found the code that worked I think I deleted the branch) where start_of_main_stack would disappear when I used Clang in combination with GNU tools. Or it was one of _current = main_thread; since it worked when you turned of multi-threading. My biggest gut feeling is that it is start_of_main_stack since it only has assignments and would be viewed from the compiler as never used if it does not look at the assembly.
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org> Sent: Thursday, February 6, 2020 4:58 PM To: Hovland, Sigvart <Sigvart.Hovland@nordicsemi.no> Cc: akira.kato@biosensics.com; devel@lists.zephyrproject.org Subject: Re: [Zephyr-devel] clang toolchain doesn't failing to compile properly Sigvart, I’d really appreciate if you could try and remember where you might have added that print to deal with the in-line asm getting optimized away. - k On Jan 31, 2020, at 5:54 AM, Sigvart Hovland <sigvart.hovland@nordicsemi.no> wrote:
|
|
|
|
Re: clang toolchain doesn't failing to compile properly
Kumar Gala
Sigvart,
toggle quoted messageShow quoted text
I’d really appreciate if you could try and remember where you might have added that print to deal with the in-line asm getting optimized away. - k
On Jan 31, 2020, at 5:54 AM, Sigvart Hovland <sigvart.hovland@nordicsemi.no> wrote:
|
|
|
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 02/06/2020 8:00am-9:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 6 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/993312203 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join Zoom Meeting
|
|
|
|
Event: Zephyr Toolchain Working Group
#cal-invite
devel@lists.zephyrproject.org Calendar <devel@...>
Zephyr Toolchain Working Group When: Where: Organizer: Maureen Helm Description: Zephyr Working Group is inviting you to a scheduled Zoom meeting. Topic: Zephyr Toolchain Working Group Join Zoom Meeting Meeting ID: 967 549 258 One tap mobile Dial by your location
|
|
|
|
add pyocd user scripy cause pylint issue
FrankLi
Hi guys,
Since to flash on mm_swiftio is not supported by pyocd, I want to override the flash algorithm for an external flash by using user script. The user script use pyocd global "target" cause pylint issue in zephyr Check. You can find the modify https://github.com/zephyrproject-rtos/zephyr/pull/22536 Add refer to https://github.com/mbedmicro/pyOCD/blob/master/docs/user_scripts.md
|
|
|
|
Dev-Review Meeting Agenda
Kumar Gala
All,
Meeting Minutes: https://docs.google.com/document/d/1vfgwa1oRVuLA0f4VZW9pMBD2n2kf7ZgI9QCw_4s01gA/edit?usp=sharing Agenda: GitHub PR/Issues: Add support for SiLabs EFR32BG13P SoC [Piotr M] - https://github.com/zephyrproject-rtos/zephyr/pull/22423 Device Tree: Roundup of DT agenda items for the dev review meeting from nordic: - who will work on a zephyr docs PR which includes the conclusions from our last meeting? - doing system initialization in DT dependency ordinal order (I want to discuss this) - issue roundup: - https://github.com/zephyrproject-rtos/zephyr/issues/19285 - https://github.com/zephyrproject-rtos/zephyr/issues/21369 (edited) #19285 devicetree: fixed non-alias reference to specific nodes #21369 devicetree: clearly define constraints on identifier/property name conflicts
|
|
|
|
New MCUBoot mailing list
Fabio Utzig <utzig@...>
Hi,
The MCUboot mailing list has been recently moved. We did not re-subscribe previously subscribed users, so for those interested it is now hosted here: https://groups.io/g/mcuboot Cheers, Fabio
|
|
|
|
The topic-gpio branch has been merged to master
Carles Cufi
Hi all,
As of this morning the 313 commits in the topic-gpio branch have been merged into Zephyr's master branch. What this means for you if: a) You are a GPIO API user: - Big chunks of the existing API have been deprecated, leading to deprecation build warnings. You should port your application to the new GPIO API as soon as possible, although you have 2 full Zephyr releases until the deprecated API is finally removed. Please refer to Peter Bigot's "porting guide" in this GitHub comment for additional information: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 b) You have outstanding, unmerged Pull Requests: - The Pull Requests may show green CI, but that is misleading. We encourage you to rebase your Pull Request as soon as possible against the current master and push. - If your Pull Request makes use of the GPIO API, it will not pass CI due to deprecation warnings. There is no solution but to port your code to the new GPIO API. If you are on a deadline for 2.2 feature freeze ping us on the #gpio channel on Slack to see if we can help. c) You are a maintainer with merge rights: - You need to make sure that CI has been rerun after the topic-gpio merge happened and *before* you merge any Pull Request to master Additional information about the merge process can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/21789 Finally I want to thank everybody who contributed to this effort, which has spanned many months and several hundred commits. Special mention to Piotr Mienkowski and Peter Bigot, whose dedication to getting this done has made it possible to merge this branch in time for the 2.2 release. Regards, Carles
|
|
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 02/04/2020 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 4 February 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878 Live meeting minutes: https://docs.google.com/
|
|
|
|
API meeting: Agenda
Carles Cufi
Hi all,
Today we will talk first about GPIO and the merge of the topic-gpio branch to master: - Cleanup the public and private API with typedefs - Testing status - Issues with master CI that might prevent the merge to master - https://github.com/zephyrproject-rtos/zephyr/issues/21789 Additionally I'd like to discuss: - RFC: API Change: clock_control - https://github.com/zephyrproject-rtos/zephyr/issues/22424 - Ability to use an API with device without extending its own API - https://github.com/zephyrproject-rtos/zephyr/issues/22415 Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit Regards, Carles
|
|
|
|
Re: support for multi instance zephyr in same soc
Carles Cufi
Hi Scott,
Yes, the whole “board” concept needs an overhaul to become instead “instances” or “targets” as you say. In the nRF5340, which is a dual-core asymmetric Cortex-M33, we used “cpuapp” and “cpunet” to distinguish between the application core and the network core: https://github.com/zephyrproject-rtos/zephyr/tree/master/boards/arm/nrf5340_dk_nrf5340
Carles
From: devel@... <devel@...>
On Behalf Of Scott Branden via Lists.Zephyrproject.Org
Sent: 04 February 2020 02:23 To: Kumar Gala <kumar.gala@...> Cc: devel@... Subject: Re: [Zephyr-devel] support for multi instance zephyr in same soc
Thanks Kumar - we will go with this convention for naming the target. ie board_cpu. It will work out as long as there are not multiple cpu's on the same board that need different zephyr builds. At that point you would need board_cpu_n
Really "boards" directory should be renamed "targets"?
On Sun, Feb 2, 2020 at 9:01 AM Kumar Gala <kumar.gala@...> wrote:
|
|
|
|
Re: support for multi instance zephyr in same soc
Marc Herbert
Interesting, some parts of the documentation gave me the (wrong?) impression that a BOARD allowed some level of variation and configuration at build time:
toggle quoted messageShow quoted text
https://docs.zephyrproject.org/latest/guides/dts/index.html#input-and-output-files - "Optional DTS format files which override BOARD.dts" - "Extensible with DTS_ROOT" https://docs.zephyrproject.org/latest/guides/porting/board_porting.html#default-board-configuration - "This default board configuration is subordinated to features activation which is application responsibility..." - "... the board’s default Kconfig configuration, which is used in application builds unless explicitly overridden." Marc
On 3 Feb 2020, at 17:22, Scott Branden <sbranden@gmail.com> wrote:
|
|
|
|
Re: support for multi instance zephyr in same soc
Scott Branden
Thanks Kumar - we will go with this convention for naming the target. ie board_cpu. It will work out as long as there are not multiple cpu's on the same board that need different zephyr builds. At that point you would need board_cpu_n Really "boards" directory should be renamed "targets"?
On Sun, Feb 2, 2020 at 9:01 AM Kumar Gala <kumar.gala@...> wrote: This has been a long standing issue. Since these are both ARM you can get away with doing something similar to how we handle building different images for SoCs that have 2 different M-class cores.
|
|
|
|
Re: [Zephyr-users] SDK 0.11.1 Release
Nashif, Anas
Hi,
Thanks Kumar. Please note that this version of the SDK is now required for development on master and is enabled in CI. Anas On 03/02/2020, 05:56, "users@lists.zephyrproject.org on behalf of Kumar Gala" <users@lists.zephyrproject.org on behalf of kumar.gala@linaro.org> wrote: Hi, Some minor fixes that got missed for the v0.11.0 release. Mostly impacts OpenOCD and newlib usage. The SDK can be found here: https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.1 Please download and try things out and report any issues. OpenOCD: • Fixed missing commits from rebase - related to ARC and Zephyr RTOS awareness Newlib: • Removed setting -DMISSING_SYSCALL_NAMES on builds. Make syscall function names consistent and naming compatible with 3rd party GNU toolchains. Thanks to all that contributed fixes and enhancements to this version of the SDK. - k
|
|
|
|
Re: Bluetooth: Starting dev for TI CC256x support
Arnaud Mouiche
Hello Christopher,
Le 03/02/2020 à 13:44, Christopher
Friedt a écrit :
Yes, I will use the Bluetooth chipset with HCI over UART connection. I will check your advice. Thanks, Arnaud
|
|
|
|
Re: Bluetooth: Starting dev for TI CC256x support
Arnaud Mouiche
Hello Peter,
toggle quoted messageShow quoted text
The chipset I expect to support first is the CC2564 which is not a SOC but a simple HCI adapter. Zephyr will run on another MCU. Regards, Arnaud Le 03/02/2020 à 13:35, Peter A. Bigot a
écrit :
https://github.com/zephyrproject-rtos/zephyr/pull/22012 removed support for this SOC. If you're interested in maintaining this platform, it could be resurrected. Please comment on that issue to get started.
|
|
|
|
RFC: API Change: clock_control
Chruściński, Krzysztof
Hi all,
I’ve created a RFC for clock control API update: https://github.com/zephyrproject-rtos/zephyr/issues/22424
Please review and comment on the GitHub issue.
Regards, Krzysztof Chruściński
|
|
|
|
Re: Bluetooth: Starting dev for TI CC256x support
Christopher Friedt
On Mon., Feb. 3, 2020, 6:57 a.m. Arnaud Mouiche, <arnaud.mouiche@...> wrote: Questions: I'm working on the split-LL BLE stack [1] implementation currently, but that is for the "Single Chip" configuration. From what you describe, it sounds as though you would like to use the SoC as a BLE coprocessor, either over UART or SPI or something. Is that correct? In that case there may be a way to add a vendor-specific HCI command [2] or simply call the command from within your application.
|
|
|
|
Re: Bluetooth: Starting dev for TI CC256x support
Peter A. Bigot
https://github.com/zephyrproject-rtos/zephyr/pull/22012 removed support for this SOC. If you're interested in maintaining this platform, it could be resurrected. Please comment on that issue to get started.
Peter
|
|
|
