Updated Event: Zephyr Project: APIs
#cal-invite
devel@lists.zephyrproject.org Calendar <devel@...>
Zephyr Project: APIs When: Where: Organizer: An RSVP is requested. Click here to RSVP Description: Live meeting minutes: https://docs.google.com/
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 05/07/2019 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 7 May 2019, 9:00am to 10:00am, (GMT-07: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
|
|
Periodic publishing
#bluetoothmesh
#nrf52
paul.leguennec@...
Hello,
I have been trying to use the periodic publishing in mesh, but I don't really see how to use it correctly. I have read the Mesh Specification, and I already asked here for help on publishing, and somebody gave me an hint by telling me to use the BT_MESH_MODEL_PUB_DEFINE macro with an update callback, but I don't think I am doing this correctly. Right now I have my callback : /*Attempt of callback that would allow periodic publishing*/
static int vendor_cb_update(struct bt_mesh_model *model)
{
struct net_buf_simple *msg = model->pub->msg;
/*Build message for VND Model CB*/
bt_mesh_model_msg_init(msg,BT_MESH_MODEL_OP_3(0x08,CID_ZEPHYR)); // init of the status msg handler
return 0;
} and I am using the macro like this : BT_MESH_MODEL_PUB_DEFINE(vnd_pub,vendor_cb_update,3+3); I have been able to publish a message by pushing a button, and I would like to use only periodic publishing for my project. Does somebody already used periodic publishing and would be able to tell me what I am doing wrong ? Many thanks, Paul
|
|
GPIO API update
Piotr Mienkowski
Hi,
I started work on updating GPIO API and introducing PINCTRL API. The initial proposal is described here: https://github.com/zephyrproject-rtos/zephyr/issues/15611 Since the hardware implementation of GPIO and PINCTRL subsystem vary widely between different vendors and even SoC families providing a generic API becomes a relatively complex issue. I would like to deal with it in a few stages: - update GPIO API configuration options, e.g. defining pin pull-up, open source configuration. - extend GPIO API to support port operations - add PINCTRL API Issue #15611 deals only with the first part of the rework. It would be great if some more developers could review it and leave their comments on the issue page. Thanks and regards, Piotr
|
|
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected
Marc Herbert
On Fri, Apr 26, 2019 at 02:49 AM, Paul Sokolovsky wrote:
Actually, fishing for that link, I see that a whole bunch of changesGood guess. Anas found the bug (commas) and fixed it at https://github.com/zephyrproject-rtos/zephyr/commit/af3f81ef04bccd0b959 Curious how Anas debugged this because I just found this user who put a lot of effort: http://www.benjaminoakes.com/git/2018/08/10/Testing-changes-to-GitHub-CODEOWNERS/ 2018-08-31 Github's answer:
So apparently no "API" available, it would have been documented at https://help.github.com/en/articles/about-code-owners otherwise. No need to ask github either as the feedback is already "in the right hands". Marc
|
|
Zephyr Project: Dev Meeting - Thu, 05/02/2019 8:00am-9:00am
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: When: Where: Organizer: Description: An RSVP is requested. Click here to RSVP
|
|
MCUBoot can't find bootable image (nRF52)
Benjamin Lindqvist
Hey,
I've been trying to build the mcumgr/smp_svr sample on a nRF52840 DK (pca10056) by following https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html, using Zephyr v1.14.0 and MCUBoot v1.3.0. I follow the instructions, everything gets built, signed and flashed fine it seems, but MCUBoot can't find a bootable image. This is how I signed the image: ./imgtool.py sign \ --key mcuboot/root-rsa-2048.pem \ --header-size 0x200 \ --align 8 \ --version 1.2 \ --slot-size 0x68000 \ $ZEPHYR_BIN_DIR/zephyr.hex \ $ZEPHYR_BIN_DIR/signed.hex MCUBoot always gets stuck at Remote debugging using localhost:2331 0x000004fa in main () at ../main.c:202 202 BOOT_LOG_ERR("Unable to find bootable image"); caused by boot_validate_slot(0, NULL) returning an error, in turn caused by if (boot_check_header_erased(slot) == 0 || (hdr->ih_flags & IMAGE_F_NON_BOOTABLE)) { triggering. Has anyone verified the sample for the versions mentioned?
|
|
Re: Wrapping compiler builtins
Sigvart Hovland
I would say it’s an interest in such a pull request to enable more toolchains to build zephyr.
> Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.
|
|
Re: Wrapping compiler builtins
Kumar Gala
On Apr 30, 2019, at 12:37 PM, Jakob Stoklund Olesen <jolesen@...> wrote:There is interest in this as we want to support various toolchains beyond GCC. So we need to look at cleaning this up. I’d suggest maybe working up a simple proof of concept PR as the best way to discuss this. - k
|
|
Event: Zephyr Project: APIs
#cal-invite
devel@lists.zephyrproject.org Calendar <devel@...>
Zephyr Project: APIs When: Where: Organizer: An RSVP is requested. Click here to RSVP Description:
|
|
Event: Zephyr Project: Dev Meeting
#cal-invite
devel@lists.zephyrproject.org Calendar <devel@...>
Zephyr Project: Dev Meeting When: Where: Organizer: An RSVP is requested. Click here to RSVP Description:
|
|
Wrapping compiler builtins
Jakob Stoklund Olesen <jolesen@...>
Hi,
I’m new to Zephyr. It’s an impressive project!
I’ve been compiling parts of Zephyr in different environments in order to run unit tests on macOS and using the native_posix board on a Linux machine. I hit some trivial portability issues with the Zephyr code, particularly:
I see that header files like toolchain/xcc.h define these built-ins for compilers that don’t have them, but redefining built-ins this way has a couple problems:
I think both 2) and 3) have the potential to cause subtle security issues that only show up on some platforms.
Other performance-conscious open source projects also use compiler built-ins, but deal with these problems by wrapping built-ins in inline functions. Two examples are
These libraries of inline functions address the problems with naked built-ins by:
Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.
Thanks, Jakob
|
|
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected
Marc Herbert
Hi,
I wasn't requested for review. Again, that's not the only case. [...]While github's features should really work as expected to save confusion and everyone's time, I hope this "under-review" risk is very small because I would expect every reviewer to... review the list of other reviewers first thing and add anyone they think could be missing and could help. Not just other co-owners, far from it. Database-backed review tools like github avoid broadcasts. This can be an advantage compared to pure email reviews but it requires a reasonable "networking" effort; otherwise there's a risk of ending up with the other extreme: semi-private, not very open-source reviews. I would also expect developers to err on the "oversubscription" side a bit because withdrawing from a review takes one click whereas you can't add yourself to something you don't know exist. The above is just based on experience with code reviews in general and more specifically the acute problem of finding reviewers' time. Everyone loves code reviews, yet for some reason I rarely ever see time scheduled for them :-) Thanks in advance for correcting any of the generalities above that wouldn't apply to Zephyr. I see that a whole bunch of changes was made to the CODEOWNERS fileIt'd be nice from github to share the corresponding parsing code; think open source. Marc
|
|
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected
Marc Herbert
[duplicate message cause the web interface doesn't seem to support cross-posting]
I don't know about the github side, however I just found and fixed a number of issues in the Zephyr script that checks the CODEOWNERS file, please help review: https://github.com/zephyrproject-rtos/ci-tools/pull/54
|
|
Re: To bring back RPL to Zephyr project
Jian Zhang
Hi Thiago,
toggle quoted messageShow quoted text
That's good to know. I will start bringing RPL back to Zephyr :) Thanks and Best Regards, Jian ---- On Mon, 15 Apr 2019 19:51:05 +0800 Thiago Silveira <thiago@...> wrote ----
Hello Jian,> > We do use the RPL module in our project, and we will keep using it in the future. > > Unfortunately, as we are a very small team, we didn't have the resources to step up and maintain it then, and we don't have the resources now. If you do happen to bring it back and take the responsibility, I'd be glad to help in any way I can. > > Best regards, > Thiago > On Fri, Apr 5, 2019 at 11:36 PM Jian Zhang <kernel@...> wrote: > Hi All, > > I am kind of new to Zephyr dev community. Previously our team was using Zephyr without actively involved in kernel development. > > Recently we just noticed that RPL module will be removed in the coming release. Because we are using Zephyr and RPL in the current project and probably will keep using it. I am thinking of bringing it back and take the responsibility to maintain it. > > Just want to check if the RPL module with Zephyr is used anywhere? In case it's not required by anyone else, it probably would be easier for us to maintain our own branch. > > Please let me know if you guys have any thoughts. > > Thanks and Best Regards, > Jian > > > > >
|
|
Re: app runs using 1.13 but does not using 1.14
Jiří Kubias <jiri.kubias@...>
Hi, you can get the error line by issuing command /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-addr2line -e zephyr/zephyr.elf 0x200049a0 - this will show you where the error is. Best regard, Jiri pá 26. 4. 2019 v 15:33 odesílatel Abderrezak Mekkaoui <ab.mekka@...> napsal:
Hi All, --
=================================================== Ing. Jiri Kubias e-mail: jiri.kubias@... mobile: 775 593 956 ===================================================
|
|
app runs using 1.13 but does not using 1.14
Abderrezak Mekkaoui <ab.mekka@...>
Hi All,
I have an app, based on the Bluetooth peripheral_esp sample, that builds and runs as expected using zephyr 1.13.99. Using 1.14, it builds correctly but crashes with the following message: ***** MPU FAULT ***** Instruction Access Violation ***** Hardware exception ***** Current thread ID = 0x200022d0 Faulting instruction address = 0x200049a0 Fatal fault in essential thread! Spinning.. Before crashing it displays some expected sensor readings. It looks like Bluetooth fails completely. Any quick hints on what might be the cause? Thanks Abderrezak
|
|
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected
Paul Sokolovsky
On Fri, 26 Apr 2019 09:25:17 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@...> wrote: Thanks Paul,Well, I was on vacation for two weeks before Apr 15. It definitely worked before that. And I saw first problematic case last week, after returning from vacation. No idea if that might be related to https://github.com/zephyrproject-rtos/zephyr/commit/636a7af43e704e25af29b31d565399fc02fef408 - nothing wrong is seen here. Actually, fishing for that link, I see that a whole bunch of changes was made to the CODEOWNERS file just recently: https://github.com/zephyrproject-rtos/zephyr/commits/master/CODEOWNERS Just imagine that any of those changes could break syntax a bit or propagation of changes to it could glitch on Github side, leading to the effect we see. And that's not counting a possible coincidence of Github tighting up the syntax for that file...
-- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected
alpi@...
Thanks Paul,
toggle quoted messageShow quoted text
Do you have some indication of when did this break? BR Alberto
-----Original Message-----
From: tsc@... [mailto:tsc@...] On Behalf Of Paul Sokolovsky via Lists.Zephyrproject.Org Sent: Friday 26 April 2019 11:10 To: devel@...; tsc@... Cc: tsc@... Subject: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected Hello, As was noticed in a few (multiple?) PRs, automatic reviewer assignment based on the CODEOWNERS file no longer works as expected, specifically fails to assign reviewers. A recent example of this is https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while there's an entry: /subsys/net/ip/ @jukkar @tbursztyka @pfalcon in CODEOWNERS, I wasn't requested for review. Again, that's not the only case. For a clean-room test, I submitted https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be seen, the reviewer list is empty. This is problematic, because there's a risk that under-reviewed changes will get into the codebase, causing regressions. So, raising to the awareness of the TSC. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Github CODEOWNERS auto-assignment doesn't work as expected
Paul Sokolovsky
Hello,
As was noticed in a few (multiple?) PRs, automatic reviewer assignment based on the CODEOWNERS file no longer works as expected, specifically fails to assign reviewers. A recent example of this is https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while there's an entry: /subsys/net/ip/ @jukkar @tbursztyka @pfalcon in CODEOWNERS, I wasn't requested for review. Again, that's not the only case. For a clean-room test, I submitted https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be seen, the reviewer list is empty. This is problematic, because there's a risk that under-reviewed changes will get into the codebase, causing regressions. So, raising to the awareness of the TSC. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|