Date   

Re: User Mode Drivers #driver

Jett ✈ Rink
 

Thank you both for detailed answers! We will continue to consider this idea for user mode drivers with the previously mentioned caveats, and we will see if implementing them is too onerous or not. Thanks again for the input!

-Jett

On Wed, Sep 9, 2020 at 2:51 PM Boie, Andrew P <andrew.p.boie@...> wrote:

Hi Jett,

 

It should certainly be possible to do this, where you implement driver logic as just code which makes other system calls at a lower-level bus abstraction to interact with the hardware. It would be hard to get this to play along with Zephyr's current driver abstraction infrastructure though.

 

However, a current limitation of the driver subsystems in Zephyr is that they unconditionally implement system calls at the subsystem level. And there is also the question on how to manage access to any global data associated with the higher-level driver, as the contents of data structures like `struct device` are considered private kernel data.

 

So using EEPROM as an example, you could in principle implement eeprom_read(), eeprom_write() etc as just some library code which makes system calls into the underlying SPI subsystem code to talk to the hardware. What currently happens right now is that the system call boundary is at the EEPROM subsystem level, and the implementation of the EEPROM APIs will call into the SPI driver already in supervisor mode. From a performance perspective the infrastructure is smart enough to skip all the syscall overhead when it calls into SPI from the EEPROM driver code, but from a least privilege standpoint it's not ideal.

 

The challenges are, as I see it:

  • struct device and supporting data structures are currently considered private kernel data, can't really provide a 'struct device' at the EEPROM level, just SPI
  • Callers into a user mode driver, if the driver code used any read-write global data, would have to also have access to this data otherwise you'd get a fault when making an API call
  • The subsystem code would need some idea of what devices are user mode and what aren't, and how to manage access to data that is kernel-private (like API vtables)

 

However, if you wanted to do this outside of the Zephyr driver abstraction model, it shouldn't be too bad. Write everything in terms of SPI driver calls, add a memory partition for any globals it has to manage, and enforce that any callers have both permissions on the underlying SPI device and also the memory partition active in the caller's memory domain.

 

Devicetree is AFAIK just our ontology of hardware characteristics so I wouldn't see a problem with getting HW values and stuff out of DTS regardless of what mode it runs in.

 

HTH,

Andrew

 

 

From: Jett Rink <jettrink@...>
Sent: Wednesday, September 9, 2020 1:21 PM
To: devel@...
Cc: Boie, Andrew P <andrew.p.boie@...>
Subject: User Mode Drivers #driver

 

Hey all,

 

Do all "drivers" need to be run in supervisor mode (within the kernel)? I am specifically thinking about external ICs that are connected to an embedded controller running Zephyr via i2c/SPI/etc.

 

Take, for example, the drivers for certain EEPROMs. The EEPROM drivers do not actually need to run within the kernel, but only need permission for the SPI kernel device that the EEPROM is attached to.

 

Within the principle of least privilege, should these drivers for external ICs that communicate over buses actually be kernel-level drivers, or should they be "user mode drivers" instead? Just for clarity, the drivers for hardware modules on the actual embedded controller should remain in the kernel.

 

Lastly, should "user mode devices" be present in the device tree or not? If we wanted to use the device tree to express how external ICs were connected, does that force us to make all drivers in the kernel or would there be flexibility to use the device tree for "user mode devices"?

 

Thank you for any input!

 

-Jett


Zephyr Project: Dev Meeting - Thu, 09/10/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 10 September 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr: Toolchain Working Group - Thu, 09/10/2020 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Thursday, 10 September 2020
2:00pm to 3:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr: Toolchain Working Group - Thu, 09/10/2020 2:00pm-3:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Thursday, 10 September 2020, 2:00pm to 3:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Maureen Helm

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr Toolchain Working Group Meeting – 10 September 2020

Rasmussen, Torsten
 

Call for today’s Toolchain WG.

 

Agenda

 

  • Updates:
    • PR #22668: Made it for v2.4.0 😊
      Thomas: IAR: Updates ?
    • Torsten: Toolchain abstraction: PR #24851: Made it for v2.4.0 😊
    • Next steps ?

 

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 682 738 030#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

 

________________________________________________________________________________

 

        

 

 

           

 


Re: Does ISR cause a preemptible thread to be swapped out

Boie, Andrew P
 

Hi George,

 

  • In Zephyr scheduling, after an ISR is done, can a preemptible thread be swapped out, and a higher priority thread, if ready, is allowed to run?

 

Yes this is guaranteed. There should always be a scheduler hook when coming out of a non-nested peripheral interrupt and if any higher priority thread(s) are runnable, the kernel will context switch to the highest one if the current thread is preemptible.  Feel free to file a bug if you are not seeing this to be the case.

 

HTH,

Andrew


Re: Does ISR cause a preemptible thread to be swapped out

Jett ✈ Rink
 

Hey George,

When coming back from an ISR, Zephyr should switch to the highest priority thread that is ready (with some caveats around multiple cooperative threads being ready). At least that is what I see from looking around in sched.c.

Also as a thought experiment, let's say that an ISR did come back to the same preemptible thread (not true). The first thing that would happen is that thread would get preempted by the higher priority thread that is now ready, so the original, lower priority, preemptible thread wouldn't be able to execute anything meaningful before it got preempted anyway.

-Jett



On Wed, Sep 9, 2020 at 2:23 PM George Kumar <grgkumar4@...> wrote:
Hi,

In Zephyr scheduling, after an ISR is done, can a preemptible thread be swapped out, and a higher priority thread, if ready, is allowed to run?

I understand the behaviour for the cooperative threads, but now sure if after an ISR a context switch can happen for preemptible threads.

Thanks.
George


Re: User Mode Drivers #driver

Boie, Andrew P
 

Hi Jett,

 

It should certainly be possible to do this, where you implement driver logic as just code which makes other system calls at a lower-level bus abstraction to interact with the hardware. It would be hard to get this to play along with Zephyr's current driver abstraction infrastructure though.

 

However, a current limitation of the driver subsystems in Zephyr is that they unconditionally implement system calls at the subsystem level. And there is also the question on how to manage access to any global data associated with the higher-level driver, as the contents of data structures like `struct device` are considered private kernel data.

 

So using EEPROM as an example, you could in principle implement eeprom_read(), eeprom_write() etc as just some library code which makes system calls into the underlying SPI subsystem code to talk to the hardware. What currently happens right now is that the system call boundary is at the EEPROM subsystem level, and the implementation of the EEPROM APIs will call into the SPI driver already in supervisor mode. From a performance perspective the infrastructure is smart enough to skip all the syscall overhead when it calls into SPI from the EEPROM driver code, but from a least privilege standpoint it's not ideal.

 

The challenges are, as I see it:

  • struct device and supporting data structures are currently considered private kernel data, can't really provide a 'struct device' at the EEPROM level, just SPI
  • Callers into a user mode driver, if the driver code used any read-write global data, would have to also have access to this data otherwise you'd get a fault when making an API call
  • The subsystem code would need some idea of what devices are user mode and what aren't, and how to manage access to data that is kernel-private (like API vtables)

 

However, if you wanted to do this outside of the Zephyr driver abstraction model, it shouldn't be too bad. Write everything in terms of SPI driver calls, add a memory partition for any globals it has to manage, and enforce that any callers have both permissions on the underlying SPI device and also the memory partition active in the caller's memory domain.

 

Devicetree is AFAIK just our ontology of hardware characteristics so I wouldn't see a problem with getting HW values and stuff out of DTS regardless of what mode it runs in.

 

HTH,

Andrew

 

 

From: Jett Rink <jettrink@...>
Sent: Wednesday, September 9, 2020 1:21 PM
To: devel@...
Cc: Boie, Andrew P <andrew.p.boie@...>
Subject: User Mode Drivers #driver

 

Hey all,

 

Do all "drivers" need to be run in supervisor mode (within the kernel)? I am specifically thinking about external ICs that are connected to an embedded controller running Zephyr via i2c/SPI/etc.

 

Take, for example, the drivers for certain EEPROMs. The EEPROM drivers do not actually need to run within the kernel, but only need permission for the SPI kernel device that the EEPROM is attached to.

 

Within the principle of least privilege, should these drivers for external ICs that communicate over buses actually be kernel-level drivers, or should they be "user mode drivers" instead? Just for clarity, the drivers for hardware modules on the actual embedded controller should remain in the kernel.

 

Lastly, should "user mode devices" be present in the device tree or not? If we wanted to use the device tree to express how external ICs were connected, does that force us to make all drivers in the kernel or would there be flexibility to use the device tree for "user mode devices"?

 

Thank you for any input!

 

-Jett


Re: User Mode Drivers #driver

Bolivar, Marti
 

Hi,

Jett ✈ Rink via lists.zephyrproject.org
<jettrink=google.com@...> writes:

Lastly, should "user mode devices" be present in the device tree or not? If
we wanted to use the device tree to express how external ICs were
connected, does that force us to make all drivers in the kernel or would
there be flexibility to use the device tree for "user mode devices"?
The devicetree describes the hardware. Whether or not a particular
software driver runs in user mode or not is an orthogonal question IMO.

If you are able to write a user mode driver as you describe, I don't see
why the hardware shouldn't be in the DT. You'll still want the device
labels in there to pass to device_get_binding(), for instance.

Martí


Does ISR cause a preemptible thread to be swapped out

George Kumar
 

Hi,

In Zephyr scheduling, after an ISR is done, can a preemptible thread be swapped out, and a higher priority thread, if ready, is allowed to run?

I understand the behaviour for the cooperative threads, but now sure if after an ISR a context switch can happen for preemptible threads.

Thanks.
George


User Mode Drivers #driver

Jett ✈ Rink
 

Hey all,

Do all "drivers" need to be run in supervisor mode (within the kernel)? I am specifically thinking about external ICs that are connected to an embedded controller running Zephyr via i2c/SPI/etc.

Take, for example, the drivers for certain EEPROMs. The EEPROM drivers do not actually need to run within the kernel, but only need permission for the SPI kernel device that the EEPROM is attached to.

Within the principle of least privilege, should these drivers for external ICs that communicate over buses actually be kernel-level drivers, or should they be "user mode drivers" instead? Just for clarity, the drivers for hardware modules on the actual embedded controller should remain in the kernel.

Lastly, should "user mode devices" be present in the device tree or not? If we wanted to use the device tree to express how external ICs were connected, does that force us to make all drivers in the kernel or would there be flexibility to use the device tree for "user mode devices"?

Thank you for any input!

-Jett


Re: C++ user apps

Simon Glass <sjg@...>
 

Hi,

Thank you for the info!

Regards,
Simon

On Mon, 24 Aug 2020 at 23:54, Kim Bøndergaard <Kim.Bondergaard@...> wrote:

See https://docs.zephyrproject.org/latest/reference/kernel/other/cxx_support.html?highlight=cxx

For application code it seems to be OK. You just have to enable it properly in your config:
Some of the configs I've been using:

CONFIG_STD_CPP11=y / CONFIG_STD_CPP14=y
CONFIG_NEWLIB_LIBC=y
CONFIG_CPLUSPLUS=y
CONFIG_LIB_CPLUSPLUS=y
CONFIG_RTTI=y

Beware of some of the pitfalls with e.g. exceptions.

Kim Bøndergaard
Prevas A/S
Team Manager / Systems Architect

Hedeager 3, DK-8200 Aarhus N

Phone +45 3315 9090
Mobile +45 5154 3961
kibo@...
www.prevas.dk




________________________________
From: devel@... <devel@...> on behalf of Simon Glass via lists.zephyrproject.org <sjg=chromium.org@...>
Sent: Monday, August 24, 2020 17:17
To: devel <devel@...>
Subject: [Zephyr-devel] C++ user apps

Hi,

Is there any guidance about using C++ in Zephyr? Is it common / recommended?

Does anyone have a link to a previous discussion?

Regards,
Simon



Zephyr Project: APIs - Tue, 09/08/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 8 September 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Zephyr 2.4.0-rc1 tagged

Maureen Helm
 

Hi everyone,

The first release candidate for Zephyr 2.4.0 has been tagged (v2.4.0-rc1).

 

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.4.0 is released; the stabilization period is now open. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the 2.4 release require approval by the TSC.

 

As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers.

 

Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline.

 

The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.4.0-rc1

More details about Zephyr releases can found on the pages below:

https://docs.zephyrproject.org/latest/development_process/release_process.html

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

The final release is tentatively scheduled for 25 Sep.

 

Note 1: You may continue to send Pull Requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the largest extent possible, so that we can release 2.4.0 on time and in the best shape possible.

 

Note 2: If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

 

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution!

 

Maureen


double free detected in bfree_recombine

George Kumar
 

Hi all,

I am running zephyr 2.2.0 on my board and while developing a multi-threading application, running into a double free at ZEPHY_BASE/lib/os/mempool.c:163.

/*Detect common double-free occurrences */
__ASSERT(alloc_bit_is_set(p, level, bn),
              "mempool double free detected at %p", block);

My question is does Zephyr have any tools like valgrind that can help me pinpoint the issue.

Thanks.
George


Timeout in NCS (nRF Connect SDK) by Nordic Semiconductors using Zephyr OS

Lavingia, Raj
 

Hello,

 

I am using the default Zephyr BLE stack while using the NCS SDK with nrf52840 development board by Nordic.

 

My setup is as follows

Board1 – Running a Peripheral_Uart demo code which is advertising.

Board2 – Running a Central_Uart demo code which is scanning.

 

When the scan starts on board 2, I am filling the advertising address of the devices which are advertising, in a buffer. When I started the printing the buffer, the addresses repeat at a certain time period. For example, if I see 01:01:01:01:01:01 address at time X sec, I see the same address at X + (120-180)sec again. So I am wondering if the data coming from the callback is getting refreshed at a certain time interval? If so, which parameters are controlling this refresh rate? Is it possible to change this time which is 120-180 sec approximately right now to whatever value I want?

 

Thanks

Raj Lavingia I Embedded Software Engineer

Shure Incoporated

5800 W. Touhy Avenue

Niles, Illinois 60714-4608 USA

T +1.847.600.6276

shure.com

 




This e-mail message (including any attachments) contains confidential, non-public information. It also may be protected by the attorney/client or other applicable privileges. It is intended to be communicated only to the designated recipient(s). Unauthorized use, reproduction, dissemination, or communication of this message or any information contained in this message is strictly prohibited and may be unlawful. If you are not an intended recipient of this message, please notify the sender promptly by e-mail or contact Shure Incorporated at info@... or 800-25-SHURE (800-257-4873).


Zephyr Project: Dev Meeting - Thu, 09/03/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 3 September 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: RFC: API change - make all device instance constant

Tomasz Bursztyka
 

Hello,

The PR was merged. Now ALL device instances are constant.
Along with this change: all isr handlers take a const void pointer.

To all relevant stakeholders that this may affect:
!!! PLEASE REBASE YOUR PR(s) ACCORDINGLY !!!

Thank you,

Tomasz


Zephyr Project: APIs - Tue, 09/01/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 1 September 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________