Date   

What is the difference "z_reschedule_irqlock" and "z_reschedule“? why two implementations?

"曹子龙
 

Hi folks:
    
why there are two implmentations of schedule?   What is the difference "z_reschedule_irqlock" and "z_reschedule“? why two implementations?

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow we will discuss an RFC that is ready to be merged, two items that were raised in last week's TSC and we will check on progress with the GPIO porting.

- RFC (ready to merge): on-off service request and release
- https://github.com/zephyrproject-rtos/zephyr/pull/21090

- Discussion: Stability documentation for APIs. Should it be documented in Doxygen?

- Discussion: What exactly is subject to the API lifecycle deprecation policies described in https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html?
- Options:
- APIs only
- APIs, Kconfig options, DeviceTree format
- APIs, Kconfig options, DeviceTree format, subsystems, drivers, boards and SoCs

- GPIO update (users)
- https://github.com/zephyrproject-rtos/zephyr/issues/20017

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: Did the SMP support arm architecture boards presents? if yes, which one?

Wayne Ren
 

As I know, currently there is no support of SMP for ARM architecture in Zephyr

 

From: devel@... <devel@...> On Behalf Of "曹子龙
Sent: 2020
118 16:26
To: devel <devel@...>
Subject: [Zephyr-devel] Did the SMP support arm architecture boards presents? if yes, which one?

 

HI folks:

     Did the SMP support arm architecture boards presents? if yes, which one?

 

    Thank you!

 

 

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技29

TEL13824125580

Emailcaozilong@...

网址: http://www.allwinnertech.com

 

 


Re: about the SMP implement ion, did the zephyr SMP support cpu affinity settings?

Boie, Andrew P
 

See the section on “CPU Mask” for directions on how to constrain threads to run on a particular set of CPUs.

 

https://docs.zephyrproject.org/latest/reference/kernel/smp/smp.html

 

Regards,

Andrew

 

From: devel@... <devel@...> On Behalf Of "???
Sent: Friday, January 17, 2020 8:35 PM
To: devel <devel@...>
Subject: [Zephyr-devel] about the SMP implement ion, did the zephyr SMP support cpu affinity settings

 

Hi folks:

 

    Did the SMP impl. of zephyr support the cpu affinity settings? i have not seen the  related members in k_thread structure.

 

Thanks for your kindly help.!

 

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 

 


Did the SMP support arm architecture boards presents? if yes, which one?

"曹子龙
 

HI folks:
     Did the SMP support arm architecture boards presents? if yes, which one?

    Thank you!


曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



where is the "z_smp_reacquire_global_lock" called to restore the lock state to whatever the thread's counter?

"曹子龙
 

Hi folks:
   throught the docment of zephyr smp imple. a task take the irq_lock can be yield to another thread, but would restore the spinlock own status when it comes back

but, throught the code, i just found the code release the global spinlock , but have not seen the reacquire the globbal spin lock when comes back.
do_swap:
 76                 if (!is_spinlock) {
 77                         z_smp_release_global_lock(new_thread);                                                                                                                             
 78                 } 

so, can anyone show me where is the :z_smp_reacquire_global_lock called ?

thank you!

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



about the SMP implement ion, did the zephyr SMP support cpu affinity settings?

"曹子龙
 

Hi folks:

    Did the SMP impl. of zephyr support the cpu affinity settings? i have not seen the  related members in k_thread structure.

Thanks for your kindly help.!


曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



Re: Dev-Review Meeting Agenda (Jan 16)

Kumar Gala
 

As a follow up we plan on The Jan 30th Dev Review meeting to discuss Pinmux/DT.

- k

On Jan 16, 2020, at 9:57 AM, Kumar Gala <kumar.gala@linaro.org> wrote:

[sorry for the late notice]

Here’s the agenda topics for this week:

* drivers: watchdog: Add SiLabs Gecko WDOG driver
[ https://github.com/zephyrproject-rtos/zephyr/pull/20316 ]

Any topics anyone else has

- k


Dev-Review Meeting Agenda (Jan 16)

Kumar Gala
 

[sorry for the late notice]

Here’s the agenda topics for this week:

* drivers: watchdog: Add SiLabs Gecko WDOG driver
[ https://github.com/zephyrproject-rtos/zephyr/pull/20316 ]

Any topics anyone else has

- k


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 01/16/2020 8:00am-9:00am, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 16 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


Re: zephyr_cc_option(-O0) issue in 1.14.99 (nrf52840)

pawel.dunaj@...
 

Hi,

I suggest checking the stack sizes. CONFIG_NO_OPTIMIZATIONS is sometimes used to decide which size to apply. Stack overflow could cause strange issues.
You can enlarge stacks enable stack analysis and see how much you need.

Regards,


Re: zephyr_cc_option(-O0) issue in 1.14.99 (nrf52840)

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi Chris and All,

I replied too quickly. CONFIG_NO_OPTIMIZATIONS=y  only delays the point at which the program hangs.
In my case it starts by displaying data and BLE advertising as expected, but crashes when a BLE connection is attempted.
It still runs as expected if
zephyr_cc_option(-O0)  and CONFIG_NO_OPTIMIZATIONS=y are not used. The zephyr sample
peripheral_esp  behaves the same way.

This is a queer behavior. Any hint is most welcome.

kind regards

Abder

build command:

>west build -b nrf52840_pca10056 src -- -G"Eclipse CDT4 - Ninja" -DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100 -DCMAKE_ECLIPSE_VERSION=4.7

original description of the issue:

I had a program than ran with no problems in 1.13. But would crash in 1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.
The program is based on the peripheral_esp sample. The peripheral_esp sample itself has the same problem: builds and runs if zephyr_cc_option(-O0)
is not present and would crash if it is present. Strangely it does not have any problem with zephyr_cc_option(-On) n=1,2 or 3.
Other programs, not using Bluetooth, have no problem with this option.
Any hints on what I might be doing wrong?

On 1/15/2020 1:46 PM, Abderrezak Mekkaoui wrote:

Thanks Chris.
That works. And using zephyr_cc_option(-O0) with CONFIG_NO_OPTIMIZATIONS=y  does not cause any trouble.
Still seems strange that other program do not seem to bother!

Kind regards

Abder

On 1/15/2020 1:12 PM, Christopher Friedt wrote:

Hi Ab,

On Wed., Jan. 15, 2020, 12:54 p.m. Abderrezak Mekkaoui, <ab.mekka@...> wrote:
I had a program than ran with no problems in 1.13. But would crash in
1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.

Have you tried using CONFIG_NO_OPTIMIZATIONS=y ? I've found that will achieve the same ends as explicitly changing CMakeLists.txt to use -O0.


Re: zephyr_cc_option(-O0) issue in 1.14.99

Abderrezak Mekkaoui <ab.mekka@...>
 

Thanks Chris.
That works. And using zephyr_cc_option(-O0) with CONFIG_NO_OPTIMIZATIONS=y  does not cause any trouble.
Still seems strange that other program do not seem to bother!

Kind regards

Abder

On 1/15/2020 1:12 PM, Christopher Friedt wrote:

Hi Ab,

On Wed., Jan. 15, 2020, 12:54 p.m. Abderrezak Mekkaoui, <ab.mekka@...> wrote:
I had a program than ran with no problems in 1.13. But would crash in
1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.

Have you tried using CONFIG_NO_OPTIMIZATIONS=y ? I've found that will achieve the same ends as explicitly changing CMakeLists.txt to use -O0.


Re: zephyr_cc_option(-O0) issue in 1.14.99

Christopher Friedt
 


Hi Ab,

On Wed., Jan. 15, 2020, 12:54 p.m. Abderrezak Mekkaoui, <ab.mekka@...> wrote:
I had a program than ran with no problems in 1.13. But would crash in
1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.

Have you tried using CONFIG_NO_OPTIMIZATIONS=y ? I've found that will achieve the same ends as explicitly changing CMakeLists.txt to use -O0.


zephyr_cc_option(-O0) issue in 1.14.99

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

I had a program than ran with no problems in 1.13. But would crash in 1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.
The program is based on the peripheral_esp sample. The peripheral_esp sample itself has the same problem: builds and runs if zephyr_cc_option(-O0)
is not present and would crash if it is present. Strangely it does not have any problem with zephyr_cc_option(-On) n=1,2 or 3.
Other programs, not using Bluetooth, have no problem with this option.
Any hints on what I might be doing wrong?

Thanks

Abderrezak


Output of peripheral_esp sample when build with zephyr_cc_option(-O0):


***** Booting Zephyr OS build zephyr-v1.14.0-2216-g3da2985b2837 *****
Bluetooth initialized
Advertising successfully started
***** USAGE FAULT *****
  Illegal load of EXC_RETURN into PC
***** Hardware exception *****
Current thread ID = 0x20000048
Faulting instruction address = 0x20001e28
Fatal fault in thread 0x20000048! Aborting.


Re: Porting Zephyr HCI Layer

Carles Cufi
 

Hi there,

 

Combining the Bluetooth Host from Nordic with the Zephyr Controller is not an option, because the SoftDevice is hardcoded to contain both Host and Controller and they cannot be decoupled.

I understand that you have your own Host running on FreeRTOS that you want to combine with the Zephyr Link Layer. Porting the Zephyr controller to FreeRTOS is not going to be trivial, but it shouldn’t be too hard either if you are willing to do the work and maintain it. The controller uses mainly bare-metal with some Zephyr-specific primitives mostly in HCI and the ULL.

 

Here you have the following options:

  • Drop your Host, use Zephyr’s
  • Port your Host to Zephyr, replacing Zephyr’s Host. This should be fairly straightforward.
  • Use another open source controller that runs of FreeRTOS (though I am not sure how easy it is to combine the controller in that stack with your Host). See nimBLE: https://github.com/apache/mynewt-nimble

 

Carles

 

From: devel@... <devel@...> On Behalf Of ryan.kayesimmons via Lists.Zephyrproject.Org
Sent: 14 January 2020 22:26
To: Hedberg, Johan <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer

 

Hi Johan

 

Thank you for your quick reply.

 

Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. 

 

In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr.

 

The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. 

That might be the only way to continue with my issue and to get full access to the hci & link layer? 

 

Kind Regards,

Ryan Kaye-Simmons

 

 

 


From: Hedberg, Johan <johan.hedberg@...>
Sent: Wednesday, January 15, 2020, 1:17 AM
To: ryan.kayesimmons@...
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer


Hi Ryan, On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: > I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? > on the same chip. That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. > Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. > I guess I just want to know if I’ll be wasting a lot of my time if I take this approach! I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan


NFFS support removal

Puzdrowski, Andrzej
 

NFFS support will be removed from the zephyr-project codebase.

 

It was decided to take such action as NFFS has few serious issue which made it unreliable (Such issues were not fixed since a long time, after deep analyze: need a lot of effort to be fixed).

As Litlefs support is available in the zephyr since while it doesn't make any sense to keep NFFS support as it lost even education value: LitleFS is better substitute.

Littlefs is one of zephyr VFS backend, so application level API is the same as was for NFFS.

 

Regards,

Andrzej

 


Re: ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

Boie, Andrew P
 

Phil,

 

I sent a PR which adds a test for this:

 

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

 

It passes on all the emulated targets we have (including Cortex-M), but if this is broken for your target please file a bug in GitHub.

 

Regards,

Andrew

 

From: devel@... <devel@...> On Behalf Of Boie, Andrew P
Sent: Tuesday, January 14, 2020 1:39 PM
To: phil.erwin@...; devel@...
Subject: Re: [Zephyr-devel] ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

 

Interrupts should be unlocked when handling system calls, and indeed a thread in a system call can sleep or be preempted. Sounds like you have found a bug. And a gap in testing, we ought to have a test that validates this.

 

Andrew

 

From: devel@... <devel@...> On Behalf Of phil.erwin@...
Sent: Tuesday, January 14, 2020 4:55 AM
To: devel@...
Subject: [Zephyr-devel] ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

 

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled.  It seems to me that external interrupts should be enabled during this time. 

In looking through the Cortex-M support, I don't see where interrupts are enabled there either, so I wanted to poll the community to ask what the expectations are: external interrupts enabled or disabled?

Phil


Re: ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

Boie, Andrew P
 

Interrupts should be unlocked when handling system calls, and indeed a thread in a system call can sleep or be preempted. Sounds like you have found a bug. And a gap in testing, we ought to have a test that validates this.

 

Andrew

 

From: devel@... <devel@...> On Behalf Of phil.erwin@...
Sent: Tuesday, January 14, 2020 4:55 AM
To: devel@...
Subject: [Zephyr-devel] ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

 

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled.  It seems to me that external interrupts should be enabled during this time. 

In looking through the Cortex-M support, I don't see where interrupts are enabled there either, so I wanted to poll the community to ask what the expectations are: external interrupts enabled or disabled?

Phil


Re: Porting Zephyr HCI Layer

ryan.kayesimmons@...
 

Hi Johan

Thank you for your quick reply.

Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. 

In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr.

The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. 
That might be the only way to continue with my issue and to get full access to the hci & link layer? 

Kind Regards,
Ryan Kaye-Simmons




From: Hedberg, Johan <johan.hedberg@...>
Sent: Wednesday, January 15, 2020, 1:17 AM
To: ryan.kayesimmons@...
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer

Hi Ryan, On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: > I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? > on the same chip. That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. > Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. > I guess I just want to know if I’ll be wasting a lot of my time if I take this approach! I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan

1381 - 1400 of 8032