1. devel@lists.zephyrproject.org
  2. Messages
   Date   
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

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
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:

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

> On Jan 30, 2020, at 3:17 PM, Scott Branden <sbranden@...> wrote:
>
> Hello,
>
> We are currently running zephyr on M7 and linux on A72.
>
> The base M7 support has been upstreamed here:
> https://github.com/zephyrproject-rtos/zephyr/commit/54ce0b2d3464d44429108f436a528ece51f866ff
>
> We are now looking at running Zephyr on A72 instead of linux.
>
> But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?
>
> Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?
>
> In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....
>
> Regards,
>  Scott Branden

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:

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:

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@linaro.org> 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.

Look at boards/arm/lpcxpresso54114 for an example

- k

On Jan 30, 2020, at 3:17 PM, Scott Branden <sbranden@gmail.com> wrote:

Hello,

We are currently running zephyr on M7 and linux on A72.

The base M7 support has been upstreamed here:
https://github.com/zephyrproject-rtos/zephyr/commit/54ce0b2d3464d44429108f436a528ece51f866ff

We are now looking at running Zephyr on A72 instead of linux.

But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?

Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?

In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....

Regards,
Scott Branden

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.

Look at boards/arm/lpcxpresso54114 for an example

- k

> On Jan 30, 2020, at 3:17 PM, Scott Branden <sbranden@...> wrote:
>
> Hello,
>
> We are currently running zephyr on M7 and linux on A72.
>
> The base M7 support has been upstreamed here:
> https://github.com/zephyrproject-rtos/zephyr/commit/54ce0b2d3464d44429108f436a528ece51f866ff
>
> We are now looking at running Zephyr on A72 instead of linux.
>
> But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?
>
> Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?
>
> In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....
>
> Regards,
>  Scott Branden

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 :
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
Re: Bluetooth: Starting dev for TI CC256x support

Arnaud Mouiche
 

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

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.

Peter

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:
- 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.
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
Bluetooth: Starting dev for TI CC256x support

Arnaud Mouiche
 

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
SDK 0.11.1 Release

Kumar Gala
 

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: support for multi instance zephyr in same soc

Kumar Gala
 

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

On Jan 30, 2020, at 3:17 PM, Scott Branden <sbranden@gmail.com> wrote:

Hello,

We are currently running zephyr on M7 and linux on A72.

The base M7 support has been upstreamed here:
https://github.com/zephyrproject-rtos/zephyr/commit/54ce0b2d3464d44429108f436a528ece51f866ff

We are now looking at running Zephyr on A72 instead of linux.

But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?

Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?

In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....

Regards,
Scott Branden
Re: clang toolchain doesn't failing to compile properly

Sigvart Hovland
 

What target are you trying to compile for?

From the stack overflow thread I find
Target: x86_64-pc-linux-gnu


Then some references to the Nordic HAL. So I’m just going to assume you are trying to target nrf52xx so what should be noted is that you can’t use the LLVM linker also I think you need to use the arm-none-eabi assembler also if you are targeting an ARM cortex-m platform.

I got it to compile with LLVM and GCC/GNU assembler/linker. You will have to add an config in the /home/zephyrproject/modules/hal/nordic/nrfx/mdk/compiler_abstraction.h:66 that you are using Clang (ARMCC > 6 is an ARM version of Clang) I think it’s something like __CLANG or it could be __llvm__ or __clang__.

Some discussion on it here:

https://github.com/zephyrproject-rtos/zephyr/pull/19120

Some of the changes are added here
https://github.com/zephyrproject-rtos/zephyr/pull/19218

Based on https://github.com/galak/zephyr/tree/llvm I believe.

I don’t have my old branch where I got it to build unfortunately so I don’t have anything direct to link too but was able to build and run hello world with clang + arm-none-eabi linker and assembler.  Also I don’t remember the exact point in the code where I had to add a print for it to work. There was some in-line assembly which was optimized out by clang if it was not used so I added a print and it would work. Sorry for not being very helpful thought I would just give you some information.

 

 

From: devel@... <devel@...> On Behalf Of Akira Kato via Lists.Zephyrproject.Org
Sent: Thursday, January 30, 2020 7:13 PM
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] clang toolchain doesn't failing to compile properly

 

Hi,

I don't know if this is the proper place to ask technical question about zephyr but I have tried stackoverflow and started github issue with no help. I am new to zephyr so I followed the getting started guide. Here's the post I made: https://stackoverflow.com/questions/59976179/zephyr-error-using-llvm-works-fine-with-default-toolchain 

The problem is described there with the error logs. 

Thanks,

Akira
support for multi instance zephyr in same soc

Scott Branden
 

Hello,

We are currently running zephyr on M7 and linux on A72.

The base M7 support has been upstreamed here:

We are now looking at running Zephyr on A72 instead of linux.

But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?

Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?

In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....

Regards,
 Scott Branden
clang toolchain for zephyr doesn't failing to compile properly #gettingstartedguide

Akira Kato <akira.kato@...>
 

Hi,
I don't know if this is the proper place to ask technical question about zephyr but I have tried stackoverflow and started github issue with no help. I am new to zephyr so I followed the getting started guide. Here's the post I made: https://stackoverflow.com/questions/59976179/zephyr-error-using-llvm-works-fine-with-default-toolchain 
The problem is described there with the error logs. 
Thanks,
Akira
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 01/30/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 30 January 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
https://zoom.us/j/993312203

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

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf
Dev Rev Meeting - Jan 30 2020 Agenda

Kumar Gala
 

NOTE: The cal invite has gotten messed up and might show the meeting starting a hour earlier than normal. This is NOT correct, we are working on trying to correct the issue. The meeting time is the same as always.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-dev-meeting

——

Today’s agenda will focus on Device Tree, including pinmux.

- k
first steps / debug #debug #nrf52480

Rafael Dias
 

Hi!

This is my first message to the Zephyr forum.

Well, I started to work with zephyr a few days ago. I followed the steps from the Getting Started Guide and I'd like to perform the debugging of the application that I`m developing.

After I reproduced the steps from the section "Eclipse Debugging", I cold open the project at the Eclipse. The debugging "is working" but I not able to configure the breakpoints to any file at the project. 

Has anyone here had this same kind of problem?

and...

How do you go about debugging an application?

best regards,

Rafael Dias
1321 - 1340 of 8033