Zephyr Toolchain Working Group

When:
Thursday, 20 February 2020
9:00am to 10:00am
(UTC-06:00) America/Chicago
Repeats: Every 2 weeks on Thursday, through Thursday, 23 July 2020

Where:
https://zoom.us/j/967549258

Organizer: Maureen Helm

Description:

Zephyr Working Group is inviting you to a scheduled Zoom meeting.

Topic:  Zephyr Toolchain Working Group
Time: Feb 20, 2020 09:00 AM Central Time (US and Canada)
        Every 2 weeks on Thu, until Jul 23, 2020, 12 occurrence(s)
        Feb 20, 2020 09:00 AM
        Mar 5, 2020 09:00 AM
        Mar 19, 2020 09:00 AM
        Apr 2, 2020 09:00 AM
        Apr 16, 2020 09:00 AM
        Apr 30, 2020 09:00 AM
        May 14, 2020 09:00 AM
        May 28, 2020 09:00 AM
        Jun 11, 2020 09:00 AM
        Jun 25, 2020 09:00 AM
        Jul 9, 2020 09:00 AM
        Jul 23, 2020 09:00 AM
Please download and import the following iCalendar (.ics) files to your calendar system.
Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

Join Zoom Meeting
https://zoom.us/j/967549258

Meeting ID: 967 549 258

One tap mobile
+16699006833,,967549258# US (San Jose)
+16465588656,,967549258# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        855 880 1246 US Toll-free
        877 369 0926 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 967 549 258
Find your local number: https://zoom.us/u/abfRKTHWtN

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. 

************* Module pyocd_user
boards/arm/mm_swiftio/burner/pyocd_user.py:9:15: E0602: Undefined variable 'target' (undefined-variable)

    Is there any way to solve or bypass this problem？ Thanks!
    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

   

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

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

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

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

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY

---

 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

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

Interesting, some parts of the documentation gave me the (wrong?) impression that a BOARD allowed some level of variation and configuration at build time:

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

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

Hello Christopher,

On Mon., Feb. 3, 2020, 6:57 a.m. Arnaud Mouiche, <arnaud.mouiche@...> wrote:

Questions:
- Is there already somebody working on the subject ?

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.

Yes, I will use the Bluetooth chipset with HCI over UART connection.
I will check your advice.

Thanks,
Arnaud

[1] https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-arch.html

[2] https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/reference/bluetooth/hci.txt

Hello Peter,

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

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

Hi all,

I wish to develop the required driver to interface Zephyr with the TI Bluetooth CC256x chipset family.
Here are the requirements:
a) Need to upload an initialization script (what they call a 'BTS' file), mainly a binary file which is sequence of action (HCI command, host baudrate change, delays...)
It is a mix of device configuration, firmware patching (new features like BLE support are enabled through the init script). Each silicon version may require a different init script content.
b) A basic protocol called HCILL to manage Host and/or adapter sleeping.


b) is described here:
https://processors.wiki.ti.com/index.php/CC256x_eHCILL_Low_Power_Protocol.
The Linux driver is also a good reference:
https://github.com/torvalds/linux/blob/master/drivers/bluetooth/hci_ll.c

a) Init process is described in
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/hciattach_ti.c

Questions:
- Is there already somebody working on the subject ?

- I'm interesting by some advice to manage such "binary initialisation script" file integration.
Here is what think to implement:
+ a python script to transform the initial binary BTS file into a C file where each action has been split in a array of strcut ready to be walk through by the driver.
+ the list of BTS files to embed in the firmware is managed in the cmake file of the board
+ the HCI driver performing init and power management can be implemented as a fresh copy of https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/bluetooth/hci/h4.c if I don't find easy way to manage a factorization.

Regards,
Arnaud

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

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.

Look at boards/arm/lpcxpresso54114 for an example

- k