devel@lists.zephyrproject.org

SDK 0.11.1 Release

Kumar Gala

#6711

Hi,

Some minor fixes that got missed for the v0.11.0 release.  Mostly impacts OpenOCD and newlib usage.

The SDK can be found here:

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

Please download and try things out and report any issues.

OpenOCD:

	• Fixed missing commits from rebase - related to ARC and Zephyr RTOS awareness

Newlib:

	• Removed setting -DMISSING_SYSCALL_NAMES on builds.  Make syscall function names consistent and naming compatible with 3rd party GNU toolchains.

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

- k

Re: support for multi instance zephyr in same soc

Kumar Gala

#6710

This has been a long standing issue.  Since these are both ARM you can get away with doing something similar to how we handle building different images for SoCs that have 2 different M-class cores.

Look at boards/arm/lpcxpresso54114 for an example

- k

Show quoted text

On Jan 30, 2020, at 3:17 PM, Scott Branden <sbranden@gmail.com> wrote:

Hello,

We are currently running zephyr on M7 and linux on A72.

The base M7 support has been upstreamed here:
https://github.com/zephyrproject-rtos/zephyr/commit/54ce0b2d3464d44429108f436a528ece51f866ff

We are now looking at running Zephyr on A72 instead of linux.

But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?

Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?

In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....

Regards,
 Scott Branden

Re: clang toolchain doesn't failing to compile properly

Sigvart Hovland

#6709

What target are you trying to compile for?

From the stack overflow thread I find
Target: x86_64-pc-linux-gnu

Then some references to the Nordic HAL. So I’m just going to assume you are trying to target nrf52xx so what should be noted is that you can’t use the LLVM linker also I think you need to use the arm-none-eabi assembler also if you are targeting an ARM cortex-m platform.

I got it to compile with LLVM and GCC/GNU assembler/linker. You will have to add an config in the /home/zephyrproject/modules/hal/nordic/nrfx/mdk/compiler_abstraction.h:66 that you are using Clang (ARMCC > 6 is an ARM version of Clang) I think it’s something like __CLANG or it could be __llvm__ or __clang__.

Some discussion on it here:

https://github.com/zephyrproject-rtos/zephyr/pull/19120

Some of the changes are added here
https://github.com/zephyrproject-rtos/zephyr/pull/19218

Based on https://github.com/galak/zephyr/tree/llvm I believe.

I don’t have my old branch where I got it to build unfortunately so I don’t have anything direct to link too but was able to build and run hello world with clang + arm-none-eabi linker and assembler. Also I don’t remember the exact point in the code where I had to add a print for it to work. There was some in-line assembly which was optimized out by clang if it was not used so I added a print and it would work. Sorry for not being very helpful thought I would just give you some information.

Show quoted text

From: devel@... <devel@...> On Behalf Of Akira Kato via Lists.Zephyrproject.Org
Sent: Thursday, January 30, 2020 7:13 PM
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] clang toolchain doesn't failing to compile properly

Hi,

I don't know if this is the proper place to ask technical question about zephyr but I have tried stackoverflow and started github issue with no help. I am new to zephyr so I followed the getting started guide. Here's the post I made: https://stackoverflow.com/questions/59976179/zephyr-error-using-llvm-works-fine-with-default-toolchain

The problem is described there with the error logs.

Thanks,

Akira

support for multi instance zephyr in same soc

Scott Branden

#6708

Hello,

We are currently running zephyr on M7 and linux on A72.

The base M7 support has been upstreamed here:

https://github.com/zephyrproject-rtos/zephyr/commit/54ce0b2d3464d44429108f436a528ece51f866ff

We are now looking at running Zephyr on A72 instead of linux.

But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?

Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?

In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....

Regards,

Scott Branden

clang toolchain for zephyr doesn't failing to compile properly #gettingstartedguide

Akira Kato <akira.kato@...>

#6706

Hi,

I don't know if this is the proper place to ask technical question about zephyr but I have tried stackoverflow and started github issue with no help. I am new to zephyr so I followed the getting started guide. Here's the post I made: https://stackoverflow.com/questions/59976179/zephyr-error-using-llvm-works-fine-with-default-toolchain

The problem is described there with the error logs.

Thanks,

Akira

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 01/30/2020 8:00am-9:00am, Please RSVP #cal-reminder

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

#6704

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 30 January 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Dev Rev Meeting - Jan 30 2020 Agenda

Kumar Gala

#6703

NOTE: The cal invite has gotten messed up and might show the meeting starting a hour earlier than normal.  This is NOT correct, we are working on trying to correct the issue.  The meeting time is the same as always.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-dev-meeting

——

Today’s agenda will focus on Device Tree, including pinmux.

- k

first steps / debug #debug #nrf52480

Rafael Dias

#6702

Hi!

This is my first message to the Zephyr forum.

Well, I started to work with zephyr a few days ago. I followed the steps from the Getting Started Guide and I'd like to perform the debugging of the application that I`m developing.

After I reproduced the steps from the section "Eclipse Debugging", I cold open the project at the Eclipse. The debugging "is working" but I not able to configure the breakpoints to any file at the project.

Has anyone here had this same kind of problem?

and...

How do you go about debugging an application?

best regards,

Rafael Dias

Re: Updated Event: Zephyr Project: Dev Meeting #cal-invite

Justin

#6701

On Wed, Jan 29, 2020 at 7:08 AM devel@... Calendar <devel@...> wrote:

Zephyr Project: Dev Meeting

When:
Thursday, 2 May 2019
8:00am to 9:00am
(UTC-07:00) America/Los Angeles
Repeats: Weekly on Thursday

Where:
https://zoom.us/j/993312203

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Updated Event: Zephyr Project: Dev Meeting #cal-invite

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

#6700

Zephyr Project: Dev Meeting

When:
Thursday, 2 May 2019
8:00am to 9:00am
(UTC-07:00) America/Los Angeles
Repeats: Weekly on Thursday

Where:
https://zoom.us/j/993312203

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Calendar

Upcoming Event: Zephyr Project: APIs - Tue, 01/28/2020 9:00am-10:00am, Please RSVP #cal-reminder

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

#6699

Reminder: Zephyr Project: APIs

When: Tuesday, 28 January 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878#
Or Telephone:
    Dial(for higher quality, dial a number based on your current location):
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY

Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

Re: ARM Cortex R intermittent MPU memory access check failures with CONFIG_USERSPACE

Glaropoulos, Ioannis

#6698

+ Andrew, Stephanos

Hi Phil,

Thanks for reporting this. I need to do a more careful looking into it, but it is likely that you have spotted a bug in the Cortex-M implementation.

The implementation of mpu_buffer_validate() has not changed since its initial porting – it seems that it does not protect writing RNR and then accessing RBAR, RASR registers aferwards and that seems to have always been the case.

So a thread context-switch interrupting this operation may modify the RNR register, making the read of RBAR, RASR or RLAR (v8m) inside the functions called by mpu_buffer_validate() invalid.

If mpu_buffer_validate() is called by thread supervisor mode, it needs to be protected by locking IRQs. In fact, only the PendSV needs to be lock because only that one does MPU reprogramming.

Alternatively RNR could be saved and restored in PendSV handler (normal IRQs do not touch MPU).

I’d appreciate if you file a bug report for this for Cortex-M.

For Cortex-R, user mode is not assumed to be working (yet) so, strictkly speaking, it is not a bug, but if you work on Cortex-R user mode, this is one thing you need to consider!

Ioannis

Show quoted text

From: devel@... [mailto:devel@...] On Behalf Of phil.erwin via Lists.Zephyrproject.Org
Sent: Monday, January 27, 2020 9:38 PM
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] ARM Cortex R intermittent MPU memory access check failures with CONFIG_USERSPACE

I'm getting intermittent run-time failures such as:

     syscall z_hdlr_k_uptime_get failed check: Memory region 0x0002ff70 (size 8) write access denied
     ***** Hardware exception *****
     Current thread ID = 0x000221b0
     Faulting instruction address = 0x1a
     Fatal fault in thread 0x000221b0! Aborting.

In this example, k_uptime_get() was called, which is going to save its 64-bit return value into memory (due to the syscall macros). The syscall gear is checking to see if the memory
address is valid. The routines wind down into mpu_buffer_validate(), which will call is_user_accessible_region() and finally into get_region_ap(). The code
is failing because get_region_ap() has a critical code section which is not wrapped with an irq_lock()/irq_unlock(). In this failure, we write the MPU index register, then
take an external interrupt, go off to another thread for a while ( which is going to re-load the MPU entries), return to the current thread (again re-loading the MPU entries), and read the attribute register (for the wrong index) and fail.

In reading the current Cortex-M code, I don't see it protecting these critical sections either, so I'm left wondering if the 'M' class will save the index register during
interrupt processing. If so, I would like to fix the 'R' code in a similar fashion.

There are several of these utility subroutines with this same critical code sections.

For reference, I've included the diff of get_region_ap() that I am going to be testing with locally where I do irq_lock() and irq_unlock().

/**
* This internal function returns the access permissions of an MPU region
* specified by its region index.
@@ -133,7 +136,17 @@ static inline int is_enabled_region(u32_t index)
*/
static inline u32_t get_region_ap(u32_t r_index)
{
-       set_region_number(r_index);
+   int
+      attr,
+      key = irq_lock();
+
+   set_region_number(r_index);
+
+   attr = get_region_attributes();

-       return (get_region_attributes() & MPU_RASR_AP_Msk) >> MPU_RASR_AP_Pos;
+   irq_unlock(key);
+
+   return (attr & MPU_RASR_AP_Msk) >> MPU_RASR_AP_Pos;
}
+

API meeting: Agenda

Carles Cufi

#6697

Hi all,

I cannot attend today so Peter Bigot will kindly chair the meeting instead.

The discussion will be centered exclusively around the completion of the GPIO transition into its new API.

- Driver conversion check:
  - https://github.com/zephyrproject-rtos/zephyr/issues/18530

- Users conversion check:
  - https://github.com/zephyrproject-rtos/zephyr/issues/20017

- Walk-through of the proposed merge procedure by the topic-gpio branch active manager, Peter Bigot:
  - https://github.com/zephyrproject-rtos/zephyr/issues/21789#issuecomment-578810880
  - Establish a timeline for completion of the full process

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project. 

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Re: GPIO porting status, 28th January

Carles Cufi

#6696

Hi all,

We are very close to finalizing the port of users to the new GPIO API. There are only 4 Pull Requests that need to be reviewed, reworked and merged in order to complete the process. If you know you are not going to have time to rework your PR in the next 2 days please let us know so that we can take over the Pull Request.

This is the current status of GPIO user porting as of today (26th January):

Remaining users with PR but requiring reviews:
drivers/sensor/bma280: https://github.com/zephyrproject-rtos/zephyr/pull/22104: Peter

Remaining users with PR but requiring rework of the PR:
drivers/wifi/winc1500: https://github.com/zephyrproject-rtos/zephyr/pull/22156: Tomasz
samples/drivers/espi: https://github.com/zephyrproject-rtos/zephyr/pull/22154: Alberto (needs rebase)
drivers/ieee802154/ieee802154_cc*: https://github.com/zephyrproject-rtos/zephyr/pull/22241: Tomasz

All reviews and rework of existing PRs are very welcome.

See the full overview here:
https://github.com/zephyrproject-rtos/zephyr/issues/20017

Regards,

Carles

Show quoted text

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 26 January 2020 22:04
To: devel <devel@lists.zephyrproject.org>; Johann Fischer
<j.fischer@phytec.de>; Maureen Helm <maureen.helm@nxp.com>; Kumar Gala
<kumar.gala@linaro.org>; Bigot, Peter <Peter.Bigot@nordicsemi.no>;
Bursztyka, Tomasz <tomasz.bursztyka@intel.com>; Piotr Mienkowski
<piotr.mienkowski@gmail.com>; Erwan Gouriou <erwan.gouriou@linaro.org>;
jose.a.meza.arellano@intel.com; Głąbek, Andrzej
<Andrzej.Glabek@nordicsemi.no>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] GPIO porting status, 26th January

Hi all,

Peter Bigot is currently working on rebasing the topic-gpio branch
against master.
The highest risk right now is the current set of users without a PR,
since existing PRs with requested changes can be expedited by taking
over the branch if necessary (though it probably won't be).

This is the current status of GPIO user porting as of today (26th
January):

Remaining users without a PR:
drivers/ieee802154/ieee802154_cc1200: Tomasz
drivers/ieee802154/ieee802154_cc2520: Tomasz
drivers/ieee802154/ieee802154_mcr20a: Johann
drivers/ieee802154/ieee802154_rf2xx*.c: Piotr
drivers/eeprom/eeprom_at2x: Peter
drivers/lora: Peter

Remaining users with PR but requiring reviews:
drivers/audio/tlv320dac310x: https://github.com/zephyrproject-
rtos/zephyr/pull/22172 (approved, will be merged after rebase)
drivers/sensor/bma280: https://github.com/zephyrproject-
rtos/zephyr/pull/22104: Peter (requires rebase, in progress)

Remaining users with PR but requiring rework of the PR:
drivers/wifi/winc1500: https://github.com/zephyrproject-
rtos/zephyr/pull/22156: Tomasz
samples/drivers/espi: https://github.com/zephyrproject-
rtos/zephyr/pull/22154: Alberto

All reviews and rework of existing PRs are very welcome.

See the full overview here:
https://github.com/zephyrproject-rtos/zephyr/issues/20017

Regards,

Carles

-----Original Message-----
From: Cufi, Carles
Sent: 24 January 2020 19:13
To: devel <devel@lists.zephyrproject.org>; Johann Fischer
<j.fischer@phytec.de>; Maureen Helm <maureen.helm@nxp.com>; Kumar Gala
<kumar.gala@linaro.org>; Bigot, Peter <Peter.Bigot@nordicsemi.no>;
Bursztyka, Tomasz <tomasz.bursztyka@intel.com>; Piotr Mienkowski
<piotr.mienkowski@gmail.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>; jose.a.meza.arellano@intel.com; Głąbek,
Andrzej <Andrzej.Glabek@nordicsemi.no>
Cc: Hedberg, Johan <johan.hedberg@intel.com>; Nashif, Anas
<anas.nashif@intel.com>
Subject: GPIO porting status, 24th January

[resending this email with the mailing list included to increase
distribution]

Hi all,

This is the current status of GPIO user porting as of today (24th
January):

Remaining users without a PR:
drivers/ieee802154/ieee802154_cc1200: Tomasz
drivers/ieee802154/ieee802154_cc2520: Tomasz
drivers/ieee802154/ieee802154_mcr20a: Johann
drivers/ieee802154/ieee802154_rf2xx*.c: Piotr

Remaining users with PR but requiring reviews:
drivers/audio/tlv320dac310x: https://github.com/zephyrproject-
rtos/zephyr/pull/22172
drivers/display/mb_display.c: https://github.com/zephyrproject-
rtos/zephyr/pull/22157
drivers/modem: https://github.com/zephyrproject-rtos/zephyr/pull/22168
samples/bluetooth/hci_spi: https://github.com/zephyrproject-
rtos/zephyr/pull/22134
samples/boards/nrf52/mesh/*: https://github.com/zephyrproject-
rtos/zephyr/pull/22129
samples/boards/reel_board/mesh_badge:
https://github.com/zephyrproject-
rtos/zephyr/pull/22137
drivers/wifi/winc1500: https://github.com/zephyrproject-
rtos/zephyr/pull/22156
samples/sensor/fxos8700-hid: https://github.com/zephyrproject-
rtos/zephyr/pull/22139
tests/bluetooth/mesh: https://github.com/zephyrproject-
rtos/zephyr/pull/22162

Remaining users with PR but requiring rework of the PR:
drivers/display/ssd16xx: https://github.com/zephyrproject-
rtos/zephyr/pull/21686: Johann
samples/drivers/espi: https://github.com/zephyrproject-
rtos/zephyr/pull/22154: Alberto
drivers/sensor/bma280: https://github.com/zephyrproject-
rtos/zephyr/pull/22104: Peter (requires rebase)
drivers/sensor/mpu6050: https://github.com/zephyrproject-
rtos/zephyr/pull/21566: Peter

All reviews and rework of existing PRs are very welcome.

See the full overview here:
https://github.com/zephyrproject-rtos/zephyr/issues/20017

Regards,

Carles

ARM Cortex R intermittent MPU memory access check failures with CONFIG_USERSPACE

Phil Erwin Jr

#6695

I'm getting intermittent run-time failures such as:

     syscall z_hdlr_k_uptime_get failed check: Memory region 0x0002ff70 (size 8) write access denied
     ***** Hardware exception *****
     Current thread ID = 0x000221b0
     Faulting instruction address = 0x1a
     Fatal fault in thread 0x000221b0! Aborting.

In this example, k_uptime_get() was called, which is going to save its 64-bit return value into memory (due to the syscall macros). The syscall gear is checking to see if the memory
address is valid. The routines wind down into mpu_buffer_validate(), which will call is_user_accessible_region() and finally into get_region_ap(). The code
is failing because get_region_ap() has a critical code section which is not wrapped with an irq_lock()/irq_unlock(). In this failure, we write the MPU index register, then
take an external interrupt, go off to another thread for a while ( which is going to re-load the MPU entries), return to the current thread (again re-loading the MPU entries), and read the attribute register (for the wrong index) and fail.

In reading the current Cortex-M code, I don't see it protecting these critical sections either, so I'm left wondering if the 'M' class will save the index register during
interrupt processing. If so, I would like to fix the 'R' code in a similar fashion.

There are several of these utility subroutines with this same critical code sections.

For reference, I've included the diff of get_region_ap() that I am going to be testing with locally where I do irq_lock() and irq_unlock().

/**
* This internal function returns the access permissions of an MPU region
* specified by its region index.
@@ -133,7 +136,17 @@ static inline int is_enabled_region(u32_t index)
*/
static inline u32_t get_region_ap(u32_t r_index)
{
-       set_region_number(r_index);
+   int
+      attr,
+      key = irq_lock();
+
+   set_region_number(r_index);
+
+   attr = get_region_attributes();

-       return (get_region_attributes() & MPU_RASR_AP_Msk) >> MPU_RASR_AP_Pos;
+   irq_unlock(key);
+
+   return (attr & MPU_RASR_AP_Msk) >> MPU_RASR_AP_Pos;
}
+

Re: Feedback requested on west manifest imports

Bolivar, Marti

#6694

Hello,

I've cut a new west pre-release today (0.6.99.dev5) which is feature complete for manifest imports.

The main new feature since 0.6.99.dev4 is you can now use whitelists and blacklists to filter what projects you import, with a slight change of plan from the original proposal which is reflected in the documentation.

We'd like to wrap up this west release in the next week or two, so if you have any more feedback, please let us know!

This introductory file is still valid:
https://github.com/mbolivar/my-zephyr-app/blob/master/README.rst 

The working documentation build is still here:
https://builds.zephyrproject.org/zephyrproject-rtos/zephyr/20433/docs/guides/west/manifest.html#manifest-imports

You may need to clear your browser cache and reload to get the latest build.

Thanks,
Marti

Re: 回复：回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Boie, Andrew P

#6693

Try this instead, this is what I do every day, I never use west as it doesn’t properly support emulators. For x86-64 the host GDB works great:

. zephyr-env.sh

cd samples/hello_world

mkdir out

cd out

cmake -DBOARD=qemu_x86_64 ..

make -j32

make debugserver

In another terminal:

cd samples/hello_world/out

gdb zephyr/zephyr.elf -ex "target remote :1234"

GDB will start up and you can debug as usual.

Show quoted text

From: devel@... <devel@...> On Behalf Of "???
Sent: Sunday, January 26, 2020 7:54 PM
To: devel <devel@...>; Boie, Andrew P <andrew.p.boie@...>
Subject: 回复：回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thank you！

It seems work seeing the source code, but still has problem on connection:

(gdb) target remote localhost:1234

Remote debugging using localhost:1234

warning: Selected architecture i386:x64-32 is not compatible with reported target architecture i386:x86-64

Remote 'g' packet reply is too long (expected 596 bytes, got 608 bytes): 00000000000000000000000000000000000000000000000063060000000000000000000000000000000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000200000000f0000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000001000006000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000801f0000

(gdb)

BTW， can this debug method view each core of SMP? how ? thank you!

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

------------------------------------------------------------------

发件人：Cufi, Carles <carles.cufi@...>

发送时间：2020年1月27日(星期一) 00:40

收件人：曹子龙 <caozilong@...>; "Boie, Andrew P" <andrew.p.boie@...>; devel <devel@...>

主　题：Re: 回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Hi there,

You are right, I made a mistake. Here’s the updated instructions that work for me:

$ cd ~/zephyrproject/zephyr

$ source zephyr-env.sh

$ west build -b qemu_x86_64 samples/hello_world/

$ cd build/

$ ninja debugserver

and then in another terminal

$ /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-gdb build/zephyr/zephyr.elf

(gdb) target remote localhost:1234

(gdb) dir ~/zephyrproject/zephyr/

(gdb) continue

So it’s a matter of using Zephyr’s SDK gdb and passing it as a parameter the path to build/zephyr/zephyr.elf

Carles

From:曹子龙 <caozilong@...>
Sent: 25 January 2020 03:15
To: Cufi, Carles <Carles.Cufi@...>; Boie, Andrew P <andrew.p.boie@...>; devel <devel@...>
Subject: 回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thank you!

But it seems cant load the symbol, so how to compile the debug elf files?

BTW: there are two elf files exist in build dir, zephyr.elf and zepyhr-qemu.elf, what is the difference?

Thread 1 received signal SIGINT, Interrupt.

0x0000000000100dfb in ?? ()

(gdb) bt

#0  0x0000000000100dfb in ?? ()

#1  0x0000000000102e7e in ?? ()

#2  0x0000000000102e5a in ?? ()

#3  0x00000000001004d2 in ?? ()

#4  0x0000000000000000 in ?? ()

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

------------------------------------------------------------------

发件人：Cufi, Carles <Carles.Cufi@...>

发送时间：2020年1月24日(星期五) 23:53

收件人：曹子龙 <caozilong@...>; "Boie, Andrew P" <andrew.p.boie@...>; devel <devel@...>

主　题：RE: 回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

$ cd ~/zephyrproject/zephyr

$ source zephyr-env.sh

$ west build -b qemu_x86_64 samples/hello_world/

$ cd build/

$ ninja debugserver

and then in another terminal

$ gdb

(gdb) target remote localhost:1234

(gdb) dir ~/zephyrproject/zephyr/

(gdb) continue

See https://docs.zephyrproject.org/latest/application/index.html#id1

From:devel@... <devel@...> On Behalf Of "??? via Lists.Zephyrproject.Org
Sent: 24 January 2020 07:36
To: Boie, Andrew P <andrew.p.boie@...>; devel <devel@...>
Cc: devel@...
Subject: 回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thanks

Can it be debuged by GDB? how to with west?

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

------------------------------------------------------------------

发件人：Boie, Andrew P <andrew.p.boie@...>

发送时间：2020年1月24日(星期五) 02:37

收件人：曹子龙 <caozilong@...>; devel <devel@...>

主　题：RE: [Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

The qemu_x86_64 target is configured to use two cores and SMP by default.

Regards,

Andrew

From:devel@... <devel@...> On Behalf Of "???
Sent: Thursday, January 23, 2020 3:36 AM
To: devel <devel@...>
Subject: [Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Now SMP only supported on xtensa, arc and x86 arch, but it seems more diffculte to run on xtensa and arc becasue of no boards.

so anybody can tell me how to launch a smp run environment on x86 arch? thank you!

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

回复：回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

"曹子龙

#6692

Thank you！

It seems work seeing the source code, but still has problem on connection:

(gdb) target remote localhost:1234

Remote debugging using localhost:1234

warning: Selected architecture i386:x64-32 is not compatible with reported target architecture i386:x86-64

Remote 'g' packet reply is too long (expected 596 bytes, got 608 bytes): 00000000000000000000000000000000000000000000000063060000000000000000000000000000000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000200000000f0000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000001000006000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000801f0000

(gdb)

BTW， can this debug method view each core of SMP? how ? thank you!

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

Show quoted text

------------------------------------------------------------------
发件人：Cufi, Carles <carles.cufi@...>
发送时间：2020年1月27日(星期一) 00:40
收件人：曹子龙 <caozilong@...>; "Boie, Andrew P" <andrew.p.boie@...>; devel <devel@...>
主　题：Re: 回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Hi there,

You are right, I made a mistake. Here’s the updated instructions that work for me:

$ cd ~/zephyrproject/zephyr
$ source zephyr-env.sh
$ west build -b qemu_x86_64 samples/hello_world/
$ cd build/
$ ninja debugserver

and then in another terminal

$ /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-gdb build/zephyr/zephyr.elf
(gdb) target remote localhost:1234
(gdb) dir ~/zephyrproject/zephyr/
(gdb) continue

So it’s a matter of using Zephyr’s SDK gdb and passing it as a parameter the path to build/zephyr/zephyr.elf

Carles

From:曹子龙 <caozilong@...>
Sent: 25 January 2020 03:15
To: Cufi, Carles <Carles.Cufi@...>; Boie, Andrew P <andrew.p.boie@...>; devel <devel@...>
Subject: 回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thank you!
But it seems cant load the symbol, so how to compile the debug elf files?
BTW: there are two elf files exist in build dir, zephyr.elf and zepyhr-qemu.elf, what is the difference?
Thread 1 received signal SIGINT, Interrupt.
0x0000000000100dfb in ?? ()
(gdb) bt
#0  0x0000000000100dfb in ?? ()
#1  0x0000000000102e7e in ?? ()
#2  0x0000000000102e5a in ?? ()
#3  0x00000000001004d2 in ?? ()
#4  0x0000000000000000 in ?? ()

曹子龙
珠海全志科技股份有限公司 BU1-PSW
地址：广东省珠海市高新区唐家湾镇科技2路9号
TEL：13824125580
Email：caozilong@...
网址： http://www.allwinnertech.com

------------------------------------------------------------------
发件人：Cufi, Carles <Carles.Cufi@...>
发送时间：2020年1月24日(星期五) 23:53
收件人：曹子龙 <caozilong@...>; "Boie, Andrew P" <andrew.p.boie@...>; devel <devel@...>
主　题：RE: 回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

$ cd ~/zephyrproject/zephyr
$ source zephyr-env.sh
$ west build -b qemu_x86_64 samples/hello_world/
$ cd build/
$ ninja debugserver

and then in another terminal

$ gdb
(gdb) target remote localhost:1234
(gdb) dir ~/zephyrproject/zephyr/
(gdb) continue

See https://docs.zephyrproject.org/latest/application/index.html#id1

From:devel@... <devel@...> On Behalf Of "??? via Lists.Zephyrproject.Org
Sent: 24 January 2020 07:36
To: Boie, Andrew P <andrew.p.boie@...>; devel <devel@...>
Cc: devel@...
Subject: 回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thanks

Can it be debuged by GDB? how to with west?

曹子龙
珠海全志科技股份有限公司 BU1-PSW
地址：广东省珠海市高新区唐家湾镇科技2路9号
TEL：13824125580
Email：caozilong@...
网址： http://www.allwinnertech.com

------------------------------------------------------------------
发件人：Boie, Andrew P <andrew.p.boie@...>
发送时间：2020年1月24日(星期五) 02:37
收件人：曹子龙 <caozilong@...>; devel <devel@...>
主　题：RE: [Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

The qemu_x86_64 target is configured to use two cores and SMP by default.

Regards,
Andrew

From:devel@... <devel@...> On Behalf Of "???
Sent: Thursday, January 23, 2020 3:36 AM
To: devel <devel@...>
Subject: [Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Now SMP only supported on xtensa, arc and x86 arch, but it seems more diffculte to run on xtensa and arc becasue of no boards.
so anybody can tell me how to launch a smp run environment on x86 arch? thank you!

曹子龙
珠海全志科技股份有限公司 BU1-PSW
地址：广东省珠海市高新区唐家湾镇科技2路9号
TEL：13824125580
Email：caozilong@...
网址： http://www.allwinnertech.com

Re: GPIO porting status, 26th January

Carles Cufi

#6691

Hi all,

Peter Bigot is currently working on rebasing the topic-gpio branch against master.
The highest risk right now is the current set of users without a PR, since existing PRs with requested changes can be expedited by taking over the branch if necessary (though it probably won't be).

This is the current status of GPIO user porting as of today (26th January):

Remaining users without a PR:
drivers/ieee802154/ieee802154_cc1200: Tomasz
drivers/ieee802154/ieee802154_cc2520: Tomasz
drivers/ieee802154/ieee802154_mcr20a: Johann
drivers/ieee802154/ieee802154_rf2xx*.c: Piotr
drivers/eeprom/eeprom_at2x: Peter
drivers/lora: Peter

Remaining users with PR but requiring reviews:
drivers/audio/tlv320dac310x: https://github.com/zephyrproject-rtos/zephyr/pull/22172 (approved, will be merged after rebase)
drivers/sensor/bma280: https://github.com/zephyrproject-rtos/zephyr/pull/22104: Peter (requires rebase, in progress)

Remaining users with PR but requiring rework of the PR:
drivers/wifi/winc1500: https://github.com/zephyrproject-rtos/zephyr/pull/22156: Tomasz
samples/drivers/espi: https://github.com/zephyrproject-rtos/zephyr/pull/22154: Alberto

All reviews and rework of existing PRs are very welcome.

See the full overview here:
https://github.com/zephyrproject-rtos/zephyr/issues/20017

Regards,

Carles

Show quoted text

-----Original Message-----
From: Cufi, Carles
Sent: 24 January 2020 19:13
To: devel <devel@lists.zephyrproject.org>; Johann Fischer
<j.fischer@phytec.de>; Maureen Helm <maureen.helm@nxp.com>; Kumar Gala
<kumar.gala@linaro.org>; Bigot, Peter <Peter.Bigot@nordicsemi.no>;
Bursztyka, Tomasz <tomasz.bursztyka@intel.com>; Piotr Mienkowski
<piotr.mienkowski@gmail.com>; Erwan Gouriou <erwan.gouriou@linaro.org>;
jose.a.meza.arellano@intel.com; Głąbek, Andrzej
<Andrzej.Glabek@nordicsemi.no>
Cc: Hedberg, Johan <johan.hedberg@intel.com>; Nashif, Anas
<anas.nashif@intel.com>
Subject: GPIO porting status, 24th January

[resending this email with the mailing list included to increase
distribution]

Hi all,

This is the current status of GPIO user porting as of today (24th
January):

Remaining users without a PR:
drivers/ieee802154/ieee802154_cc1200: Tomasz
drivers/ieee802154/ieee802154_cc2520: Tomasz
drivers/ieee802154/ieee802154_mcr20a: Johann
drivers/ieee802154/ieee802154_rf2xx*.c: Piotr

Remaining users with PR but requiring reviews:
drivers/audio/tlv320dac310x: https://github.com/zephyrproject-
rtos/zephyr/pull/22172
drivers/display/mb_display.c: https://github.com/zephyrproject-
rtos/zephyr/pull/22157
drivers/modem: https://github.com/zephyrproject-rtos/zephyr/pull/22168
samples/bluetooth/hci_spi: https://github.com/zephyrproject-
rtos/zephyr/pull/22134
samples/boards/nrf52/mesh/*: https://github.com/zephyrproject-
rtos/zephyr/pull/22129
samples/boards/reel_board/mesh_badge: https://github.com/zephyrproject-
rtos/zephyr/pull/22137
drivers/wifi/winc1500: https://github.com/zephyrproject-
rtos/zephyr/pull/22156
samples/sensor/fxos8700-hid: https://github.com/zephyrproject-
rtos/zephyr/pull/22139
tests/bluetooth/mesh: https://github.com/zephyrproject-
rtos/zephyr/pull/22162

Remaining users with PR but requiring rework of the PR:
drivers/display/ssd16xx: https://github.com/zephyrproject-
rtos/zephyr/pull/21686: Johann
samples/drivers/espi: https://github.com/zephyrproject-
rtos/zephyr/pull/22154: Alberto
drivers/sensor/bma280: https://github.com/zephyrproject-
rtos/zephyr/pull/22104: Peter (requires rebase)
drivers/sensor/mpu6050: https://github.com/zephyrproject-
rtos/zephyr/pull/21566: Peter

All reviews and rework of existing PRs are very welcome.

See the full overview here:
https://github.com/zephyrproject-rtos/zephyr/issues/20017

Regards,

Carles

Re: 回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Carles Cufi

#6690

Hi there,

You are right, I made a mistake. Here’s the updated instructions that work for me:

$ cd ~/zephyrproject/zephyr

$ source zephyr-env.sh

$ west build -b qemu_x86_64 samples/hello_world/

$ cd build/

$ ninja debugserver

and then in another terminal

$ /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-gdb build/zephyr/zephyr.elf

(gdb) target remote localhost:1234

(gdb) dir ~/zephyrproject/zephyr/

(gdb) continue

So it’s a matter of using Zephyr’s SDK gdb and passing it as a parameter the path to build/zephyr/zephyr.elf

Carles

Show quoted text

From: 曹子龙 <caozilong@...>
Sent: 25 January 2020 03:15
To: Cufi, Carles <Carles.Cufi@...>; Boie, Andrew P <andrew.p.boie@...>; devel <devel@...>
Subject: 回复：回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thank you!

But it seems cant load the symbol, so how to compile the debug elf files?

BTW: there are two elf files exist in build dir, zephyr.elf and zepyhr-qemu.elf, what is the difference?

Thread 1 received signal SIGINT, Interrupt.

0x0000000000100dfb in ?? ()

(gdb) bt

#0 0x0000000000100dfb in ?? ()

#1 0x0000000000102e7e in ?? ()

#2 0x0000000000102e5a in ?? ()

#3 0x00000000001004d2 in ?? ()

#4 0x0000000000000000 in ?? ()

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

------------------------------------------------------------------

发件人：Cufi, Carles <Carles.Cufi@...>

发送时间：2020年1月24日(星期五) 23:53

收件人：曹子龙 <caozilong@...>; "Boie, Andrew P" <andrew.p.boie@...>; devel <devel@...>

主　题：RE: 回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

$ cd ~/zephyrproject/zephyr

$ source zephyr-env.sh

$ west build -b qemu_x86_64 samples/hello_world/

$ cd build/

$ ninja debugserver

and then in another terminal

$ gdb

(gdb) target remote localhost:1234

(gdb) dir ~/zephyrproject/zephyr/

(gdb) continue

See https://docs.zephyrproject.org/latest/application/index.html#id1

From: devel@... <devel@...> On Behalf Of "??? via Lists.Zephyrproject.Org
Sent: 24 January 2020 07:36
To: Boie, Andrew P <andrew.p.boie@...>; devel <devel@...>
Cc: devel@...
Subject: 回复：[Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Thanks

Can it be debuged by GDB? how to with west?

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com

------------------------------------------------------------------

发件人：Boie, Andrew P <andrew.p.boie@...>

发送时间：2020年1月24日(星期五) 02:37

收件人：曹子龙 <caozilong@...>; devel <devel@...>

主　题：RE: [Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

The qemu_x86_64 target is configured to use two cores and SMP by default.

Regards,

Andrew

From:devel@... <devel@...> On Behalf Of "???
Sent: Thursday, January 23, 2020 3:36 AM
To: devel <devel@...>
Subject: [Zephyr-devel] is there any gudeline on how to run SMP mode kernel on X86 architecture?

Now SMP only supported on xtensa, arc and x86 arch, but it seems more diffculte to run on xtensa and arc becasue of no boards.

so anybody can tell me how to launch a smp run environment on x86 arch? thank you!

曹子龙

珠海全志科技股份有限公司 BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com