Date   

Increasing bss section in Zephyr

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi All

How to Increase the .bss section in Zephyr ?

There is a requirement for my project to have a big size array for 15K
If I declare and compile , getting error as

.bss will not fit in region RAM
Region 'RAM' overflowed by 20160 bytes

Any help on this regard is welcome !!

Mahendra


Zephyr API for I2S

Goldman, Michael <michael.goldman@...>
 

Hi all,

I would like to ask about future plans for I2S Zephyr API:


1) When are you planning to release the API?

2) Is it possible to share the code before officially releasing it?

Thanks,
Michael Goldman

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Serial Port throws error - Galileo Gen2 Boot up with USB thumb drive/MicroSD

Vaish, Atul <atul.vaish@...>
 

Hi
After a while , restated to check (earlier with the same setup, could run hello world and CoAP server) networking functionalities with Zephyr using Galileo Gen 2 , but after following https://wiki.zephyrproject.org/view/Galileo_Gen1_Gen2
(except Jumper settings) , I get stuck below . What could be the missing here ?

[cid:image001.png(a)01D206F4.06D672F0]



With Micro SD card
[cid:image002.png(a)01D206F4.B7E17A40]


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case
- https://gerrit.zephyrproject.org/r/3923 : lib/http: Fix size_t dependency by adding stddef.h header
- https://gerrit.zephyrproject.org/r/4531 : unified/build: allow building the unified kernel
- https://gerrit.zephyrproject.org/r/4529 : unified/test_fp: mark test so that it runs the nanokernel version
- https://gerrit.zephyrproject.org/r/4528 : unified/test_sema: fix isr wrapper names
- https://gerrit.zephyrproject.org/r/4527 : unified: Fix test_sema/microkernel
- https://gerrit.zephyrproject.org/r/4526 : unified/test_timer: adapt for unified kernel
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/4524 : unified/test_mail: adapt test to not use sem groups and mem pools
- https://gerrit.zephyrproject.org/r/4530 : unified: initial unified kernel implementation
- https://gerrit.zephyrproject.org/r/4525 : unified/test_pipe: adapt to not use sem groups
- https://gerrit.zephyrproject.org/r/4521 : zperf_shell: add unified kernel string for unified kernel case
- https://gerrit.zephyrproject.org/r/4523 : unified/test_context: adapt test to run on unified kernel
- https://gerrit.zephyrproject.org/r/4522 : unified/tests: tag working tests on unified kernel as 'unified_capable'
- https://gerrit.zephyrproject.org/r/4520 : unified/object_tracing: disable object tracing in unified kernel
- https://gerrit.zephyrproject.org/r/4519 : unified/sys_timer: guard microkernel announce with !KERNEL_V2
- https://gerrit.zephyrproject.org/r/4517 : unified: include kernel.h via major top-level header files
- https://gerrit.zephyrproject.org/r/4512 : unified/build: adapt Kbuild for unified kernel
- https://gerrit.zephyrproject.org/r/4518 : unified/drivers: adapt timer drivers to unified kernel
- https://gerrit.zephyrproject.org/r/4516 : workqueue: use kernel.h for workqueue header file
- https://gerrit.zephyrproject.org/r/4513 : unified/arm: add unified kernel support for ARM arch
- https://gerrit.zephyrproject.org/r/4515 : atomic: fix bug in ATOMIC_INIT()
- https://gerrit.zephyrproject.org/r/4507 : sysgen: add --kernel_type argument
- https://gerrit.zephyrproject.org/r/4514 : unified/x86: add unified kernel support for x86 arch
- https://gerrit.zephyrproject.org/r/4510 : arm: only compile gdb stubs when CONFIG_GDB_INFO=y
- https://gerrit.zephyrproject.org/r/4509 : arm: add __ASSERT() for stack alignment
- https://gerrit.zephyrproject.org/r/4508 : build: only generate the SSE group for x86
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: Tinycrypt shim driver
- https://gerrit.zephyrproject.org/r/3459 : soc: Add soc id and version interface
- https://gerrit.zephyrproject.org/r/4473 : i2c: Fix restart flag in burst read
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC
- https://gerrit.zephyrproject.org/r/4475 : samples/drivers/uart: Fix line endings
- https://gerrit.zephyrproject.org/r/4474 : uart_console: Fix line endings
- https://gerrit.zephyrproject.org/r/4476 : samples/uart: More boards

MERGED within last 24 hours:


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

Kumar Gala
 

On Aug 17, 2016, at 5:20 AM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

Did not expect this to generate such a big discussion. Here is a use case in addition to what was mentioned in the thread below. Think of this API as a helper API for higher lever features and not a way to select/deselect features based on HW.
I’d rather see the higher level feature that needs this first. Meaning, show me patch series that needs this info and than it will become far more clear what we should be doing. Until than I don’t think just adding a new API makes sense.

Depending on the HW/MCU being used, getting the hardware information such as model number, vendor ID, hardware revision might vary in complexity so implementing this for supported SOCs makes a lot of sense using an API that can be used by applications and higher level features such as IOT protocols. Originally this ZEP was created to prepare for LWM2M and specifically the device profile:

http://dev_devtoolkit.openmobilealliance.org/IoT/LWM2M10/doc/TS/index.html#!Documents/lwm2mobjectdevice.htm

To prepare for the implementation of the profile and to avoid implementing this for the various MCUs in different places where it can be used, the API was proposed.
For LWM2M is using SoC info actually the right choice? Should this be board specified?

Feeding this type of data at build time is always an option, but I do not think it makes sense in this case and especially when the HW has lots of information stored already that would make it very difficult to fill in at build time. Doing this at build time will encourage developers and users to enter random data and things like TODO or XYZ all over the place, just to get their app to build and move on. Why bother if the data is already provided by the hardware?

Uniqueness of the data is not key here, multiple boards of the same HW might end up generating the same ID, however, this depends on the hardware and some cases such data can be combined with other sources to achieve this.
I’m not sure I follow why uniqueness isn’t key.



Anas






On 29/07/2016, 23:48, "Kumar Gala" <kumar.gala(a)linaro.org> wrote:

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: 1
[ZEP-768] Move defaults.tc and .known-issue under tests/
https://jira.zephyrproject.org/browse/ZEP-768


UPDATED JIRA items within last 24 hours: 1
[ZEP-767] Add FS API to flush cache of an open file
https://jira.zephyrproject.org/browse/ZEP-767


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4500 : usb: add Kconfig options for CDC ACM VID/PID
- https://gerrit.zephyrproject.org/r/4534 : Bluetooth: GATT: Fix unaligned accesses
- https://gerrit.zephyrproject.org/r/4532 : fix: net samples no longer include unneeded 802.15.4 files
- https://gerrit.zephyrproject.org/r/4499 : TCF: disable running single core testcases on Quark SE's x86+arc
- https://gerrit.zephyrproject.org/r/4533 : TCF: specify ARCH when creating initconfig
- https://gerrit.zephyrproject.org/r/4505 : kernel: add CONFIG_MDEF
- https://gerrit.zephyrproject.org/r/4503 : slist: add sys_slist_get() to fetch and remove the head
- https://gerrit.zephyrproject.org/r/4509 : arm: add __ASSERT() for stack alignment
- https://gerrit.zephyrproject.org/r/4507 : sysgen: add --kernel_type argument
- https://gerrit.zephyrproject.org/r/4504 : slist: add sys_slist_append_list/slist()
- https://gerrit.zephyrproject.org/r/4510 : arm: only compile gdb stubs when CONFIG_GDB_INFO=y
- https://gerrit.zephyrproject.org/r/4501 : dlist: add SYS_DLIST_FOR_EACH_NODE/_SAFE
- https://gerrit.zephyrproject.org/r/4531 : build: allow building the unified kernel
- https://gerrit.zephyrproject.org/r/4529 : unified/test_fp: mark test so that it runs the nanokernel version
- https://gerrit.zephyrproject.org/r/4528 : unified/test_sema: fix isr wrapper names
- https://gerrit.zephyrproject.org/r/4530 : unified: initial unified kernel implementation
- https://gerrit.zephyrproject.org/r/4527 : unified: Fix test_sema/microkernel
- https://gerrit.zephyrproject.org/r/4526 : unified/test_timer: adapt for unified kernel
- https://gerrit.zephyrproject.org/r/4525 : unified/test_pipe: adapt to not use sem groups
- https://gerrit.zephyrproject.org/r/4524 : unified/test_mail: adapt test to not use sem groups and mem pools
- https://gerrit.zephyrproject.org/r/4523 : unified/test_context: adapt test to run on unified kernel
- https://gerrit.zephyrproject.org/r/4522 : unified/tests: tag working tests on unified kernel as 'unified_capable'
- https://gerrit.zephyrproject.org/r/4521 : zperf_shell: add unified kernel string for unified kernel case
- https://gerrit.zephyrproject.org/r/4520 : unified/object_tracing: disable object tracing in unified kernel
- https://gerrit.zephyrproject.org/r/4519 : unified/sys_timer: guard microkernel announce with !KERNEL_V2
- https://gerrit.zephyrproject.org/r/4518 : unified/drivers: adapt timer drivers to unified kernel
- https://gerrit.zephyrproject.org/r/4517 : unified: include kernel.h via major top-level header files
- https://gerrit.zephyrproject.org/r/4516 : workqueue: use kernel.h for workqueue header file
- https://gerrit.zephyrproject.org/r/4515 : atomic: fix bug in ATOMIC_INIT()
- https://gerrit.zephyrproject.org/r/4514 : unified/x86: add unified kernel support for x86 arch
- https://gerrit.zephyrproject.org/r/4512 : unified/build: adapt Kbuild for unified kernel
- https://gerrit.zephyrproject.org/r/4513 : unified/arm: add unified kernel support for ARM arch
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/4508 : build: only generate the SSE group for x86
- https://gerrit.zephyrproject.org/r/4506 : build: make sysgen take optional command line arguments
- https://gerrit.zephyrproject.org/r/4502 : dlist: add static initialization macro
- https://gerrit.zephyrproject.org/r/4496 : fix: fstat return value is now being checked
- https://gerrit.zephyrproject.org/r/4497 : TCF: update defaults to use configuration fragments
- https://gerrit.zephyrproject.org/r/4498 : TCF: default Quark SE's ARC core to use UART1 as console for testing

UPDATED within last 24 hours:
- 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/4327 : fix: "uninitialized" variables break DEBUG sanity
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- https://gerrit.zephyrproject.org/r/4460 : kconfig: include configuration fragment files from output directory
- https://gerrit.zephyrproject.org/r/4372 : fs: Adds file system API to grow or shrink a file
- https://gerrit.zephyrproject.org/r/4485 : sample: fs: Add tests for fs_truncate and fs_statvfs
- https://gerrit.zephyrproject.org/r/4478 : fs: Adds file system API to get volume statistics
- https://gerrit.zephyrproject.org/r/4473 : i2c: Fix restart flag in burst read
- https://gerrit.zephyrproject.org/r/4479 : Bluetooth: Controller: Measure and use correct stack size
- https://gerrit.zephyrproject.org/r/4472 : i2c: ksdk: Add shim driver
- https://gerrit.zephyrproject.org/r/4461 : i2c: qmsi_shim: change some i2c config parameters to SoC specific
- https://gerrit.zephyrproject.org/r/4482 : mqtt: Remove the app_buf structure
- https://gerrit.zephyrproject.org/r/3843 : zephyr: remove deprecated dynamic interrupt API
- https://gerrit.zephyrproject.org/r/4139 : TCF: Tags test previously broken by ARC-x86 communication issue
- https://gerrit.zephyrproject.org/r/3846 : arc: remove deprecated dynamic interrupt implementation
- https://gerrit.zephyrproject.org/r/3845 : x86: remove dynamic interrupts and exceptions
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC

MERGED within last 24 hours:


[RFC] Hardware crypto APIs

Joseph, Jithu
 

The purpose of these APIs, is to provide applications, a hardware independent way to perform encryption/decryption (ZEP-328 - https://jira.zephyrproject.org/browse/ZEP-328 ).
In other words Crypto hardware drivers implement functions as mandated by the header file, and apps can use the standard driver model way to open the crypto device and invoke functions (defined in the header), to realize cipher operations (encryption/decryption), using standard cipher modes like ECB, CBC, CTR etc.

Here are the list of patches and what they do :

1. cipher.h header (https://gerrit.zephyrproject.org/r/#/c/3311/ ) - defines the cipher interface for encryption/decryption.

2. Sample driver - https://gerrit.zephyrproject.org/r/#/c/3312 -A sample driver using the above interface (and using tinycrypt s/w library for actual encryption)

3. Sample app - https://gerrit.zephyrproject.org/r/#/c/3313/ - Sample app using the crypto interface

Cipher.h primer - Apps are meant to first open a context, by specifying one time parameters like key, algorithm and modes (via cipher_ctx struct). These one-time parameters are used to program the hardware crypto block . The driver returns the corresponding encryption, decryption functions pointers relevant to the chosen mode. Subsequently, apps can invoke them (multiple times) using standard "mode" functions defined in the header. The below sequence diagram tries to portray this pictorially. (You will need to enable fixed font size in mail client to see it as intended . e.g on outlook File > Options > Mail > Stationery and Fonts > Set the font for plain text e-mails to a monospaced font (say) Courier New. )

+-------------------------------------------------------------------------------------------------+
| +-------+ +---------+ +-------------+ |
| | App | |Crypto | | Crypto | |
| +---+---+ |Driver | | H/W block | |
| | +----+----+ +-------+-----+ |
| | | | |
| +-------------------------------------------------------------------------------------+ |
| | | Session Context setup phase | | | |
| +-------------------------------------------------------------------------------------+ |
| | +--------------------------------+ | | |
| | |cipher_begin_session(*dev, *ctx)| | | |
| +---------->where: +------> program h/w | |
| | |ctx -> Key, Algo type, mode etc | +----+with one time->| |
| | +--------------------------------+ | parameters | |
| | | | |
| | returns function pointers corresponding | | |
| <-------to the selected mode in ctx->ops <-----+ | |
| | | | |
| +-------------------------------------------------------------------------------------+ |
| | |Operation Phase (possibly repeated multiple times)| | | |
| +-------------------------------------------------------------------------------------+ |
| | +------------------------------+ | | |
| | | cipher_xx_yy(*ctx, *pkt, ..) | | | |
| +---> | where: | | | |
| | +---------> Pkt -> Input/Output buffers +---------> | |
| | | | xx -> mode (ecb,cbc, ctr etc)| +--------------------> |
| |nex| | yy -> encrypt / decrypt | <--------------------+ |
| |op | | .. -> IVs, CTRs (mode spec) | | | |
| | | +------------------------------+ | | |
| ^ | | | |
| | Provide the result | | |
| | | <------------------------------------------------+ | |
| +---+ | | |
| +------------------------------------------------------------------------------------+ |
| | | Session Freeing phase | | | |
| +------------------------------------------------------------------------------------+ |
| | | | |
| | cipher_free_session(*dev, *ctx) | | |
| +------------------------------------------------> | Clear session info |
| | +---from h/w---------> |
| | | | |
| <--------------------------------------------------+ | |
| | | | |
| | | | |
| -------------------------------------------------------------------------------------------+ |
| +---v---+ +---------+ +-------v-----+ |
| | App | |Crypto | | Crypto | |
| +-------+ |Driver | | H/W block | |
| +---------+ +-------------+ |
| |
| |
+-------------------------------------------------------------------------------------------------+

This interface is expected to evolve as SOCs with hardware crypto support start coming in (with possibly newer requirements) , the current API is intended as a starting point. Comments are welcome.


Thanks
Jithu


[Acknowledgments : Geoffrey Thorpe <geoff.thorpe(a)nxp.com> and Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>, for their initial review comments on gerrit ]


Re: Proposal to streamline GPIO, Pinmux driver API

Liu, Baohong
 

Hi,

-----Original Message-----
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Friday, September 2, 2016 3:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Proposal to streamline GPIO, Pinmux driver API

Hello Community,

I would like to discuss GPIO / Pinmux driver combo which I believe become
overcomplicated and may be confusing for a regular user.

The current API seems to be designed around Intel Quark architecture and
QMSI SDK. In Quark there are separate Pinmux and GPIO modules and so we
got separate Pinmux and GPIO drivers. However, in most chipsets GPIO
module takes care of both PIO (reading/writing from/to a pin) and pin
muxing (connecting pin to a peripheral/PIO controller). By now the functional
split between the two drivers become blurred and is overlapping.

Some examples:

At present GPIO driver defines GPIO_PUD_PULL_UP (Enable GPIO pin pull-
up) to be used with gpio_pin_configure() function and Pinmux driver has
pinmux_pin_pullup() function. Both are meant to do the same thing
however gpio_pin_configure() will not work with Intel Quark chips and
pinmux_pin_pullup() will mostly not work with other chips e.g.
Freescale/NXP FRDM-K64F. Still some chipsets e.g. Atmel SAM3x implement
both functions but then even for Atmel SAM3x setting pin pull-down is only
possible via gpio_pin_configure() function.

pinmux_pin_input_enable() function is used by Quark chips to
disable/enable input pad and gpio_pin_configure() to set pin as input or
output. This is not easily rendered from the function's name/description and
in fact Atmel SAM3x driver implements pinmux_pin_input_enable() to
configure pin as input or output overlapping it with the same functionality
provided by gpio_pin_configure().

In case of ARM based chips e.g. Atmel SAM3x, Freescale/NXP FRDM-K64F to
configure pin with pull-up and connect it to external peripheral one needs to
call pinmux_pin_set() which takes as an argument pin index, e.g. pin PB2,
third pin on port B would have index 34 and gpio_pin_configure() which
takes as an argument port and port's pin number, e.g. PB2 has number 2. So
in two subsequent calls we need to use different pin values even if we
operate on the same pin. While this may be convenient for Quark chips it is
not for other chip families.

Currently it is not really possible to know which function should be used
when and how without analyzing Zephyr's source code.

I believe that split between Pinmux and GPIO driver is not a good general
solution and in case we preserve the current API it will soon become even
more convoluted.

I would like to propose to phase out Pinmux driver and implement pin
multiplexing in GPIO driver. That would require adding something like
GPIO_FUNC_A, ..., GPIO_FUNC_D to GPIO API.

Other possibility would be to limit Pinmux driver only to architectures that
really need it, like Quark chips. Having pin multiplexing available
simultaneously in GPIO and Pinmux driver will be confusing for Quark users,
however that's already the case with pull-up configuration.

I haven't created a Jira issue, neither RFC in Gerrit yet. At first I would like to
get a quick feedback if you find my arguments sensible.

Thanks,
Piotr
Some confusion does exist when these APIs are used across platforms.
But, for QUARK, the boundary is clear and there is no overlapping;
Combining them into one is not conceptually right.


Re: How to handle a board with a dozen SoC's?

Jon Medhurst (Tixy) <tixy@...>
 

On Fri, 2016-09-02 at 15:29 +0000, Nashif, Anas wrote:
Ok, there is a JIRA about board/soc structure documentation already
and it happens to be assigned to me, I will address this ASAP
Thanks, that would be helpful. I've been using existing code as examples
and decoding Makefiles to see what's possible, but I'm aware that the
end result would probably not be a desirable or 'best' solution :-)

My situation is also the inverse of the normal common SoC being used on
multiple boards, as I have multiple SoC's custom made for a fixed board.

--
Tixy


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 3
[ZEP-762] unexpected "abspath" and "notdir" from mingw make system
https://jira.zephyrproject.org/browse/ZEP-762

[ZEP-764] Doc is being built for no reason and fails
https://jira.zephyrproject.org/browse/ZEP-764

[ZEP-763] Samples:README: samples/drivers/I2c_stts751 describes error
https://jira.zephyrproject.org/browse/ZEP-763


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

[ZEP-753] Make I2C_SDA_HOLD and I2C_SDA_SETUP SoC specific
https://jira.zephyrproject.org/browse/ZEP-753

[ZEP-233] Support USB mass storage device class
https://jira.zephyrproject.org/browse/ZEP-233


CLOSED JIRA items within last 24 hours: 2
[ZEP-12] (Fixed) Create a generic 802.15.4 driver API
https://jira.zephyrproject.org/browse/ZEP-12

[ZEP-517] (Fixed) build on windows failed "zephyr/Makefile:869: *** multiple target patterns"
https://jira.zephyrproject.org/browse/ZEP-517


RESOLVED JIRA items within last 24 hours: 4
[ZEP-451] (Fixed) Quark SE output by default redirected to IPM
https://jira.zephyrproject.org/browse/ZEP-451

[ZEP-546] (Fixed) UART interrupts not triggered on ARC
https://jira.zephyrproject.org/browse/ZEP-546

[ZEP-471] (Fixed) Ethernet packet with multicast address is not working
https://jira.zephyrproject.org/browse/ZEP-471

[ZEP-730] (Fixed) Zephyr documentation page references 1.5.0, but it's not yet released
https://jira.zephyrproject.org/browse/ZEP-730


Re: How to handle a board with a dozen SoC's?

Nashif, Anas
 

Ok, there is a JIRA about board/soc structure documentation already and it happens to be assigned to me, I will address this ASAP, this might help you with the issue below.

Anas

On 2 Sep 2016, at 11:23, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:
I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.
I realised this and $subject may be a bit ambiguous, I meant that the
FPGA can be programmed at any one time with a single CPU type chosen
from a range of a dozen or so. I'm not trying to support multiple CPU
and 'SoC' types in a single Zephyr image at the same time. I'm looking
at a separate image for each one.


Re: Proposal to streamline GPIO, Pinmux driver API

Nashif, Anas
 

Hi,

Some time ago the TSC discussed APIs in general and it was agreed that we need to revisit the APIs as we have them right when there is critical mass of architecture and board support and I think we are getting there.

On Pinmux I agree it is low level and SOC specific, You have a very good story here that can be added to Jira.


Anas

On 2 Sep 2016, at 06:21, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

Hello Community,

I would like to discuss GPIO / Pinmux driver combo which I believe become overcomplicated and may be confusing for a regular user.

The current API seems to be designed around Intel Quark architecture and QMSI SDK. In Quark there are separate Pinmux and GPIO modules and so we got separate Pinmux and GPIO drivers. However, in most chipsets GPIO module takes care of both PIO (reading/writing from/to a pin) and pin muxing (connecting pin to a peripheral/PIO controller). By now the functional split between the two drivers become blurred and is overlapping.

Some examples:

At present GPIO driver defines GPIO_PUD_PULL_UP (Enable GPIO pin pull-up) to be used with gpio_pin_configure() function and Pinmux driver has pinmux_pin_pullup() function. Both are meant to do the same thing however gpio_pin_configure() will not work with Intel Quark chips and pinmux_pin_pullup() will mostly not work with other chips e.g. Freescale/NXP FRDM-K64F. Still some chipsets e.g. Atmel SAM3x implement both functions but then even for Atmel SAM3x setting pin pull-down is only possible via gpio_pin_configure() function.

pinmux_pin_input_enable() function is used by Quark chips to disable/enable input pad and gpio_pin_configure() to set pin as input or output. This is not easily rendered from the function's name/description and in fact Atmel SAM3x driver implements pinmux_pin_input_enable() to configure pin as input or output overlapping it with the same functionality provided by gpio_pin_configure().

In case of ARM based chips e.g. Atmel SAM3x, Freescale/NXP FRDM-K64F to configure pin with pull-up and connect it to external peripheral one needs to call pinmux_pin_set() which takes as an argument pin index, e.g. pin PB2, third pin on port B would have index 34 and gpio_pin_configure() which takes as an argument port and port's pin number, e.g. PB2 has number 2. So in two subsequent calls we need to use different pin values even if we operate on the same pin. While this may be convenient for Quark chips it is not for other chip families.

Currently it is not really possible to know which function should be used when and how without analyzing Zephyr's source code.

I believe that split between Pinmux and GPIO driver is not a good general solution and in case we preserve the current API it will soon become even more convoluted.

I would like to propose to phase out Pinmux driver and implement pin multiplexing in GPIO driver. That would require adding something like GPIO_FUNC_A, ..., GPIO_FUNC_D to GPIO API.

Other possibility would be to limit Pinmux driver only to architectures that really need it, like Quark chips. Having pin multiplexing available simultaneously in GPIO and Pinmux driver will be confusing for Quark users, however that's already the case with pull-up configuration.

I haven't created a Jira issue, neither RFC in Gerrit yet. At first I would like to get a quick feedback if you find my arguments sensible.

Thanks,
Piotr


Re: How to handle a board with a dozen SoC's?

Jon Medhurst (Tixy) <tixy@...>
 

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:
I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.
I realised this and $subject may be a bit ambiguous, I meant that the
FPGA can be programmed at any one time with a single CPU type chosen
from a range of a dozen or so. I'm not trying to support multiple CPU
and 'SoC' types in a single Zephyr image at the same time. I'm looking
at a separate image for each one.

--
Tixy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4472 : i2c: ksdk: Add shim driver
- https://gerrit.zephyrproject.org/r/4473 : i2c: Fix restart flag in burst read
- https://gerrit.zephyrproject.org/r/4491 : net: revert tcpip_poll_tcp() to not require a data_buf
- https://gerrit.zephyrproject.org/r/4490 : Bluetooth: UUID: Add 32bit UUID support
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/4489 : Bluetooth: SDP: Server: Support ServiceAttrReq and ServiceSearchAttrReq
- https://gerrit.zephyrproject.org/r/4488 : Bluetooth: SDP: Server: Support ServiceSearchRequest
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4479 : Bluetooth: Controller: Measure and use correct stack size
- https://gerrit.zephyrproject.org/r/4485 : sample: fs: Add tests for fs_truncate and fs_statvfs
- https://gerrit.zephyrproject.org/r/4484 : drivers/pinmux: delete deprecated PINMUX_DEV_QUARK_MCU
- https://gerrit.zephyrproject.org/r/4483 : drivers/pinmux: fix CONFIG_PINMUX_DEV_NAME dependency issue
- https://gerrit.zephyrproject.org/r/4480 : fs: Add file system API to flush cache of an open file
- https://gerrit.zephyrproject.org/r/4478 : fs: Adds file system API to get volume statistics
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC
- https://gerrit.zephyrproject.org/r/4474 : uart_console: Fix line endings
- https://gerrit.zephyrproject.org/r/4476 : samples/uart: More boards
- https://gerrit.zephyrproject.org/r/4475 : samples/drivers/uart: Fix line endings
- https://gerrit.zephyrproject.org/r/4471 : sanitycheck: allow extra arguments to be passed to the build

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4456 : net/ip: Fix warnings when enabling IP debugging
- https://gerrit.zephyrproject.org/r/4282 : net: fetch valid conn. to determine MSS in data_is_sent_and_acked()
- https://gerrit.zephyrproject.org/r/3934 : SDP Server
- https://gerrit.zephyrproject.org/r/4055 : Bluetooth: SDP: Server implementation
- https://gerrit.zephyrproject.org/r/3848 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/4372 : fs: Adds file system API to grow or shrink a file
- https://gerrit.zephyrproject.org/r/4139 : TCF: adds test fixed by ZEP-704
- https://gerrit.zephyrproject.org/r/4371 : win-build: fixes to build with alternative make implementations
- 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/4461 : i2c: qmsi_shim: change some i2c config parameters to SoC specific
- https://gerrit.zephyrproject.org/r/4360 : ksdk: Add KSDK RNGA driver.
- https://gerrit.zephyrproject.org/r/4445 : ksdk: Build ksdk fsl_enet.c and fsl_phy.c
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE
- https://gerrit.zephyrproject.org/r/4460 : kconfig: include configuration fragment files from output directory

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4470 : Only build nav.yaml if docs successfully built
- https://gerrit.zephyrproject.org/r/4415 : Bluetooth: HoG: Require authentication for connections
- https://gerrit.zephyrproject.org/r/4414 : Bluetooth: Add sample implementing HIDS
- https://gerrit.zephyrproject.org/r/4413 : Bluetooth: Add service sample for HoG
- https://gerrit.zephyrproject.org/r/4469 : Bluetooth: btp: Extend BTP specification to cover L2CAP tests


How to handle a board with a dozen SoC's?

Jon Medhurst (Tixy) <tixy@...>
 

Hi

I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.

[1] https://www.arm.com/products/tools/development-boards/versatile-express/cortex-m-prototyping-system.php

It seems to me that 'BOARD' is what the build system expects to use to
specify the thing to build, but adding a dozen new boards under /boards
(one for each 'SoC') doesn't seem the right way to go - and I would then
need somewhere to put the common code for the physical board.

I'm going to be in a similar situation for creating my dozen or so SoC's
but I believe that the build system may be a bit more flexible in that
situation, with SOC_FAMILY and SOC_SERIES.

As well as the hardware board there is a host of software simulations
[2] for similar but differing configurations as the hardware. I don't
believe that adds any extra complexity though, apart from the number of
ever expanding versions and them not being definitively identified by
name or number. Oh joy...

[2] https://developer.arm.com/docs/dui0837/latest/programming-reference-for-mps2-fvps/mps2-about

Thanks for any advice.

--
Tixy


Re: Porting to Cortex-M0+

Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi Maureen,

Another member of the TSC will follow up with Atmel.
Thanks, I will wait for the green light. My Atmel SAM E70 port works well in my local workarea, I have everything necessary for initial support apart from UART driver. There are still a few minor implementation details I'll have to discuss but I'll do it later in a separate thread when I know I am supposed to work on it.

I have one more question to the design flow I could not find a clear answer in the wiki to. As I have mentioned I would like to add support for Atmel SAM E70 chipset, I've already opened a Jira issue. I expect that now before doing the actual job and especially before trying to push anything to Gerrit I need to wait until the task is officially accepted and assigned to me, isn't it?

Cheers,
Piotr


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Rohit Grover
 

Paul, Jukka,

> On Thu, 1 Sep 2016 14:47:41 +0000
> Rohit Grover <Rohit.Grover(a)arm.com> wrote:
>
> > Jukka, Paul,
> >
> > I believe we should go ahead and fix tcpip_poll_tcp() according to the
> > patch I submitted previously. This fix can supersede
> > https://gerrit.zephyrproject.org/r/#/c/4226, and we can pause on that
> > particular pull request for now.
>
> +1. Would you submit it to Gerrit?
>

Submitted https://gerrit.zephyrproject.org/r/#/c/4491/

Regards,
Rohit.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: Request to have generic sensor support

Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

Hello Kasim,

The sensor types from sensor.h are in no way final, and new types can be
added as the need arises for new drivers.

Not sure if your driver could define a more specific type (that may be
useful for other future drivers) rather then a generic one, but a
generic data type can be easily added.

For sending generic data to the driver, you can add a
SENSOR_ATTR_USER_DATA attribute, a SENSOR_VALUE_TYPE_USER_DATA value
type and a void *user_data field in the union from struct sensor_value.

Sending generic data back to the application can be done by adding a
SENSOR_CHAN_USER_DATA channel (together with the generic sensor value
type and filed).

Best regards,
Bogdan

On Jo, 2016-09-01 at 14:19 +0000, kasim shibi wrote:


Hi All,


I happened to work on a sensor
driver in zephyr 1.4. The
"sensor.h" provides support for
very few sensors.
Moreover lack of support for any
custom/generic data to pass between
the application and driver.
Please correct me if i am wrong.

I am looking for an option to pass
an array (1024 bytes), where the
internal data format i can
define/manage between my driver and
application.


If at all , only choice is to add
as a new sensor. Please share the
steps for the zephyr team to add
support for a new sensor.


Thanks
Kasim




Proposal to streamline GPIO, Pinmux driver API

Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hello Community,

I would like to discuss GPIO / Pinmux driver combo which I believe become overcomplicated and may be confusing for a regular user.

The current API seems to be designed around Intel Quark architecture and QMSI SDK. In Quark there are separate Pinmux and GPIO modules and so we got separate Pinmux and GPIO drivers. However, in most chipsets GPIO module takes care of both PIO (reading/writing from/to a pin) and pin muxing (connecting pin to a peripheral/PIO controller). By now the functional split between the two drivers become blurred and is overlapping.

Some examples:

At present GPIO driver defines GPIO_PUD_PULL_UP (Enable GPIO pin pull-up) to be used with gpio_pin_configure() function and Pinmux driver has pinmux_pin_pullup() function. Both are meant to do the same thing however gpio_pin_configure() will not work with Intel Quark chips and pinmux_pin_pullup() will mostly not work with other chips e.g. Freescale/NXP FRDM-K64F. Still some chipsets e.g. Atmel SAM3x implement both functions but then even for Atmel SAM3x setting pin pull-down is only possible via gpio_pin_configure() function.

pinmux_pin_input_enable() function is used by Quark chips to disable/enable input pad and gpio_pin_configure() to set pin as input or output. This is not easily rendered from the function's name/description and in fact Atmel SAM3x driver implements pinmux_pin_input_enable() to configure pin as input or output overlapping it with the same functionality provided by gpio_pin_configure().

In case of ARM based chips e.g. Atmel SAM3x, Freescale/NXP FRDM-K64F to configure pin with pull-up and connect it to external peripheral one needs to call pinmux_pin_set() which takes as an argument pin index, e.g. pin PB2, third pin on port B would have index 34 and gpio_pin_configure() which takes as an argument port and port's pin number, e.g. PB2 has number 2. So in two subsequent calls we need to use different pin values even if we operate on the same pin. While this may be convenient for Quark chips it is not for other chip families.

Currently it is not really possible to know which function should be used when and how without analyzing Zephyr's source code.

I believe that split between Pinmux and GPIO driver is not a good general solution and in case we preserve the current API it will soon become even more convoluted.

I would like to propose to phase out Pinmux driver and implement pin multiplexing in GPIO driver. That would require adding something like GPIO_FUNC_A, ..., GPIO_FUNC_D to GPIO API.

Other possibility would be to limit Pinmux driver only to architectures that really need it, like Quark chips. Having pin multiplexing available simultaneously in GPIO and Pinmux driver will be confusing for Quark users, however that's already the case with pull-up configuration.

I haven't created a Jira issue, neither RFC in Gerrit yet. At first I would like to get a quick feedback if you find my arguments sensible.

Thanks,
Piotr

6741 - 6760 of 8113