Date   

Re: Quark Flash driver application issue

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

Hi Liu

Thanks for the reply

Its given as #define FLASH_TEST_REGION_OFFSET.

Offset means I thought that starting address + offset ( eg: 0x40000000 + 0)
So, you meant to say , I need to give FLASH_TEST_REGION_OFFSET as 0x40000000 ?


Best regards



From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 11:26 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: Quark Flash driver application issue

SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.

System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000

Thanks
Baohong

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 9:30 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Quark Flash driver application issue

Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.

Regards
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 6:09 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Quark Flash driver application issue

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra


Re: Chain booting in Zephyr

Chuck Jordan <Chuck.Jordan@...>
 

From: Piotr Mienkowski [mailto:piotr.mienkowski(a)gmail.com]
Sent: Tuesday, December 13, 2016 7:29 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Chain booting in Zephyr


Do we have any expectation of having a RAM vector table in the future?

I do not know if there's plans to have the actual hardware vector table in RAM, but there are as I understand plans to change the current software ISR table and the way it's populated, as part of the hard real-time interrupt optimizations upcoming. Andrew Boie should have more details regarding these changes.

I would say RAM vector table is simpler and nicer, if you can burn the

RAM (~256 bytes.) We've certainly made that trade-off, and said

"we'll optimize when we need to."

There is one more argument if favor of putting vector table in RAM. Typically during flash write/erase operations which tend to be long any read access to flash will generate idle cycles on AHB bus and ultimately stall the core. The only possibility for an application that performs flash programming and wants to respond to IRQs in real time is to have vector table in RAM (handler code has to be placed in RAM too). That's certainly not a very popular scenario but there exists such applications.

Cheers,
Piotr

[chuckj] Yes indeed. A CPU exception might occur as well.

Also, in terms of "common" failures that can occur. If the vector table is at address 0 and in RAM, a common software bug is to have a NULL pointer to do a store access relative to address 0, corrupting the vector table. People have addressed this with memory protection unit, MMU, or by moving the vector table to a non-zero location, OR by having the vector table in a read-executed memory (with no write access).


Re: Quark Flash driver application issue

Liu, Baohong
 

SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.

System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000

Thanks
Baohong

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 9:30 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Quark Flash driver application issue

Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.

Regards
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 6:09 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Quark Flash driver application issue

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra


Re: Quark Flash driver application issue

Liu, Baohong
 

Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.

Regards
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 6:09 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Quark Flash driver application issue

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra


Re: Chain booting in Zephyr

Boie, Andrew P
 

On Tue, 2016-12-13 at 16:29 +0100, Piotr Mienkowski wrote:
Do we have any expectation of having a RAM vector table in the future?
I do not know if there's plans to have the actual hardware vector table in
RAM, but there are as I understand plans to change the current software ISR
table and the way it's populated, as part of the hard real-time interrupt
optimizations upcoming. Andrew Boie should have more details regarding these
changes.
I would say RAM vector table is simpler and nicer, if you can burn the 
RAM (~256 bytes.)   We’ve certainly made that trade-off, and said 
“we’ll optimize when we need to.”
There is one more argument if favor of putting vector table in RAM. Typically
during flash write/erase operations which tend to be long any read access to
flash will generate idle cycles on AHB bus and ultimately stall the core. The
only possibility for an application that performs flash programming and wants
to respond to IRQs in real time is to have vector table in RAM (handler code
has to be placed in RAM too). That's certainly not a very popular scenario but
there exists such applications.
This all seems reasonable. I'm currently working on an overhaul on how the
vector table is created at build time and will add a Kconfig option to place it
in either RAM or ROM as required.

Andrew


Re: how long do we keep jenkins logs

Andrew Grimberg <agrimberg@...>
 

Greetings folks,

Giving an update to this as I just merged a change to improve the log
shipping to also include a version of the console log with the timestamping.

You'll find a console log and a console-timestamp log on builds that
happen starting this morning and going forward in any of the saved build
logs.

-Andy-

On 10/27/2016 10:13 AM, Andrew Grimberg wrote:
Oh look, I'm resurrecting a thread you may have thought died :)

As of https://gerrit.zephyrproject.org/r/#/c/6142/ which was just merged
all jobs will now announce a new logs hosting location. This is added to
the Gerrit comment and for those jobs that haven't rolled out of Jenkins
the job description will also be updated with this URL.

https://logs.zephyrproject.org is the base location. Logs for the
production silo are kept for 6 months. Those that show up in the sandbox
silo are kept for 7 days which is pretty much par for the course there
since we wipe all the jobs out of the sandbox every Saturday.

As an FYI if your job was running as the change got merged in, it may
have picked up the log push bits but may not have been running on the
modified build minion. Any new builds should be fine though!

One final note about this. The pushed logs are pre-compressed and the
hosting site is configured to deliver the logs in a way that browser
will automatically open them. This means that the logs should be
delivered faster than they were if you were looking in via the Jenkins UI.

-Andy-

On 08/02/2016 07:49 AM, Perez Hernandez, Javier B wrote:
Hi!

Jenkins keeps only the last 40 builds.
I think we can increase the amount of logs we save, let me confirm.


Javier B. Perez


On Tue, 2016-08-02 at 08:12 -0500, Kumar Gala wrote:
I submitted this patch just yesterday

https://gerrit.zephyrproject.org/r/#/c/3517/

and it appears the verify results are already removed

https://jenkins.zephyrproject.org/job/zephyr-verify/9956/

How long do we keep the logs, etc, around? Seems like removal after
a day of activity is way too short

- k
--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 3
[ZEP-1435] Improve Quark SE C1000 ARC Floating Point Performance
https://jira.zephyrproject.org/browse/ZEP-1435

[ZEP-1432] ksdk pinmux driver should expose the public pinmux API
https://jira.zephyrproject.org/browse/ZEP-1432

[ZEP-1434] menuconfig screen shots show nanokernel options
https://jira.zephyrproject.org/browse/ZEP-1434


UPDATED JIRA items within last 24 hours: 8
[ZEP-1313] porting and user guides must include a security section
https://jira.zephyrproject.org/browse/ZEP-1313

[ZEP-665] Extend gpio_qmsi_ss driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-665

[ZEP-1393] Add ksdk pinmux driver
https://jira.zephyrproject.org/browse/ZEP-1393

[ZEP-1177] Reduce Zephyr's Dependency on Host Tools
https://jira.zephyrproject.org/browse/ZEP-1177

[ZEP-1433] Jira daily digest fails to install pip package
https://jira.zephyrproject.org/browse/ZEP-1433

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

[ZEP-1421] BMI160 gyroscope driver stops reporting after 1-5 minutes
https://jira.zephyrproject.org/browse/ZEP-1421

[ZEP-1276] Move disk_access_* out of file system subsystem
https://jira.zephyrproject.org/browse/ZEP-1276


CLOSED JIRA items within last 24 hours: 1
[ZEP-1407] (Fixed) Nios2 _arch_irq_lock/unlock implemenation can cause race conditions
https://jira.zephyrproject.org/browse/ZEP-1407


RESOLVED JIRA items within last 24 hours: 0


Re: Chain booting in Zephyr

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Do we have any expectation of having a RAM vector table in the future?
I do not know if there's plans to have the actual hardware vector table in RAM, but there are as I understand plans to change the current software ISR table and the way it's populated, as part of the hard real-time interrupt optimizations upcoming. Andrew Boie should have more details regarding these changes.
I would say RAM vector table is simpler and nicer, if you can burn the
RAM (~256 bytes.) We’ve certainly made that trade-off, and said
“we’ll optimize when we need to.”
There is one more argument if favor of putting vector table in RAM.
Typically during flash write/erase operations which tend to be long any
read access to flash will generate idle cycles on AHB bus and ultimately
stall the core. The only possibility for an application that performs
flash programming and wants to respond to IRQs in real time is to have
vector table in RAM (handler code has to be placed in RAM too). That's
certainly not a very popular scenario but there exists such applications.

Cheers,
Piotr


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9023 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/9002 : board: v2m_beetle: Update defconfig
- https://gerrit.zephyrproject.org/r/9001 : counter: cmsdk: Add Timer 0 and 1 as Timers
- https://gerrit.zephyrproject.org/r/9031 : counter: cmsdk: Add DualTimer as Counter
- https://gerrit.zephyrproject.org/r/9026 : Bluetooth: AVDTP: Add AVDTP_RTX_Timer & Handler
- https://gerrit.zephyrproject.org/r/9015 : Bluetooth: AVDTP: Add AVDTP Pending Request
- https://gerrit.zephyrproject.org/r/9025 : Bluetooth: AVDTP: Fix Coding style
- https://gerrit.zephyrproject.org/r/9030 : counter: cmsdk: Add clock control to TMR Counters.
- https://gerrit.zephyrproject.org/r/9008 : arm: allow an extra irq priority when a CPU does not have BASEPRI
- https://gerrit.zephyrproject.org/r/9029 : drivers: timer: Optimize RTC driver and prevent past events
- https://gerrit.zephyrproject.org/r/9027 : tests: Remove unnecessary CONFIG_TEST_RANDOM_GENERATOR
- https://gerrit.zephyrproject.org/r/9028 : net: Switch net dependency to CONFIG_RANDOM_GENERATOR
- https://gerrit.zephyrproject.org/r/9016 : drivers: eth_ksdk: TEST_RANDOM_GENERATOR provides also sys_rand32_get
- https://gerrit.zephyrproject.org/r/9012 : samples: bmi160: use direct GPIO trigger instead of ipm
- https://gerrit.zephyrproject.org/r/9024 : dhcpv4: Provide prj file for frdm_k64f
- https://gerrit.zephyrproject.org/r/9020 : dhcpv4: Adjust prj file selection.
- https://gerrit.zephyrproject.org/r/9021 : dhcpv4: Report address acquisition.
- https://gerrit.zephyrproject.org/r/9018 : samples: net: Add dedicated dhcpv4 prj.conf for frdm k64f board
- https://gerrit.zephyrproject.org/r/9017 : drivers: eth_ksdk: Simplifying MAC address generation
- https://gerrit.zephyrproject.org/r/9014 : Bluetooth: Remove inline declaration from bt_le_conn_params_valid
- https://gerrit.zephyrproject.org/r/9013 : Bluetooth: RFCOMM: Handle DM from peer
- https://gerrit.zephyrproject.org/r/9007 : arm: move IRQ_PRIORITY_OFFSET to header file, rename to _IRQ_PRIO_OFFSET
- https://gerrit.zephyrproject.org/r/9006 : arm: add CPU_CORTEX_M_HAS_BASEPRI kconfig flag
- https://gerrit.zephyrproject.org/r/9011 : Prefix timestamps on archived console logs
- https://gerrit.zephyrproject.org/r/9010 : cc3200: Move UART peripheral clock enable into soc init
- https://gerrit.zephyrproject.org/r/9009 : net: tcp: Swap tcp->context backpointers
- https://gerrit.zephyrproject.org/r/9003 : drivers: gpio_cmsdk_ahb: Fix erronous if statements
- https://gerrit.zephyrproject.org/r/9000 : soc: arm: beetle: Add Timers IRQ map

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/5652 : net: buf: Redesigned pool & buffer allocation API
- https://gerrit.zephyrproject.org/r/7611 : boards: add initial support for STM3210C-EVAL board with SoC STM32F107VC
- https://gerrit.zephyrproject.org/r/8903 : net: Fix incorrect logging format specifiers
- https://gerrit.zephyrproject.org/r/8937 : drivers: eth_ksdk: There is a unique L2 driver
- https://gerrit.zephyrproject.org/r/7496 : soc/stm32f1: Add the new type of SoC STM32F107
- https://gerrit.zephyrproject.org/r/8936 : drivers: eth_ksdk: Theres is no longer 'ETHERNET' Kconfig option
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/8943 : frdm_k64f: Setup PTC12 pin as GPIO
- https://gerrit.zephyrproject.org/r/8998 : scripts: fix wrong RAM reporting on ARM
- https://gerrit.zephyrproject.org/r/8979 : kernel: remove NANOKERNEL and MICROKERNEL configs
- https://gerrit.zephyrproject.org/r/8837 : drivers: ethernet: Push DW specific Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/8838 : drivers: ethernet: Enable sys log levels depending on NET_ETHERNET_L2
- https://gerrit.zephyrproject.org/r/8835 : net: l2: ethernet: Handle Ethernet II full frame relevantly
- https://gerrit.zephyrproject.org/r/8836 : drivers: enc28j60: This controller provides a full frame to l2
- https://gerrit.zephyrproject.org/r/8841 : drivers: enc28j60: Fix one tiny naming issue
- https://gerrit.zephyrproject.org/r/8845 : samples: net: Remove useless prj.mdef from dhcpv4_client
- https://gerrit.zephyrproject.org/r/8855 : drivers: enc28j60: Removing useless legacy driver
- https://gerrit.zephyrproject.org/r/8834 : net: if: Add a dedicated place holder for device specific attributes
- https://gerrit.zephyrproject.org/r/8846 : samples: net: Add Arduino 101 dedicated config for dhcpv4_client
- https://gerrit.zephyrproject.org/r/8843 : drivers: enc28j60: Add logging
- https://gerrit.zephyrproject.org/r/8833 : net: if: Move and document net_if_api structure
- https://gerrit.zephyrproject.org/r/8842 : drivers: ennc28j60: There is a unique L2 driver
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/8840 : drivers: enc28j60: Fix a Kconfig comment
- https://gerrit.zephyrproject.org/r/8844 : drivers: enc28j60: Expose RX thread stack size and prio config
- https://gerrit.zephyrproject.org/r/8839 : drivers: enc28j60: Fix a tiny style issue
- https://gerrit.zephyrproject.org/r/8854 : samples: net: mbedtls: Let's enable fastest enc28j60 speed on a101
- https://gerrit.zephyrproject.org/r/8997 : samples: net: Add echo_client build test for frdm CC2520 configuration
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/8900 : tests: add gpio driver test case
- https://gerrit.zephyrproject.org/r/8897 : samples/zoap-client: Fix using wrong addresses
- https://gerrit.zephyrproject.org/r/8992 : Bluetooth: RFCOMM: Disconnect session after last dlc disconnection
- https://gerrit.zephyrproject.org/r/8987 : gpio: nrf5x: Add support for GPIOTE and GPIO callbacks
- https://gerrit.zephyrproject.org/r/8930 : subsys: disk: Refactor disk_access stuff into a directory
- https://gerrit.zephyrproject.org/r/8986 : kernel: enhance realtime-ness when handling timeouts
- https://gerrit.zephyrproject.org/r/8811 : kernel/arch: enhance the "ready thread" cache
- https://gerrit.zephyrproject.org/r/8917 : net: tcp: Select correct source address for SYNACK packets
- https://gerrit.zephyrproject.org/r/8983 : kernel: fix mis-use of sys_dlist_t vs sys_dnode_t in _timeout
- https://gerrit.zephyrproject.org/r/6913 : power: Add ARC core suspend and resume support
- https://gerrit.zephyrproject.org/r/8925 : cc3200: Ensure UART can wake up Zephyr after wfi in idle
- https://gerrit.zephyrproject.org/r/6911 : arcv2_irq: Add power management suspend/resume
- https://gerrit.zephyrproject.org/r/8945 : sensor: remove SENSOR_VALUE_TYPE_INT
- https://gerrit.zephyrproject.org/r/8944 : sensor: remove unused Q16_16 value type
- https://gerrit.zephyrproject.org/r/8981 : kernel: add defines for delta_ticks_from_prev special values
- https://gerrit.zephyrproject.org/r/8982 : kernel/timers: move tick computation out of irq_lock block
- https://gerrit.zephyrproject.org/r/8813 : driver: ethernet: adds reset signal to enc28j60 driver
- https://gerrit.zephyrproject.org/r/4871 : util.h: Add DEFINED() macro for expresion-legal ifdef-checking
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9004 : drivers: sensor: fxos8700: Fix uninitialized variable
- https://gerrit.zephyrproject.org/r/9005 : Make sure netrc is properly formated
- https://gerrit.zephyrproject.org/r/8999 : Re-add ability for Jenkins to sudo
- https://gerrit.zephyrproject.org/r/7612 : Bluetooth: AVDTP: Add AV-Stream data structure
- https://gerrit.zephyrproject.org/r/8991 : net: echo_client: Fix using CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/8996 : net: Remove unnecessary k_wakeup
- https://gerrit.zephyrproject.org/r/8994 : samples: net: Fix compile error following frdm pinmux change
- https://gerrit.zephyrproject.org/r/8793 : samples/mbedtls_dtlsclient: Using semaphore for rx
- https://gerrit.zephyrproject.org/r/8970 : samples/mbedtls_dtlsclient: Add ARG_UNUSED
- https://gerrit.zephyrproject.org/r/8919 : tests/tcp: Initialize buffer to NULL
- https://gerrit.zephyrproject.org/r/8969 : samples/mbedtls_dtlsclient: Validate destination buffer size
- https://gerrit.zephyrproject.org/r/8887 : iot/dns: Update DNS client private routines
- https://gerrit.zephyrproject.org/r/8888 : iot/dns: Use a k_sem for the DNS rx routine
- https://gerrit.zephyrproject.org/r/8989 : samples/net/README: Add DNS client section
- https://gerrit.zephyrproject.org/r/8886 : iot/dns: Introduce the dns_context structure
- https://gerrit.zephyrproject.org/r/8889 : iot/dns: Update sample application
- https://gerrit.zephyrproject.org/r/8819 : arc: Add cc to clobber list for sleep instruction
- https://gerrit.zephyrproject.org/r/8726 : kernel: legacy: Fix int overflow in nano_stack_init
- https://gerrit.zephyrproject.org/r/8978 : kernel: disable MDEF by default
- https://gerrit.zephyrproject.org/r/8977 : scripts: remove old qemu patch
- https://gerrit.zephyrproject.org/r/8967 : toolchain: Add a popcount macro for GCC
- https://gerrit.zephyrproject.org/r/8974 : kernel: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8975 : x86/soc: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8973 : shell: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8972 : kernel/mem_slab: Use the right data-type
- https://gerrit.zephyrproject.org/r/8971 : kernel/mem_pool: Use the right data-type
- https://gerrit.zephyrproject.org/r/8931 : kernel: Refactor remaining time evaluation for timeouts
- https://gerrit.zephyrproject.org/r/8932 : kernel: Introduce new k_delayed_work_remaining_get API
- https://gerrit.zephyrproject.org/r/8958 : Bluetooth: Kconfig: Fix logging dependency on printk
- https://gerrit.zephyrproject.org/r/8976 : tcp: Validate net_context_put return code
- https://gerrit.zephyrproject.org/r/8923 : tests/iot/http: Initialize parser struct
- https://gerrit.zephyrproject.org/r/8951 : net: Remove legacy tinydtls.h header


Re: Using/misusing k_sem_init()

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Hi Ben,

What is the behaviour you expect exactly ? What would a semaphore
re-init signal to the thread pending on the semaphore in your
application ?
Sorry, I wrote a somehow longish description of the issue but didn't
mentioned the expected behavior.

When I clean up the descriptor list and re-initialize the semaphores I
would expect the pending thread to be awaken and continue as normal. At
that point the resources (transmission buffers) are available again so
the transmit thread can send the data (copy them to transmission buffers
and let the MAC module know there is new data).
You could give the semaphore twice (since you initialize it with '2') to
flush the threads pending on it, but that would probably just cause them
to pend again on the semaphore. Worst, the thread would probably just
think it got the semaphore and just try to do the operation expected of
it when it is able to get the semaphore.
I'm not sure I understand what is meant by flushing the threads. I
believe that using k_sem_give() in a loop instead of k_sem_init() would
do exactly the job I need, the transmit thread would be awaken and
continue as normal. It's only that this solution seemed not very elegant
especially in cases where the initial semaphore count is high.

That said, I redesigned my Ethernet driver code not to copy the data.
The network buffers passed to the driver by the higher layer are
released directly by the IRQ handler with net_buf_unref() after the data
are sent by the MAC module. At the moment my code is not using any
semaphores and for me the issue is resolved.

Thanks and regards,
Piotr


Quark Flash driver application issue

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

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra


Re: Using/misusing k_sem_init()

Daniel Thompson <daniel.thompson@...>
 

On 12/12/16 18:10, Benjamin Walsh wrote:
Let's focus on the transmit path. Assuming we have two transmission
buffers and each buffer can store one full Ethernet frame the Ethernet
driver can send up to two frames to the MAC module but to send a third
frame it has to wait until a free buffer becomes available. This is a
perfect case for using counting semaphores.

<snip>
>>
However, now we can have a situation where the driver (transmit thread)
has sent two frames, stopped on k_sem_take() call when trying to send a
third one and at that moment an unrecoverable transmission error
happens. At this point I would like to reinitialize the descriptor list
and also reinitialize the semaphores,
To reinitialize things here implies that the owner of the buffer has
lost so much state that it can no longer release it as normal. Why does
an unrecoverable error cause such a catastrophic loss of state?


Would that be OK, is there a better solution?
One thing you could do would be to abort the thread, then re-init the
semaphore, then respawn the thread.

We could maybe add a k_sem_flush() API, that unpend all threads waiting
on the semaphore, but returning them an errno.
To avoid race conditions its likely a flush would have to be sticky,
causing everything to return an error until the next init.

Basically in a situation where you resource tracking is borked to the
point that you no longer know how to resolve the situation with the
"give" API then its likely you can't know, when calling k_sem_flush(),
that all the threads are nicely blocked waiting for the flush.

On that basis, perhaps any proposed API should be more explicit,
k_sem_set_error().

I admit a degree of skepticism here. The code to handle the new
semaphore error paths may end up more complex than the code to correctly
track buffer ownership within the IP stack error paths.


Daniel.


Re: Chain booting in Zephyr

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown(a)linaro.org]
Sent: Monday, December 12, 2016 22:54
To: devel(a)lists.zephyrproject.org
Subject: [devel] Chain booting in Zephyr

As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've been
running into is setting the vector table address in the chained image.
Of the two Cortex-M boards I have, I've found two different kinds of
failure, and was wondering if anyone had ideas on the best way to make
this work.

The way the bootloader works on these devices with built-in flash, is
that the bootloader itself is located at the beginning of flash.
There are then 1 or more partitions following this that contain the main
image. Since the image does not start at the beginning of flash, and
Zephyr on ARM uses a ROM-based vector table, it is necessary to update
the vector table address (VTOR) before enabling interrupts.

- FRDM-K64F

This board support seems to assume that the code always resides at
the beginning of flash, and doesn't seem to write to the VTOR at
all.

- STM32F4 (96b_carbon)

This board support does write the vector table offset, but assumes
that it is always the same as CONFIG_FLASH_BASE_ADDRESS.

Both of these have some problems. With the boot loader, there is a
header at the beginning of the image, and the vector table itself always
follows this.

Having the vector table in ROM does have some advantages (simplicity, as
well as minor security).

I guess my question is, should I just try to fix this in an ad-hoc
manner as I discover targets that don't chain-boot correctly. It seems
like a good general solution would be to add a symbol (or use a
symbol) for the vector table, instead of trying to guess where it might
be.

Do we have any expectation of having a RAM vector table in the future?
I do not know if there's plans to have the actual hardware vector table in RAM, but there are as I understand plans to change the current software ISR table and the way it's populated, as part of the hard real-time interrupt optimizations upcoming. Andrew Boie should have more details regarding these changes.

Regards,

Carles


Re: Chain booting in Zephyr

Sterling Hughes <sterling@...>
 

Hi David,

On 12 Dec 2016, at 13:54, David Brown wrote:

As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've
been running into is setting the vector table address in the chained
image. Of the two Cortex-M boards I have, I've found two different
kinds of failure, and was wondering if anyone had ideas on the best
way to make this work.

The way the bootloader works on these devices with built-in flash, is
that the bootloader itself is located at the beginning of flash.
There are then 1 or more partitions following this that contain the
main image. Since the image does not start at the beginning of flash,
and Zephyr on ARM uses a ROM-based vector table, it is necessary to
update the vector table address (VTOR) before enabling interrupts.

- FRDM-K64F

This board support seems to assume that the code always resides at
the beginning of flash, and doesn't seem to write to the VTOR at
all.
This is similar to how the NRF51 operates. In Mynewt these values are
trampolined to SRAM locations (i.e. the interrupt vectors jump to code
in SRAM.) We locate the bootloader after the vector table, and the
vector table points to locations in RAM after boot. Obviously, we leave
interrupts disabled in the bootloader, until we’ve initialized the
vector table in RAM.

- STM32F4 (96b_carbon)

This board support does write the vector table offset, but assumes
that it is always the same as CONFIG_FLASH_BASE_ADDRESS.

Both of these have some problems. With the boot loader, there is a
header at the beginning of the image, and the vector table itself
always follows this.

Having the vector table in ROM does have some advantages (simplicity,
as well as minor security).

I guess my question is, should I just try to fix this in an ad-hoc
manner as I discover targets that don't chain-boot correctly. It
seems like a good general solution would be to add a symbol (or use a
symbol) for the vector table, instead of trying to guess where it
might be.
Agreed.


Do we have any expectation of having a RAM vector table in the future?
I would say RAM vector table is simpler and nicer, if you can burn the
RAM (~256 bytes.) We’ve certainly made that trade-off, and said
“we’ll optimize when we need to.”

Cheers,

Sterling


Chain booting in Zephyr

David Brown
 

As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've
been running into is setting the vector table address in the chained
image. Of the two Cortex-M boards I have, I've found two different
kinds of failure, and was wondering if anyone had ideas on the best
way to make this work.

The way the bootloader works on these devices with built-in flash, is
that the bootloader itself is located at the beginning of flash.
There are then 1 or more partitions following this that contain the
main image. Since the image does not start at the beginning of flash,
and Zephyr on ARM uses a ROM-based vector table, it is necessary to
update the vector table address (VTOR) before enabling interrupts.

- FRDM-K64F

This board support seems to assume that the code always resides at
the beginning of flash, and doesn't seem to write to the VTOR at
all.

- STM32F4 (96b_carbon)

This board support does write the vector table offset, but assumes
that it is always the same as CONFIG_FLASH_BASE_ADDRESS.

Both of these have some problems. With the boot loader, there is a
header at the beginning of the image, and the vector table itself
always follows this.

Having the vector table in ROM does have some advantages (simplicity,
as well as minor security).

I guess my question is, should I just try to fix this in an ad-hoc
manner as I discover targets that don't chain-boot correctly. It
seems like a good general solution would be to add a symbol (or use a
symbol) for the vector table, instead of trying to guess where it
might be.

Do we have any expectation of having a RAM vector table in the future?

Thanks,
David


Re: Reg: Zephyr 1.6 GPIO Mask and Unmask gpio interrupts

vishnuvaradan vishnuvaradan
 

Hi Tomasz

Thanks for replying

Inside the gpio_pin_enable function I have called gpio_pin_disable_function
but my code gets hang inside that isr itself.

Should I need to use gpio_pin_disable macro inside the isr instead of
gpio_pin_disable_function?

On Fri, Dec 9, 2016 at 2:05 PM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi,

Have a look at samples/basic/button/src/main.c for instance.

Zephyr GPIO API first requires to configure it through
gpio_pin_configure()
and then to setup a callback and enabled/disable the relevant pin for that
callback (you can do it by port directly,
if you need multiples pins at once). We don't expose the mask/unmask logic
directly.

Tomasz

Hi tomasz and mahendra

what #define to be used in gpio_pin_configure to mask and unmask gpio
interrupt ?
can you help me with an example ?

On Thu, Dec 8, 2016 at 8:20 PM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi,

So from the application level to mask and unmask gpio interrupts can I
use QM_IR_MASK_INTERRUPTS & QM_IR_UNMASK_INTERRUPTS functions

(Or) should I use settings in gpio_pin_configure function ??


The second one. Always use the Zephyr GPIO API, so include/gpio.h

Tomasz


Re: Using/misusing k_sem_init()

Benjamin Walsh <benjamin.walsh@...>
 

Hi Piotr,

Sorry for the late response.

I'm reviewing my new code for Atmel SAM low level Ethernet driver and
there is one place where I have a troubling use of k_sem_init()
function. Very shortly my situation:

As is typically the case Atmel's Ethernet MAC module is using a so
called descriptor list to define a linked list of transmission and
reception buffers. These shared buffers are then used to pass data
between MAC module and low level Ethernet driver.

Let's focus on the transmit path. Assuming we have two transmission
buffers and each buffer can store one full Ethernet frame the Ethernet
driver can send up to two frames to the MAC module but to send a third
frame it has to wait until a free buffer becomes available. This is a
perfect case for using counting semaphores.

During driver initialization phase we would call

k_sem_init(&tx_sem, 2, 2);

to initialize semaphores and then k_sem_take() in transmit thread every
time we send a frame and k_sem_give() in IRQ handler every time the MAC
module has read all the data from the transmit buffer. So far so good.
However, now we can have a situation where the driver (transmit thread)
has sent two frames, stopped on k_sem_take() call when trying to send a
third one and at that moment an unrecoverable transmission error
happens. At this point I would like to reinitialize the descriptor list
and also reinitialize the semaphores, i.e. I would like to call
k_sem_init() while there is a thread waiting for the very semaphore to
become available.
What is the behaviour you expect exactly ? What would a semaphore
re-init signal to the thread pending on the semaphore in your
application ?

I can tell you that with the current implementation of k_sem_init(), the
thread would not be awakened, but the wait queue would be reinitialized,
so that thread would be "lost".

You could give the semaphore twice (since you initialize it with '2') to
flush the threads pending on it, but that would probably just cause them
to pend again on the semaphore. Worst, the thread would probably just
think it got the semaphore and just try to do the operation expected of
it when it is able to get the semaphore.

Would that be OK, is there a better solution?
One thing you could do would be to abort the thread, then re-init the
semaphore, then respawn the thread.

We could maybe add a k_sem_flush() API, that unpend all threads waiting
on the semaphore, but returning them an errno.

Cheers,
Ben


Thanks and regards,
Piotr
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/8997 : samples: net: Add echo_client build test for CC2520 configuration
- https://gerrit.zephyrproject.org/r/8998 : scripts: fix wrong RAM reporting on ARM
- https://gerrit.zephyrproject.org/r/8996 : net: Remove unnecessary k_wakeup
- https://gerrit.zephyrproject.org/r/8994 : samples: net: Fix compile error following API change
- https://gerrit.zephyrproject.org/r/8987 : gpio: nrf5x: Add support for GPIOTE and GPIO callbacks
- https://gerrit.zephyrproject.org/r/8992 : Bluetooth: RFCOMM: Disconnect session after last dlc disconnection
- https://gerrit.zephyrproject.org/r/8991 : net: echo_client: Fix using CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/8989 : samples/net/README: Add DNS client section
- https://gerrit.zephyrproject.org/r/8990 : tests: add driver aio comparator test case
- https://gerrit.zephyrproject.org/r/8986 : kernel: enhance realtime-ness when handling timeouts
- https://gerrit.zephyrproject.org/r/8985 : kernel: fix typo
- https://gerrit.zephyrproject.org/r/8984 : sample/philosphers: ignore format-security warning
- https://gerrit.zephyrproject.org/r/8983 : kernel: fix mis-use of sys_dlist_t vs sys_dnode_t in _timeout
- https://gerrit.zephyrproject.org/r/8982 : kernel/timers: move tick computation out of irq_lock block
- https://gerrit.zephyrproject.org/r/8981 : kernel: add defines for delta_ticks_from_prev special values

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5652 : net: buf: Redesigned pool & buffer allocation API
- https://gerrit.zephyrproject.org/r/8888 : iot/dns: Use a k_timer for the DNS rx routine
- https://gerrit.zephyrproject.org/r/8979 : kernel: remove NANOKERNEL config option
- https://gerrit.zephyrproject.org/r/8978 : kernel: disable MDEF by default
- https://gerrit.zephyrproject.org/r/8977 : scripts: remove old qemu patch
- https://gerrit.zephyrproject.org/r/8947 : sensor: update drivers to not return double values
- https://gerrit.zephyrproject.org/r/8944 : sensor: remove unused Q16_16 value type
- https://gerrit.zephyrproject.org/r/8945 : sensor: remove SENSOR_VALUE_TYPE_INT
- https://gerrit.zephyrproject.org/r/8946 : sensor: use integers for simple value calculations
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/8714 : [DO NOT SUBMIT] RFC: Bluetooth: SDP client API user concept draft
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/7612 : Bluetooth: AVDTP: Add AV-Stream data structure
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/8726 : kernel: legacy: Fix int overflow in nano_stack_init
- https://gerrit.zephyrproject.org/r/8951 : net: Remove legacy tinydtls.h header
- https://gerrit.zephyrproject.org/r/7622 : clock/stm32: add STM32F107 reset and clock control
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/6913 : power: Add ARC core suspend and resume support
- https://gerrit.zephyrproject.org/r/8976 : tcp: Validate net_context_put return code
- https://gerrit.zephyrproject.org/r/8900 : tests: add gpio driver test case
- https://gerrit.zephyrproject.org/r/8889 : iot/dns: Update sample application
- https://gerrit.zephyrproject.org/r/8886 : iot/dns: Introduce the dns_context structure
- https://gerrit.zephyrproject.org/r/8923 : tests/iot/http: Initialize parser struct
- https://gerrit.zephyrproject.org/r/8919 : tests/tcp: Initialize buffer to NULL
- https://gerrit.zephyrproject.org/r/8887 : iot/dns: Update DNS client private routines
- https://gerrit.zephyrproject.org/r/8970 : samples/mbedtls_dtlsclient: Add ARG_UNUSED
- https://gerrit.zephyrproject.org/r/8969 : samples/mbedtls_dtlsclient: Validate destination buffer size
- https://gerrit.zephyrproject.org/r/8793 : samples/mbedtls_dtlsclient: Using semaphore for rx
- https://gerrit.zephyrproject.org/r/8811 : kernel/arch: enhance the "ready thread" cache
- https://gerrit.zephyrproject.org/r/8974 : kernel: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8973 : shell: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8975 : x86/soc: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8968 : samples: added disco_fever app
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/8971 : kernel/mem_pool: Use the right data-type
- https://gerrit.zephyrproject.org/r/8972 : kernel/mem_slab: Use the right data-type

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8988 : MAINTAINERS: Update network applications section
- https://gerrit.zephyrproject.org/r/8980 : device: do not set struct as deprecated
- https://gerrit.zephyrproject.org/r/8831 : device: add deprecated attribute to device sync APIs


Re: Zephyr versioning (1.6.0 or 0.1.6?)

Jon Trulson
 

On Sat, 10 Dec 2016, Nashif, Anas wrote:


On 5 Dec 2016, at 17:20, Jon Trulson <jon(a)radscan.com> wrote:

On Mon, 5 Dec 2016, Jon Trulson wrote:

Hi,

I noticed that a new Zephyr version was tagged, 1.6.0. I am confused a
little bit by the version number though:
[...]

Responding to my own post - clearly KERNEL_VERSION_NUMBER is the wrong
macro. It seems like KERNELVERSION is supposed to be the correct one
for these macros? A little confusing.

Anyway, I just decided to use KERNEL_VERSION_MAJOR,
KERNEL_VERSION_MINOR, and KERNEL_PATCHLEVEL directly. This works
fine.

Sorry for the noise.
Here is a snippet:

uint32_t version = sys_kernel_version_get();

printk("Zephyr version %d.%d.%d\n",
SYS_KERNEL_VER_MAJOR(version),
SYS_KERNEL_VER_MINOR(version),
SYS_KERNEL_VER_PATCHLEVEL(version));

This is the correct usage, and yes, KERNEL_VERSION_NUMBER is not the right macro.
Yes, I had seen sys_kernel_version_get(), but what I was trying to do
was get this information at compile time so that some timer code I was
using could be supported in both 1.5 and 1.6 versions of Zephyr
(nanotimer vs. k_timer).

Using the macros I mentioned previously works fine. Thanks for the
response!


--
Jon Trulson

"If we can hit that bull's-eye, the rest of the dominoes will fall
like a house of cards... Checkmate."
-- Zapp Brannigan


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/8968 : samples: added disco_fever app
- https://gerrit.zephyrproject.org/r/8967 : toolchain: Add a popcount macro for GCC
- https://gerrit.zephyrproject.org/r/8979 : kernel: remove NANOKERNEL config option
- https://gerrit.zephyrproject.org/r/8978 : kernel: disable MDEF by default
- https://gerrit.zephyrproject.org/r/8977 : scripts: remove old qemu patch
- https://gerrit.zephyrproject.org/r/8976 : tcp: Validate net_context_put return code
- https://gerrit.zephyrproject.org/r/8975 : x86/soc: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8974 : kernel: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8973 : shell: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8972 : kernel/mem_slab: Use the right data-type
- https://gerrit.zephyrproject.org/r/8971 : kernel/mem_pool: Use the right data-type
- https://gerrit.zephyrproject.org/r/8970 : samples/mbedtls_dtlsclient: Add ARG_UNUSED
- https://gerrit.zephyrproject.org/r/8969 : samples/mbedtls_dtlsclient: Validate destination buffer size

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/8931 : kernel: Refactor remaining time evaluation for timeouts
- https://gerrit.zephyrproject.org/r/8932 : kernel: Introduce new k_delayed_work_remaining_get API
- https://gerrit.zephyrproject.org/r/7068 : boards: added support for the zedboard_pulpino board
- https://gerrit.zephyrproject.org/r/8926 : kernel: introduce single-threaded kernel

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8980 : device: do not set struct as deprecated
- https://gerrit.zephyrproject.org/r/8898 : samples: spi_fram: correct syntax error and update comments
- https://gerrit.zephyrproject.org/r/8868 : drivers: adc: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/8832 : drivers: spi: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/8927 : samples: gpio: use correct gpio driver name
- https://gerrit.zephyrproject.org/r/8873 : drivers: i2c: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/8831 : device: add deprecated attribute to device sync APIs
- https://gerrit.zephyrproject.org/r/8924 : arm: Fix irq offload inline asm memory ordering.
- https://gerrit.zephyrproject.org/r/8870 : random: Rewrite sys_rand32_init() with SYS_INIT()
- https://gerrit.zephyrproject.org/r/8869 : Remove application calls to sys_rand32_init.
- https://gerrit.zephyrproject.org/r/7660 : sensor: Add nRF5 temperature driver.
- https://gerrit.zephyrproject.org/r/8805 : samples: Add thermometer
- https://gerrit.zephyrproject.org/r/8929 : samples: sensor: fxos8700: Check sample fetch return value
- https://gerrit.zephyrproject.org/r/8956 : printk: Export _vprintk similar to how _prf is exported
- https://gerrit.zephyrproject.org/r/8957 : Bluetooth: Use _vprintk() instead of _prf()
- https://gerrit.zephyrproject.org/r/8826 : pinmux: Introduce new ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8827 : frdm_k64f: Add pin init using ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8828 : hexiwear_k64: Add pin init using ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8829 : k64: Change the default pinmux driver to the ksdk one
- https://gerrit.zephyrproject.org/r/8830 : pinmux: Deprecate the k64 pinmux driver
- https://gerrit.zephyrproject.org/r/7217 : meta-zephyr-sdk: disable MIPS

5881 - 5900 of 7903