Upcoming Event: Zephyr Project: APIs - Tue, 03/24/2020 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 24 March 2020, 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 Live meeting minutes: https://docs.google.com/
|
|
Re: net_buf: non-atomic reference counting
Paul Sokolovsky
Hello,
On Tue, 24 Mar 2020 11:25:48 +0200 "Jukka Rissanen" <jukka.rissanen@...> wrote: Hi Darryl,Perhaps it could be rephrased differently: net_buf is more like Zephyr's internal system object. Where it's used currently, thread synchronization is expected(*) to happen on different level(s), and net_buf itself is kept lightweight and optimized. Perhaps that can be changed, but effects on existing subsystems using net_buf should be considered. (*) That doesn't mean there're no bugs, so reproducible bugreports are welcome.
-- 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
|
|
API meeting: agenda
Carles Cufi
Hi all,
Note: This is the last week where the meeting takes place at 17h CET. Next week we go back to 18h CET. Today's topics: - How to document standalone drivers like the enc28j60 (Piotr) - Upgrade the hwinfo API to stable - PR: https://github.com/zephyrproject-rtos/zephyr/pull/23661 - RTC API proposal - PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/commits/2880ee02b0f2fd91d897d8a11a4cbdefe87a19b0 - Naming in the async_notify module - PR: https://github.com/zephyrproject-rtos/zephyr/pull/23601 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: net_buf: non-atomic reference counting
Jukka Rissanen
Hi Darryl,
toggle quoted messageShow quoted text
I think it is more of a historical relic than a purpose design. There has not been any reports that this have caused issues. Patches are welcome of course. Cheers, Jukka
On Sun, 2020-03-22 at 17:39 -0700, Darryl Gamroth wrote:
Hi all,
|
|
Chettimada, Vinayak Kariappa
Please create a github issue with details of building your application and steps to reproduce the issue. Do specify the commit hash, and if you have a branch, do mention that too.
I see you have re-sent this mail again to mailing list, did you try measuring the stack usage of threads using the PR mentioned in previous email threads?
Regards, Vinayak
From: devel@... <devel@...>
On Behalf Of Narendar Malepu via Lists.Zephyrproject.Org
Sent: 24 March 2020 07:20 To: devel@... Cc: devel@... Subject: [Zephyr-devel] nrf52840 ble error #ble #nrf52840
Hi, [00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %) [00:01:36.902,893] <err> os: ***** BUS FAULT ***** [00:01:36.902,893] <err> os: Imprecise data bus error [00:01:36.902,923] <err> os: r0/a1: 0x00000029 r1/a2: 0x00000004 r2/a3: 0x00000000 [00:01:36.902,923] <err> os: r3/a4: 0x20004a0c r12/ip: 0x00000000 r14/lr: 0x000388fb [00:01:36.902,923] <err> os: xpsr: 0x61000000 [00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee [00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0 [00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown) [00:01:37.159,637] <err> os: Halting system
|
|
Narendar Malepu
Hi,
Iam using nrf52840 development board, developing software using zephyr. In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting. [00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)
[00:01:36.902,893] <err> os: ***** BUS FAULT *****
[00:01:36.902,893] <err> os: Imprecise data bus error
[00:01:36.902,923] <err> os: r0/a1: 0x00000029 r1/a2: 0x00000004 r2/a3: 0x00000000
[00:01:36.902,923] <err> os: r3/a4: 0x20004a0c r12/ip: 0x00000000 r14/lr: 0x000388fb
[00:01:36.902,923] <err> os: xpsr: 0x61000000
[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee
[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)
[00:01:37.159,637] <err> os: Halting system When i checked with above address error is at zephyr/include/sys/dlist.h:211 can someone help with above error Thanks
|
|
net_buf: non-atomic reference counting
Darryl Gamroth <dgamroth@...>
Hi all,
I was looking at using net_bufs for an application broadcasting reference counted buffers to multiple threads and I noticed the reference counting is not atomic. I'm curious, is this by design? Thanks.
|
|
[API stability change] Request to change the stability of HWINFO from unstable to stable
Alexander Wachter <alexander@...>
Dear all,
This email is a request to change the stability of the Hardware Information API from "unstable" to "stable". Pull-request: #23661 Discussion in the API meeting takes place on Tuesday, March 24th. If there are any objections, please comment on the PR or attend to the API meeting. Kind regards, -- Alexander Wachter The guy who introduced this API
|
|
Zephyr Toolchain Working Group Meeting – 19 March 2020
Rasmussen, Torsten
Hi,Today’s meeting minutes:https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/
Notes/MinutesStatus updates
expect to hit same include files issue, as with using IAR IDE.
This will be hard to solve.
There are attributes set per target regarding memory: read-only read-write Settings are specified in an xml file
AP:
Short term goals:
Could be completely different test system with focus on:
Toolchain abstraction:
Linker
Best regards
Torsten T. Rasmussen
|
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 03/19/2020 8:00am-9:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 19 March 2020, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/993312203 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join Zoom Meeting
|
|
Zephyr Toolchain Working Group - Thu, 03/19/2020
#cal-notice
devel@lists.zephyrproject.org Calendar <noreply@...>
Zephyr Toolchain Working Group When: Where: Description:
Topic: Zephyr Toolchain Working Group Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada) Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s) Mar 19, 2020 07:00 AM Apr 2, 2020 07:00 AM Apr 16, 2020 07:00 AM Apr 30, 2020 07:00 AM May 14, 2020 07:00 AM May 28, 2020 07:00 AM Jun 11, 2020 07:00 AM Jun 25, 2020 07:00 AM Jul 9, 2020 07:00 AM Jul 23, 2020 07:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB
Join Zoom Meeting https://zoom.us/j/967549258
Meeting ID: 967 549 258
One tap mobile +16699006833,,967549258# US (San Jose) +16465588656,,967549258# US (New York)
Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York) 855 880 1246 US Toll-free 877 369 0926 US Toll-free +1 647 558 0588 Canada 855 703 8985 Canada Toll-free Meeting ID: 967 549 258 Find your local number: https://zoom.us/u/abfRKTHWtN
|
|
Dev-Review Meeting Agenda Mar 19 2020
Kumar Gala
Agenda:
* Review any open PR / issues with dev-review label * Device Tree update / next steps (Kumar & Marti) * Power Management thoughts / initial ideas / plans (Peter) * Pinmux / DT (Piotr) If you have anything you’d like to add let me know Thanks - k
|
|
Upcoming Event: Zephyr Toolchain Working Group - Thu, 03/19/2020 7:00am-8:00am
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Toolchain Working Group When: Thursday, 19 March 2020, 7:00am to 8:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/967549258 Organizer: Maureen Helm Description: Zephyr Working Group is inviting you to a scheduled Zoom meeting.
Topic: Zephyr Toolchain Working Group Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada) Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s) Mar 19, 2020 07:00 AM Apr 2, 2020 07:00 AM Apr 16, 2020 07:00 AM Apr 30, 2020 07:00 AM May 14, 2020 07:00 AM May 28, 2020 07:00 AM Jun 11, 2020 07:00 AM Jun 25, 2020 07:00 AM Jul 9, 2020 07:00 AM Jul 23, 2020 07:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB
Join Zoom Meeting https://zoom.us/j/967549258
Meeting ID: 967 549 258
One tap mobile +16699006833,,967549258# US (San Jose) +16465588656,,967549258# US (New York)
Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York) 855 880 1246 US Toll-free 877 369 0926 US Toll-free +1 647 558 0588 Canada 855 703 8985 Canada Toll-free Meeting ID: 967 549 258 Find your local number: https://zoom.us/u/abfRKTHWtN
|
|
Re: Socket Poll functionality in case of socket is closed
Ravi kumar Veeramally
Hi,
toggle quoted messageShow quoted text
Thanks for clarification. Ravi
On 19/03/2020 14.30, Paul Sokolovsky wrote:
Hello,
|
|
Zephyr Toolchain Working Group Meeting – 19 March 2020
Rasmussen, Torsten
Hi,
For today’s meeting let’s follow up on last meeting action items and get a status update. Also I think we should continue the talk on the short goals, to get some progress.
Where: Agenda
Feel free to send a mail, if you would like additional topics to be discussed.
Best regards
Torsten T. Rasmussen
Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
|
|
Re: Socket Poll functionality in case of socket is closed
Paul Sokolovsky
Hello,
On Wed, 18 Mar 2020 11:34:00 +0200 "Ravi kumar Veeramally" <ravikumar.veeramally@...> wrote: Hi,If a peer closes TCP connection from its side, it's effectively an analog of EOF condition. In this case, poll() should return POLLIN. This will cause a client to issue a recv()/read() call, which will return 0, and will let a client detect the EOF condition. This is one of the "most basic" of "not immediately obvious" API contracts re: sockets and polling. It's definitely something like that, because quickly looking for normative references in the POSIX standard, I can't find them, e.g. in https://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html this particular case isn't described (some other "not immediately obvious" cases are). So, it's a kind of common knowledge, and a lot of software relies on that behavior (well, it's not possible to write async socket code without it). If you google for it, you should be able to find a lot of references. Note that there's also a POLLHUP flag, behavior of which in regard to sockets is "less clear" and "somewhat of a gray area". zsock_poll_prepare_ctx() is an internal function, which uses a special internal API contract, where particular error codes are used to signal very specific conditions. -EALREADY is one of such codes. It doesn't reach public API clients (and doesn't have the same meaning as POSIX EALREADY error). ButRight, to achieve the behavior described above. I did a simple test with few modifications in echo-client andThat sounds *about* right. Except that POSIX requires EPIPE to be returned trying to write to a socket with underlying connection closed. Or to be more exact, with the quote (https://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html): ------- [EPIPE] The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the calling thread. ------- So, if we return ESHUTDOWN, we should change that to EPIPE. If your mail trails to the ultimate question of "how to detect peer-closed socket if we called poll with POLLOUT?", then to keep it short: a) Hmm, I don't have an answer right away, though I bet I used to consider it (likely outside Zephyr context). b) I bet that's where POLLHUP return status kicks in. c) In all cases like that, where we can't "extract" normative behavior description from POSIX, we should check and follow the behavior of a well-know implementation, and that's definitely Linux. Please don't hesitate to cc: me on mails like this, I may sometimes not check the mailing list for a few days. [] -- 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
|
|
Narendar Malepu
But i'm not using any threads in my application, did you mean ble created threads
On Wed, Mar 18, 2020 at 6:45 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
|
|
Re: ARMv7 Cortex-A port for Xilinx Zynq7000
Immo Birnbaum
Hey everyone,
here's another update regarding the ARMv7 port: other than the 'interrupt' test, which I blacklisted, I've now got green lights on all kernel tests running on the QEMU Cortex-A9 (Zynq) target which are not automatically de-selected for whatever reason (61 passed, 23 skipped, 10 discarded). As a solution for the 'interrupt' test assertion failure is already being discussed and as I moved over completely to Stephanos' GIC interrupt handling code (although my code base isn't at the most recent regarding the modification of the interrupt handling, I'll take care of that soon), any solution of this issue should reflect directly in the ARMv7-A branch, eventually making the blacklisting obsolete. There's been one major change along the way: I've exchanged the timer being used to drive the system. As some of the tests that failed were related to the tickless mode, and as the readily available Xilinx TTC driver isn't suitable for this mode (it's a self-reloading 16-bit counter, where dynamically calculated comparator values would require on-the-fly re-calculation of a prescaler, which would lead to varying imprecision in timing, and where, for example, you might miss out on an entire interval if interrupts are globally locked for more than one period), I've switched over to the ARM global timer, for which Carlo has already provided a high-level interface plus an access implementation in aarch64. The ARM global timer is similar to the timers that drive the system clock on the other architectures, continuously counting up while comparing against an absolute value. While on ARMv8 access is possible via special instructions, on ARMv7 the timer's identical register layout is memory-mapped. So I've added a register-based implementation in aarch32, for which the timer's device tree entry must be supplied with an additional base address. Using this timer, the tickless mode tests passed as well. The fact that the tests failed with the TTC driver might eventually be a test suite issue - the TTC driver doesn't set the tickless capability config flag when it is chosen in the build configuration, yet the test cases didn't get filtered out? There's just one catch: I had to extend the ARM global timer's interface a little in the aarch32 implementation. While Carlo's implementation provides the basic functions for reading the current value and writing to the comparator which I re-implemented for aarch32, I had to add functions that read and write the state of the interrupt status ("event") bit. Initially I observed that the timer's ISR always ran twice in a row (the IAR register returns the timer's vector twice in a row before returning 0x3FF) when not using the auto-reload feature in tick-based mode (when configured this way, the interrupt works just as expected), erroneously incrementing the comparator value and leading to some really wonky timing behaviour. I spent the best part of a day experimenting with various things such as extra barriers, puzzled why these double interrupts kept occurring. Eventually, I came across both ARM's and Xilinx's errata documentation - lo and behold, this behaviour is an actual bug in the MPcore silicon (which QEMU even emulates!). The suggested workaround is to clear the event bit *after* updating the comparator (to UINT64_MAX in tickless mode, some value must always be written from within the ISR) and checking its value whenever the ISR is entered. During the second, erroneous execution of the ISR, polling the event bit's value returns 0 as the comparator hasn't matched yet and the ISR exits upon detecting that no event is pending. This is also how the Linux folks implemented the workaround in their driver. It doesn't prevent the extra ISR execution, but at least it doesn't screw up the system's timing. Carlo, would you mind if I added a menuconfig option below the ARM global timer in order to enable the (ARMv7-specific) workaround and included the special handling #ifdef'd in arm_arch_timer.c -> arm_arch_timer_compare_isr()? Also, do you see any use in adding an option enabling the auto-update of the comparator in tick-based mode? It doesn't improve the interrupt latency in any way, it would just save two register writes in my case. I guess it's not that relevant, what do you think? The one thing that works but isn't yet as clean as I would like it to be (and which should also have a matching test case for aarch32) is the FPU register saving thing. So far, I've completely skipped the CONFIG_FP_SHARING setting whereever I've added a branch for ARMv7 - if it's an ARMv7-A and if it has a FPU, pull the register saving off. Yet, while there is no marker which single thread gets to use the non-shared FPU registers as there is on Cortex-M, and the register saving basically isn't optional once the FPU is in play, I should probably auto-incorporate the FP_SHARING flag just to keep the semantics clean. I also still have to add the setting of the initial FPSCR and FPEXC values to the arch-specific thread creation code. More on that in the next update, I guess... I'll have a look into how pull requests work and start off small with the minor bugfixes in the existing UART/TTC drivers, while with regards to the rest of my work I still have to work out with the big wigs at work if I personally get to take the credit in the copyright notices of any new sources, or if they'll mention the company - after all, they provided the resources. Best regards, Immo
|
|
Re: West 0.7.2 can't work
FrankLi
Thanks, It's fixed
|
|
Chettimada, Vinayak Kariappa
From: devel@... <devel@...>
On Behalf Of Chettimada, Vinayak Kariappa via Lists.Zephyrproject.Org
Sent: 18 March 2020 14:04 To: Narendar Malepu <narendarm@...> Cc: devel@... Subject: Re: [Zephyr-devel] nrf52840 ble error #ble #nrf52840
Please identify and increase thread stack size based on your application code. You can use the implementation in this PR to analyse stack usage.
-Vinayak
From: Narendar Malepu <narendarm@...>
Hi Vinayak Kariappa,
Here is the result for above command zephyr/include/sys/dlist.h:211
On Wed, Mar 18, 2020 at 12:57 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
|
|