This patch enables SPI4 on the 96Boards STM32 Sensors Mezzanine.
SPI4 has been broken out to a Grove Connector on the board.
Changes:
- Updated board dts to enable spi4
- Updated board Kconfig
- Updated board documentation
- Update board pinmux
- Updated stm32f4 pinmux header file
- Updated stm32f401 dtsi
- Updated stm32f4 defconfig to enable PORTE GPIO
- Added board to spi_loopback test
Test: spi_loopback test passed
Signed-off-by: Sahaj Sarup <sahaj.sarup@linaro.org>
The GPT based counter is a count up timer.
This fixes counter_basic_api tests.
Fix over 80 chars coding style issue.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Runtime stack traces (at least as currently implemented)
don't work on x86_64 normally as RBP is treated as a general-
purpose register. Depend on CONFIG_NO_OPTIMIZATIONS to enable
this on 64-bit.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Cleanup around COND_CODE_1 usage and replacing with
IF_ENABLED if applicable.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Added macro for code inserting based on configuration flag.
This macro is wrapper around COND_CODE_1().
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Added support of the Microchip with FTDI serial devices to be able
create a hardware map for them. In the future that hardware map
for the Microchip board will let run automatic Sanitycheck tests on it.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
Explain a common subtle Kconfig gotcha where it might appear that
symbols with prompts are incorrectly "stuck" to a particular value in
the menuconfig interface. I've seen it come up several times now, e.g.
in the discussion that lead to
https://github.com/zephyrproject-rtos/zephyr/pull/20702. I also suspect
it's what's causing
https://github.com/zephyrproject-rtos/zephyr/issues/20673.
Also give suggestions for how to make things behave as intended.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Get this commit in, needed to pass CI with the doc changes in this PR:
check_compliance.py: Add STACK_SIZE to Kconfig symbol whitelist
Needed for https://github.com/zephyrproject-rtos/zephyr/pull/20722.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add any useful information from 'title:' to the 'description:' strings
(e.g. explanations of acronyms), and remove 'title:' as well as any
copy-pasted "this binding gives a ..." boilerplate.
Also clean some description strings up a bit.
Some other things could probably be cleaned up (replacing 'GPIO node'
with 'GPIO controller' on controllers for consistency, for example), but
I kept things close to the original to avoid accidentally messing up.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Most bindings look something like this:
title: Foo
description: This binding provides a base representation of Foo
That kind of description doesn't add any useful information, as it's
just the title along with some copy-pasted text. I'm not sure what "base
representation" was supposed to mean originally either.
Many bindings also put something that's closer to a description in the
title, because it's not clear what's expected or how the title is used.
In reality, the title isn't used anywhere. 'description:' on the other
hand shows up as a comment in the generated header.
Deprecate 'title:' and generate a long informative warning if it shows
up in a binding.
Next commits will clean up the 'description:' strings (bringing them
closer to 'title:' in most cases) and remove 'title:' from all bindings.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add information about the minimum Python version to the advanced Linux
documentation.
Drop 16.04 from the GSG since its system Python 3 is no longer covered
by these instructions.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Zephyr currently requires Python 3.4 or later. The core Python team
declared version 3.4 hit End of Life (EOL) in March, so there's no
reason to continue to support it if that's causing a burden, which it
is.
This commit allows Zephyr's Python scripts to depend on features
present in version 3.6 or later.
This does skip support for a currently active version of Python:
- Python 3.5 is actively supported by the core Python devs until 09/2020
- Zephyr's 2.2 release, the first which could include this change, is
tentatively scheduled for 02/2020.
However, almost all supported platforms are either unaffected, or
their users can upgrade easily:
- Windows users who need to can upgrade Python with:
choco upgrade python
- macOS users who need to can upgrade Python with:
brew upgrade python3
- Red Hat Enterprise Linux users who need to upgrade can use
Software Collections (SCLs), e.g. as described here:
https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/
- CentOS Linux users also have access to SCLs, as described here:
https://wiki.centos.org/AdditionalResources/Repositories/SCL
- Ubuntu's current long-term support (LTS) release (Bionic Beaver,
version 18.04) ships with Python 3.6. It and all later versions of
Ubuntu won't be affected by this change.
- Debian's current stable release (Buster, version 10) ships Python 3.7
and likewise won't be affected.
The impact of this change is therefore biggest for older versions of
Linux. In particular, these are impacted:
- Older Ubuntu LTS releases.
- Ubuntu 16.04 ships Python 3.5; it is still supported by Canonical.
- Ubuntu 14.04 ships Python 3.4, which is EOL. This Ubuntu version
is also no longer getting standard support from Canonical. Paying
customers are receiving security updates only.
https://wiki.ubuntu.com/Releases
- Older Debian versions.
- Debian 9 (stretch) ships Python 3.5 and is still a supported
Debian version.
- Debian 8 (jessie) ships Python 3.4, which is EOL. This Debian
version is no longer receiving mainline maintenance by the Debian
project. LTS updates are provided by interested community
volunteers only.
https://wiki.debian.org/LTS
Affected Linux users will no longer have a system Python 3 which works
"out of the box" with Zephyr after this change. Some ideas for these
users are:
- Use Zephyr v2.1 or v1.14 LTS, which are maintained and still
support Python 3.4
- Compile Python 3.6 or later from source and use it within a venv:
https://docs.python.org/3/library/venv.html
- Use something like https://github.com/pyenv/pyenv
Python 3.6 has compelling new features which make writing Zephyr's
scripts easier, and which it would be good to be able to rely upon.
This motivates moving from Python 3.4 to 3.6 instead of 3.5.
My personal killer 3.6 features motivating skipping 3.5 (YMMV):
- Windows console and file system encodings are UTF-8 (PEPs 528 and
529): Zephyr's scripts, and many utilities related to git, broadly
assume strings are UTF-8, so this is very helpful
- os.PathLike and the file system path protocol (PEP 519) allow
intermixing "smart" paths in pathlib with existing os.path based
code
- f-strings (PEP 0498) are a wonderful and efficient string
interpolation mechanism
- CPython dictionaries are insertion ordered as an implementation
detail starting with 3.6, which in practice helps with
reproducibility (and *all* Python implementations have insertion
ordered dicts starting with 3.7)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Bump to v0.10.1 Docker Image to get access to SDK 0.11.0-alpha8,
Ubuntu 18.04, gcc-9, clang-9, and python 3.6.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Based on work by Michael Scott.
Add a new Kconfig knob, CONFIG_LWM2M_IPSO_TIMESTAMP_EXTENSIONS. This
defaults to n. When enabled, various IPSO objects will by default have
the timestamp resource (5518) added to their representations. This can
be turned off on a per-object basis.
The idea of adding timestamp resources was originally suggested by
Hannes Tschofenig on this OMA page:
https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/429
Signed-off-by: Michael Scott <mike@foundries.io>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is just a cosmetic change to avoid a warning:
"unit-address and first reg (0xb0000000)
don't match for ethernet@e0009800"
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
When networking is selected, building the test
fails with:
undefined reference to `z_impl_k_thread_create'
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
When networking is selected, building the test
fails with:
error: static assertion failed: "Too many traffic classes"
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
qemu_x86_64 will exit the emulator on a fatal system error,
like qemu_x86 already does.
Improves CI times when tests fail since sanitycheck will not
need to wait for the timeout to expire.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
timeouts were not reported correctly and we were getting the default
'N/A' in case of a timeout.
Fixes#21438
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When testing with one device and without a hardware map, make sure we
load the temporary map into the suite.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
More changes moving away from using global options and instead using
class variables and parameters.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This function is not used anywhere else now that we use logging module,
so push this into the class where it is being used.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The use of a global options variable is making it very difficult to
create a testsuite for this script, so reduce and push options into
arguments instead.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Drop custom output functions and use logging mode for almost all
reporting. Also log everything into sanitycheck.log so detailed run
information can be inspected later, even if we did not run with
--verbose mode on the console.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Stop using global options and instead use propagated variable.
This is to make testing of sanitycheck easier.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
tabulate: Needed to show list of devices in a well formatted table.
anytree: needed to list testsuite in a tree form.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When something goes bad during the flashing process set the reason
correctly and put the error messages from the flasher into device.log
and display the location of that file instead of an empty handler.log
right now.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move all hardware map generation/usage to a seperate class. This will
make it easier to extend the supported hardware in the future.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
