Date   

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

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

Reminder: Zephyr Project: APIs

When: Tuesday, 15 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
 


Re: Regarding issue in cmake build of hci_uart module

Anupam Roy
 

Hello Lawrence & Jamie,

 After 'west' update, nrfx.h file is available in <zephyr project directory>/modules/hal/nordic/nrfx dir & also CMAKE build got successful!

Thank You very much for your help~

 

BR,

-Anupam Roy

 

--------- Original Message ---------

Sender : Lawrence King <lawrence.king@...>

Date : 2020-09-11 18:30 (GMT+5:30)

Title : Re: [Zephyr-devel] Regarding issue in cmake build of hci_uart module

 

Which version of Zephyr are you trying to build? Run ‘git branch’ to find out. The newer versions of Zephyr require Zephyr SDK newer than v0.11.1

 

Also did you do a ‘west update’? this is required to pull in the right versions of the hal to match the version of Zephyr you have checked out.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of lairdjm
Sent: Friday, September 11, 2020 2:21 AM
To: anupam.r@...; zephyr-devel@...
Cc: AMIT KUMAR JAISWAL <amit.jaiswal@...>; Nitin Jhanwar <nitin.j@...>
Subject: Re: [Zephyr-devel] Regarding issue in cmake build of hci_uart module

 

Hi Anupam,

Is west in your path, if you type ‘west’ from the command line does it run? If not then it needs adding to the path. If you go to the $zephyr/../modules/hal/nordic/nrfx folder, does the folder exist and is nrfx.h in that folder?

Thanks,

Jamie

 

From: devel@... <devel@...> On Behalf Of Anupam Roy via lists.zephyrproject.org
Sent: 11 September 2020 06:38
To: zephyr-devel@...
Cc: AMIT KUMAR JAISWAL <amit.jaiswal@...>; Nitin Jhanwar <nitin.j@...>
Subject: [Zephyr-devel] Regarding issue in cmake build of hci_uart module

 

EXTERNAL EMAIL: Be careful with attachments and links.

Hello Zephyr Developers,

 Presently, I am trying to do CMAKE build of  $zephyr/zephyr/samples/bluetooth/hci_uart/ for my nRF52840 BLE Controller (dongle).

Board config was set as follows.

cmake -DBOARD=nrf52840dongle_nrf52840 ..

 

After setting board config, I am facing build fail due to missing nrfx.h file.

Any insight or clue for resolving this problem will be really helpful. Thank You very much!

 

Following is the compilation log snippet.

 [  9%] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
In file included from /home/sri/work/code/zephyr/zephyr/include/arch/arm/aarch32/cortex_m/cmsis.h:17,
     
            from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu_v7m.h:10,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu.h:13,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/arch.h:186,
                 from <zephyr project directory>/zephyr/include/arch/cpu.h:19,
                 from <zephyr project directory>/zephyr/include/kernel_includes.h:38,
                 from <zephyr project directory>/zephyr/include/kernel.h:17,
                 from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets_aarch32
.c:28,
                
from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets.c:12:
<zephyr project directory>/zephyr/soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such file or directory
   16 | #include <nrfx.h>
      |          ^~~~~~~~
compilation terminated.
zephyr/CMakeFiles/offsets.dir/build.make:81: recipe for target 'zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj' failed
make[2]: *** [zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj] Error 1
CMakeFiles/Makefile2:1963: recipe for target 'zephyr/CMakeFiles/offsets.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/offsets.dir/all] Error 2
Makefile:102: recipe for target 'all' failed
make: *** [all] Error 2

 

Note: I am using Zephyr SDK v0.11.1

 

BR,

-Anupam Roy


Re: Regarding issue in cmake build of hci_uart module

Lawrence King
 

Which version of Zephyr are you trying to build? Run ‘git branch’ to find out. The newer versions of Zephyr require Zephyr SDK newer than v0.11.1

 

Also did you do a ‘west update’? this is required to pull in the right versions of the hal to match the version of Zephyr you have checked out.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of lairdjm
Sent: Friday, September 11, 2020 2:21 AM
To: anupam.r@...; zephyr-devel@...
Cc: AMIT KUMAR JAISWAL <amit.jaiswal@...>; Nitin Jhanwar <nitin.j@...>
Subject: Re: [Zephyr-devel] Regarding issue in cmake build of hci_uart module

 

Hi Anupam,

Is west in your path, if you type ‘west’ from the command line does it run? If not then it needs adding to the path. If you go to the $zephyr/../modules/hal/nordic/nrfx folder, does the folder exist and is nrfx.h in that folder?

Thanks,

Jamie

 

From: devel@... <devel@...> On Behalf Of Anupam Roy via lists.zephyrproject.org
Sent: 11 September 2020 06:38
To: zephyr-devel@...
Cc: AMIT KUMAR JAISWAL <amit.jaiswal@...>; Nitin Jhanwar <nitin.j@...>
Subject: [Zephyr-devel] Regarding issue in cmake build of hci_uart module

 

EXTERNAL EMAIL: Be careful with attachments and links.

Hello Zephyr Developers,

 Presently, I am trying to do CMAKE build of  $zephyr/zephyr/samples/bluetooth/hci_uart/ for my nRF52840 BLE Controller (dongle).

Board config was set as follows.

cmake -DBOARD=nrf52840dongle_nrf52840 ..

 

After setting board config, I am facing build fail due to missing nrfx.h file.

Any insight or clue for resolving this problem will be really helpful. Thank You very much!

 

Following is the compilation log snippet.

 [  9%] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
In file included from /home/sri/work/code/zephyr/zephyr/include/arch/arm/aarch32/cortex_m/cmsis.h:17,
     
            from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu_v7m.h:10,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu.h:13,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/arch.h:186,
                 from <zephyr project directory>/zephyr/include/arch/cpu.h:19,
                 from <zephyr project directory>/zephyr/include/kernel_includes.h:38,
                 from <zephyr project directory>/zephyr/include/kernel.h:17,
                 from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets_aarch32
.c:28,
                
from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets.c:12:
<zephyr project directory>/zephyr/soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such file or directory
   16 | #include <nrfx.h>
      |          ^~~~~~~~
compilation terminated.
zephyr/CMakeFiles/offsets.dir/build.make:81: recipe for target 'zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj' failed
make[2]: *** [zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj] Error 1
CMakeFiles/Makefile2:1963: recipe for target 'zephyr/CMakeFiles/offsets.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/offsets.dir/all] Error 2
Makefile:102: recipe for target 'all' failed
make: *** [all] Error 2

 

Note: I am using Zephyr SDK v0.11.1

 

BR,

-Anupam Roy


Re: Regarding issue in cmake build of hci_uart module

lairdjm
 

Hi Anupam,

Is west in your path, if you type ‘west’ from the command line does it run? If not then it needs adding to the path. If you go to the $zephyr/../modules/hal/nordic/nrfx folder, does the folder exist and is nrfx.h in that folder?

Thanks,

Jamie

 

From: devel@... <devel@...> On Behalf Of Anupam Roy via lists.zephyrproject.org
Sent: 11 September 2020 06:38
To: zephyr-devel@...
Cc: AMIT KUMAR JAISWAL <amit.jaiswal@...>; Nitin Jhanwar <nitin.j@...>
Subject: [Zephyr-devel] Regarding issue in cmake build of hci_uart module

 

EXTERNAL EMAIL: Be careful with attachments and links.

Hello Zephyr Developers,

 Presently, I am trying to do CMAKE build of  $zephyr/zephyr/samples/bluetooth/hci_uart/ for my nRF52840 BLE Controller (dongle).

Board config was set as follows.

cmake -DBOARD=nrf52840dongle_nrf52840 ..

 

After setting board config, I am facing build fail due to missing nrfx.h file.

Any insight or clue for resolving this problem will be really helpful. Thank You very much!

 

Following is the compilation log snippet.

 [  9%] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
In file included from /home/sri/work/code/zephyr/zephyr/include/arch/arm/aarch32/cortex_m/cmsis.h:17,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu_v7m.h:10,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu.h:13,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/arch.h:186,
                 from <zephyr project directory>/zephyr/include/arch/cpu.h:19,
                 from <zephyr project directory>/zephyr/include/kernel_includes.h:38,
                 from <zephyr project directory>/zephyr/include/kernel.h:17,
                 from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets_aarch32
.c:28,
                 from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets.c:12:
<zephyr project directory>/zephyr/soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such file or directory
   16 | #include <nrfx.h>
      |          ^~~~~~~~
compilation terminated.
zephyr/CMakeFiles/offsets.dir/build.make:81: recipe for target 'zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj' failed
make[2]: *** [zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj] Error 1
CMakeFiles/Makefile2:1963: recipe for target 'zephyr/CMakeFiles/offsets.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/offsets.dir/all] Error 2
Makefile:102: recipe for target 'all' failed
make: *** [all] Error 2

 

Note: I am using Zephyr SDK v0.11.1

 

BR,

-Anupam Roy


Regarding issue in cmake build of hci_uart module

Anupam Roy
 

Hello Zephyr Developers,

 Presently, I am trying to do CMAKE build of  $zephyr/zephyr/samples/bluetooth/hci_uart/ for my nRF52840 BLE Controller (dongle).

Board config was set as follows.

cmake -DBOARD=nrf52840dongle_nrf52840 ..

 

After setting board config, I am facing build fail due to missing nrfx.h file.

Any insight or clue for resolving this problem will be really helpful. Thank You very much!

 

Following is the compilation log snippet.

 [  9%] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
In file included from /home/sri/work/code/zephyr/zephyr/include/arch/arm/aarch32/cortex_m/cmsis.h:17,
                 from <zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu_v7m.h:10,
                 from
<zephyr project directory>/zephyr/include/arch/arm/aarch32/cortex_m/mpu/arm_mpu.h:13,
                 from
<zephyr project directory>/zephyr/include/arch/arm/aarch32/arch.h:186,
                 from
<zephyr project directory>/zephyr/include/arch/cpu.h:19,
                 from
<zephyr project directory>/zephyr/include/kernel_includes.h:38,
                 from
<zephyr project directory>/zephyr/include/kernel.h:17,
                 from
<zephyr project directory>/zephyr/arch/arm/core/offsets/offsets_aarch32.c:28,
                 from <zephyr project directory>/zephyr/arch/arm/core/offsets/offsets.c:12:
<zephyr project directory>/zephyr/soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such file or directory
   16 | #include <nrfx.h>
      |          ^~~~~~~~
compilation terminated.
zephyr/CMakeFiles/offsets.dir/build.make:81: recipe for target 'zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj' failed
make[2]: *** [zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj] Error 1
CMakeFiles/Makefile2:1963: recipe for target 'zephyr/CMakeFiles/offsets.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/offsets.dir/all] Error 2
Makefile:102: recipe for target 'all' failed
make: *** [all] Error 2

 

Note: I am using Zephyr SDK v0.11.1

 

BR,

-Anupam Roy


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

George Kumar
 

Thanks Andrew P. Yes this is the behaviour I am observing. So I guess everything is as expected.

Thanks to all for responding.
George


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

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: Upcoming Event: Zephyr Toolchain Working Group - Thu, 04/16/2020 7:00am-8:00am #cal-reminder

Erwin Rol
 

Greetings!
It is on the topic of our recent conversation. Think now this project seems ideal :) Have a look:

*Reminder:* Zephyr Toolchain Working Group


*When:* Thursday, 16 April 2020, 7:00am to 8:00am, (GMT-07:00) America/Los Angeles

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

View Event ( https://lists.zephyrproject.org/g/devel/viewevent?eventid=753190 )

*Organizer:* Maureen Helm

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

Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

Mar 19, 2020 07:00 AM

Apr 2, 2020 07:00 AM

Apr 16, 2020 07:00 AM

Apr 30, 2020 07:00 AM

May 14, 2020 07:00 AM

May 28, 2020 07:00 AM

Jun 11, 2020 07:00 AM

Jun 25, 2020 07:00 AM

Jul 9, 2020 07:00 AM

Jul 23, 2020 07: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

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




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