Date   

Re: Why do_swap() sets cpu.current before context switch?

Andy Ross
 

Katsuhiro Suzuki wrote:
> Newer switching sets NEW thread handle into _current_cpu.current
> BEFORE calling arch_switch().  This implementation will face a
> problem in RISC-V environment if thread calls do_swap() explicitly
> and switch to thread B (use FPU) from thread A (not use FPU)
> because...

So... this is the very middle of a context switch.  The expectation of the kernel is that no exception/interrupt handlers are going to fire, because (by definition) if they do they will see corrupt/inconsistent thread state.  Or rather, if an architecture wants to allow that, it needs to be prepared to do the work.

I mean, the information is available to you: you know what the new thread is, because you're handed its switch handle which you created yourself.  You likewise know the old thread, because you're passed the address of its switch_handle field from which you can extract a pointer to the enclosing thread struct.  You know you're in the middle of a context switch, because arch_switch() was called.  You COULD write an FPU exception handler to detect this state and do the right thing.  I don't necessarily think this would be a good design, but it's possible.

Can you explain why you need to take an FPU exception in the middle of a context switch?  That seems a little questionable to me.  Why are you hitting lazy-saved FPU registers in a situation where it would be faster to just check the mask state to see if they are populated or not?  (Forgive me: I don't know the RISC-V FPU architecture, but I assume that's the situation you're in: the FPU registers may or may not be in use and using them if they aren't will trap.)

Andy


Why do_swap() sets cpu.current before context switch?

Katsuhiro Suzuki
 

Hello kernel guys,

I have question about newer version of context switching (CONFIG_USE_SWITCH=y).

Newer switching sets NEW thread handle into _current_cpu.current BEFORE calling arch_switch().
This implementation will face a problem in RISC-V environment if thread calls do_swap() explicitly and switch to thread B (use FPU) from thread A (not use FPU) because...

- If _current_cpu.current has FPU flag, interrupt handler will save all FPU regs to stack
- At older switching
- _current_cpu.current is pointing thread A (not use FPU)
- The handler will skip saving
- But at newer switching
- _current_cpu.current is thread B (use FPU)
- The handler try to save FPU regs using FPU instructions
- But we haven't switching thread yet and thread A is prohibited to use FPU
- The handler will face illegal instruction exception (and going to hang...)

I don't know why newer switching sets thread B into _current_cpu.current such timing.
Does anyone know the reason about this implementation?

Best Regards,
Katsuhiro Suzuki


Event: Zephyr Project: APIs - 09/07/2021 #cal-reminder

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

Reminder: Zephyr Project: APIs

When:
09/07/2021
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


Cancelled Event: Zephyr: Networking Forum - Tuesday, September 7, 2021 #cal-cancelled

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

Cancelled: Zephyr: Networking Forum

This event has been cancelled.

When:
Tuesday, September 7, 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: tsc@...

Description:


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


Event: Zephyr: Networking Forum - 09/07/2021 #cal-reminder

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

Reminder: Zephyr: Networking Forum

When:
09/07/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: tsc@...

An RSVP is requested. Click here to RSVP

Description:


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


Unknown origin of error

markus.prager@...
 

Hi everyone

I am currently trying to write a driver for an STMicroelectronics LIS3DHH accelerometer. I based my code on the existing LIS2DH code that is already integrated in Zephyr and tried to adapt it to the LIS3DHH. Now when I try to build my project I get an error that i can't quite figure out where it is coming or originating from since it is occurring in an automatically generated file:

from /home/markus/driver_test_lis3dhh/my-workspace/zephyr/drivers/sensor/spi_lis3dhh/lis3dhh.c:7:
/home/markus/driver_test_lis3dhh/my-workspace/iots-fiso-id-p2-zephyr/build/zephyr/include/generated/devicetree_unfixed.h:24457:36: error: 'DT_N_S_soc_S_spi_40003800_S_lis3dhh_11_P_spi_max_frequency' undeclared here (not in a function); did you mean 'DT_N_S_soc_S_spi_40003800_S_lis3dhh_11_P_compatible_IDX_0'?
24457 | #define DT_N_INST_0_st_lis3dhh     DT_N_S_soc_S_spi_40003800_S_lis3dhh_11

I guess it looks like it is coming from the devicetree, but I can't see anything wrong with that one. I am doing all this on a custom board, so the devicetree I wrote myself - so I guess chances are high I did something wrong there, but I don't know what it could be.

So here is the relevant part of my devicetree if that helps:

&spi2 {
    pinctrl-0 = <&spi2_sck_pb13 &spi2_miso_pb14 &spi2_mosi_pb15>;/*PIN34,PIN35,PIN36*/
    cs-gpios = <&gpioc 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;/* PC6, Acc_CS */
    status = "okay";
 
    lis3dhh: lis3dhh@11 {
        compatible = "st,lis3dhh","st,spi_lis3dhh";
        reg = <0x11>;
        label = "LIS3DHH";
        spi-max-frequency = <10000000>; /*max. 10MHz*/
        int1-gpios = <&gpioc 7 GPIO_ACTIVE_HIGH>; /*PC7*/
        int2-gpios = <&gpioc 8 GPIO_ACTIVE_HIGH>;  /*PC8 */
    };
};

Any suggestions, hints or directions are very welcome.
Thanks in advance,
Markus


Networking Forum Agenda

Lubos, Robert
 

Hi all,

 

Sorry for the late notice, the are no items in the agenda for Today’s networking forum – please let me know if there is any topic you want to discuss. Otherwise, I’ll cancel the meeting.

 

Meeting notes:

https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0

 

Shared Folder:

https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

 

Teams meeting:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

 

Regards,
ROBERT LUBOS | Senior Firmware Engineer
M +48 504 088 482 | Krakow, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 


Need assistance with NRF5340dk regarding LWM2M

Brenton Chetty
 

Hi, Dev. Team

I am trying to get the LWM2M example working on the NRF5340dk. I got it working using QEMU.

- I flashed the lwm2m example using "nrf5340dk_nrf5340_cpuapp".
- I am not sure which network core to flash to "nrf5340dk_nrf5340_cpunet". Which do you suggest?
- When I run a serial terminal on the NRF board it says "<err> net_if: There is no network interface to work with!" I assume this is because I didn't flash a network core onto nrf5340dk_nrf5340_cpunet.
- I tried the "Socket Echo Server" example and tried following "https://docs.zephyrproject.org/latest/guides/networking/usbnet_setup.html#" however when I typed "dmesg" from the Linux host, I did not receive
"cdc_ether 1-2.7:1.0 eth0: register 'cdc_ether' at usb-0000:00:01.2-2.7, CDC Ethernet Device, 00:00:5e:00:53:01"

May you please assist me towards this objective?

WIth thanks
Brenton


Re: SDK 0.13.0 Release

Stephanos Ioannidis
 

Hi Roberto,

As per the discussion in the Toolchain WG meeting today, I have created an issue about this:
https://github.com/zephyrproject-rtos/sdk-ng/issues/395

Please comment on the linked issue if you have any further suggestions.

Stephanos

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Roberto Bagnara via lists.zephyrproject.org
Sent: Friday, September 3, 2021 11:18 PM
To: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] SDK 0.13.0 Release

On 04/08/21 01:15, Kumar Gala wrote:
Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.13.0

Please download and try things out and report any issues.

• general:
• Added support for ARC64. NOTE: GDB isn't currently supported for ARC64.
• CI/go.sh changes to make building MacOS and CI building easier.
• Various fixes for building/packaging on MacOS
• Added GitHub CI workflow to build MacOS x86_64 packages

• qemu:
• Updated to QEMU 6.0.0
• Added arc64 support. NOTE: this update ARC support replaces the machine (-M simhs) with (-M virt). This change will require updates to boards/arc/qemu_arc/board.cmake in Zephyr to match.
• Pull in fix from upstream for TFM: target/arm: Use correct SP in M-profile exception
• Pull in fixes from upstream for: hw/arm: Fix modelling of SSE-300
TCMs and SRAM

• gcc:

• Update to gcc 10.3 release
• Added support for ARC64
• Removed libgcc transactional memory clone registry support
• Fixed incorrect build specs for libstdc++ nano variant. The
libstdc++ nano variant, which is used with newlib-nano, is now built with -fno-exceptions to reduce compiled binary size.

• binutils:
• Updated to add support for ARC64

• newlib:
• Updated to add support for ARC64
• Added multithreading support
• Fix nano.spec file to pull in nano libraries.
• Set -mthumb-interwork for nano newlib builds to workaround at crosstool issue.

• crosstool-ng:
• sync with upstream. Upstream now supports newlib-nano so we drop our Zephyr specific updates. This also pulls in gcc-10.3 and initial support for ARC64.
• Fix stripping of newlib-nano libs

• yocto:
• Update to yocto 3.2.3 baseline. This is in prep to support building
qemu-6.0.0

• openocd:
• Update to upstream 20210630 snapshot

Thanks to all that contributed fixes and enhancements to this version of the SDK.
Hi there.

Would it make sense to add documentation to the SDK installers?
I mean, given the reference to gcc 10.3 in the announcement, I know where to find GCC documentation for it, but what about binutils, the standard libraries and the other stuff included.
Surely applicable documentation can be found, but the manual process of finding the right documentation is cumbersome and error prone.
What do you think?

Roberto


API meeting: agenda

Carles Cufi
 


Now: Zephyr: Toolchain Working Group - 09/06/2021 #cal-notice

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

Zephyr: Toolchain Working Group

When:
09/06/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

Description:

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


Event: Zephyr: Toolchain Working Group - 09/06/2021 #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When:
09/06/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

An RSVP is requested. Click here to RSVP

Description:

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


Re: Zephyr 2.7.0-rc1

Marc Reilly
 

Hi All

On Sat, 4 Sept 2021 at 06:34, Christopher Friedt <chrisfriedt@...> wrote:
Hi all,

We are pleased to announce Zephyr 2.7.0-rc1 \o/

This marks the beginning of the stabilization period leading up to our
scheduled release date of 2021-10-15. During the stabilization period,
only PRs for bug-fixes, documentation, and test cases will be
accepted. Any additional features must obtain TSC approval.

Damn, I just made a pull request for a new spi bitbang driver (https://github.com/zephyrproject-rtos/zephyr/pull/38313/), is it too late for that to be included?

Regardless, a big thanks to all those who make this project possible!

Cheers
Marc


Zephyr 2.7.0-rc1

Christopher Friedt
 

Hi all,

We are pleased to announce Zephyr 2.7.0-rc1 \o/

This marks the beginning of the stabilization period leading up to our
scheduled release date of 2021-10-15. During the stabilization period,
only PRs for bug-fixes, documentation, and test cases will be
accepted. Any additional features must obtain TSC approval.

This will be Zephyr's second LTS release. As such, we anticipate the
coming weeks to be very busy reducing overall bug count. Please give
this RC a test drive and report any issues on supported platforms
(with a PR if possible).

The full ChangeLog.txt for v2.7.0-rc1 was far too large to list on
GitHub's release page, so this time it is available as an attachment
at the link below:

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

Thank you to all who contributed to this release!

C


Out of Tree board support on TF-M

Li, Jun R
 

Hi,

I’m working to enable TF-M on a custom board based on nRF53 SoC. After checking the current TF-M module, it looks like that the boards that TF-M supports have been hardcoded in the Kconfig. I’m wondering how I can add a new board support for TF-M without changing TF-M’s module code? Does the current TF-M support Out-Of-Tree boards?

 

Thank you!

 

Jun Li

Intel Corporation


Moving from Slack to Discord

Carles Cufi
 

Hi all,

As voted during the TSC meeting on the 11th of August this year, the Zephyr Project is transitioning from Slack to Discord for real-time chat.
This transition will take place starting today, and the following steps have been taken already:

- Zephyr's new Discord server is up and running
- The new address for joining Zephyr's chat (i.e. Discord) is https://chat.zephyrproject.org/
- A subset of the existing Slack channels has been re-created in Discord. If you require additional channels to be created please contact the #discord channel in Discord itself
- An automated message will warn users on Slack about the transition so that they are informed.

[1] https://docs.google.com/document/d/1eHxigBEO1dDiq1O8IP5wX807CtLphh60Guu7jW_etKk/edit#


Thanks,

Carles


Re: SDK 0.13.0 Release

Roberto Bagnara
 

On 04/08/21 01:15, Kumar Gala wrote:
Hi,
Latest version of the SDK can be found here:
https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.13.0
Please download and try things out and report any issues.
• general:
• Added support for ARC64. NOTE: GDB isn't currently supported for ARC64.
• CI/go.sh changes to make building MacOS and CI building easier.
• Various fixes for building/packaging on MacOS
• Added GitHub CI workflow to build MacOS x86_64 packages

• qemu:
• Updated to QEMU 6.0.0
• Added arc64 support. NOTE: this update ARC support replaces the machine (-M simhs) with (-M virt). This change will require updates to boards/arc/qemu_arc/board.cmake in Zephyr to match.
• Pull in fix from upstream for TFM: target/arm: Use correct SP in M-profile exception
• Pull in fixes from upstream for: hw/arm: Fix modelling of SSE-300 TCMs and SRAM
• gcc:
• Update to gcc 10.3 release
• Added support for ARC64
• Removed libgcc transactional memory clone registry support
• Fixed incorrect build specs for libstdc++ nano variant. The libstdc++ nano
variant, which is used with newlib-nano, is now built with -fno-exceptions to reduce compiled binary size.
• binutils:
• Updated to add support for ARC64

• newlib:
• Updated to add support for ARC64
• Added multithreading support
• Fix nano.spec file to pull in nano libraries.
• Set -mthumb-interwork for nano newlib builds to workaround at crosstool issue.
• crosstool-ng:
• sync with upstream. Upstream now supports newlib-nano so we drop our Zephyr specific updates. This also pulls in gcc-10.3 and initial support for ARC64.
• Fix stripping of newlib-nano libs
• yocto:
• Update to yocto 3.2.3 baseline. This is in prep to support building qemu-6.0.0

• openocd:
• Update to upstream 20210630 snapshot
Thanks to all that contributed fixes and enhancements to this version of the SDK.
Hi there.

Would it make sense to add documentation to the SDK installers?
I mean, given the reference to gcc 10.3 in the announcement,
I know where to find GCC documentation for it, but what about
binutils, the standard libraries and the other stuff included.
Surely applicable documentation can be found, but the manual
process of finding the right documentation is cumbersome
and error prone.
What do you think?

Roberto


Re: Technical issue

lairdjm
 

Hi Sacha,
How have you configured it? Have you enabled and set the sample up to have the correct configuration options for your usecase? hcitool, hciconfig etc. are all deprecated tools, bluetoothctl is the single utility to use for Bluetooth when using BlueZ. Also BlueZ 5.50 is old, try on a newer build like 5.61.
Thanks,
Jamie

On Fri, 2021-09-03 at 01:25 -0700, Sacha Person via lists.zephyrproject.org wrote:
Hi,

I have a problem, the nrf52840 dongle using hci_usb sample isn't working on Raspberrypi OS.

Some of the BlueZ tools work with it but not others, can you check it out ?

Here's a StackOverflow question that shows all the error messages I've got with it, even following the Zephyr documentation:https://unix.stackexchange.com/questions/667401/bluez-controller-not-working-with-every-bluetooth-services-but-some-of-them-yes

Thank you !


Technical issue

Sacha Person <sacha.prsn@...>
 

Hi,

I have a problem, the nrf52840 dongle using hci_usb sample isn't working on Raspberrypi OS.

Some of the BlueZ tools work with it but not others, can you check it out ?

Here's a StackOverflow question that shows all the error messages I've got with it, even following the Zephyr documentation: https://unix.stackexchange.com/questions/667401/bluez-controller-not-working-with-every-bluetooth-services-but-some-of-them-yes

Thank you !


Error -EADDRNOTAVAIL when using bt_mesh_model_publish()

Omar Morceli
 

Hi
I am trying to publish some data using a vendor model, and I am getting error code -125  ( -EADDRNOTAVAIL).
Knowing the device was successfully configured and the key was bound correctly with no errors found in the logs.

41 - 60 of 8046