Date   

Gerrit changes

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1213 : test: ignore
- https://gerrit.zephyrproject.org/r/1212 : Zephyr 1.2.0
- https://gerrit.zephyrproject.org/r/1211 : sanitychecks: update footprint numbers
- https://gerrit.zephyrproject.org/r/1210 : Bluetooth: Add support for reading local address from storage
- https://gerrit.zephyrproject.org/r/1209 : Bluetooth: Add skeleton for persistent storage API
- https://gerrit.zephyrproject.org/r/1207 : Bluetooth: Remove unnecessary double check for CONFIG_BLUETOOTH_CONN
- https://gerrit.zephyrproject.org/r/1206 : Bluetooth: Shorten set_adv_parameters to set_adv_param
- https://gerrit.zephyrproject.org/r/1208 : Bluetooth: Rework local address tracking
- https://gerrit.zephyrproject.org/r/1197 : tests: enable pinmux build tests
- https://gerrit.zephyrproject.org/r/1203 : gpio/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1205 : gcc-4.sc.iamcu.inc: Enable LTO
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/1202 : Bluetooth: tester: Return pre defined db offset on start server
- https://gerrit.zephyrproject.org/r/1200 : Bluetooth: tester: Update server commands with sequence params
- https://gerrit.zephyrproject.org/r/1199 : drivers/nble: Add support for attr iteration functions
- https://gerrit.zephyrproject.org/r/1195 : meta-zephyr-sdk-clone-0.7.5.sh: Use Gerrit repo

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/932 : drivers: Quark flash support
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel primer
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental sensing sample for Arduino 101

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1196 : pinmux/galileo: include board.h
- https://gerrit.zephyrproject.org/r/1198 : job: gerrit changes: new job to send changes in gerrit.
- https://gerrit.zephyrproject.org/r/1192 : arduino_101/quark_se_devboard: speed up flashing the SS


Gerrit changes

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1199 : drivers/nble: Add support for attr iteration functions
- https://gerrit.zephyrproject.org/r/1195 : meta-zephyr-sdk-clone-0.7.5.sh: Use Gerrit repo
- https://gerrit.zephyrproject.org/r/1197 : tests: enable pinmux build tests
- https://gerrit.zephyrproject.org/r/1196 : pinmux/galileo: include board.h
- https://gerrit.zephyrproject.org/r/1203 : gpio/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1202 : Bluetooth: tester: Return pre defined db offset on start server
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/1200 : Bluetooth: tester: Update server commands with sequence params
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental sensing sample for Arduino 101
- https://gerrit.zephyrproject.org/r/1180 : spi_dw: use SPI bus frequency in spi_dw_configure()
- https://gerrit.zephyrproject.org/r/1177 : drivers/nble: Refactor Nordic BLE chip enable functions
- https://gerrit.zephyrproject.org/r/1178 : ia32: Allow to connect Nordic chip to qemu
- https://gerrit.zephyrproject.org/r/1170 : galileo: Enable PCI enumeration

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1159 : bmi160: Add sample application
- https://gerrit.zephyrproject.org/r/1158 : sensor: add driver for BMI160
- https://gerrit.zephyrproject.org/r/1157 : sensor.h: Add helper functions for unit conversions
- https://gerrit.zephyrproject.org/r/1156 : sensor.h: add new attributes
- https://gerrit.zephyrproject.org/r/1129 : samples/nble: Remove default driver debug for samples
- https://gerrit.zephyrproject.org/r/1130 : drivers/nble: Implement GATT read Characteristic Presentation Format
- https://gerrit.zephyrproject.org/r/995 : quark_se_devboard: Enable NBLE for quark_se_devboard in Kconfig
- https://gerrit.zephyrproject.org/r/1072 : drivers/nble: Implement notification response
- https://gerrit.zephyrproject.org/r/996 : quark_se_devboard: Configure UART0 for quark_se_devboard
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel primer
- https://gerrit.zephyrproject.org/r/1161 : doc: Add sensor section in API documentation
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/932 : drivers: Quark flash support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1198 : job: gerrit changes: new job to send changes in gerrit.
- https://gerrit.zephyrproject.org/r/1192 : arduino_101/quark_se_devboard: speed up flashing the SS
- https://gerrit.zephyrproject.org/r/1187 : tests: bluetooth/shell: exclude STM32F103RB from microkernel test
- https://gerrit.zephyrproject.org/r/1181 : sanitycheck: add nucleo_f103rb abd stm32_mini_a15
- https://gerrit.zephyrproject.org/r/1183 : samples: shell: declare commands as const
- https://gerrit.zephyrproject.org/r/1184 : bluetooth: shell: declare commands as const
- https://gerrit.zephyrproject.org/r/1188 : samples: bluetooth: ipsp: exclude STM32F103RB from the test
- https://gerrit.zephyrproject.org/r/1185 : test_tickless: disable test for STM32 SoCs
- https://gerrit.zephyrproject.org/r/1182 : console: shell: expect const commands array
- https://gerrit.zephyrproject.org/r/1186 : test_sha256: disable test for STM32F103RB SoC
- https://gerrit.zephyrproject.org/r/1189 : arm: linker: fix indentation
- https://gerrit.zephyrproject.org/r/1191 : sensor: bmp280: fix pressure value
- https://gerrit.zephyrproject.org/r/1174 : pinmux: Fix where to look for PINMUX_BASE_ADDR
- https://gerrit.zephyrproject.org/r/1175 : Bluetooth: Move supported commands reading to common_init()
- https://gerrit.zephyrproject.org/r/1176 : Bluetooth: Make controller to host flow control conditional
- https://gerrit.zephyrproject.org/r/1173 : Zephyr v1.2.0-rc2
- https://gerrit.zephyrproject.org/r/1169 : galileo: Fix SPI driver init level
- https://gerrit.zephyrproject.org/r/1171 : arm: Fix wrong function comment
- https://gerrit.zephyrproject.org/r/1149 : boards: arduino_101: Enable SPI flash only when SPI is enabled
- https://gerrit.zephyrproject.org/r/991 : Bluetooth: BR/EDR: Enable cancel Passkey Notify authentication
- https://gerrit.zephyrproject.org/r/1070 : Bluetooth: GATT: Force write to CCC when reconnecting
- https://gerrit.zephyrproject.org/r/1071 : drivers/nble: Implement read CUD attribute
- https://gerrit.zephyrproject.org/r/1054 : include: misc: Add a generic single linked list API
- https://gerrit.zephyrproject.org/r/1102 : test_fifo: Reorganize directories
- https://gerrit.zephyrproject.org/r/1165 : samples/drivers: extend PWM app to FRDM_K64F
- https://gerrit.zephyrproject.org/r/1163 : gpio/sch: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1153 : tests: kernel: test_pool: reduce ram requirements
- https://gerrit.zephyrproject.org/r/1155 : tests: Add a test suite for the single linked list generic
- https://gerrit.zephyrproject.org/r/1168 : rtc/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1131 : test_fifo: Fix issues flagged by checkpatch
- https://gerrit.zephyrproject.org/r/1154 : tests: kernel: test_context: reduce ram requirements
- https://gerrit.zephyrproject.org/r/1166 : pwm/k64_ftm: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1164 : pwm/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1152 : tests: kernel: reduce ram requirements
- https://gerrit.zephyrproject.org/r/1167 : watchdog/wdt_dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1160 : eth_dw: fix buffer leak when RX frames are too large
- https://gerrit.zephyrproject.org/r/1145 : i2c: qmsi: Add support for default configuration
- https://gerrit.zephyrproject.org/r/1109 : arm: Disable unaligned access traps


Zephyr 1.2.0-rc2 tagged

Nashif, Anas
 

Hi,
We tagged release candidate 2 and planning to release 1.2.0 end of the day Friday. There are already a few bug fixes on top of rc2 that will be in the final release.

Below is the log since 1.2.0-rc1:


Alexandre d'Alton (2):
arc: implement stack checking
arc: remove unecessary instruction and doc

Anas Nashif (6):
boards: remove atom defconfig from basic minute-ia
spi_test: remove dependency on driver name from kconfig
kconfig: use menuconfig for PCI options
sanity: add quark_se_devboard to tested boards
quark_d2000_crb: improve binary flashing speed
Zephyr v1.2.0-rc2

Andre Guedes (4):
pwm: Remove redundancy in Kconfig.qmsi
i2c: Remove redundancy in Kconfig.qmsi
doc: Add returning code conventions
i2c: qmsi: Add support for default configuration

Andrei Emeltchenko (1):
Bluetooth/shell: Fix wrong memory access

Andrew Boie (5):
compare_footprint: Python 3 compatibility
docs: clarify MINGW installation instructions
benchmarks: use portable static interrupt APIs
object-footprint: gitignore generated output
x86: irq: fix _get_dynamic_stub() calculation

Baohong Liu (1):
drivers: AON counters: Move interrupt setting to SOC Kconfig

Daniel Leung (21):
pinmux/galileo: extract kconfig options into its own file
pinmux: remove base address and number of pins from kconfig
refactor common driver initialization priorities
i2c/atmel_sam3: rename *_INT_PRIORITY to *_IRQ_PRI
i2c/dw: rename *_INT_PRIORITY to *_IRQ_PRI
i2c/qmsi: rename *_INT_PRIORITY to *_IRQ_PRI
arc/quark_se_ss: clean up soc.h
i2c/quark_se_ss: Remove base address kconfig options
serial/ns16550: reduce number of kconfig options
serial/ns16550: make IRQ triggering condition a SoC decision
console/uart: remove duplicate default value for parent UART dev
aio_comparator/dw: base address to be defined by SoC
i2c: remove orphan kconfig I2C_STATUS_DELAY
i2c/dw: remove kconfigs that are SoC specific
samples: enable sanity check of I2C driver on Arduino Due
gpio/sch: remove kconfigs that are SoC specific
pwm/dw: remove kconfigs that are SoC specific
samples/drivers: extend PWM app to FRDM_K64F
pwm/k64_ftm: remove kconfigs that are SoC specific
watchdog/wdt_dw: remove kconfigs that are SoC specific
rtc/dw: remove kconfigs that are SoC specific

Dmitriy Korovkin (3):
arm: Disable unaligned access traps
arm: Fix wrong function comment
galileo: Fix SPI driver init level

Johan Hedberg (2):
Bluetooth: samples/README: Fix sanitycheck references
Bluetooth: tests/shell: Add some help text

Mariusz Skamra (1):
drivers/console: Fix flush data on uart_pipe_setup

Peter Mitsis (2):
test_fifo: Fix issues flagged by checkpatch
test_fifo: Reorganize directories

Sebastien Griffoul (1):
eth_dw: fix buffer leak when RX frames are too large

Tomasz Bursztyka (4):
pinmux: Fix where to look for PINMUX_BASE_ADDR
gpio: dw: ISR handler should acknowlegde only current interrupts
include: misc: Add a generic single linked list API
tests: Add a test suite for the single linked list generic

Yannis Damigos (6):
Bluetooth: tester: Fix typo
tests: kernel: test-lifo: reduce ram requirements
tests: kernel: test-fifo: reduce ram requirements
tests: kernel: reduce ram requirements
tests: kernel: test_pool: reduce ram requirements
tests: kernel: test_context: reduce ram requirements

Makefile | 2 +-
arch/arc/Kconfig | 8 +
arch/arc/Makefile | 1 +
arch/arc/core/fast_irq.S | 20 +-
arch/arc/core/offsets/offsets.c | 3 +
arch/arc/core/regular_irq.S | 13 +
arch/arc/core/swap.S | 25 +-
arch/arc/core/thread.c | 6 +-
arch/arc/include/nano_private.h | 3 +
arch/arc/soc/quark_se_ss/Kconfig.defconfig | 40 --
arch/arc/soc/quark_se_ss/soc.h | 39 +-
arch/arc/soc/quark_se_ss/soc_config.c | 6 +-
arch/arm/core/fault.c | 1 -
arch/arm/defconfig | 1 -
arch/arm/soc/atmel_sam3/Kconfig.defconfig | 12 -
arch/arm/soc/fsl_frdm_k64f/Kconfig.defconfig | 16 -
arch/arm/soc/fsl_frdm_k64f/soc.h | 16 +
.../soc/st_stm32/stm32f1/Kconfig.defconfig.family | 16 -
arch/arm/soc/ti_lm3s6965/Kconfig.defconfig | 12 -
arch/x86/core/dynamic.c | 2 +-
arch/x86/soc/atom/Kconfig.defconfig | 31 -
arch/x86/soc/atom/soc.h | 27 +-
arch/x86/soc/ia32/Kconfig.defconfig | 31 -
arch/x86/soc/ia32/soc.h | 24 +-
arch/x86/soc/quark_d2000/Kconfig.defconfig | 75 +--
arch/x86/soc/quark_d2000/soc.h | 54 +-
arch/x86/soc/quark_se/Kconfig.defconfig | 89 +--
arch/x86/soc/quark_se/soc.h | 76 ++-
arch/x86/soc/quark_se/soc_config.c | 2 +-
arch/x86/soc/quark_x1000/Kconfig.defconfig | 107 +---
arch/x86/soc/quark_x1000/soc.h | 69 +-
boards/arduino_101/Kconfig.defconfig | 9 -
boards/arduino_101/arduino_101_defconfig | 1 -
boards/arduino_due/Kconfig.defconfig | 13 -
boards/basic_minuteia/basic_atom_defconfig | 17 -
boards/galileo/Kconfig.defconfig | 20 +-
boards/galileo/board.h | 9 +
boards/galileo/galileo_defconfig | 3 -
boards/minnowboard/minnowboard_defconfig | 1 -
boards/nucleo_f103rb/nucleo_f103rb_defconfig | 1 -
boards/qemu_x86/qemu_x86_defconfig | 1 -
boards/qemu_x86/qemu_x86_iamcu_defconfig | 1 -
boards/quark_d2000_crb/Kconfig.defconfig | 9 -
boards/quark_d2000_crb/support/openocd.cfg | 1 +
.../quark_se_devboard/quark_se_devboard_defconfig | 1 -
boards/stm32_mini_a15/stm32_mini_a15_defconfig | 1 -
doc/collaboration/code/code.rst | 1 +
doc/collaboration/code/error_code_conventions.rst | 36 ++
doc/getting_started/installation_win.rst | 18 +-
drivers/aio/Kconfig | 6 -
drivers/aio/aio_dw_comparator.c | 2 +-
drivers/clock_control/Kconfig.stm32f10x | 2 +-
drivers/clock_control/stm32f10x_clock.c | 2 +-
drivers/console/Kconfig | 4 +-
drivers/console/uart_console.c | 2 +-
drivers/console/uart_pipe.c | 8 +-
drivers/ethernet/eth_dw.c | 12 +-
drivers/gpio/Kconfig.sch | 31 -
drivers/gpio/gpio_dw.c | 2 +-
drivers/gpio/gpio_sch.c | 15 +-
drivers/i2c/Kconfig | 5 -
drivers/i2c/Kconfig.atmel_sam3 | 4 +-
drivers/i2c/Kconfig.dw | 82 +--
drivers/i2c/Kconfig.qmsi | 24 +-
drivers/i2c/Kconfig.quark_se_ss | 8 -
drivers/i2c/i2c_atmel_sam3.c | 4 +-
drivers/i2c/i2c_dw.c | 54 +-
drivers/i2c/i2c_qmsi.c | 14 +-
drivers/i2c/i2c_quark_se_ss.c | 4 +-
drivers/pci/Kconfig | 15 +-
drivers/pinmux/Kconfig | 65 +-
drivers/pinmux/dev/pinmux_dev_galileo.c | 4 +-
drivers/pinmux/dev/pinmux_dev_quark_mcu.c | 2 +-
drivers/pinmux/frdm_k64f/pinmux_k64.c | 4 +-
drivers/pinmux/galileo/Kconfig | 70 ++
drivers/pinmux/galileo/pinmux_board_galileo.c | 5 +-
drivers/pinmux/galileo/pinmux_galileo.c | 4 +-
.../pinmux/quark_mcu/pinmux_board_arduino_101.c | 5 +-
.../quark_mcu/pinmux_board_quark_d2000_crb.c | 5 +-
.../pinmux/quark_mcu/pinmux_board_quark_se_dev.c | 3 +-
drivers/pwm/Kconfig.dw | 15 -
drivers/pwm/Kconfig.k64 | 32 -
drivers/pwm/Kconfig.qmsi | 4 -
drivers/pwm/pwm_dw.c | 6 +-
drivers/pwm/pwm_k64_ftm.c | 13 +-
drivers/rtc/Kconfig | 28 +-
drivers/rtc/rtc_dw.c | 6 +-
drivers/rtc/rtc_qmsi.c | 4 +-
drivers/serial/Kconfig | 27 -
drivers/serial/Kconfig.ns16550 | 191 +-----
drivers/serial/uart_ns16550.c | 52 +-
drivers/shared_irq/Kconfig | 2 +-
drivers/spi/Kconfig.dw | 2 +-
drivers/watchdog/Kconfig | 12 -
drivers/watchdog/wdt_dw.c | 6 +-
include/arch/arc/v2/aux_regs.h | 5 +-
include/arch/arm/cortex_m/scb.h | 2 +-
include/arch/x86/arch.h | 6 +-
include/misc/slist.h | 236 +++++++
kernel/Kconfig | 2 +
samples/bluetooth/README | 6 +-
samples/drivers/grove_lcd/testcase.ini | 4 +-
samples/drivers/i2c_fujitsu_fram/testcase.ini | 6 +-
samples/drivers/pwm/Makefile | 6 +
samples/drivers/pwm/prj_arm.conf | 5 +
samples/drivers/pwm/prj_x86.conf | 6 +
samples/drivers/pwm/src/Makefile | 1 +
samples/drivers/pwm/src/main.c | 109 ++++
samples/drivers/pwm/testcase.ini | 6 +
samples/drivers/pwm_dw/Makefile | 6 -
samples/drivers/pwm_dw/prj_x86.conf | 6 -
samples/drivers/pwm_dw/src/Makefile | 1 -
samples/drivers/pwm_dw/src/main.c | 103 ---
samples/drivers/pwm_dw/testcase.ini | 6 -
samples/drivers/spi_test/src/spi.c | 11 +-
scripts/compare_footprint | 22 +-
scripts/sanity_chk/arches/arc.ini | 6 +-
scripts/sanity_chk/arches/x86.ini | 5 +-
.../benchmark/footprint/microkernel/float/arm.conf | 1 +
tests/benchmark/footprint/microkernel/max/arm.conf | 1 +
.../microkernel/src/microkernel_footprint.c | 42 +-
.../microkernel/src/test_asm_inline_gcc.h | 66 --
tests/benchmark/footprint/microkernel/testcase.ini | 3 -
tests/benchmark/footprint/nanokernel/max/arc.conf | 3 +
tests/benchmark/footprint/nanokernel/max/arm.conf | 1 +
tests/benchmark/footprint/nanokernel/reg/arc.conf | 2 +
.../nanokernel/src/nanokernel_footprint.c | 44 +-
.../footprint/nanokernel/src/test_asm_inline_gcc.h | 66 --
tests/benchmark/footprint/nanokernel/testcase.ini | 2 -
tests/benchmark/object_footprint/.gitignore | 2 +
.../object_footprint/src/nanokernel_objects.c | 42 +-
.../object_footprint/src/test_asm_inline_gcc.h | 67 --
tests/bluetooth/shell/src/main.c | 5 +-
tests/bluetooth/tester/testcase.ini | 2 +-
tests/kernel/test_context/src/Makefile | 1 -
tests/kernel/test_context/src/context.c | 4 +-
tests/kernel/test_fifo/Makefile | 6 -
tests/kernel/test_fifo/README.microkernel.txt | 86 ---
tests/kernel/test_fifo/README.nanokernel.txt | 121 ----
tests/kernel/test_fifo/microkernel/Makefile | 6 +
tests/kernel/test_fifo/microkernel/README.txt | 86 +++
tests/kernel/test_fifo/microkernel/prj.conf | 7 +
tests/kernel/test_fifo/microkernel/prj.mdef | 15 +
tests/kernel/test_fifo/microkernel/src/Makefile | 3 +
tests/kernel/test_fifo/microkernel/src/fifo.c | 624 ++++++++++++++++++
tests/kernel/test_fifo/microkernel/testcase.ini | 2 +
tests/kernel/test_fifo/nanokernel/Makefile | 5 +
tests/kernel/test_fifo/nanokernel/README.txt | 121 ++++
tests/kernel/test_fifo/nanokernel/prj.conf | 8 +
tests/kernel/test_fifo/nanokernel/src/Makefile | 3 +
tests/kernel/test_fifo/nanokernel/src/fifo.c | 710 ++++++++++++++++++++
.../kernel/test_fifo/nanokernel/src/fifo_timeout.c | 495 ++++++++++++++
tests/kernel/test_fifo/nanokernel/testcase.ini | 2 +
tests/kernel/test_fifo/prj.conf | 8 -
tests/kernel/test_fifo/prj.mdef | 15 -
tests/kernel/test_fifo/src/Makefile | 5 -
tests/kernel/test_fifo/src/fifo_timeout.c | 498 --------------
tests/kernel/test_fifo/src/micro_fifo.c | 628 ------------------
tests/kernel/test_fifo/src/nano_fifo.c | 713 ---------------------
tests/kernel/test_fifo/testcase.ini | 11 -
tests/kernel/test_fifo_priv/Makefile | 2 +-
tests/kernel/test_fifo_priv/prj.mdef | 2 +-
tests/kernel/test_lifo/src/Makefile | 1 -
tests/kernel/test_lifo/src/lifo.c | 4 +-
tests/kernel/test_lifo/testcase.ini | 2 -
tests/kernel/test_mutex/prj.mdef | 16 +-
tests/kernel/test_pool/prj.mdef | 8 +-
tests/kernel/test_sema/microkernel/prj.mdef | 10 +-
.../kernel/test_sema/microkernel/src/test_fiber.c | 2 +-
tests/kernel/test_sema/nanokernel/src/Makefile | 1 -
tests/kernel/test_sema/nanokernel/src/sema.c | 4 +-
tests/kernel/test_sema/nanokernel/testcase.ini | 2 -
tests/kernel/test_slist/Makefile | 5 +
tests/kernel/test_slist/README.txt | 48 ++
tests/kernel/test_slist/prj.conf | 1 +
tests/kernel/test_slist/src/Makefile | 3 +
tests/kernel/test_slist/src/slist.c | 251 ++++++++
tests/kernel/test_slist/testcase.ini | 2 +
tests/kernel/test_timer/microkernel/src/Makefile | 2 +-
179 files changed, 3526 insertions(+), 3775 deletions(-)


Re: RFC: extend sanitycheck testcase filtering expressiveness

Wang, Jing J
 

Andrew,
Eval is widely used in many projects, e.g. yocto. Its safety depends on what area you apply it. To build up a public server which allow any user input, maybe it is unsafe. For testcase filtering, all input is controlled by TC owner. In this usage, I think eval is appropriate, and save quite a lot efforts. On the other hand, are you sure introducing another parser or develop a new parser is safer than eval?

Rgds
jwang

-----Original Message-----
From: Boie, Andrew P
Sent: Wednesday, March 30, 2016 11:37 PM
To: Wang, Jing J <jing.j.wang(a)intel.com>; Korovkin, Dmitry (Wind River) <dmitriy.korovkin(a)windriver.com>
Cc: devel(a)lists.zephyrproject.org
Subject: RE: [devel] Re: RFC: extend sanitycheck testcase filtering expressiveness

QA test suite actually has similar requirement for test case filtering
by expression. We took a lightweight approach, directly use "python
expression" instead of creating a new one. The benefit of "python
expression" is, the expression can be parsed by python eval() function
directly. Thus, below filter expression is naturally supported with a
small code snippets.
@tag_exp('soc not in ["quark_se", "quark_d2000"]')
def test_xxxx(self):
I briefly considered this approach but after doing some reading concluded it was unsafe.

http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html

Andrew


Re: Sanity check and test cases

Boie, Andrew P
 

On Wed, 2016-03-30 at 19:45 +0300, Yannis Damigos wrote:

I have pushed it to gerrit:
https://gerrit.zephyrproject.org/r/#/c/1142/
https://gerrit.zephyrproject.org/r/#/c/1143/
Thanks for doing this.
I believe test_sema also has this problem, in addition to
test_fifo/test_lifo.


--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Re: Sanity check and test cases

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 30, 2016 at 6:33 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:





On 30/03/2016, 11:52, "Benjamin Walsh" <benjamin.walsh(a)windriver.com> wrote:

You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
Now that I've seen the patch it got me thinking. What if we added an
opt-in debug code for fiber/tasks that helped to measure stack usage?
This could be something really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.
also look at

include/misc/stack.h

for Stack usage analysis helpers
Thanks. Looks like we have everything in place then.

Cheers,
--
Maciek Borzecki


Re: Sanity check and test cases

Yannis Damigos
 

On 03/30/2016 07:17 PM, Perez-Gonzalez, Inaky wrote:
On Wed, 2016-03-30 at 15:38 +0000, Kalowsky, Daniel wrote:
Hey Yannis,



Is it safe to submit the patch to gerrit or should I first test it
on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good
enough. I've added Inaky to the thread who can more than likely run
this through a series of hardware tests pretty quickly.
Can you point me to the patch? I can't see it in the original email in
the thread (save my email doing funky stuff :)

Thanks
I have pushed it to gerrit:
https://gerrit.zephyrproject.org/r/#/c/1142/
https://gerrit.zephyrproject.org/r/#/c/1143/


Re: Sanity check and test cases

Nashif, Anas
 

On 30/03/2016, 11:52, "Benjamin Walsh" <benjamin.walsh(a)windriver.com> wrote:

You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
Now that I've seen the patch it got me thinking. What if we added an
opt-in debug code for fiber/tasks that helped to measure stack usage?
This could be something really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.
also look at

include/misc/stack.h

for Stack usage analysis helpers

Anas


finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?


Re: Sanity check and test cases

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

On Wed, 2016-03-30 at 15:38 +0000, Kalowsky, Daniel wrote:
Hey Yannis,

 

Is it safe to submit the patch to gerrit or should I first test it
on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good
enough.  I've added Inaky to the thread who can more than likely run
this through a series of hardware tests pretty quickly.
Can you point me to the patch? I can't see it in the original email in
the thread (save my email doing funky stuff :)

Thanks


Re: Sanity check and test cases

Benjamin Walsh <benjamin.walsh@...>
 

You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
Now that I've seen the patch it got me thinking. What if we added an
opt-in debug code for fiber/tasks that helped to measure stack usage?
This could be something really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.

finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?


Re: Sanity check and test cases

Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Yannis,

-----Original Message-----
From: Yannis Damigos [mailto:giannis.damigos(a)gmail.com]
Sent: Wednesday, March 30, 2016 7:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Sanity check and test cases

Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically
allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and
arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good enough. I've added Inaky to the thread who can more than likely run this through a series of hardware tests pretty quickly.


Re: Sanity check and test cases

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 30, 2016 at 4:47 PM, Maciek Borzecki
<maciek.borzecki(a)gmail.com> wrote:
Hi,

On Wed, Mar 30, 2016 at 4:21 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?
You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
Now that I've seen the patch it got me thinking. What if we added an
opt-in debug code for fiber/tasks that helped to measure stack usage?
This could be something really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?

Cheers,
--
Maciek Borzecki


Re: RFC: extend sanitycheck testcase filtering expressiveness

Boie, Andrew P
 

QA test suite actually has similar requirement for test case filtering by
expression. We took a lightweight approach, directly use "python
expression" instead of creating a new one. The benefit of "python
expression" is, the expression can be parsed by python eval() function
directly. Thus, below filter expression is naturally supported with a small code
snippets.
@tag_exp('soc not in ["quark_se", "quark_d2000"]')
def test_xxxx(self):
I briefly considered this approach but after doing some reading concluded it was unsafe.

http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html

Andrew


Re: Sanity check and test cases

Maciek Borzecki <maciek.borzecki@...>
 

Hi,

On Wed, Mar 30, 2016 at 4:21 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?
You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.

Cheers,
--
Maciek Borzecki


Re: FW: [users] TCP/IP support in network IP stack

Paul Duffy <paduffy@...>
 

Could MQTT-SN work for you?

On 3/30/2016 4:53 AM, Mahendravarman rajarao wrote:
Thanks a lot for the reply

If TCP support to the network stack is provided then Can I use the MQTT client library to make support for MQTT ?

Can you please tell me when can I expect the TCP support to network stack ?

Thanks again
.


Sanity check and test cases

Yannis Damigos
 

Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?

best regards,
Yannis


Re: FW: [users] TCP/IP support in network IP stack

Mahendravarman rajarao <mahendravarman.rajarao@...>
 

Thanks a lot for the reply

If TCP support to the network stack is provided then Can I use the MQTT client library to make support for MQTT ?

Can you please tell me when can I expect the TCP support to network stack ?

Thanks again


Re: RFC: extend sanitycheck testcase filtering expressiveness

Wang, Jing J
 

QA test suite actually has similar requirement for test case filtering by expression. We took a lightweight approach, directly use "python expression" instead of creating a new one. The benefit of "python expression" is, the expression can be parsed by python eval() function directly. Thus, below filter expression is naturally supported with a small code snippets.
@tag_exp('soc not in ["quark_se", "quark_d2000"]')
def test_xxxx(self):

Rgds
jwang

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Tuesday, March 29, 2016 4:23 AM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: RFC: extend sanitycheck testcase filtering expressiveness

On Fri, 25 Mar 2016, Boie, Andrew P wrote:

Proposed solution:

We need a more expressive language for filtering test cases. I propose
a simple boolean expression language with the following grammar:

expression ::= expression "and" expression
| expression "or" expression
| "not" expression
| "(" expression ")"
| symbol "==" constant
| symbol "!=" constant
| symbol "<" number
| symbol ">" number
| symbol ">=" number
| symbol "<=" number
| symbol "in" list
| symbol

list ::= "[" list_contents "]"

list_contents ::= constant
| list_contents "," constant

constant ::= number
| string

When symbols are encountered, they are looked up in an environment
dictionary. In sanitycheck the environment will initially consist of:

{
ARCH : <architecture>,
PLATFORM : <platform>,
<all CONFIG_* key/value pairs in the test's generated defconfig>
}

We can later augment this with additional interesting metadata if we
want. For example I was thinking of ways we could integrate some
footprint information for large tests.

For the case where

expression ::= symbol

it evaluates to true if the symbol is defined to a non-empty string.

For all comparison operators, if the config symbol is undefined, it
will be treated as a 0 (for > < >= <=) or an empty string "" (for == != in).
For numerical comparisons it doesn't matter if the environment stores
the value as an integer or string, it will be cast appropriately.

Operator precedence, starting from lowest to highest:

or (left associative)
and (left associative)
not (right associative)
all comparison operators (non-associative)

In testcase.ini the 'config_whitelist' directive will be removed and
replaced with 'filter' directives containing one of these expressions.
arch_whitelist, arch_exclude, platform_whitelist, platform_exclude are
all syntactic sugar for these expressions. For instance

arch_exclude = x86 arc

Is the same as:

filter = not ARCH in ["x86", "arc"]
I see nothing bad in the proposal.

Implementation details:

Writing a parser by hand is a pain and prone to bugs. The best way to
do a language like this is to use a LR parser generator like lex/yacc.
There exists an open source library called PLY which does lex/yacc for
Python, it has been around for a long time and works very well:

http://www.dabeaz.com/ply/index.html

The sample implementation I have drops a copy of PLY directly in the
Zephyr source tree since its license is compatible and this will
result in the least pain for users as they won't have to do anything.
If this is unacceptable we can either find a way to stick it in the
SDK, or add it to the list of workstation dependencies (either have
the user install with pip or their distribution's package manager.
Fedora appears to have PLY installed by default).
I would refrain from copying PLY into the source tree for the following
reasons:
- Support. Updating the library, which is not the part of the
project may be a headache.
- Licensing. There may be issues with distributing with Zephyr the code
that we have not developed.
- Importing. In case of side projects that, for instance, run all
sanity_chk projects on real hardware, using sanity_chk combined with
additional library may create problems.
- Distributions. Ubuntu has PLY 3.4 as a part of the distribution. As you
have mentioned, Fedora has it as well.
Regards,
/Dmitriy


Re: FW: [users] TCP/IP support in network IP stack

Jukka Rissanen
 

On Tue, 2016-03-29 at 15:30 +0000, Mahendravarman Rajarao (RBEI/EAA3)
wrote:
Hi

Under Zephyr RTOS net/ip/net_core.c, Support for IPPROTO_UDP is
available and Support for IPPROTO_TCP is mentioned as not yet
supported

Does it mean the Zephyr RTOS network stack has support only for UDP
and there is no support for TCP/IP?
Yes, TCP is not supported right now.


Any plans on support for TCP/IP on network stack ?
Yes, I am currently working on adding TCP support to the network stack.


Cheers,
Jukka


k64 rgb-led kernel module

Idupsle <idupsle@...>
 

Hello everybody,

I recently wanted to have a more fun with the k64 and wrote a little kernel
module. I don't know, if it is needed for the real kernel and if the structure
is right. But if anyone is interested in it... here!
Eg:

#include <drivers/k64_rgb.h>
rgb_set_color(0); // set red
rgb_set_color(1); // set green
rgb_set_color(2); // set blue
rgb_set_color(3); // set yellow
rgb_set_color(4); // set cyan
rgb_set_color(5); // set magenta
rgb_set_color(6); // set white
rgb_set_color(7); // set off



diff --git a/drivers/gpio/Kconfig.k64 b/drivers/gpio/Kconfig.k64
index 8854f73..837855a 100644
--- a/drivers/gpio/Kconfig.k64
+++ b/drivers/gpio/Kconfig.k64
@@ -136,4 +136,10 @@ config GPIO_K64_PORTE_PRI
help
K64 Port E IRQ priority

+config GPIO_K64_RGB_LED
+ bool "Freeschale K64-based board LED-RGB driver"
+ depends on GPIO_K64 && CONFIG_PINMUX_DEV_FRDM_K64F
+ default n
+ help
+ K64 Ports for RGB LED.
endif # GPIO_K64
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f34c0ce..61a815a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -8,4 +8,6 @@ obj-$(CONFIG_GPIO_SCH) += gpio_sch.o
obj-$(CONFIG_GPIO_QMSI) += gpio_qmsi.o
obj-$(CONFIG_GPIO_ATMEL_SAM3) += gpio_atmel_sam3.o
obj-$(CONFIG_GPIO_K64) += gpio_k64.o
+obj-$(CONFIG_GPIO_K64_RGB_LED) += k64_rgb.o
obj-$(CONFIG_GPIO_STM32) += gpio_stm32.o
+
diff --git a/drivers/gpio/k64_rgb.c b/drivers/gpio/k64_rgb.c
new file mode 100644
index 0000000..06df03d
--- /dev/null
+++ b/drivers/gpio/k64_rgb.c
@@ -0,0 +1,93 @@
+#ifdef CONFIG_GPIO_K64_RGB_LED
+
+#include <errno.h>
+
+#include <nanokernel.h>
+#include <device.h>
+#include <init.h>
+#include <gpio.h>
+#include <sys_io.h>
+#include <soc.h>
+
+#include <pinmux/frdm_k64f/pinmux_k64.h>
+
+#include "gpio_k64.h"
+#include "k64_rgb.h"
+
+void k64_rgb_set_red(uint8_t value)
+{
+ if (value) {
+ sys_set_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_RED%K64_PINMUX_NUM_PINS);
+ } else {
+ sys_clear_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_RED%K64_PINMUX_NUM_PINS);
+ }
+}
+void k64_rgb_set_blue(uint8_t value)
+{
+ if (value) {
+ sys_set_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_BLUE%K64_PINMUX_NUM_PINS);
+ } else {
+ sys_clear_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_BLUE%K64_PINMUX_NUM_PINS);
+ }
+}
+void k64_rgb_set_green(uint8_t value)
+{
+ if (value) {
+ sys_set_bit((GPIO_K64_E_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_GREEN%K64_PINMUX_NUM_PINS);
+ } else {
+ sys_clear_bit((GPIO_K64_E_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_GREEN%K64_PINMUX_NUM_PINS);
+ }
+}
+
+void k64_rgb_set(uint8_t r, uint8_t g, uint8_t b)
+{
+ k64_rgb_set_red(0);
+ k64_rgb_set_blue(0);
+ k64_rgb_set_green(0);
+ if (r)
+ k64_rgb_set_red(1);
+ if (g)
+ k64_rgb_set_blue(1);
+ if (b)
+ k64_rgb_set_green(1);
+}
+int rgb_set_color(uint8_t color)
+{
+
+ if (color > 7) return 1;
+ switch(color)
+ {
+ case K64_RGB_RED: k64_rgb_set(1, 0, 0);
+ break;
+ case K64_RGB_GREEN: k64_rgb_set(0, 1, 0);
+ break;
+ case K64_RGB_BLUE: k64_rgb_set(0, 0, 1);
+ break;
+ case K64_RGB_YELLOW: k64_rgb_set(1, 1, 0);
+ break;
+ case K64_RGB_CYAN: k64_rgb_set(0, 1, 1);
+ break;
+ case K64_RGB_MAGENTA: k64_rgb_set(1, 0, 1);
+ break;
+ case K64_RGB_WHITE: k64_rgb_set(1, 1, 1);
+ break;
+ case K64_RGB_OFF: k64_rgb_set(0, 0, 0);
+ break;
+ }
+ return 0;
+}
+
+#endif
+
diff --git a/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c b/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c
index 9717ef5..9c39b0e 100644
--- a/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c
+++ b/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c
@@ -38,11 +38,16 @@
* Since the K64 MCU configures these pins for JTAG/SWD signaling at reset,
* they should only be re-configured if the debug interface is not used.
*/
+#ifdef CONFIG_GPIO_K64_RGB_LED
+#define LED_RGB_PINS 3
+#else
+#define LED_RGB_PINS 0
+#endif

#ifndef CONFIG_PRESERVE_JTAG_IO_PINS
-#define NUM_DFLT_PINS_SET 22
+#define NUM_DFLT_PINS_SET 22 + LED_RGB_PINS
#else
-#define NUM_DFLT_PINS_SET (22 - 3)
+#define NUM_DFLT_PINS_SET (22 - 3) + LED_RGB_PINS
#endif

/*
@@ -58,6 +63,10 @@ struct pin_config mux_config[NUM_DFLT_PINS_SET] = {
#ifndef CONFIG_PRESERVE_JTAG_IO_PINS
{ K64_PIN_PTA1, K64_PINMUX_FUNC_GPIO },
#endif
+#ifdef CONFIG_GPIO_K64_RGB_LED
+ { K64_PIN_PTB21, K64_PINMUX_FUNC_GPIO },
+ { K64_PIN_PTB22, K64_PINMUX_FUNC_GPIO },
+#endif
{ K64_PIN_PTB23, K64_PINMUX_FUNC_GPIO },
#ifndef CONFIG_PRESERVE_JTAG_IO_PINS
{ K64_PIN_PTA2, K64_PINMUX_FUNC_GPIO },
@@ -76,6 +85,9 @@ struct pin_config mux_config[NUM_DFLT_PINS_SET] = {
{ K64_PIN_PTE25, (K64_PINMUX_ALT_5 | K64_PINMUX_OPEN_DRN_ENABLE) },
/* I2C0_SCL */
{ K64_PIN_PTE24, (K64_PINMUX_ALT_5 | K64_PINMUX_OPEN_DRN_ENABLE) },
+#ifdef CONFIG_GPIO_K64_RGB_LED
+ { K64_PIN_PTE26, K64_PINMUX_FUNC_GPIO },
+#endif
{ K64_PIN_PTB2, K64_PINMUX_FUNC_ANALOG }, /* ADC0_SE12/Analog In 0 */
{ K64_PIN_PTB3, K64_PINMUX_FUNC_ANALOG }, /* ADC0_SE13/Analog In 1 */
{ K64_PIN_PTB10, K64_PINMUX_FUNC_ANALOG }, /* ADC1_SE14/Analog In 2 */
diff --git a/drivers/pinmux/frdm_k64f/pinmux_k64.h b/drivers/pinmux/frdm_k64f/pinmux_k64.h
index ca40c14..bc30e25 100644
--- a/drivers/pinmux/frdm_k64f/pinmux_k64.h
+++ b/drivers/pinmux/frdm_k64f/pinmux_k64.h
@@ -280,6 +280,12 @@
#define K64_PIN_PTE30 158
#define K64_PIN_PTE31 159

+#ifdef CONFIG_GPIO_K64_RGB_LED
+#define K64_PIN_RED 54
+#define K64_PIN_GREEN 154
+#define K64_PIN_BLUE 53
+#endif
+
int _fsl_k64_set_pin(uint32_t pin_id, uint32_t func);

int _fsl_k64_get_pin(uint32_t pin_id, uint32_t *func);
diff --git a/include/drivers/k64_rgb.h b/include/drivers/k64_rgb.h
new file mode 100644
index 0000000..de63ae6
--- /dev/null
+++ b/include/drivers/k64_rgb.h
@@ -0,0 +1,39 @@
+#ifndef _K64RGB_H
+#define _K64RGB_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+#ifdef CONFIG_GPIO_K64_RGB_LED
+//#include "gpio_k64.h"
+#include <gpio.h>
+
+
+/* Available color slsections */
+#define K64_RGB_RED 0
+#define K64_RGB_GREEN 1
+#define K64_RGB_BLUE 2
+#define K64_RGB_YELLOW 3
+#define K64_RGB_CYAN 4
+#define K64_RGB_MAGENTA 5
+#define K64_RGB_WHITE 6
+#define K64_RGB_OFF 7
+
+
+extern int rgb_set_color(uint8_t color);
+//{
+// return k64_rgb_set_color(color);
+//}
+
+
+
+
+#endif /* CONFIG_GPIO_K64_RGB */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _K64RGB_H */

7681 - 7700 of 8104