Date   

Re: SDK version used in CI?

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Hi!

Is the 0.8.1.
here is the install script for CI slaves:
https://gerrit.zephyrproject.org/r/gitweb?p=ci-management.git;a=blob;f=packer/provision/basebuild/Makefile;h=58a8390aa2a9eada90dc20cd0aed9fffc2024b25;hb=HEAD

Regards

Javier B. Perez

On Mon, 2016-08-01 at 14:03 -0500, Kumar Gala wrote:
What version of the SDK are we using in CI?

- k


SDK version used in CI?

Kumar Gala
 

What version of the SDK are we using in CI?

- k


System Design - Need feedback from developers

Mahendravarman rajarao <mahendravarman.rajarao@...>
 

Hi

Need clarifications on the system design ,
Consider the following example

1. There is a main task named Main_task
2. There are two tasks TASK_A and TASK_B .. Both these tasks are stared from the Main_task
3. Main_Task is of higher priority.. Then comes TASK_A priority and TASK_B priority
4. There is an shared Interrupt with callback function

Which of the following method best suites for Zephyr environment with RTOS scheduler ?

1. When Interrupt occurs set a flag in the Intr callback. In the Main_Task that flags are maintained and

corresponding functions in the TASK_A and TASK_B are called ..

2. Initialize a mailbox in TASK_A and a mailbox for TASK_B
. When Interrupt occurs.. put the message into the TASK_A mailbox and TASK_B mailbox
based on the message, certains functionality will be execute in TASK_A and TASK_B

Which design can be used such that RTOS schedules the tasks properly based on interrupt ?
Is both methods are same w.r.t schdueling or any difference is there ?

Please help


Re: deprecation policy

Boie, Andrew P
 

On Mon, 2016-08-01 at 18:05 +0000, Patel, Niheer V (Wind River) wrote:
Agreed, I don't think we have a concrete policy. We may need the
TSC to weigh
in.
I have added two separate agenda items for the TSC on Wednesday to
discuss separately or together as it makes sense.
        1. General deprecation policy
        2. Defining application versus kernel interfaces.
Thanks Niheer.
wrt item #2, my current understanding is that all internel kernel
interfaces are prefixed with '_'.

Andrew


Re: deprecation policy

Patel, Niheer <Niheer.Patel@...>
 

-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Monday, August 01, 2016 10:57 AM
To: kumar.gala(a)linaro.org
Cc: devel(a)lists.zephyrproject.org; PEREZ-GONZALEZ, INAKY
Subject: [devel] Re: Re: deprecation policy

On Mon, 2016-08-01 at 12:24 -0500, Kumar Gala wrote:

No not at this time. There is one reference to dynamic IRQs, in the
task IRQ code. No kernel or sample/testcase code that uses task
IRQs.
Was it expected that the interface was for kernel code only?  If so, I
think its fair game to remove.
They were exposed to the application level. They both were concerned with
installing interrupt handlers dynamically at runtime. The preferred approach
nowadays is to configure interrupts statically at build time, as removing dynamic
interrupts presents the option on XIP systems to keep certain large-ish data
structures like the IDT in ROM.

If this was intended for some application code, we should probably
come up with with a documented policy about how we intend to address
such issues going forward.  I’m guessing in the short term for this
case its probably fine.  I keep think we need some means to try and
have a clearer definition of application interfaces vs kernel.
Agreed, I don't think we have a concrete policy. We may need the TSC to weigh
in.
I have added two separate agenda items for the TSC on Wednesday to discuss separately or together as it makes sense.
1. General deprecation policy
2. Defining application versus kernel interfaces.

Regards,
Niheer


Andrew


Re: deprecation policy

Boie, Andrew P
 

On Mon, 2016-08-01 at 12:24 -0500, Kumar Gala wrote:
 
No not at this time. There is one reference to dynamic IRQs, in the
task IRQ code. No kernel or sample/testcase code that uses task
IRQs.
Was it expected that the interface was for kernel code only?  If so,
I think its fair game to remove.
They were exposed to the application level. They both were concerned
with installing interrupt handlers dynamically at runtime. The
preferred approach nowadays is to configure interrupts statically at
build time, as removing dynamic interrupts presents the option on XIP
systems to keep certain large-ish data structures like the IDT in ROM.

If this was intended for some application code, we should probably
come up with with a documented policy about how we intend to address
such issues going forward.  I’m guessing in the short term for this
case its probably fine.  I keep think we need some means to try and
have a clearer definition of application interfaces vs kernel.
Agreed, I don't think we have a concrete policy. We may need the TSC to
weigh in.

Andrew


Re: deprecation policy

Kumar Gala
 

On Jul 28, 2016, at 10:29 PM, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:


From: Perez-Gonzalez, Inaky
Sent: Thursday, July 28, 2016 5:33 PM
To: Boie, Andrew P; devel(a)lists.zephyrproject.org
Subject: RE: deprecation policy

Are there any in-kernel users?
No not at this time. There is one reference to dynamic IRQs, in the task IRQ code. No kernel or sample/testcase code that uses task IRQs.
Was it expected that the interface was for kernel code only? If so, I think its fair game to remove.

If this was intended for some application code, we should probably come up with with a documented policy about how we intend to address such issues going forward. I’m guessing in the short term for this case its probably fine. I keep think we need some means to try and have a clearer definition of application interfaces vs kernel.

- k


Re: Porting to Cortex-M0+

Boie, Andrew P
 

On Mon, 2016-08-01 at 13:34 +0000, Euan Mutch wrote:
Do I have to rewrite _Swap() to not use SVC or is there another way 
to do it that I have missed?
I am not too deeply familiar with ARM arch code. Ben Walsh would be the
person to talk to. I believe he gets back from sabbatical today
although it may take him some time to get through all his email.

Andrew


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-616] OS X setup instructions not working on El Capitan
https://jira.zephyrproject.org/browse/ZEP-616


UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 1
[ZEP-609] (Cannot Reproduce) Missing free
https://jira.zephyrproject.org/browse/ZEP-609


RESOLVED JIRA items within last 24 hours: 1
[ZEP-525] (Fixed) srctree changes are breaking applications
https://jira.zephyrproject.org/browse/ZEP-525


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3512 : console: shell: Zephyr shell enhancement
- https://gerrit.zephyrproject.org/r/3511 : net: contiki: Add NULL check to neighbor polling
- https://gerrit.zephyrproject.org/r/3510 : drivers/nble: Take semaphore in write without response
- https://gerrit.zephyrproject.org/r/3507 : fs: Updates file system sample app to use flash storage diskio

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3506 : fs: Adds flash device support to diskio interface
- https://gerrit.zephyrproject.org/r/3461 : bluetooth: adding Direct Test Mode support to shell application
- https://gerrit.zephyrproject.org/r/2797 : samples: bmi160: add sensor_value_sprintf helper function
- https://gerrit.zephyrproject.org/r/3500 : sys_log: replace old debug macros at bluetooth tester
- https://gerrit.zephyrproject.org/r/2434 : include/arch/arm/cortex_m/sys_io.h: Added memory bit manipulation functions for bytewise operations
- https://gerrit.zephyrproject.org/r/3454 : sys_log: replace old debug macros at ieee802154 driver
- https://gerrit.zephyrproject.org/r/3404 : soc: nrf5x: Add support to read and write to gpios
- https://gerrit.zephyrproject.org/r/3480 : boards: galileo: Only show galileo pinmux options when the board is chosen
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: Tinycrypt shim driver
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/3381 : net: net_context: Fix local ipv4 addr compare with INADDR_ANY
- https://gerrit.zephyrproject.org/r/3504 : samples/net: Add network-related functions to MQTT Subscriber
- https://gerrit.zephyrproject.org/r/3499 : samples/net: Add network-related functions to MQTT Publisher
- https://gerrit.zephyrproject.org/r/3488 : sys_log: replace old debug macros at DesignWare USB driver
- https://gerrit.zephyrproject.org/r/3402 : fs: Add Zephyr File System API
- https://gerrit.zephyrproject.org/r/2566 : fs: Add a sample app to demo Zephyr file system API
- https://gerrit.zephyrproject.org/r/3492 : fs: Adds the glue layer for the Fat FS module
- https://gerrit.zephyrproject.org/r/3416 : fs: Adds diskio interface
- https://gerrit.zephyrproject.org/r/3479 : doc: Remove contributor documentation moved to wiki
- https://gerrit.zephyrproject.org/r/3498 : nxp_kinetis: Refactor K64F init to use CMSIS register accesses

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3394 : drivers/nble: Use semaphore to control notification rate
- https://gerrit.zephyrproject.org/r/3477 : build: use quiet cmd for AR of libzephyr.a
- https://gerrit.zephyrproject.org/r/3495 : sys_log: replace old debug macros at USB stack
- https://gerrit.zephyrproject.org/r/3497 : sys_log: replace debug macros at Freescale K64 PWM driver
- https://gerrit.zephyrproject.org/r/3501 : sys_log: replace old debug macros at SSS boot
- https://gerrit.zephyrproject.org/r/3502 : sys_log: replace old debug macros at DMA sample
- https://gerrit.zephyrproject.org/r/3496 : sys_log: replace USB CDC ACM Device Class Driver debug macros
- https://gerrit.zephyrproject.org/r/2070 : build: create libzephyr.a and link it in instead of objects
- https://gerrit.zephyrproject.org/r/3491 : samples/net : Adding mbedTLS sample client
- https://gerrit.zephyrproject.org/r/2283 : qmsi: flash: Improved reentrancy of the soc flash driver


Porting to Cortex-M0+

Euan Mutch <euan.mutch@...>
 

Hi,

I am in the process of porting Zephyr to Cortex-M0+, the problem is that for the M0+ if you use a Supervisor Call (SVC) with interrupts disabled, since there is no interrupt masking either, then the Supervisor Call will generate a hard fault.

Which means that every time _Swap() is called it hard faults.

Currently I have managed to get round this by just commenting out the disabling of interrupts before _Swap() is called. However I don't think this is a viable long term solution!

Do I have to rewrite _Swap() to not use SVC or is there another way to do it that I have missed?

Thanks,
Euan


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-612] Need to send a dummy packet to establish connection using the TCP/IP stack
https://jira.zephyrproject.org/browse/ZEP-612

[ZEP-615] Un-supported flash erase size listed in SPI flash w25qxxdv driver header file
https://jira.zephyrproject.org/browse/ZEP-615


UPDATED JIRA items within last 24 hours: 1
[ZEP-591] MQTT Port to New IP Stack
https://jira.zephyrproject.org/browse/ZEP-591


CLOSED JIRA items within last 24 hours: 2
[ZEP-590] (Fixed) Update Zephyr's tinycrypt to version 2.0
https://jira.zephyrproject.org/browse/ZEP-590

[ZEP-611] (Fixed) Links on downloads page are not named consistently
https://jira.zephyrproject.org/browse/ZEP-611


RESOLVED JIRA items within last 24 hours: 3
[ZEP-49] (Fixed) x86: unify separate SysV and IAMCU code
https://jira.zephyrproject.org/browse/ZEP-49

[ZEP-415] (Fixed) aaU, I want to use the NATS messaging protocol to send sensor data to the cloud
https://jira.zephyrproject.org/browse/ZEP-415

[ZEP-401] (Fixed) PWM driver turns off pin if off time is 0 in set_values
https://jira.zephyrproject.org/browse/ZEP-401


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3506 : fs: Adds flash device support to diskio interface

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3495 : sys_log: replace old debug macros at USB stack
- https://gerrit.zephyrproject.org/r/3503 : sys_log: replace old debug macros at USB DFU sample
- https://gerrit.zephyrproject.org/r/3488 : sys_log: replace old debug macros at DesignWare USB driver
- https://gerrit.zephyrproject.org/r/3496 : sys_log: replace USB CDC ACM Device Class Driver debug macros
- https://gerrit.zephyrproject.org/r/3497 : sys_log: replace debug macros at Freescale K64 PWM driver
- https://gerrit.zephyrproject.org/r/3500 : sys_log: replace old debug macros at bluetooth tester
- https://gerrit.zephyrproject.org/r/3501 : sys_log: replace old debug macros at SSS boot
- https://gerrit.zephyrproject.org/r/3502 : sys_log: replace old debug macros at DMA sample
- https://gerrit.zephyrproject.org/r/3454 : sys_log: replace old debug macros at ieee802154 driver
- https://gerrit.zephyrproject.org/r/2283 : qmsi: flash: Improved reentrancy of the soc flash driver
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/2566 : fs: Add a sample app to demo Zephyr file system API
- https://gerrit.zephyrproject.org/r/3404 : soc: nrf5x: Add support to read and write to gpios
- https://gerrit.zephyrproject.org/r/3416 : fs: Adds diskio interface
- https://gerrit.zephyrproject.org/r/3492 : fs: Adds the glue layer for the Fat FS module
- https://gerrit.zephyrproject.org/r/3402 : fs: Add Zephyr File System API

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3455 : sys_log: replace old debug macros at pcal9535a driver


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-607] Shell APP doesn't work on Galileo board
https://jira.zephyrproject.org/browse/ZEP-607

[ZEP-608] Console: shell won't wake up from sleep in micro kernel
https://jira.zephyrproject.org/browse/ZEP-608

[ZEP-609] Missing free
https://jira.zephyrproject.org/browse/ZEP-609

[ZEP-610] TSC mailing list missing on mailing list "Manage List" list-of-lists list
https://jira.zephyrproject.org/browse/ZEP-610


UPDATED JIRA items within last 24 hours: 3
[ZEP-586] test_bat issues
https://jira.zephyrproject.org/browse/ZEP-586

[ZEP-530] doc: jira link "here" in the login must point to new location of contribution guidelines in the wiki
https://jira.zephyrproject.org/browse/ZEP-530

[ZEP-595] UART: usb simulated uart doesn't work in poll mode
https://jira.zephyrproject.org/browse/ZEP-595


CLOSED JIRA items within last 24 hours: 1
[ZEP-226] (Fixed) Update sample PMA to support device suspend/resume
https://jira.zephyrproject.org/browse/ZEP-226


RESOLVED JIRA items within last 24 hours: 1
[ZEP-575] (Fixed) Ethernet/IPv4/UDP: ip_buf_appdatalen returns wrong values
https://jira.zephyrproject.org/browse/ZEP-575


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3504 : samples/net: Add network-related functions to MQTT Subscriber
- https://gerrit.zephyrproject.org/r/3502 : sys_log: replace old debug macros at DMA sample
- https://gerrit.zephyrproject.org/r/3503 : sys_log: replace old debug macros at USB DFU sample
- https://gerrit.zephyrproject.org/r/3499 : samples/net: Add network-related functions to MQTT Publisher
- https://gerrit.zephyrproject.org/r/3500 : sys_log: replace old debug macros at bluetooth tester
- https://gerrit.zephyrproject.org/r/3501 : sys_log: replace old debug macros at SSS boot
- https://gerrit.zephyrproject.org/r/3496 : sys_log: replace USB CDC ACM Device Class Driver debug macros
- https://gerrit.zephyrproject.org/r/3497 : sys_log: replace debug macros at Freescale K64 PWM driver
- https://gerrit.zephyrproject.org/r/3495 : sys_log: replace old debug macros at USB stack
- https://gerrit.zephyrproject.org/r/3498 : nxp_kinetis: Refactor K64F init to use CMSIS register accesses

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2566 : fs: Add a sample app to demo Zephyr file system API
- https://gerrit.zephyrproject.org/r/3492 : fs: Adds the glue layer for the Fat FS module
- https://gerrit.zephyrproject.org/r/3402 : fs: Add Zephyr File System API
- https://gerrit.zephyrproject.org/r/3416 : fs: Adds diskio interface
- https://gerrit.zephyrproject.org/r/3455 : sys_log: replace old debug macros at pcal9535a driver
- https://gerrit.zephyrproject.org/r/3422 : samples: add program to toggle a LED connected to a gpio pin
- https://gerrit.zephyrproject.org/r/3491 : samples/net : Adding mbedTLS sample client
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: Tinycrypt shim driver
- https://gerrit.zephyrproject.org/r/2283 : qmsi: flash: Improved reentrancy of the soc flash driver
- https://gerrit.zephyrproject.org/r/3489 : samples/net: DNS client application
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/3488 : sys_log: replace old debug macros at DesignWare USB driver
- https://gerrit.zephyrproject.org/r/3337 : script: full name accept unicode characters
- https://gerrit.zephyrproject.org/r/3454 : sys_log: replace old debug macros at ieee802154 driver
- https://gerrit.zephyrproject.org/r/3459 : soc: Add soc id and version interface

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3485 : spi: Remove suspend and resume hooks from spi_driver_api
- https://gerrit.zephyrproject.org/r/3483 : spi: k64: Move suspend and resume hooks to pm_ops
- https://gerrit.zephyrproject.org/r/3458 : sys_log: replace old debug macros at GPIO drivers
- https://gerrit.zephyrproject.org/r/3482 : pwm: Remove suspend and resume hooks from pwm_driver_api
- https://gerrit.zephyrproject.org/r/3481 : pwm: k64_ftm: Move suspend and resume hooks to pm_ops
- https://gerrit.zephyrproject.org/r/3486 : i2c: Remove suspend and resume hooks from i2c_driver_api
- https://gerrit.zephyrproject.org/r/3484 : spi: intel: Move suspend and resume hooks to pm_ops
- https://gerrit.zephyrproject.org/r/3476 : qemu_nios2: increase RAM size
- https://gerrit.zephyrproject.org/r/3490 : samples/net/mqtt: Update README file for Debian/Ubuntu users
- https://gerrit.zephyrproject.org/r/2565 : fs: Update FatFs Kconfig names
- https://gerrit.zephyrproject.org/r/3493 : net: contiki: Prevent a null dereference
- https://gerrit.zephyrproject.org/r/3494 : net: coap: Add a Kconfig option to enable/disable link format filters


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Kumar Gala
 

If what you are talking about is really for errata than I think we should solve that specific problem. I think a combination of a consistent #define naming and usage convention:

#define CONFIG_ERRATUM_<VENDOR_NAME>_<CHIP>_<VND/CHIP SPECIFIC ERRATUM DESC>

For cases that could be handled at compile time. Than for runtime cases:

Something like:

bool has_erratum(enum erratum_list e).

where erratum_list can be defined in some SoC specific header and code to report if the given erratum is valid on the given chip.

Also, for what you describe, only the revision info is need so at most we’d have an internal API like:
uint32_t __get_soc_revision(void)

- k

On Jul 28, 2016, at 11:01 AM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:

I'm confused as to what you mean by using features. Do you mean major silicon features such as different Cache size or different HW acceleration blocks? These would likely be a major rev of the silicon which would warrant a new binary. Also, how are silicon features determined without reading the underlying SOC version?

The origin of the request for the API is for a very specific scenario. When SOC vendors bring up new silicon, there are often multiple revisions of silicon available to the dev/test team before the chip is commercially available. Early versions of the silicon invariably have hardware bugs and the driver SW needs to compensate. As new iterations of the silicon are available to the dev/test team, either run-time detection is used to apply/disable the HW work-arounds, or the older HW boards become deadweight. This has significant cost and efficiency implications. This API is intended to be used at a very low level to allow drivers to enable/disable HW work-arounds. Having the API in the kernel saves the dev team from deriving their own API. I've seen scenarios where different component teams on the same project each implement their own SOC version detection scheme for this purpose.

The API is not intended for use by applications, and is not intended to distinguish between major chipset releases (example, not intended to distinguish between 384 vs a 486, or a Cortex M0 vs a Cortex M4). I'm still confused as to why a developer go through the trouble to have a single binary that runs on significantly different systems. This would be an inefficient use of FLASH and Memory, unnecessarily increasing cost of the end device.

I maintain that if an OEM picks up new silicon that has additional functionality, there will be a new HW board to enable new features/sensors, a new display etc. The OEM will naturally go through the process to create a separate binary. They may decide to use the same code-base to create multiple binaries, but that will be at compile-time, and won't require run-time detection to distinguish code-paths. It is _more_ work to create a single binary that runs on multiple HW SKUs, and a _lot more_ work to create a single binary that runs on two platforms that are significantly different.

Can you provide an example of an API that would provide feature level granularity?

Thanks,
Gajinder



-----Original Message-----
From: Kumar Gala [mailto:kumar.gala(a)linaro.org]
Sent: Thursday, July 28, 2016 6:25 AM
To: Vij, Gajinder S <gajinder.s.vij(a)intel.com>
Cc: Morgaine <morgaine.dinova(a)googlemail.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC] Provide a generic interface for getting the SOC ID and version

The use case you specify of picking SOC-version-specific code at run-time should be using features and not an ID for determining such things. This goes directly to Tixy’s email thread which I agree with 100%.

- k

On Jul 22, 2016, at 8:02 PM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:

There is a clear use case for the API, as articulated by Morgaine and Pedro (included below). The purpose of the API is to provide the mechanism for a developer to be able to select SOC-version-specific code paths at run-time, reducing the need for a custom image per SOC version. When and if version specific code is used depends on the circumstances and should be left to the developer as a policy decision.

I’d like to determine if there is still objections to this API being implemented in Zephyr. I read through the thread and will attempt to address the concerns raised.

On the concerns articulated by Tixy, since the App, Kernel, and BSP are all compiled from source into a single binary, I don’t see the same app compatibility issues cropping up in a Zephyr scenario that have come up in Linux. It is conceivable that someone may attempt to use the SOC version as a way to distinguish between different variants of a product family, but that would be an inappropriate use of the API.

I don’t know where the notion of using this API as an entropy source came from. I have removed this from the Jira description.

To the question about forward support and uniqueness of the IDs – should this happen on different architectures, I don’t see a problem because I expect the BSPs will still be unique, and therefore I don’t expect a binary run on one platform to successfully be run on another.

Comments welcome.

Thanks,
Gajinder


Pedro’s use case:
Ø The user might know the SOC ID at compile time (although a user might want to check against the hardware in case of doubt).
Ø The SOC revision can change between hardware stepping, so the user might not know at compile time the version of a given model.
Ø In that case reading the hardware registers is the only way to know the revision.

Morgaine’s use case:
Ø This API creates a 1:N relationship between compiled firmware and target behaviour. In other words it allows target behaviour to be parametrized by some target identifier in a standard way given by the API, without requiring each different target to be loaded with different firmware.



From: Morgaine [mailto:morgaine.dinova(a)googlemail.com]
Sent: Thursday, July 21, 2016 10:27 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID and version

Kumar writes:
So I ask again, what are we trying to accomplish?
See my preceding reply, which explored exactly that question.

From the original requirement expressed in the RFC and from Tixy's subsequent comments, it's clear that there are at least two distinct purposes in people's minds: the one mentioned in the RFC which required uniqueness for generating unique per-target data, and another purpose related to feature sets. It was noted that the second of these is somewhat problematic.

My interest is in the simpler of these, the requirement expressed in the RFC, because it is such a common need. Someone else will have to argue in favour of the other if they feel it's important. The two could of course be combined if the agreed data width permits.

Morgaine.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-605] SMP over BR/EDR
https://jira.zephyrproject.org/browse/ZEP-605

[ZEP-603] In coap_server sample application, observable resource does not generate notification with 5.00 (Internal server error) if content-format gets modified
https://jira.zephyrproject.org/browse/ZEP-603

[ZEP-604] In coap_server sample app, CoAP resource "separate" is not able to send separate response
https://jira.zephyrproject.org/browse/ZEP-604

[ZEP-606] Doc files deleted from gerrit aren't deleted from website
https://jira.zephyrproject.org/browse/ZEP-606


UPDATED JIRA items within last 24 hours: 5
[ZEP-591] MQTT Port to New IP Stack
https://jira.zephyrproject.org/browse/ZEP-591

[ZEP-414] Add driver API reentrancy support to flash driver
https://jira.zephyrproject.org/browse/ZEP-414

[ZEP-328] HW Encryption Abstraction
https://jira.zephyrproject.org/browse/ZEP-328

[ZEP-358] Add support for TMP112 sensor
https://jira.zephyrproject.org/browse/ZEP-358

[ZEP-203] clean up APIs for static exceptions
https://jira.zephyrproject.org/browse/ZEP-203


CLOSED JIRA items within last 24 hours: 4
[ZEP-69] (Fixed) Extend PWM API to use arbitrary unit of time
https://jira.zephyrproject.org/browse/ZEP-69

[ZEP-434] (Fixed) Driver for HMC5883L magnetometer
https://jira.zephyrproject.org/browse/ZEP-434

[ZEP-572] (Fixed) X86 kernel BAT failed: Kernel Allocation Failure!
https://jira.zephyrproject.org/browse/ZEP-572

[ZEP-554] (Fixed) samples/drivers/aon_counter check readme file
https://jira.zephyrproject.org/browse/ZEP-554


RESOLVED JIRA items within last 24 hours: 7
[ZEP-573] (Fixed) IoT applications must use netz API
https://jira.zephyrproject.org/browse/ZEP-573

[ZEP-327] (Fixed) Encryption Libraries needed for Thread support
https://jira.zephyrproject.org/browse/ZEP-327

[ZEP-440] (Fixed) Add driver API reentrancy support to WDT shim driver
https://jira.zephyrproject.org/browse/ZEP-440

[ZEP-412] (Fixed) Add driver API reentrancy support to RTC driver for LMT
https://jira.zephyrproject.org/browse/ZEP-412

[ZEP-415] (Fixed) aaU, I want to use the NATS messaging protocol to send sensor data to the cloud
https://jira.zephyrproject.org/browse/ZEP-415

[ZEP-430] (Fixed) Add driver API reentrancy support to PWM shim driver
https://jira.zephyrproject.org/browse/ZEP-430

[ZEP-385] (Fixed) Ethernet+IP{v4|v6}+TCP client mode is not working
https://jira.zephyrproject.org/browse/ZEP-385


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3494 : net: coap: Add a Kconfig option to enable/disable link format filters
- https://gerrit.zephyrproject.org/r/3493 : net: contiki: Prevent a null dereference
- https://gerrit.zephyrproject.org/r/3492 : fs: Adds the glue layer for the Fat FS module
- https://gerrit.zephyrproject.org/r/3491 : samples/net : Adding mbedTLS sample server
- https://gerrit.zephyrproject.org/r/3490 : samples/net/mqtt: Update README file for Debian/Ubuntu users
- https://gerrit.zephyrproject.org/r/3489 : samples/net: DNS client application
- https://gerrit.zephyrproject.org/r/3488 : sys_log: replace old debug macros at DesignWare USB driver
- https://gerrit.zephyrproject.org/r/3484 : spi: intel: Move suspend and resume hooks to pm_ops
- https://gerrit.zephyrproject.org/r/3482 : pwm: Remove suspend and resume hooks from pwm_driver_api
- https://gerrit.zephyrproject.org/r/3481 : pwm: k64_ftm: Move suspend and resume hooks to pm_ops
- https://gerrit.zephyrproject.org/r/3486 : i2c: Remove suspend and resume hooks from i2c_driver_api
- https://gerrit.zephyrproject.org/r/3483 : spi: k64: Move suspend and resume hooks to pm_ops
- https://gerrit.zephyrproject.org/r/3485 : spi: Remove suspend and resume hooks from spi_driver_api
- https://gerrit.zephyrproject.org/r/3480 : boards: galileo: Only show galileo pinmux options when galileo is the chosen one
- https://gerrit.zephyrproject.org/r/3479 : doc: Remove contributor documentation moved to wiki
- https://gerrit.zephyrproject.org/r/3477 : build: use quiet cmd for AR of libzephyr.a
- https://gerrit.zephyrproject.org/r/3476 : qemu_nios2: increase RAM size

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3422 : samples: add program to toggle a LED connected to a gpio pin
- https://gerrit.zephyrproject.org/r/3404 : soc: nrf5x: Add support to read and write to gpios
- https://gerrit.zephyrproject.org/r/3416 : fs: Adds diskio interface
- https://gerrit.zephyrproject.org/r/3415 : fs: Directory layout for file system
- https://gerrit.zephyrproject.org/r/2566 : fs: Add a sample app to demo Zephyr file system API
- https://gerrit.zephyrproject.org/r/2565 : fs: Update FatFs Kconfig names
- https://gerrit.zephyrproject.org/r/3402 : fs: Add Zephyr File System API
- https://gerrit.zephyrproject.org/r/3381 : net: net_context: Fix local ipv4 addr compare with INADDR_ANY
- https://gerrit.zephyrproject.org/r/3311 : crypto/include: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/3455 : sys_log: replace old debug macros at pcal9535a driver
- https://gerrit.zephyrproject.org/r/3458 : sys_log: replace old debug macros at GPIO drivers
- https://gerrit.zephyrproject.org/r/3393 : net: Network for Zephyr API (netz)
- https://gerrit.zephyrproject.org/r/3454 : sys_log: replace old debug macros at ieee802154 driver
- https://gerrit.zephyrproject.org/r/2070 : build: create libzephyr.a and link it in instead of objects
- https://gerrit.zephyrproject.org/r/3439 : spi_qmsi: Add suspend/resume
- https://gerrit.zephyrproject.org/r/3350 : uart_qmsi: Implement suspend and resume functions

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3478 : sanitycheck: allow deprecated APIs
- https://gerrit.zephyrproject.org/r/3487 : test_mbedtls: exclude platforms with insufficient RAM/ROM
- https://gerrit.zephyrproject.org/r/3475 : arduino_101: Remove if-else block from script
- https://gerrit.zephyrproject.org/r/3420 : board: nitrogen: Add support for the Nitrogen board
- https://gerrit.zephyrproject.org/r/3367 : altera_max10: default to UFM flashing
- https://gerrit.zephyrproject.org/r/3466 : qemu Nios2: Increase the amount of available RAM
- https://gerrit.zephyrproject.org/r/3465 : newlib: upgrade to 2.4.0
- https://gerrit.zephyrproject.org/r/3407 : net: Fix incorrect IP app data length
- https://gerrit.zephyrproject.org/r/3403 : soc: nrf5x: Disconnect GPIO input buffer when configured as output
- https://gerrit.zephyrproject.org/r/3456 : ARC toolchain: Upgrade
- https://gerrit.zephyrproject.org/r/3450 : x86: improve exception APIs
- https://gerrit.zephyrproject.org/r/3428 : basic_cortex_m3: Remove empty board file
- https://gerrit.zephyrproject.org/r/3436 : quark_d2000_crb: Remove empty board file
- https://gerrit.zephyrproject.org/r/3433 : quark_se_sss_devboard: Remove empty board file
- https://gerrit.zephyrproject.org/r/3429 : basic_minuteia: Remove empty board file
- https://gerrit.zephyrproject.org/r/3427 : frdm_k64f: Remove empty board file
- https://gerrit.zephyrproject.org/r/3426 : nucleo_f103rb: Remove empty board file
- https://gerrit.zephyrproject.org/r/3431 : qemu_cortex_m3: Remove empty board file
- https://gerrit.zephyrproject.org/r/3425 : olimexino_stm32: Remove empty board file
- https://gerrit.zephyrproject.org/r/3424 : stm32_mini_a15: Remove empty board file
- https://gerrit.zephyrproject.org/r/3434 : arduino_due: Remove empty board file
- https://gerrit.zephyrproject.org/r/3432 : qemu_x86: Remove empty board file
- https://gerrit.zephyrproject.org/r/3430 : minnowboard: Remove empty board file
- https://gerrit.zephyrproject.org/r/3435 : galileo: Remove empty board file
- https://gerrit.zephyrproject.org/r/3468 : samples/net: Add a NATS publisher application
- https://gerrit.zephyrproject.org/r/3449 : samples/net: MQTT subscriber with QoS
- https://gerrit.zephyrproject.org/r/3464 : sensor: isl29035: fix undefined CONFIG LUX RANGE 4k in elif
- https://gerrit.zephyrproject.org/r/3012 : samples: Add suspend/resume of devices to Quark SE power sample
- https://gerrit.zephyrproject.org/r/3419 : drivers/serial: fix nordic kconfig config string typo
- https://gerrit.zephyrproject.org/r/3469 : samples/net: Add a NATS subscriber application
- https://gerrit.zephyrproject.org/r/3445 : samples/net: MQTT publisher with QoS
- https://gerrit.zephyrproject.org/r/3001 : i2c: Fixed i2c_dw spamming when logs are enabled
- https://gerrit.zephyrproject.org/r/3414 : qmsi: pwm: Use locking mechanism to guard critical regions
- https://gerrit.zephyrproject.org/r/3016 : samples: power/quark_se: Add support for Sleep states
- https://gerrit.zephyrproject.org/r/3418 : samples: sample app for the nRF5 flash driver
- https://gerrit.zephyrproject.org/r/3474 : Revert "samples/net: Add netz_client sample code"


Re: deprecation policy

Boie, Andrew P
 

________________________________
From: Perez-Gonzalez, Inaky
Sent: Thursday, July 28, 2016 5:33 PM
To: Boie, Andrew P; devel(a)lists.zephyrproject.org
Subject: RE: deprecation policy

Are there any in-kernel users?
No not at this time. There is one reference to dynamic IRQs, in the task IRQ code. No kernel or sample/testcase code that uses task IRQs.


Re: deprecation policy

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

Are there any in-kernel users?
________________________________
From: Boie, Andrew P [andrew.p.boie(a)intel.com]
Sent: Friday, July 29, 2016 1:28 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] deprecation policy

Do we have a concrete policy on deprecated APIs?

A while back we agreed to deprecate the dynamic IRQ / exception APIs, and task irq APIs, and they all have been marked with __deprecated. The change that did this landed mid-April and was in the 1.4.0 release.
Once the merge window reopens after 1.5.0 gets tagged and released, I would like to remove this code from the kernel.
Any objections to this? Is 6 months enough time (period between 1.4.0 -> 1.6.0) for end users to adapt?

Andrew

7581 - 7600 of 8692