1. users@lists.zephyrproject.org
  2. Messages
   Date   
Re: DTS own node DT_N_S_ undeclared

Kumar Gala
 

On Mar 5, 2021, at 11:26 AM, Piotr Barszczewski <piotr@1am.pl> wrote:

Hello,

Thank you for your response. My code is very similar to https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/boards/nrf/battery/src/battery.c with the change that I’ve refactored it to accept different instances instead of supporting single #define VBATT DT_PATH(vbatt) . It’s practically 1:1 with what I needed so it seemed more reasonable to approach this way.

Regarding #define VBATT_LIPO DT_NODELABEL(vbatt_lipo) and #define VBATT_LIPO DT_PATH(vbatt, vbatt0) I’ve tried this but the result is that in the end

/* Existence and alternate IDs: */
#define DT_N_S_vbatt_S_vbatt0_EXISTS 1
#define DT_N_INST_0_voltage_divider DT_N_S_vbatt_S_vbatt0
#define DT_N_NODELABEL_vbatt_lipo DT_N_S_vbatt_S_vbatt0

Always points to non-existing DT_N_S_vbatt_S_vbatt0. It’s not clear to me where it should it be defined if not from DTS.

Best regards
So you are seeing correct behavior. The are several ways to get a NODE reference (DT_PATH and DT_NODELABEL) are 2 of them. They should expand to DT_N_S_vbatt_S_vbatt0. (This is meant to be concatenated with other identifies to resolve to an actual define in the generated header - via the macros on devicetree.h). It will not resolve to a meaningful value that can be compiled by itself.

It has to be used in connection with another macro in devicetree.h to get some data from the dts node.

For example if you wanted the "output-ohms” for vbatt0 you’d do something like:

int out_ohms = DT_PROP(VBATT_LIPO, output_ohms);

That would resolve to:

int out_ohms = 3300000;

- k
Re: DTS own node DT_N_S_ undeclared

Piotr Barszczewski <piotr@...>
 

Hello,

Thank you for your response. My code is very similar to https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/boards/nrf/battery/src/battery.c with the change that I’ve refactored it to accept different instances instead of supporting single #define VBATT DT_PATH(vbatt) . It’s practically 1:1 with what I needed so it seemed more reasonable to approach this way.

Regarding #define VBATT_LIPO DT_NODELABEL(vbatt_lipo)  and #define VBATT_LIPO DT_PATH(vbatt, vbatt0) I’ve tried this but the result is that in the end 

/* Existence and alternate IDs: */
#define DT_N_S_vbatt_S_vbatt0_EXISTS 1
#define DT_N_INST_0_voltage_divider DT_N_S_vbatt_S_vbatt0
#define DT_N_NODELABEL_vbatt_lipo   DT_N_S_vbatt_S_vbatt0

Always points to non-existing DT_N_S_vbatt_S_vbatt0. It’s not clear to me where it should it be defined if not from DTS.

Best regards
Re: DTS own node DT_N_S_ undeclared

Kumar Gala
 

On Mar 5, 2021, at 9:55 AM, Piotr Barszczewski <piotr@1am.pl> wrote:

Hello,

I'm writing an application for nrf52832 based board ADC + voltage divider functionalty as in the great nRF battery example https://docs.zephyrproject.org/latest/samples/boards/nrf/battery/README.html. I'm adapting it to support multiple vbatt nodes from DTS and while on the code layer it's quite simple I'm struggling with the DTS.

My board dts file contains this part:

#include <nordic/nrf52832_qfaa.dtsi>
/ {
model = "vendor my_board";
compatible = nordic,nrf52832-qfaa","nordic,nrf52832";
// ...
vbatt {
vbatt_lipo: vbatt0 {
compatible = "voltage-divider";
io-channels = <&adc 6>; /* P0.30 = AIN6 */
output-ohms = <3300000>;
full-ohms = <(3300000 + 4700000)>;
status = "okay";
};
vbatt_cr: vbatt1 {
compatible = "voltage-divider";
io-channels = <&adc 1>; /* P0.03 = AIN1 */
output-ohms = <3300000>;
full-ohms = <(3300000 + 4700000)>;
status = "okay";
};
};
// ...
};

The devicetree snippet seems ok

/* Existence and alternate IDs: */
#define DT_N_S_vbatt_S_vbatt0_EXISTS 1
#define DT_N_INST_0_voltage_divider DT_N_S_vbatt_S_vbatt0
#define DT_N_NODELABEL_vbatt_lipo DT_N_S_vbatt_S_vbatt0

except for the DT_N_S_vbatt_S_vbatt0 which is not defined anywhere and as a result I'm getting:

zephyr/include/devicetree.h:73:17: error: 'DT_N_S_vbatt_S_vbatt_lipo' undeclared here (not in a function); did you mean 'DT_N_S_vbatt_S_vbatt_lipo_ORD'?

What else should I do to make my own DTS node be usable in the source file? I'm following the docs, referencing it by #define VBATT_LIPO DT_PATH(vbatt, vbatt_lipo) which is in line with the guides and docs but the DT_N_S_* is missing and I don't have a clue on how could I fix this.
Did anyone experience this before and could point me to where I could find a solution? Been trying for days now without result.

Oh, noticed your DT_PATH(batt, vbatt_lipo) is not correct.

Try:

#define VBATT_LIPO DT_PATH(batt, vbatt0)

or

#define VBATT_LIPO DT_NODELABEL(vbatt_lipo)

- k
Re: DTS own node DT_N_S_ undeclared

Kumar Gala
 

On Mar 5, 2021, at 9:55 AM, Piotr Barszczewski <piotr@1am.pl> wrote:

Hello,

I'm writing an application for nrf52832 based board ADC + voltage divider functionalty as in the great nRF battery example https://docs.zephyrproject.org/latest/samples/boards/nrf/battery/README.html. I'm adapting it to support multiple vbatt nodes from DTS and while on the code layer it's quite simple I'm struggling with the DTS.

My board dts file contains this part:

#include <nordic/nrf52832_qfaa.dtsi>
/ {
model = "vendor my_board";
compatible = nordic,nrf52832-qfaa","nordic,nrf52832";
// ...
vbatt {
vbatt_lipo: vbatt0 {
compatible = "voltage-divider";
io-channels = <&adc 6>; /* P0.30 = AIN6 */
output-ohms = <3300000>;
full-ohms = <(3300000 + 4700000)>;
status = "okay";
};
vbatt_cr: vbatt1 {
compatible = "voltage-divider";
io-channels = <&adc 1>; /* P0.03 = AIN1 */
output-ohms = <3300000>;
full-ohms = <(3300000 + 4700000)>;
status = "okay";
};
};
// ...
};

The devicetree snippet seems ok

/* Existence and alternate IDs: */
#define DT_N_S_vbatt_S_vbatt0_EXISTS 1
#define DT_N_INST_0_voltage_divider DT_N_S_vbatt_S_vbatt0
#define DT_N_NODELABEL_vbatt_lipo DT_N_S_vbatt_S_vbatt0

except for the DT_N_S_vbatt_S_vbatt0 which is not defined anywhere and as a result I'm getting:
That looks normal.


zephyr/include/devicetree.h:73:17: error: 'DT_N_S_vbatt_S_vbatt_lipo' undeclared here (not in a function); did you mean 'DT_N_S_vbatt_S_vbatt_lipo_ORD'?
What does the code you are building look like?

What else should I do to make my own DTS node be usable in the source file? I'm following the docs, referencing it by #define VBATT_LIPO DT_PATH(vbatt, vbatt_lipo) which is in line with the guides and docs but the DT_N_S_* is missing and I don't have a clue on how could I fix this.
Did anyone experience this before and could point me to where I could find a solution? Been trying for days now without result.
I think the .dts you have looks reasonable, my guess is the issue is more on the code usage side.

Your define of VBATT_LIPO will give you a node reference which by its self is not useful. Its useful only w/regards to the macros in include/devicetree.h

If you can share a snip of what the code looks like will probably be easier to see what might be the issue.

- k
DTS own node DT_N_S_ undeclared

Piotr Barszczewski <piotr@...>
 

Hello,

I'm writing an application for nrf52832 based board ADC + voltage divider functionalty as in the great nRF battery example https://docs.zephyrproject.org/latest/samples/boards/nrf/battery/README.html. I'm adapting it to support multiple vbatt nodes from DTS and while on the code layer it's quite simple I'm struggling with the DTS. 

My board dts file contains this part:

#include <nordic/nrf52832_qfaa.dtsi>
/ {
    model = "vendor my_board";
    compatible = nordic,nrf52832-qfaa","nordic,nrf52832";
    // ...
    vbatt {
        vbatt_lipo: vbatt0  {
            compatible = "voltage-divider";
            io-channels = <&adc 6>;    /* P0.30 = AIN6 */
            output-ohms = <3300000>;
            full-ohms = <(3300000 + 4700000)>;
            status = "okay";
        };
        vbatt_cr: vbatt1  {
            compatible = "voltage-divider";
            io-channels = <&adc 1>;    /* P0.03 = AIN1 */
            output-ohms = <3300000>;
            full-ohms = <(3300000 + 4700000)>;
            status = "okay";
        };
    };
    // ...
};

The devicetree snippet seems ok

/* Existence and alternate IDs: */
#define DT_N_S_vbatt_S_vbatt0_EXISTS 1
#define DT_N_INST_0_voltage_divider DT_N_S_vbatt_S_vbatt0
#define DT_N_NODELABEL_vbatt_lipo   DT_N_S_vbatt_S_vbatt0

except for the DT_N_S_vbatt_S_vbatt0 which is not defined anywhere and as a result I'm getting:

    zephyr/include/devicetree.h:73:17: error: 'DT_N_S_vbatt_S_vbatt_lipo' undeclared here (not in a function); did you mean 'DT_N_S_vbatt_S_vbatt_lipo_ORD'?

What else should I do to make my own DTS node be usable in the source file? I'm following the docs, referencing it by #define VBATT_LIPO DT_PATH(vbatt, vbatt_lipo) which is in line with the guides and docs but the DT_N_S_* is missing and I don't have a clue on how could I fix this.
Did anyone experience this before and could point me to where I could find a solution? Been trying for days now without result.

Best regards
Zephyr on VEGABoard - Can't flash the hello_world demo #flash #west #risc-v #vegaboard #rv32m1

jean-baptiste.edde@...
 

Hello,

I’m a student in electronics and I’m trying to use Zephyr on the VEGABoard, but I’m facing some issues.
I’ve been able to run some demos provided by openisa in the sdk, and modify some, using GPIOs, etc.
 
With Zephyr though, when I’m using the toolchain of the VEGABoard and build the Zephyr hello_wolrd example with “west build …”, I’ve got an error: “Can’t build a dummy C file”. But when I build using “cmake …” then “ninja”, it works.

I’ve tried with other toolchains and I’ve got no problems at all.
 
But the issue comes when I want to flash the Zephyr app on the VEGABoard (nothing appears on the serial terminal connected to port of openSDA), it doesn’t works. Here is what I get:

-- west flash: using runner openocd
-- runners.openocd: Flashing file: zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-00432-gfdd28b5a (2018-12-25-08:25)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : mohor tap selected
Info : adv debug unit selected
Info : Option 1 is passed to adv debug unit
Info : core 0 selected
Info : add flash_bank rv32m1 rv32m1.flash0
Info : add flash_bank rv32m1 rv32m1.flash1
core1_boot
Info : J-Link V9 compiled Feb  2 2021 16:34:10
Info : Hardware version: 9.30
Info : VTarget = 3.264 V
Info : clock speed 1000 kHz
Info : JTAG tap: rv32m1.cpu tap/device found: 0x249511c3 (mfg: 0x0e1 (Wintec Industries), part: 0x4951, ver: 0x2)
Info : adv debug unit is configured with option ADBG_USE_HISPEED
Info : Listening on port 3333 for gdb connections
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* rv32m1.cpu         rv32m1     little rv32m1.cpu         running
Info : JTAG tap: rv32m1.cpu tap/device found: 0x249511c3 (mfg: 0x0e1 (Wintec Industries), part: 0x4951, ver: 0x2)
auto erase enabled
wrote 1048576 bytes from file zephyr/zephyr.hex in 24.739641s (41.391 KiB/s)
Info : JTAG tap: rv32m1.cpu tap/device found: 0x249511c3 (mfg: 0x0e1 (Wintec Industries), part: 0x4951, ver: 0x2)
verified 1048484 bytes in 12.324958s (83.076 KiB/s)
Info : JTAG tap: rv32m1.cpu tap/device found: 0x249511c3 (mfg: 0x0e1 (Wintec Industries), part: 0x4951, ver: 0x2)
shutdown command invoked
Warn : Flash driver of rv32m1.flash0 does not support free_driver_priv()
Warn : Flash driver of rv32m1.flash1 does not support free_driver_priv()
I’ve tried with both the RI5CY and ZERO_RISCY cores.
  • Config: Windows 10
  • BOARD: VEGABoard
  • Cores: RI5CY and ZERO_RSCY
 
Could you help me figure out where the problem is and how it can be fixed please?

Thank you
Re: BlueZ PHY CODED scan via HCI UART on nRF52840_pca10056 #ble #nrf52840 #uart #hci

arne@...
 

With a 5.10.11 linux kernel and bluez-5.55, setting PHY in btmgmt still doesn't work due to a bug in the kernel. You can easily work around that by using hcitool:


# set default phy to encoded
hcitool -i hci0 cmd 08 31 03 04 04 


after which btmgmt reports the correct phy:

[mgmt]# phy

Supported phys: LE1MTX LE1MRX LE2MTX LE2MRX LECODEDTX LECODEDRX

Configurable phys: LE2MTX LE2MRX LECODEDTX LECODEDRX

Selected phys: LECODEDTX LECODEDRX

Then I had to change some zephyr code to report support for extended scan parameters and LE extended creation connection:

diff --git a/subsys/bluetooth/controller/hci/hci.c b/subsys/bluetooth/controller/hci/hci.c

index 82c7785068..a46a6680f9 100644

--- a/subsys/bluetooth/controller/hci/hci.c

+++ b/subsys/bluetooth/controller/hci/hci.c

@@ -671,6 +671,11 @@ static void read_supported_commands(struct net_buf *buf, struct net_buf **evt)

      BIT(6) | BIT(7);

  /* LE Remove Adv Set, LE Clear Adv Sets */

  rp->commands[37] |= BIT(0) | BIT(1);

+

+ /* LE Set Extended Scan Parameters, set extended scan enable */

+ rp->commands[37] |= BIT(5) | BIT(6);

+ /* LE Extended Create Connection */

+ rp->commands[37] |= BIT(7);

 #endif /* CONFIG_BT_CTLR_ADV_EXT */

 #endif /* CONFIG_BT_BROADCASTER */

 
With all this, I can only see some coded PHY extended advertisements.  The Nordic long range demo running on an nRF52840 dk in EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED mode for example shows up:

[bluetooth]# scan on

Discovery started

[CHG] Controller F7:7C:28:9D:3F:43 Discovering: yes

[CHG] Device DA:BC:1B:2C:89:2D RSSI: -46

[CHG] Device DA:BC:1B:2C:89:2D RSSI: -63

HCI Event: LE Meta Event (0x3e) plen 42                                                                                                                                                                          #1148 [hci0] 82955.304690

      LE Extended Advertising Report (0x0d)

        Num reports: 1

        Entry 0

          Event type: 0x0021

            Props: 0x0001

              Connectable

            Data status: Incomplete, more data to come

          Address type: Random (0x01)

          Address: DA:BC:1B:2C:89:2D (Static)

          Primary PHY: LE Coded

          Secondary PHY: LE Coded

          SID: 0x00

          TX power: 127 dBm

          RSSI: -45 dBm (0xd3)

          Periodic advertising invteral: 0.00 msec (0x0000)

          Direct address type: Public (0x00)

          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)

          Data length: 0x10

        02 01 06 0f 09 4e 6f 72 64 69 63 5f 41 54 54 5f  .....Nordic_ATT_

@ MGMT Event: Device Found (0x0012) plen 14                                                                                                                                                                     {0x0002} [hci0] 82955.311211

        LE Address: 00:00:00:00:00:00 (OUI 00-00-00)

        RSSI: 0 dBm (0x00)

        Flags: 0x00000000

        Data length: 0


It kinda feels like the advertisements are being buffered or blocked somewhere; you can be scanning for several seconds and get nothing, only for 5 to arrive at the same time (in btmon). And not all coded PHY advertisers show up.

Arne
Re: Using the Cortex M4 on IMX7D

Arnaud POULIQUEN
 

Hi,




Hey Arnaud,

Thanks for your reply.

I've seen that stm32_rproc driver has additionally functions within static const
struct rproc_ops st_rproc_ops
https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/stm32_rpro
c.c#L544
especially

.parse_fw = stm32_rproc_parse_fw,

within the plain rproc driver

rproc->ops->parse_fw = rproc_elf_load_rsc_table

is registerd within "static int rproc_alloc_ops()"
This is the generic elf parser functions that are available here:
https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_elf_loader.c


https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/remoteproc
_core.c#L2202

and is called by doing the "echo start" command.
Have you specified the firmware name?

Here is the sequence to load a firmware from Linux user application:
cp $1 /lib/firmware/
echo $1> /sys/class/remoteproc/remoteproc0/firmware
echo start >/sys/class/remoteproc/remoteproc0/state

with $1 is the firmware to load


https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/remoteproc
_elf_loader.c#L359


but fails after the find_table() function.
This function return NULL or the address of the resource table, but not return an error
Do you have a kernel error message ?


so if i just skip that for a test in
https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/remoteproc
_core.c#L1464,
does that take me over the point?
I can not see the code where rproc actually "loads" the firmware to the M4?

This is mainly done in https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_elf_loader.c

Regards,
Arnaud


best regards and a great weekend
Michael
#nrf5340 #dts #nrf5340 #dts

mohamed.belaroussi@...
 

Hello,
I am getting this error 
Error: nrf5340pdk_nrf5340_cpuapp.dts.pre.tmp:710.1-6 Label or path temp not found 
when I try to load a project in SES v5.34a (File  > Open nRF Connect SDK Project ...).

Here is the complete log from SES Output window,

Creating solution spi_test_LR1110-2-TX-RX-CMAC-AES.emProject
C:/Zypher/v1.5.0-rc1/toolchain/opt/bin/cmake.exe -GNinja -DBOARD=nrf5340pdk_nrf5340_cpuapp -DBOARD_DIR=C:\Zypher\v1.5.0-rc1\zephyr\boards\arm\nrf5340dk_nrf5340 -BC:\Dev\PID-4\spi_test_LR1110-2-TX-RX-CMAC-AES\build_nrf5340pdk_nrf5340_cpuapp_Zypher_v1.50rc1_temp -SC:\Dev\PID-4\spi_test_LR1110-2-TX-RX-CMAC-AES -DNCS_TOOLCHAIN_VERSION=1.5.0 -DDTC_OVERLAY_FILE=C:\Dev\PID-4\spi_test_LR1110-2-TX-RX-CMAC-AES/nrf5340pdk_nrf5340_cpuapp.overlay -DEXTRA_KCONFIG_TARGETS=menuconfig_ses -DEXTRA_KCONFIG_TARGET_COMMAND_FOR_menuconfig_ses=C:\Zypher\v1.5.0-rc1\toolchain\segger_embedded_studio/html/configure_nordic_project_menuconfig.py
-- Application: C:/Dev/PID-4/spi_test_LR1110-2-TX-RX-CMAC-AES
-- Zephyr version: 2.4.99 (C:/Zypher/v1.5.0-rc1/zephyr)
-- Found Python3: C:/Zypher/v1.5.0-rc1/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter 
-- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
-- Board: nrf5340pdk_nrf5340_cpuapp
-- Cache files will be written to: C:/Zypher/v1.5.0-rc1/zephyr/.cache
-- Found dtc: C:/Zypher/v1.5.0-rc1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/Zypher/v1.5.0-rc1/toolchain/opt)
-- Found BOARD.dts: C:/Zypher/v1.5.0-rc1/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340pdk_nrf5340_cpuapp.dts
-- Found devicetree overlay: C:/Dev/PID-4/spi_test_LR1110-2-TX-RX-CMAC-AES/nrf5340pdk_nrf5340_cpuapp.overlay
-- Configuring incomplete, errors occurred!
Including boilerplate (Zephyr base): C:/Zypher/v1.5.0-rc1/zephyr/cmake/app/boilerplate.cmake
-- Using NCS Toolchain 1.5.0 for building. (C:/Zypher/v1.5.0-rc1/toolchain/cmake)
Error: nrf5340pdk_nrf5340_cpuapp.dts.pre.tmp:710.1-6 Label or path temp not found
FATAL ERROR: Syntax error parsing input tree
CMake Error at C:/Zypher/v1.5.0-rc1/zephyr/cmake/dts.cmake:205 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  C:/Zypher/v1.5.0-rc1/zephyr/cmake/app/boilerplate.cmake:533 (include)
  C:/Zypher/v1.5.0-rc1/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  C:/Zypher/v1.5.0-rc1/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
  CMakeLists.txt:15 (find_package)
 
error: cmake failed
create_nordic_project.py failed (1)

Thank you for your help.

Kind regards
Mohamed
Bluetooth support adafruit feather sense

Dimitrios Kosyvas <kosyvas14828@...>
 

Hello

I am trying to communicate via Bluetooth using the adafruit feather sense board but i only manage to connect with the device and i am not able to send or receive any data with the nrfconnect application . Could you give me some advice or if there is an working example i would appreciate it



Dimitris Kosyvas
Re: LTS schedule and scope meeting on Tuesday, 23rd February

Carles Cufi
 

Hi all,

This meeting will be continued today.

When: Tuesday, 2nd March, 17:00 UTC (18:00 CET, 12PM EST, 11AM CST, 9AM PST)
Where: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%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

Carles

-----Original Message-----
From: Cufi, Carles
Sent: 18 February 2021 11:20
To: devel@lists.zephyrproject.org; tsc@lists.zephyrproject.org;
users@lists.zephyrproject.org
Cc: Brett Preston <bpreston@linuxfoundation.org>
Subject: LTS schedule and scope meeting on Tuesday, 23rd February

Hi all,

As you probably know, on Tuesdays we have two regularly scheduled
meetings:

- API meeting (17:00 UTC)
- Bug triage and Release Readiness meeting (18:00 UTC)

This week however, we will hold a special one-off meeting to discuss the
schedule and scope of the next LTS release.
The meeting will be open to everyone and will last two hours.

When: Tuesday, 23rd February, 17:00 UTC (18:00 CET, 12PM EST, 11AM CST,
9AM PST)
Where: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

Thanks,

Carles
Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow Tue 2 Mar at 8AM PST / 17.00
CET.

Currently the agenda has one item:

* WiFi management supporting both offloaded and native driver

If there are any other network related topics you want to discuss,
please let me know.


Live Agenda/Minutes:
https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0/edit?usp=sharing

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

___________________________________________________________
Join Microsoft 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
)
+1 321-558-6518 ( tel:+1 321-558-6518,,458216365# ) United States,
Orlando (Toll)
Conference ID: 458 216 365#
Local numbers (
https://dialin.teams.microsoft.com/325d775d-c910-441e-90d0-353ebaa56cdd?id=458216365
) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) | Learn
more about Teams ( https://aka.ms/JoinTeamsMeeting ) | Meeting options
(
https://teams.microsoft.com/meetingOptions/?organizerId=841a7c92-7816-4faf-9887-5e334e88f6d8&tenantId=af0096d9-700c-411a-b795-b3dd7122bad2&threadId=19_meeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw@thread.v2&messageId=0&language=en-US
)


Cheers,
Jukka
Re: Using the Cortex M4 on IMX7D

Michael Graichen
 

Am 26.02.21 um 18:06 schrieb Arnaud POULIQUEN:
Hi,

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: vendredi 26 février 2021 17:27
To: Michael Graichen <michael.graichen@hotmail.com>
Cc: users@lists.zephyrproject.org; Arnaud POULIQUEN
<arnaud.pouliquen@st.com>
Subject: Re: [Zephyr-users] Using the Cortex M4 on IMX7D



On Feb 26, 2021, at 3:43 AM, Michael Graichen
<michael.graichen@hotmail.com> wrote:

Hey,

I have just started working on a IMX7D
(https://www.kontron.de/products/boards-and-standard-form-
factors/smarc/smarc-samx7.html) together with Zephyr I noticed that the
Colibri iMX7 Board has support for the Cortex M4.
So I've build an example by using:

cmake -GNinja -DBOARD=colibri_imx7d_m4 ../samples/basic/blinky

and tried to load that on the Cortex M4

echo -n zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
and
echo -n start > /sys/class/remoteproc/remoteproc0/state

Unfortunatly the start fails because the elf-file has no resource table.
I can select TOP ---> Additional libraries ---> [*] coprocessor
resource table within menuconfig but the resulting elf-file is still missing the
resource table.

What am i missing? How can a add a resource table to the elf-file?
The Linux remoteproc framework allows you to load a firmware without a resource table.
The resource table is useful only if you want to use the RPMsg protocol or a trace buffer.
So this should work, except if the IMX platform driver doesn't allow this....


best regards
Michael

I don’t believe the remoteproc loading was ever supported for the imx family
with zephyr. This is something you’d need to add support for. I think it might
be supported on the STM32 MP1 as an example. (I added Arnaud on CC as he
added the STM32 MP1 support).
Right, I think today only the stm32mp1 support the resource table in zephyr, but this should be enough generic to
be supported by another platform.
Anyway if you don't want to use RPMsg, probably better as a first step to understand why you
can not load a firmware without resource table.
Regards
Arnaud


For the i.mx I think you can load via u-boot and there’s a section in the zephyr
board docs here about it:

https://docs.zephyrproject.org/latest/boards/arm/colibri_imx7d_m4/doc/index.
html

- k


Hey Arnaud,

Thanks for your reply.

I've seen that stm32_rproc driver has additionally functions within static const struct rproc_ops st_rproc_ops
https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/stm32_rproc.c#L544
especially

.parse_fw = stm32_rproc_parse_fw,

within the plain rproc driver

rproc->ops->parse_fw = rproc_elf_load_rsc_table

is registerd within "static int rproc_alloc_ops()"

https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/remoteproc_core.c#L2202

and is called by doing the "echo start" command.

https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/remoteproc_elf_loader.c#L359


but fails after the find_table() function.

so if i just skip that for a test in https://elixir.bootlin.com/linux/v5.11.2/source/drivers/remoteproc/remoteproc_core.c#L1464, does that take me over the point?
I can not see the code where rproc actually "loads" the firmware to the M4?

best regards and a great weekend
Michael
Re: Using the Cortex M4 on IMX7D

Michael Graichen
 

Am 27.02.21 um 09:32 schrieb Marco Cavallini:
Hi,
I tested Zephyr with a Colibri i.MX7 and it works our of the box.
west build -p auto -b colibri_imx7d_m4 samples/philosophers
afterwards I loaded and run the binary using u-boot
--
Marco Cavallini - KOAN  - Italy

Thanks you you reply.

guess I will test that next week.

What Memory addresses did you use when you tested the "out of the Box" example?

Have a great weekend
Michael
Re: Using the Cortex M4 on IMX7D

Michael Graichen
 

Am 26.02.21 um 17:27 schrieb Kumar Gala:

On Feb 26, 2021, at 3:43 AM, Michael Graichen <michael.graichen@hotmail.com> wrote:

Hey,

I have just started working on a IMX7D (https://www.kontron.de/products/boards-and-standard-form-factors/smarc/smarc-samx7.html) together with Zephyr
I noticed that the Colibri iMX7 Board has support for the Cortex M4.
So I've build an example by using:

cmake -GNinja -DBOARD=colibri_imx7d_m4 ../samples/basic/blinky

and tried to load that on the Cortex M4

echo -n zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
and
echo -n start > /sys/class/remoteproc/remoteproc0/state

Unfortunatly the start fails because the elf-file has no resource table.
I can select TOP ---> Additional libraries ---> [*] coprocessor resource table within menuconfig
but the resulting elf-file is still missing the resource table.

What am i missing? How can a add a resource table to the elf-file?

best regards
Michael
I don’t believe the remoteproc loading was ever supported for the imx family with zephyr. This is something you’d need to add support for. I think it might be supported on the STM32 MP1 as an example. (I added Arnaud on CC as he added the STM32 MP1 support).
For the i.mx I think you can load via u-boot and there’s a section in the zephyr board docs here about it:
https://docs.zephyrproject.org/latest/boards/arm/colibri_imx7d_m4/doc/index.html
- k
Thanks for your reply.

This link was the reason why I thought to give it a try. But I'm using barebox as a bootloader right now, so I thought to test "the Linux way" first. I guess I will test u-boot next week.

I have looked over the boot instruction from the link.
u-boot is using the plain .bin file for loading the M4 while remoteproc is using the .elf file.

Is it right that all those environment variables, especially 'setenv m4addr 0x007f800' that are set in u-boot before booting the M4 should come out of the resource table when using remoteproc?

Do you have more information about how a resource table for the IMX7-M4 should look like?



Have a great weekend.
Michael
Re: Using the Cortex M4 on IMX7D

Marco Cavallini
 

Hi,
I tested Zephyr with a Colibri i.MX7 and it works our of the box.

west build -p auto -b colibri_imx7d_m4 samples/philosophers

afterwards I loaded and run the binary using u-boot

--
Marco Cavallini - KOAN  - Italy
Re: Using the Cortex M4 on IMX7D

Arnaud POULIQUEN
 

Hi,

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: vendredi 26 février 2021 17:27
To: Michael Graichen <michael.graichen@hotmail.com>
Cc: users@lists.zephyrproject.org; Arnaud POULIQUEN
<arnaud.pouliquen@st.com>
Subject: Re: [Zephyr-users] Using the Cortex M4 on IMX7D



On Feb 26, 2021, at 3:43 AM, Michael Graichen
<michael.graichen@hotmail.com> wrote:

Hey,

I have just started working on a IMX7D
(https://www.kontron.de/products/boards-and-standard-form-
factors/smarc/smarc-samx7.html) together with Zephyr I noticed that the
Colibri iMX7 Board has support for the Cortex M4.
So I've build an example by using:

cmake -GNinja -DBOARD=colibri_imx7d_m4 ../samples/basic/blinky

and tried to load that on the Cortex M4

echo -n zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
and
echo -n start > /sys/class/remoteproc/remoteproc0/state

Unfortunatly the start fails because the elf-file has no resource table.
I can select TOP ---> Additional libraries ---> [*] coprocessor
resource table within menuconfig but the resulting elf-file is still missing the
resource table.

What am i missing? How can a add a resource table to the elf-file?
The Linux remoteproc framework allows you to load a firmware without a resource table.
The resource table is useful only if you want to use the RPMsg protocol or a trace buffer.
So this should work, except if the IMX platform driver doesn't allow this....


best regards
Michael

I don’t believe the remoteproc loading was ever supported for the imx family
with zephyr. This is something you’d need to add support for. I think it might
be supported on the STM32 MP1 as an example. (I added Arnaud on CC as he
added the STM32 MP1 support).
Right, I think today only the stm32mp1 support the resource table in zephyr, but this should be enough generic to
be supported by another platform.
Anyway if you don't want to use RPMsg, probably better as a first step to understand why you
can not load a firmware without resource table.

Regards
Arnaud


For the i.mx I think you can load via u-boot and there’s a section in the zephyr
board docs here about it:

https://docs.zephyrproject.org/latest/boards/arm/colibri_imx7d_m4/doc/index.
html

- k
Re: Using the Cortex M4 on IMX7D

Kumar Gala
 

On Feb 26, 2021, at 3:43 AM, Michael Graichen <michael.graichen@hotmail.com> wrote:

Hey,

I have just started working on a IMX7D (https://www.kontron.de/products/boards-and-standard-form-factors/smarc/smarc-samx7.html) together with Zephyr
I noticed that the Colibri iMX7 Board has support for the Cortex M4.
So I've build an example by using:

cmake -GNinja -DBOARD=colibri_imx7d_m4 ../samples/basic/blinky

and tried to load that on the Cortex M4

echo -n zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
and
echo -n start > /sys/class/remoteproc/remoteproc0/state

Unfortunatly the start fails because the elf-file has no resource table.
I can select TOP ---> Additional libraries ---> [*] coprocessor resource table within menuconfig
but the resulting elf-file is still missing the resource table.

What am i missing? How can a add a resource table to the elf-file?

best regards
Michael

I don’t believe the remoteproc loading was ever supported for the imx family with zephyr. This is something you’d need to add support for. I think it might be supported on the STM32 MP1 as an example. (I added Arnaud on CC as he added the STM32 MP1 support).

For the i.mx I think you can load via u-boot and there’s a section in the zephyr board docs here about it:

https://docs.zephyrproject.org/latest/boards/arm/colibri_imx7d_m4/doc/index.html

- k
Using the Cortex M4 on IMX7D

Michael Graichen
 

Hey,

I have just started working on a IMX7D (https://www.kontron.de/products/boards-and-standard-form-factors/smarc/smarc-samx7.html) together with Zephyr
I noticed that the Colibri iMX7 Board has support for the Cortex M4.
So I've build an example by using:

cmake -GNinja -DBOARD=colibri_imx7d_m4 ../samples/basic/blinky

and tried to load that on the Cortex M4

echo -n zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
and
echo -n start > /sys/class/remoteproc/remoteproc0/state

Unfortunatly the start fails because the elf-file has no resource table.
I can select TOP ---> Additional libraries ---> [*] coprocessor resource table within menuconfig
but the resulting elf-file is still missing the resource table.

What am i missing? How can a add a resource table to the elf-file?

best regards
Michael
Re: openocd.conf default

Bolivar, Marti
 

Hi there,

You can read through the 'west flash -H -r openocd' output to see
what options you have for overriding the default behavior, but
the short answer is no, most of this is determined by the board.cmake
file.

If a particular board.cmake file is not correct, please file a bug.

You are of course free to ignore the default openocd runner entirely and
just run openocd yourself if you have settings you prefer.

HTH,
Martí

Gunnar Bråding via lists.zephyrproject.org
<gunnar=astrogator.se@lists.zephyrproject.org> writes:

Hi!

I might have missed something, but is there a way to set a default openocd.conf in the local application directory, or set some other file as the default? The board-specific ones are not necessarily correct. I even wonder if the debug settings are board specific, rather than user-specific?
Actually I personally would consider it nice to just use my general configuration when selecting probe and such.

Cheers,
— Gunnar Brading
221 - 240 of 2694