Date   

a Problem with external_lib sample

Omar Morceli
 


i'm facing a problem when i building the external_lib sample 


> west build -b nrf52dk_nrf52832                      
[1/142] Performing build step for 'mylib_project'
FAILED: mylib/src/mylib_project-stamp/mylib_project-build mylib/lib/libmylib.a
cmd.exe /C "cd /D C:\Users\OMAR\zephyrproject\zephyr\samples\application_development\external_lib\mylib && make PREFIX=C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib "CC=C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2020-q4-major/bin/arm-none-eabi-gcc.exe" "AR=C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2020-q4-major/bin/arm-none-eabi-ar.exe" "CFLAGS=-IC:/Users/OMAR/zephyrproject/zephyr/include -IC:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/zephyr/include/generated -IC:/Users/OMAR/zephyrproject/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/Users/OMAR/zephyrproject/zephyr/lib/libc/minimal/include -IC:/Users/OMAR/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -IC:/Users/OMAR/zephyrproject/modules/hal/nordic/nrfx -IC:/Users/OMAR/zephyrproject/modules/hal/nordic/nrfx/drivers/include -IC:/Users/OMAR/zephyrproject/modules/hal/nordic/nrfx/mdk -IC:/Users/OMAR/zephyrproject/zephyr/modules/hal_nordic/nrfx/. -IC:/Users/OMAR/zephyrproject/modules/debug/segger/SEGGER -IC:/Users/OMAR/zephyrproject/modules/debug/segger/Config -IC:/Users/OMAR/zephyrproject/zephyr/modules/segger/. -Ic:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include -Ic:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include-fixed -DKERNEL -D__ZEPHYR__=1 -D_FORTIFY_SOURCE=2 -DBUILD_VERSION=zephyr-v2.6.0-663-g4ad79bb609be -D__PROGRAM_START -DNRF52832_XXAA -DNRF52832_XXAA -Os -imacros C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros C:/Users/OMAR/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/Users/OMAR/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/Users/OMAR/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -isystemC:/Users/OMAR/zephyrproject/zephyr/lib/libc/minimal/include -isystemc:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include -isystemc:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include-fixed" && "C:\Program Files\CMake\bin\cmake.exe" -E touch C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib/src/mylib_project-stamp/mylib_project-build"
mkdir -p C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib/obj C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib/lib
The syntax of the command is incorrect.
make: *** [all] Error 1
[2/142] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'C:\Users\OMAR\zephyrproject\zephyr\samples\application_development\external_lib\build'


Thanks


Re: Dev-Review Meeting Agenda Sept 9th

Bolivar, Marti
 


From: devel@... <devel@...> on behalf of Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@...>
Sent: Wednesday, September 8, 2021 10:02 AM
To: devel <devel@...>
Cc: Marull, Gerard <gerard.marull@...>; Erwan Gouriou <erwan.gouriou@...>
Subject: [Zephyr-devel] Dev-Review Meeting Agenda Sept 9th
 
PINCTRL:
  - devicetree description (option 1 vs option 3)

    Option1 (grouping by device):
    NRF: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fgmarull%2Fe2afed5c97a188f3830ff0bd59d3d3ae&amp;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C166a6b8c438849649be008d972ea8828%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637667173911869513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=np7sKz42jb%2FwCq3lv2mJvx8b2BbwLxJtg5vqXkr2FxY%3D&amp;reserved=0
    NXP: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fgalak%2Fa3c021d8052e58c818d4df60c981558c&amp;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C166a6b8c438849649be008d972ea8828%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637667173911869513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=lstQAmYLPhryqZbB72qn%2Fpej91bowQOOmkjBdfmp0tQ%3D&amp;reserved=0

    Option3 (grouping by pin):
    NRF: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fgmarull%2F6993e3eacad1b0d7c00c1ea2f16c3a12&amp;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C166a6b8c438849649be008d972ea8828%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637667173911879471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FAAZAPUoq1mEJfjJV9b2KEl4RCIf44ulF4bYl%2BDmjto%3D&amp;reserved=0
    NXP: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fgalak%2Ffb558ef83203db69b9ad983bd39b5d71&amp;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C166a6b8c438849649be008d972ea8828%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637667173911879471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=lLwzURnxykr63bLlC2IbdjMbiFyXBIX%2Bwdu6CdvetNw%3D&amp;reserved=0
 
  - API discussion

  - https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fdiscussions%2F35077&amp;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C166a6b8c438849649be008d972ea8828%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637667173911879471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3b1rv%2F0VgCHo5uarvge6CDoC96XVsc8QZ1U9o48pV1A%3D&amp;reserved=0

drivers: regulator: convert to gpio_dt_spec
- https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F37689&amp;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C166a6b8c438849649be008d972ea8828%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637667173911879471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FhMOb10KltcSJSMj1KZ%2Bu6Sqvu8aSs%2B1fF7JkUq3HdE%3D&amp;reserved=0

Plus anything anyone else has.

- k







Re: Unknown origin of error

markus.prager@...
 

Alright, so thanks to Nick (thank you!) I have now narrowed down my problem a little.

as a background, here is the C code that is causing the issue (i marked the error-origin in fat characters):

#define LIS3DHH_SPI_CFG(inst)                         \
    (&(struct lis3dhh_spi_cfg){                       \
        .spi_conf = {                                 \
            .frequency =                              \
              DT_INST_PROP(inst, clock_frequency),  \
            .operation = (SPI_WORD_SET(8) |           \
                          SPI_OP_MODE_MASTER |        \
                          SPI_MODE_CPOL |             \
                          SPI_MODE_CPHA),             \
            .slave = DT_INST_REG_ADDR(inst),          \
            .cs = LIS3DHH_SPI_CS_PTR(inst),           \
        },                                            \
        .cs_gpios_label = LIS3DHH_SPI_CS_LABEL(inst), \
    })


So the problem is the devicetree that i am trying to use. Nick suggested i move the "spi-max-frequency" from the lis3dhh device to the spi2 node (like the spi yaml file suggests -> dts/bindings/spi/spi-device.yaml). So something like this:

&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";
    spi-max-frequency = <10000000>; /*max. 10MHz*/
 
    lis3dhh: lis3dhh@11 {
        compatible = "st,lis3dhh","st,spi_lis3dhh";
        reg = <0x11>;
        label = "LIS3DHH";
        int1-gpios = <&gpioc 7 GPIO_ACTIVE_HIGH>; /*PC7*/
        int2-gpios = <&gpioc 8 GPIO_ACTIVE_HIGH>;  /*PC8 */
    };
};


However, this lead me to realize that my devicetree does not access the normal spi-device.yaml but rather the st,stm32-spi.yaml which is accessing  st,stm32-spi-common.yaml .
Now this file is not actually demanding a "spi-max-frequency" value at all. Though spi-controller.yaml it is possible to assign it a clock-frequency though.

So what I have tried now is adding that clock-frequency in both my code and in the devicetree. Now when i try that, i get the following error (i tried both options of adding it under the lis3dhh device and the spi node):

/home/markus/driver_test_lis3dhh/my-workspace/iots-fiso-id-p2-zephyr/build/zephyr/include/generated/devicetree_unfixed.h:24461:36: error: 'DT_N_S_soc_S_spi_40003800_S_lis3dhh_11_P_clock_frequency' undeclared here (not in a function); did you mean 'DT_N_S_soc_S_spi_40003800_S_lis3dhh_11_P_compatible'?
24461 | #define DT_N_INST_0_st_lis3dhh     DT_N_S_soc_S_spi_40003800_S_lis3dhh_11

I also tried editing st,stm32-spi-common.yaml to include an spi-max-frequency value.
Here I get the following error:

/home/markus/driver_test_lis3dhh/my-workspace/iots-fiso-id-p2-zephyr/build/zephyr/include/generated/devicetree_unfixed.h:24461: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_P_spi_max_frequency'?
24461 | #define DT_N_INST_0_st_lis3dhh     DT_N_S_soc_S_spi_40003800_S_lis3dhh_11

So I guess there is an issue with me trying to access the wrong level of the devicetree? If I understand the error correctly, it is telling me that I am trying to access spi-max-frequency on the lis3dhh device (which i also gave that attribute by the way) but that does not exist and I should rather address the spi node's spi-max-frequency.
Now I don't really understand how I change this. Either accessing the node's spi-max-frequency or how to tell the devicetree to use the lis3dhh's spi-max-frequency attribute.


Again, I am very thankful for any advice.
Cheers,
Markus


Power sequencing and driver intialisation

Glenn Andrews
 

Hi All,

We're building a custom board with a no-standard power sequence.

The processor and a TCA6418 GPIO expander come up first on a low-current 1V8 supply. The TCA6418 controls the enable pins for all the power regulators in the system, including the high-current 1V8 that powers the rest of the devices connected to the processor.

So order of initialization will be:
  1. A single I2C bus
  2. TCA6418
  3. Enable other regulators and wait a bit
  4. All other external devices, including other devices on the I2C bus.

Is it possible to do this using just the priority levels in the drivers?

For legacy reasons we're using Zephyr v2.3.0 and are unlikely to be able to upgrade to a newer version any time soon.

Thanks,

Glenn


Problem when building external_lib sample

Omar Morceli
 

hi 

i'm facing a problem when i building the external_lib sample 


> west build -b nrf52dk_nrf52832                      
[1/142] Performing build step for 'mylib_project'
FAILED: mylib/src/mylib_project-stamp/mylib_project-build mylib/lib/libmylib.a
cmd.exe /C "cd /D C:\Users\OMAR\zephyrproject\zephyr\samples\application_development\external_lib\mylib && make PREFIX=C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib "CC=C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2020-q4-major/bin/arm-none-eabi-gcc.exe" "AR=C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2020-q4-major/bin/arm-none-eabi-ar.exe" "CFLAGS=-IC:/Users/OMAR/zephyrproject/zephyr/include -IC:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/zephyr/include/generated -IC:/Users/OMAR/zephyrproject/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/Users/OMAR/zephyrproject/zephyr/lib/libc/minimal/include -IC:/Users/OMAR/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -IC:/Users/OMAR/zephyrproject/modules/hal/nordic/nrfx -IC:/Users/OMAR/zephyrproject/modules/hal/nordic/nrfx/drivers/include -IC:/Users/OMAR/zephyrproject/modules/hal/nordic/nrfx/mdk -IC:/Users/OMAR/zephyrproject/zephyr/modules/hal_nordic/nrfx/. -IC:/Users/OMAR/zephyrproject/modules/debug/segger/SEGGER -IC:/Users/OMAR/zephyrproject/modules/debug/segger/Config -IC:/Users/OMAR/zephyrproject/zephyr/modules/segger/. -Ic:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include -Ic:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include-fixed -DKERNEL -D__ZEPHYR__=1 -D_FORTIFY_SOURCE=2 -DBUILD_VERSION=zephyr-v2.6.0-663-g4ad79bb609be -D__PROGRAM_START -DNRF52832_XXAA -DNRF52832_XXAA -Os -imacros C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros C:/Users/OMAR/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/Users/OMAR/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/Users/OMAR/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -isystemC:/Users/OMAR/zephyrproject/zephyr/lib/libc/minimal/include -isystemc:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include -isystemc:/program files (x86)/gnu arm embedded toolchain/10 2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/include-fixed" && "C:\Program Files\CMake\bin\cmake.exe" -E touch C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib/src/mylib_project-stamp/mylib_project-build"
mkdir -p C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib/obj C:/Users/OMAR/zephyrproject/zephyr/samples/application_development/external_lib/build/mylib/lib
The syntax of the command is incorrect.
make: *** [all] Error 1
[2/142] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'C:\Users\OMAR\zephyrproject\zephyr\samples\application_development\external_lib\build'


Thanks


Event: Zephyr Project: Dev Meeting - 09/09/2021 #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

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

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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: Why do_swap() sets cpu.current before context switch?

Yasushi SHOJI
 

Hi,

On Thu, Sep 9, 2021 at 12:01 AM Katsuhiro Suzuki
<katsuhiro@...> wrote:
On 2021/09/08 16:22, Yasushi SHOJI wrote:
On Wed, Sep 8, 2021 at 10:23 AM Katsuhiro Suzuki <katsuhiro@...> wrote:
Why do you `use _current_cpu` at all? `_arch_switch()` or
`arch_switch()` on the main branch takes
both new and old thread handles.
Because to keep consistency for another context switching (by preemption) and
other interrupts.
Only _current_cpu.current is available when an interrupt occurred.
The reason why we set _current to the new thread is that we can't set it after
we switch to the new thread. The newly switched thread will just start
running from
the point it left off. Otherwise, we have to make sure that each and
every arch must
set _current to the new thread in `arch_switch()`.

At an IRQ, you know the `_current` is the currently executing thread and you can
get a new thread from ready_q, if needed.
At explicit switch, you are given both old and new threads.
So in both cases, we _can_ implement the switch.

I agree that we need to do similar things for arch_switch and irq, and
love to use
exact same code for both, but it might be better to have separate code for
each situation. Or, at least use .macro to construct parts of it.

ps. Unfortunately, unlike the Linux kernel, we don't have any way to
get the thread struct
from a stack pointer, IIRC.

just my 2 cents,
--
yashi


Dev-Review Meeting Agenda Sept 9th

Kumar Gala
 


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

Andy Ross
 

On 9/8/2021 8:08 AM, Katsuhiro Suzuki wrote:
RISC-V's FPU arch has the flag to permit/forbid using FPU. In Zephyr, this flag is set to
forbid side if thread was declared as not using FPU. And CPU raise interrupt when using
any FPU instruction at FPU forbidden state.

Can't you just check that flag in the context switch code?  It seems like that would be faster on average (most DSP workloads try very hard to avoid doing synchronous context switches to avoid the need to spill all that state), and have much better latency guarantees (taking an exception is REALLY expensive!).

Andy


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

Katsuhiro Suzuki
 

Hello,

On 2021/09/08 11:35, andy-intel@... wrote:
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.
Thanks for your advice.

Current RISC-V implementation (CONFIG_USE_SWITCH=n) is using 'ecall' (this is
SW interrupt instruction) to execute context switching explicitly.

And jump into interrupt handler that is used from not only SW interrupt but also
other interrupts. In interrupt handler, kernel saves FPU registers of current thread
that is pointing old thread.

I agree with you that I can add special path for explicit context switching.
If such path is needed, I will add that.


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.)
In my understanding, RISC-V has not supported lazy-saved FPU yet. Always need to save
FPU registers at the beginning of interrupt handler.

RISC-V's FPU arch has the flag to permit/forbid using FPU. In Zephyr, this flag is set to
forbid side if thread was declared as not using FPU. And CPU raise interrupt when using
any FPU instruction at FPU forbidden state.


Andy
Best Regards,
Katsuhiro Suzuki



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

Katsuhiro Suzuki
 

Hello,

Thank you for reply.


On 2021/09/08 16:22, Yasushi SHOJI wrote:
Hi,
On Wed, Sep 8, 2021 at 10:23 AM Katsuhiro Suzuki
<katsuhiro@...> wrote:
I have question about newer version of context switching (CONFIG_USE_SWITCH=y).
Does RISC-V support USE_SWITCH?
Currently, No. I'm trying to add a support for CONFIG_USE_SWITCH=y case.


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...
AFAICS, even with v1.11, we are setting `_current` to `new_thread` in
`_Swap()` before calling `_arch_switch()`.
What version are you referring to as "older"?
Sorry for confusing. Older means CONFIG_USE_SWITCH=n.
Does not means Zephyr's version.


Why do you `use _current_cpu` at all? `_arch_switch()` or
`arch_switch()` on the main branch takes
both new and old thread handles.
Because to keep consistency for another context switching (by preemption) and
other interrupts.
Only _current_cpu.current is available when an interrupt occurred.


Best,
Best Regards,
Katsuhiro Suzuki


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

Yasushi SHOJI
 

Hi,

On Wed, Sep 8, 2021 at 10:23 AM Katsuhiro Suzuki
<katsuhiro@...> wrote:
I have question about newer version of context switching (CONFIG_USE_SWITCH=y).
Does RISC-V support USE_SWITCH?

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...
AFAICS, even with v1.11, we are setting `_current` to `new_thread` in
`_Swap()` before calling `_arch_switch()`.
What version are you referring to as "older"?

Why do you `use _current_cpu` at all? `_arch_switch()` or
`arch_switch()` on the main branch takes
both new and old thread handles.

Best,
--
yashi


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

761 - 780 of 8778