The old GCC ARM Embedded website on launchpad
(https://launchpad.net/gcc-arm-embedded) has been superseeded by the new
GNU Arm Embedded one
(https://developer.arm.com/open-source/gnu-toolchain/gnu-rm).
This also means a change of name from "GCC" to "GNU". Reflect this in
the enviroment variables so that the proper term is used henceforth.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Both variables were used (with the same value) interchangeably
throughout CMake files and per the discussion in GH issue,
ZEPHYR_BASE is preferred.
Also add a comment with explanation of one vs. the other.
Tested by building hello_world for several boards ensuring no errors.
Fixes#7173.
Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
In preparation for introducing a warning.
Unquoted string defaults work through a quirk of Kconfig (undefined
symbols get their name as their string value), but look confusing. It's
done inconsistently now too.
Suggested by Kumar Gala.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
We had a comment related to the #endif for CONFIG_USB_DC_STM32 however
the comment said CONFIG_USB_DC_STM, so fix it to match the ifdef.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Use DT to generate defines for irq and reset gpios in bluetooth
controller node.
Define a bt alias to allow generation of defines with friendly
names.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
To prepare to upcoming dtc v1.4.6, fix warnings in dts files.
This commit addresses the following warning:
"unnecessary #address-cells/#size-cells without "ranges" or child
"reg" property in /gpio_keys".
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
All boards based on STM32 should use dts for I2C and SPI.
Move CONFIG flags selection from boards to arch and select them
for all STM32 SoCs.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Currently, it seems that only boards with smaller amount of RAM
get a value for "ram" property, and very few boards have "flash"
defined. However, to test bigger sample applications, it's helpful
to have these properties universally defined.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Let's point users at the latest documentation on flash
partitions from each of the board files, rather than duplicating some
of the information in it.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This moves and merges the existing board-level dts.fixup files
for STM32 F4 SOC family into one soc family level dts.fixup file.
No new fixup blocks have been added, only fixup blocks, that were
part of at least one board level dts.fixup file are present in
soc family level dts.fixup file.
96b_carbon boards fixup block for Bluetooth HCI device via SPI
stays in board level dts.fixup file, because it is board specific.
Contributes to #5707
Signed-off-by: Daniel Wagenknecht <wagenknecht.daniel@gmail.com>
Move bluetooth module SPI port related configuration
to dts and generate dts based defines on 96b_carbon
and disco_l475_iot1.
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
Instead of accessing the environment variable ZEPHYR_BASE every time we
require accessing the source code root, use an intermediate variable
that has OS path separators correctly set to '/' to avoid issues on
Windows.
Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External
applications using that will need to change to use the new ZEPHYR_BASE
variable.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Enable DT support in the dfu-util flasher when the target is a
DfuSe (DFU + ST extensions) device.
Untangling DfuSe-specific options (currently, the default is 'leave',
to immediately start running after the flashing is done) from the
actual address makes this cleaner, and sets up a subsequent patch to
let callers set DfuSe options.
It also lets us fix an unnecessary printline when flashing DfuSe
devices. There's no need to reset those, since the 'leave' modifier
starts execution immediately.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The various runners (flash/debug scripts) use environment variables to
take arguments. This is legacy behavior which is not desirable.
Use command line arguments instead.
Note: this leaves more general environment variables with publicly
documented behavior in place for now, for compatibility, e.g.:
ZEPHYR_FLASH_OVER_DFU, OPENSDA_FW, ESP_IDF_PATH, PYOCD_DAPARG
For example, when using dfu-util to flash arduino_101, instead of
setting DFUUTIL_PID, DFUUTIL_ALT, and DFUUTIL_IMG environment
variables, have the script invocation look like this:
python3 .../zephyr_flash_debug.py dfu-util flash \
[common arguments omitted] \
--pid=8087:0aba --alt=x86_app \
--img=.../build/zephyr/zephyr.bin
Make similar changes for other runners (openocd, etc.) and
targets (debug, debugserver).
To implement this in the scripts:
- have the individual scripts/support/runner/some-runner.py files
register their own command line arguments
- teach them to construct instances from arguments, not the
environment
- have zephyr_flash_debug.py request runners to register command
line argument parsers, and handle arguments
In the build system:
- add a new board_runner_args() extension function that board.cmake
files can use to add to the zephyr_flash_debug.py command line
- adjust cmake/flash/CMakeLists.txt to invoke with arguments
- add new helper include files for each runner (like
boards/common/dfu-util.board.cmake, etc.), which add default
options as needed and then add on overrides from
board_runner_args() calls
- update board.cmake files to use the new includes and extension
This implied some tweaking when using openocd to make the CMake string
escaping and unescaping work properly.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The Python-based runners have replaced the old shell scripts. Refactor
the build system accordingly:
- FLASH_SCRIPT is now BOARD_FLASH_RUNNER
- DEBUG_SCRIPT is now BOARD_DEBUG_RUNNER
The values, rather than being the names of files, are now the names of
runners in scripts/support/runner. They are still short, descriptive
names like "openocd", "jlink", "em-starterkit", etc.
Adjust the zephyr_flash_debug.py call and runner internals
accordingly. Have each runner class report a name and the commands it
can handle. This lets us move some boilerplate from each do_run()
method into the common run() routine, and enables further improvements
in future patches.
The handles_command() method is temporary, and will be replaced by a
more general mechanism for describing runner capabilities in a
subsequent patch. The initial use case for extending this is to add
device tree awareness to the runners.
To try to avoid user confusion, abort the configuration if an
xxx_SCRIPT is defined.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The old way of constructing FLASH_SCRIPT_ENV_VARS was corrupting the
values that were passed to the flasher. This new method is the
standard way of creating a dictionary/hashmap in CMake and does not
suffer from the same problem.
This fixes
https://github.com/zephyrproject-rtos/zephyr/issues/4844#event-1334599401
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Move the dts files into the board dir so that board ports can be more
standalone. This will allow us at some point to have board ports
outside of the tree.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Move the dts fixup files into the board dir so that board ports can be
more standalone. This will allow us at some point to have board ports
outside of the tree.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Move all STM32 based board pinmux files into the board dirs so we are
consistent across all the STM32 platforms/boards.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
BLE is the only networking interface on 96b_carbon, so if
CONFIG_NETWORKING is set, automatically use 6lowpan/BLE link
layer. This will allow to make networking apps work "out of the
box" on 96b_carbon, similar to e.g. qemu_x86 (which automatically
uses SLIP) or frdm_k64f (which automatically uses Ethernet).
This also enables NET_L2_BT_ZEP1656, because most 6LoWPAN/BLE samples
in Zephyr currently use that option, and it is required to achieve
working 6LoWPAN/BLE with Linux kernels currently widely accessible
to the end users. E.g. the latest Ubuntu LTS release, 16.04, ships
with 4.4 kernel, and can be upgraded with a special effort to HWE
kernel which is currently at 4.10. NET_L2_BT_ZEP1656 is needed for
both these kernels.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Stop using CONFIG_I2C_x_DEFAULT_CFG to get the initial value. Since we
only support master mode we always default to it for initial config and
we get the bitrate from the device tree.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add cross-referenced information on the 96b_carbon and
96b_carbon_nrf51 pages which disambiguates between the two "boards".
Also describe how to flash 96b_carbon_nrf51 with
samples/bluetooth/hci_spi and 96b_carbon with samples/bluetooth/ipsp
to support a Bluetooth HCI stack on 96Boards Carbon (the physical
board).
While we're here, make the documentation page for 96b_carbon match the
format in doc/templates/board.tmpl.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
On 96Boards Carbon, Bluetooth is provided by a secondary nRF51 chip
connected to SPI_1, so enable this peripheral and its driver when BT
is selected.
Similarly, provide BT_SPI_* configs to integrate with the BT HCI SPI
driver. The files these config values apply to only get built when
CONFIG_BT=y, but this configuration can't be handled in the "if BT"
section in 96b_carbon's Kconfig.defconfig. This is because BT_SPI is
a choice value, and thus doesn't support a default setting.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
We can use the chosen property "zephyr,console" to determine what uart
should be used as the console and find its name to generate a define for
CONFIG_UART_CONSOLE_ON_DEV_NAME.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This patch add I2C to supported features and I2C section for
96b_carbon, nucleof401re and olimexino_stm32
It also adds serial port section to 96b_carbon and olimexino_stm32
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
Configure I2C using DT for the following STM32 boards:
disco_l475_iot1
nucleo_f401re
96b_carbon
olimexino_stm32
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
Right now we allow for the I2C subsystem to be built without any drivers
enabled that utilize it. When we added support for the new STM32 I2C
driver we forced the I2C driver to be enabled if the I2C subsystem was
enabled. While this makes a reasonable amount of sense, it breaks
current assumptions for various testcases that we need to cleanup.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add board metadata to be consumed by the sanitycheck script to provide
better matching with testcases and to test based on features declated in
the board files.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Now that all ARM platforms have a device tree we can move selecting of
HAS_DTS up and remove any !HAS_DTS cases, as well as setting in all the
defconfigs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
More general spelling fixes, and cleaning up stray UTF-8 characters
such as curly-quotes, em- and en-dashes. Use replacement strings
for |reg| and |trade|.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commits align CONFIG_ factor names between stm32f4 and stm32l4
series to enable code factorization such as use of Q_DIVISOR.
Though, it does not concatenate kconfig sections as we might use
a bit of time to see what is needed in this regard
Change-Id: Ia603406d53949abf5675b801a5448397d5ab8462
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Following activation of stm32 common clock driver for stm32f4 series
remove references to stm32f4 specific driver.
Change-Id: I372a0ea046007bcb34944d6b2b8880077583b1d3
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This commit provides CONFIG_ definitions to support
LL based clock driver on stm32f4 boards:
96b_carbon
nucleo_f401re
nucleo_f411re
This commit sticks to clock configurations previously defined.
Two changes to notice:
-HSE clock value should now be defined
-Prescaler values required as "1" should now be set to "1" instead
of "0".
Change-Id: I003bd226f198217d5e266e11fe37094773c1c62c
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This patch adds MPU support to the 96 boards Carbon board based on
STM32F401XE.
Change-Id: I8444318099a665133488ccdd5ba129c805f9a20e
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@linaro.org>
The current PLL settings for the Carbon have two problems.
1. The VCO frequency (672MHz) is out of spec.
2. The 48MHz clock is being driven at 84MHz which breaks USB,
breaks SDIO and also risks biasing the RNG.
Fix this by bringing the VCO down to 336MHz (which also fixes
the 48MHz clock) and update the other dividers accordingly.
Change-Id: I394c476a8b27f027da5cdc31992613b376cf6aff
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Converted over all STM32F4 based boards to use device tree and removed
associated bits that now come from the device tree for STM32F4.
Boards that are now using devicetree:
* 96b_carbon
* nucleo f401re
* nucleo f411re
Change-Id: Ibe197ca0a3f5ad78d594485a578d986403cc824a
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Now that dfu-util is a supported flashing method, make it the
default flashing option for Carbon when used via 'make flash'.
Change-Id: I0d2fb9a8cbb4324ea77f1c94ca5df6f1a51e67f6
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Add the GPIO pin and port definitions for the LEDs available on the
board.
Change-Id: I586a0ebfbbe8fa6e50dd1f91c1437665dd8ec677
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
There was a misalignment between Zephyr UART device numbering and
SoC UART IP. Device "UART_1" was mapped to IP USART_2, which could
be confusing for user.
This commit allows to align "UART_1" to IP USART_1.
Change is propagated to all STM32F103RB/STM32F401RE based boards and
respective pinmux drivers
Change-Id: Ia8099dfeec7b9c0c686c2a58ccb4dbb1a55b6537
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
STM32Cube uses SoC defines made to reflect HW heterogeneity that
should be taken into account by SW.
Aim of this commit is to adapt values used by Zephyr to the same
diversity. This will help create new SoC values only when justified
by a real hardware difference that should be taken into account
by software.
For instance, for SoC stm32f401re following define is used:
*STM32F401xE
Which means:
*Same SW could be used on STM32F401RE and STM32F401CE:
same CONFIG_SOC could be used
*Different SW should be used on STMF401RE and STM32F401RC:
different CONFIG_SOC should be used
This change focuses on stm32f4xx series.
Change-Id: I56ff4d1815d09747cf722385532eb2dcbdf37b44
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Move common config options one level up to try to simplify the per-board
defconfig
Change-Id: I3d80fa494050634d0f877af2015b01b85df20d1d
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add support for the STM32F401 chip on the board
Change-Id: I96c0799f3658ecea096fa5971bce9faf21919ee1
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
