Some boards are supported natively by qemu. This option will allow us to
run tests using those platforms directly without having to go via a
dedicated qemu board definition.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
In order to be able to document the build on Windows and UNIX
systems, slight variations are required on the app commands
that are used throughout the documentation system.
This includes getting rid of the prompt symbol and providing commands
for both UNIX and Windows operating systems.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
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>
Update board definitions with supported feature. This is temporary
until we have full coverage for device drivers in DTS, then we can use
DTS instead.
Signed-off-by: Anas Nashif <anas.nashif@intel.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>
Footnote reference in a code block is ignored. This text shouldn't
really be in a code block anyway, so just make it a paragraph with a
trailing footnote reference.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Not all boards require the various binary formats zephyr generates. So
be selective based on the arch, SoC or board and only geenrate the
binaries actually needed.
Fixes#5009
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Clean up & rework JTAG documentation for ESP-32 boards to provide full
commands and clarify gotchas.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Supports both master and slave mode, standard and fast modes,
configurable timeouts, and a few other tunable settings.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
ESP-IDF is in constant development and it's likely that files Zephyr
depends on will be moved, removed, or renamed. Make a note that an
older version of ESP-IDF should be used instead.
Closes#1538.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Move all QEMU related defines to the boards and cleanup xtensa platforms
which were marked to be QEMU capable by mistake.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
xtensa uses more stack than other arches, enable the sentinel since we
don't currently have HW-assisted stack checking on this arch.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The ESP-WROOM-32 board exits the bootloader at 40 MHz, not 160 MHz as
suggested by documentation. The CCOUNT special register works as
advertised, but not at the expected rate. This was verified by
timestamping (at the host) the output of a dependency-free loop that
looks like:
int key = irq_lock();
while(1) {
u32_t i, count;
volatile int dummy;
for(i = 0; i < 5000000; i++) {
dummy++;
}
__asm__ volatile ("rsr.ccount %0" : "=a"(count));
printk("%d\n", count);
}
The SoC has a fairly robust set of possible CPU clocking modes, but we
don't have a driver for that yet. Until we do, set the single
configured CPU frequency to the one we get at runtime.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The Xtensa port was the only one remaining to be converted to the new
way of connecting interrupts in Zephyr. Some things are still
unconverted, mainly the exception table, and this will be performed
another time.
Of note: _irq_priority_set() isn't called on _ARCH_IRQ_CONNECT(), since
IRQs can't change priority on Xtensa: while the architecture has the
concept of interrupt priority levels, each line has a fixed level and
can't be changed.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The random number generator from ESP32 uses noise from Wi-Fi and
Bluetooth radios. If these are off, a pseudo-random number is
generated instead; this is currently the case, but even though it's a
black box, it's arguably better than returning a timestamp as a
pseudo-random number generator.
According to the ESP32 Technical Reference manual, the RNG passed the
Dieharder Random Number Test suite (version 3.31.1)[1], but nothing has
been said about the quality of the PRNG.
The RNG register is read directly; no effort is made to use its
contents to feed an entropy pool in a way that's similar to /dev/random
on POSIX systems, as no such subsystem exists on Zephyr at the moment.
[1] http://webhome.phy.duke.edu/~rgb/General/dieharder.php
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This provides basic GPIO support, with interrupts, and the ability to
read and write to ports on a pin-by-pin basis.
Jira: ZEP-2286
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This implements a driver for the pin multiplexer as present in the ESP32
SoCs.
All APIs are supported.
Jira: ZEP-2297
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
ReST defines interpreted text roles where text enclosed by single quotes
can be "intrepreted", for example :ref:`some name` becomes a link to
a label anywhere in the doc set named "some name", :c:func:`funcname()`
becomes a link to the API documentation for "funcname", and
:option:`CONFIG_NAME` becomes a link to, in our case, the documentation
for the generated Kconfig option.
This patch fixes uses of `some name` (without a role) by either adding
an explicit role, or changing to ``some name``, which indicates inline
code block formatting (most likely what was intended).
This is a precursor to changing the default behavior of interpreted
text to treat `some name` as :any:`some name` (as configured in
doc/conf.py), which would attempt to create a link to any available
definition of "some name".
We may not change this default role behavior, but it becomes an option
after the fixes in this patch. In any case, this patch fixes incorrect
uses of single-quoted text (possibly introduced because GitHub's
markdown language uses single-quoted text for inline code formatting).
Jira: ZEP-2414
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
The documentation details how to install and configure all the
pre-requisites to build Zephyr for the ESP32 SoC, including using the
vendor SDK and toolchain, the flashing tool, and how to use JTAG.
Jira: ZEP-2109
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This will allow checking if we are building for QEMU globally, without
having to know the exact architecture and board name.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Sidebar navigation for supported boards is wonky: opens to show
all boards (making for lots of scrolling to see the sidebar) and
sidebar items aren't always clickable (as explained in the JIRA
issue).
Fix is to not use multiple toctree directives in boards.rst and
create intermediate architecture-specific supported board docs.
JIRA: INF-132
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
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>
This flashes Zephyr at 0x1000: that's where the first stage bootloader,
part of the ESP32 ROM, expects to find an "image header".
The second-stage bootloader, part of ESP-IDF, isn't used by the Zephyr
port. However, the bootloader can be used if desired; please refer to
the ESP-IDF documentation on how to set up partitions tables and use
the bootloader.
The following environment variables will affect the ESP32 flashing
process:
Variable Default value
ESP_DEVICE /dev/ttyUSB0
ESP_BAUD_RATE 921600
ESP_FLASH_SIZE detect
ESP_FLASH_FREQ 40m
ESP_FLASH_MODE dio
ESP_TOOL espidf
It's impossible to determine which serial port the ESP32 board is
connected to, as it uses a generic RS232-USB converter. The default of
/dev/ttyUSB0 is provided as that's often the assigned name on a Linux
machine without any other such converters.
The baud rate of 921600bps is recommended. If experiencing issues when
flashing, try halving the value a few times (460800, 230400, 115200,
etc). It might be necessary to change the flash frequency or the flash
mode; please refer to the esptool documentation for guidance on these
settings.
If ${ESP_TOOL} is set to "espidf", the esptool.py script found within
ESP-IDF will be used. Otherwise, this variable is handled as a path to
the tool.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The first stage bootloader, part of the ESP32 ROM, already sets up
a stack that's sufficient to execute C programs. So, instead of
implementing __stack() in assembly, do it in C to simplify things
slightly.
This ESP32-specific initialization will perform the following:
- Disable the watchdog timer that's enabled by the bootloader
- Move exception handlers to IRAM
- Disable normal interrupts
- Disable the second CPU
- Zero out the BSS segment
Things that might be performed in the future include setting up the
CPU frequency, memory protection regions, and enabling the flash
cache.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Unconditionally use CONFIG_SIMULATOR_XTENSA to determine if XT_SIMULATOR
or XT_BOARD should be defined.
If CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC, also define XT_CLOCK_FREQ. This
isn't ideal as the clock frequency might be changed in runtime and this
effectively makes it a constant.
Until we can control the clock frequency in runtime, this will suffice.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This is a minimal driver enabling console output during the port
bringup. While the driver works, only one of the three UART devices
are supported, and there isn't any way to change any parameters or
use interrupts. This will most likely be superceded by a proper
driver after the port has matured.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Now that we can specify what toolchain is intended for each
SOC, enable some more SOCs to be built.
A full sanitycheck run will require the installation of both
RF-2016.4 and RG-2016.4 releases.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The xtensa simulator can in fact simulate a variety of Xtensa SOCs.
Fixes build for alternate xt-sim_* defconfigs.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The xt-sim defconfigs were selecting CONFIG_SIMULATOR_XTENSA instead
of CONFIG_BOARD_SIMULATOR_XTENSA.
Fix defconfigs and rename to CONFIG_BOARD_XT_SIM to ease any future
confusion between these similarly named defconfigs.
CONFIG_SIMULATOR_XTENSA is automatically set by xt-sim's
Kconfig.defconfig, it doesn't need to be explicitly specified in the
defconfigs themselves.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Anas Nashif