When you build application for em starterkit 2.3 em7d, it will
report error during build since it is not supported currently.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
em starterkit has two versions, 2.2 and 2.3.
Change soc.h to support both versions,
main changes are the interrupt connections.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
Since em starterkit has different firmware versions(2.2 and 2.3),
but the EM7D of 2.3 has new secureshield feature, which is not supported
in Zephyr, but EM7D of 2.2 is a normal EM core, which can be supported,
so we add support for 2.2 EM7D.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
The API name space for Bluetooth is bt_* and BT_* so it makes sense to
align the Kconfig name space with this. The additional benefit is that
this also makes the names shorter. It is also in line with what Linux
uses for Bluetooth Kconfig entries.
Some Bluetooth-related Networking Kconfig defines are renamed as well
in order to be consistent, such as NET_L2_BLUETOOTH.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Historically, stacks were just character buffers and could be treated
as such if the user wanted to look inside the stack data, and also
declared as an array of the desired stack size.
This is no longer the case. Certain architectures will create a memory
region much larger to account for MPU/MMU guard pages. Unfortunately,
the kernel interfaces treat both the declared stack, and the valid
stack buffer within it as the same char * data type, even though these
absolutely cannot be used interchangeably.
We introduce an opaque k_thread_stack_t which gets instantiated by
K_THREAD_STACK_DECLARE(), this is no longer treated by the compiler
as a character pointer, even though it really is.
To access the real stack buffer within, the result of
K_THREAD_STACK_BUFFER() can be used, which will return a char * type.
This should catch a bunch of programming mistakes at build time:
- Declaring a character array outside of K_THREAD_STACK_DECLARE() and
passing it to K_THREAD_CREATE
- Directly examining the stack created by K_THREAD_STACK_DECLARE()
which is not actually the memory desired and may trigger a CPU
exception
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The .balign directives were not working correctly in their
previous positions as the directive was applying to the section
before the variable's section, causing in some builds the
variables to be misaligned, and accesses to them causing faults.
With the alignments after the section declaration, the variables
will now be aligned as specified. Any future variable declarations
should use this form instead to ensure proper alignment.
Signed-off-by: Michael R Rosen <michael.r.rosen@intel.com>
Here are the main changes:
* board: Update EMSK onboard resources such as Button, Switch and LEDs
+ update soc.h for em7d, em9d, em11d
+ update board.h for em_starterkit board
* arc: Add floating point support and code density support
+ add kconfig configuration
+ add compiler options
+ add register definitions, marcos, assembly codes
+ fixes in existing codes and configurations.
* arc: Update detailed board configurations for cores of emsk 2.3
* script: Provide arc_debugger.sh for debugging em_starterkit board
+ make BOARD=em_starterkit debug
This will start openocd server for emsk, and arc gdb will connect
to this debug server, user can run `continue` command if user just
want to run the application, or other commands if debugging needed.
+ make BOARD=em_starterkit debugserver
This will start an openocd debugger server for emsk, and user can
connect to this debugserver using arc gdb and do what they want to.
+ make BOARD=em_starterkit flash
This will download the zephyr application elf file to emsk,
and run it.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
- There's no clear need to disable frame pointers if this feature is
used, remove this directive.
- The 'top' and 'base' terms are reversed. The 'base' is the high
address of the stack. The top is the lowest address, where we cannot
push further down. Fixup member and offset names to correspond to how
these terms are used in hardware documentation.
- Use correct pointers for stack top location
- Fatal exceptions now go through _NanoFatalErrorHandler to report the
faulting ip and thread.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Unline k_thread_spawn(), the struct k_thread can live anywhere and not
in the thread's stack region. This will be useful for memory protection
scenarios where private kernel structures for a thread are not
accessible by that thread, or we want to allow the thread to use all the
stack space we gave it.
This requires a change to the internal _new_thread() API as we need to
provide a separate pointer for the k_thread.
By default, we still create internal threads with the k_thread in stack
memory. Forthcoming patches will change this, but we first need to make
it easier to define k_thread memory of variable size depending on
whether we need to store coprocessor state or not.
Change-Id: I533bbcf317833ba67a771b356b6bbc6596bf60f5
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Adds event based scheduling logic to the kernel. Updates
management of timeouts, timers, idling etc. based on
time tracked at events rather than periodic ticks. Provides
interfaces for timers to announce and get next timer expiry
based on kernel scheduling decisions involving time slicing
of threads, timeouts and idling. Uses wall time units instead
of ticks in all scheduling activities.
The implementation involves changes in the following areas
1. Management of time in wall units like ms/us instead of ticks
The existing implementation already had an option to configure
number of ticks in a second. The new implementation builds on
top of that feature and provides option to set the size of the
scheduling granurality to mili seconds or micro seconds. This
allows most of the current implementation to be reused. Due to
this re-use and co-existence with tick based kernel, the names
of variables may contain the word "tick". However, in the
tickless kernel implementation, it represents the currently
configured time unit, which would be be mili seconds or
micro seconds. The APIs that take time as a parameter are not
impacted and they continue to pass time in mili seconds.
2. Timers would not be programmed in periodic mode
generating ticks. Instead they would be programmed in one
shot mode to generate events at the time the kernel scheduler
needs to gain control for its scheduling activities like
timers, timeouts, time slicing, idling etc.
3. The scheduler provides interfaces that the timer drivers
use to announce elapsed time and get the next time the scheduler
needs a timer event. It is possible that the scheduler may not
need another timer event, in which case the system would wait
for a non-timer event to wake it up if it is idling.
4. New APIs are defined to be implemented by timer drivers. Also
they need to handler timer events differently. These changes
have been done in the HPET timer driver. In future other timers
that support tickles kernel should implement these APIs as well.
These APIs are to re-program the timer, update and announce
elapsed time.
5. Philosopher and timer_api applications have been enabled to
test tickless kernel. Separate configuration files are created
which define the necessary CONFIG flags. Run these apps using
following command
make pristine && make BOARD=qemu_x86 CONF_FILE=prj_tickless.conf qemu
Jira: ZEP-339 ZEP-1946 ZEP-948
Change-Id: I7d950c31bf1ff929a9066fad42c2f0559a2e5983
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Future tickless kernel patches would be inserting some
code before call to Swap. To enable this it will create
a mcro named as the current _Swap which would call first
the tickless kernel code and then call the real __swap()
Jira: ZEP-339
Change-Id: Id778bfcee4f88982c958fcf22d7f04deb4bd572f
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Historically, space for struct k_thread was always carved out of the
thread's stack region. However, we want more control on where this data
will reside; in memory protection scenarios the stack may only be used
for actual stack data and nothing else.
On some platforms (particularly ARM), including kernel_arch_data.h from
the toplevel kernel.h exposes intractable circular dependency issues.
We create a new per-arch header "kernel_arch_thread.h" with very limited
scope; it only defines the three data structures necessary to instantiate
the arch-specific bits of a struct k_thread.
Change-Id: I3a55b4ed4270512e58cf671f327bb033ad7f4a4f
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Unlike assertions, these APIs are active at all times. The kernel will
treat these errors in the same way as fatal CPU exceptions. Ultimately,
the policy of what to do with these errors is implemented in
_SysFatalErrorHandler.
If the archtecture supports it, a real CPU exception can be triggered
which will provide a complete register dump and PC value when the
problem occurs. This will provide more helpful information than a fake
exception stack frame (_default_esf) passed to the arch-specific exception
handling code.
Issue: ZEP-843
Change-Id: I8f136905c05bb84772e1c5ed53b8e920d24eb6fd
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We do the same thing on all arch's right now for thread_monitor_init so
lets put it in a common place. This also should fix an issue on xtensa
when thread monitor can be enabled (reference to _nanokernel.threads).
Change-Id: If2f26c1578aa1f18565a530de4880ae7bd5a0da2
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We do a bit of the same stuff on all the arch's to setup a new thread.
So lets put that code in a common place so we unify it for everyone and
reduce some duplicated code.
Change-Id: Ic04121bfd6846aece16aa7ffd4382bdcdb6136e3
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
There are a few places that we used an naked unsigned type, lets be
explicit and make it 'unsigned int'.
Change-Id: I33fcbdec4a6a1c0b1a2defb9a5844d282d02d80e
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types. This handles the remaining includes and kernel, plus
touching up various points that we skipped because of include
dependancies. We also convert the PRI printf formatters in the arch
code over to normal formatters.
Jira: ZEP-2051
Change-Id: Iecbb12601a3ee4ea936fd7ddea37788a645b08b0
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types. There are few places we dont convert over to the new
types because of compatiability with ext/HALs or for ease of transition
at this point. Fixup a few of the PRI formatters so we build with newlib.
Jira: ZEP-2051
Change-Id: I7d2d3697cad04f20aaa8f6e77228f502cd9c8286
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This is a start to move away from the C99 {u}int{8,16,32,64}_t types to
Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr
to define the sized types in a consistent manor across all the
architectures we support and not conflict with what various compilers
and libc might do with regards to the C99 types.
We introduce <zephyr/types.h> as part of this and have it include
<stdint.h> for now until we transition all the code away from the C99
types.
We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some
existing variables defined u8 & u16 as well as to be consistent with
Zephyr naming conventions.
Jira: ZEP-2051
Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Fix doxygen comment typos used to generate API docs
Change-Id: I94df2e3a2bda248824ed2aeff3dd0eb743f0bf3e
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
CONFIG_* usually come from Kconfig, rename variables that are locally
defined to avoid confusion about where they are set.
Change-Id: I83b8459913c5deb68dc1b9f5386b8934363a6d1f
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
I2C_CLOCK_SPEED Kconfig option is DW driver specific. It does not
define I2C interface speed but rather the I2C DW module clock speed.
It is confusing for a user of any other I2C driver than DW.
This patch renames this option to I2C_DW_CLOCK_SPEED and makes it
visible only for DW I2C driver.
Change-Id: I97f57332fd5cca644eabdef0968a0b2174b885ff
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
Fix c6e27a05 was too aggressive. It turns out that bluetooth on the
Quark SE boards won't enable it's own UART, because it had always been
enabled. Apps that don't do it already will be broken.
Enable UART_QMSI_0 whenever BLUETOOTH_H4 is pulled in on this
platform.
Change-Id: I5e21c6004714adba8fb0fafa056dc2d62698a3d1
Issue: ZEP-1788
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The defconfigs would always create a device for UART 0, which is
problematic in circumstances where both the x86 and ARC cores are
alive and one wants to use it in a non-default configuration.
Specifically: on Arduino 101 this is the bluetooth device and it
operates at 1MBps instead of of 115200kbps. If an x86 app sets this
up correctly, but then starts the ARC core running an app which
doesn't reference this UART at all, the device will still exist and
set up the (wrong!) configuration, clobbering the correct settings.
Just remove the "def-bool y" bits from the defconfig. There's no
need, users of these devices (e.g. the console) will enable them
anyway. There's no value to compiling it in without a configured
user.
Issue: ZEP-1677
Change-Id: I4a0e944f23705495433e9f3d0459065f131579cb
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This implementation of _tsc_read returns a 64-bit value that
is derived from the 64-bit tick count multiplied by hwcycles per tick,
and then it adds the current value from the 32-bit timer.
This produces a 64-bit time. There is a bunch of math here, which
could be avoided if the CPU is built with Real-Time-Clock option.
EM Starter Kit SOCs don't have this. I don't think Arduino 101 does
either.
See ZEP-1559
Change-Id: I9f846d170246556ac40fe2f45809e457c6375d8c
Signed-off-by: Chuck Jordan <cjordan@synopsys.com>
This commit removes the local implementation of enter_arc_state, where
the ARC is instructed to sleep, using instead the QMSI 1.4 functions.
Change-Id: Id489ad53851be50fc5e50add698891fcfaef3abe
Signed-off-by: Juan Solano <juanx.solano.menacho@intel.com>
This flag is no longer necessary and TICKLESS_IDLE will be
enabled by default if SYS_POWER_MANAGEMENT is enabled.
Jira: ZEP-1325
Change-Id: Ic6cd4b8dc0a17c6a413cabf6509b215a4558318d
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Update the builtin QMSI code to 1.4 (RC2).
The below shim drivers were updated for API or interface changes:
- aio
- counter
- i2c_ss
- rtc
- wdt.
Also, arch soc specific power management code were updated.
Jira: ZEP-1572
Change-Id: Ibc8fae032a39ffb2c2c997f697835bc0208fd308
Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
Signed-off-by: Kuo-Lang Tseng <kuo-lang.tseng@intel.com>
Rename devices. For example, the two i2c devices in the
quark se sensor sub-system will have name string "I2C_0"
and "I2C_1", while the other two i2c devices accessible to
both x86 and arc will have name string "I2C_2" and "I2C_3".
This is valid only when you build arc binary.
It does not apply if you build x86 or arm binary. Similar change is
also made for GPIO and SPI.
Jira: ZEP-1588 ZEP-1614
Change-Id: Ibad4486e70e0aaf287763514a5a9d28b43bca094
Signed-off-by: Baohong Liu <baohong.liu@intel.com>
This patch changes Quark SE power drivers to support multicore scenarios
e.g. both LMT and ARC core are enabled and manage power.
Handling LPS states in multicore scenarios are dead simple because LPS
states are core-specific states. It means that putting the LMT core in
LPS doesn't affect the ARC core, and vice-versa. DEEP_SLEEP state, on
the other hand, affects both cores since it turns power off from the SoC
and both cores are shutdown. It means that if LMT puts the system in
DEEP_SLEEP, ARC core is shutdown even if it is busy handling some task.
In order to support the multicore scenario, this patch introduces the
SYS_POWER_STATE_DEEP_SLEEP_2 state to both ARC and x86 power drivers.
On ARC, this state works as following:
1) Save ARC execution context;
2) Raise a flag to inform the x86 core that ARC is ready to enter in
DEEP_SLEEP;
3) Enter in the lowest core-specific power state, which in this case is
LPSS.
On x86, DEEP_SLEEP_2 is very similar to DEEP_SLEEP. The difference relies
in the post_ops() which calls _arc_init() in order to start ARC core so
it can restore its context.
This patch also adds the test/power/multicore/ directory which provides
sample application to x86 and ARC cores in order to easily verify the
multicore support. In test/power/multicore/README.rst you can find more
details regarding the applications.
Jira: ZEP-1103
Change-Id: Ie28ba6d193ea0e58fca69d38f8d3c38ca259a9ef
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
This avoids asm files from having to explicitly define the _ASMLANGUAGE
symbol themselves.
Change-Id: I71f5a169f75d7443a58a0365a41c55b20dae3029
Signed-off-by: Benjamin Walsh <walsh.benj@gmail.com>
They are not part of the API, so rename from K_<state> to
_THREAD_<state>.
Change-Id: Iaebb7d3083b80b9769bee5616e0f96ed2abc5c56
Signed-off-by: Benjamin Walsh <walsh.benj@gmail.com>
Huaqi Fang