doc: misspelling and UTF-8 fixes
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 commit is contained in:
David B. Kinder
Anas Nashif
parent
ed96de9f10
commit
2f41cb8329
43 changed files with 119 additions and 115 deletions
10
README.rst
10
README.rst
|
|
@ -1,7 +1,7 @@
|
|||
Zephyr™ Project
|
||||
###############
|
||||
Zephyr Project
|
||||
##############
|
||||
|
||||
The Zephyr™ Project is a scalable real-time operating system (RTOS) supporting
|
||||
The Zephyr Project is a scalable real-time operating system (RTOS) supporting
|
||||
multiple hardware architectures, optimized for resource constrained devices,
|
||||
and built with security in mind.
|
||||
|
||||
|
|
@ -29,11 +29,11 @@ Welcome to the Zephyr community!
|
|||
Resources
|
||||
*********
|
||||
|
||||
Here’s a quick summary of resources to find your way around the Zephyr Project
|
||||
Here's a quick summary of resources to find your way around the Zephyr Project
|
||||
support systems:
|
||||
|
||||
* **Zephyr Project Website**: The https://zephyrproject.org website is the
|
||||
central source of information about the Zephyr Project. On this site, you’ll
|
||||
central source of information about the Zephyr Project. On this site, you'll
|
||||
find background and current information about the project as well as all the
|
||||
relevant links to project material. For a quick start, refer to the
|
||||
`Zephyr Introduction`_ and `Getting Started Guide`_.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Arduino/Genuino 101 (Sensor Subsystem)
|
|||
The Arduino 101 contains a 32 MHz Argonaut RISC Core (ARC)* EM processor as part
|
||||
of the Quark SE C1000 SoC within the Curie module.
|
||||
The ARC core is referenced as the digital signal processor (DSP) sensor hub or a
|
||||
sensor subsystem depending on what document you’re looking at.
|
||||
sensor subsystem depending on what document you're looking at.
|
||||
|
||||
For more information about using the sensor subsystem with Zephyr, see
|
||||
:ref:`arduino_101`.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Hardware
|
|||
96Boards Carbon provides the following hardware components:
|
||||
|
||||
- STM32F401RET6 in LQFP64 package
|
||||
- ARM®32-bit Cortex®-M4 CPU with FPU
|
||||
- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
|
||||
- 84 MHz max CPU frequency
|
||||
- VDD from 1.7 V to 3.6 V
|
||||
- 512 KB Flash
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Hardware
|
|||
96Boards Nitrogen provides the following hardware components:
|
||||
|
||||
- nRF52832 microcontroller with 512kB Flash, 64kB RAM
|
||||
- ARM®32-bit Cortex®-M4 CPU with FPU
|
||||
- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
|
||||
- Bluetooth LE
|
||||
- NFC
|
||||
- LPC11U35 on board SWD debugger
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ CC3200 LaunchXL
|
|||
Overview
|
||||
********
|
||||
The SimpleLink CC3200 LaunchXL is a development board for the CC3200
|
||||
wireless microcontroller (MCU), the industry’s first single-chip
|
||||
wireless microcontroller (MCU), the industry's first single-chip
|
||||
programmable MCU with built-in Wi-Fi connectivity.
|
||||
|
||||
Features:
|
||||
|
|
@ -29,7 +29,7 @@ Hardware
|
|||
|
||||
The CC3200 SoC has two MCUs:
|
||||
|
||||
#. Applications MCU - an ARM® Cortex®-M4 Core at 80 MHz, with 256Kb RAM,
|
||||
#. Applications MCU - an ARM |reg| Cortex |reg|-M4 Core at 80 MHz, with 256Kb RAM,
|
||||
and access to external serial 1Mb flash with bootloader and peripheral
|
||||
drivers in ROM.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Hardware
|
|||
|
||||
The CC3220SF SoC has two MCUs:
|
||||
|
||||
#. Applications MCU - an ARM® Cortex®-M4 Core at 80 MHz, with 256Kb RAM,
|
||||
#. Applications MCU - an ARM |reg| Cortex |reg|-M4 Core at 80 MHz, with 256Kb RAM,
|
||||
and access to external serial 1Mb flash with bootloader and peripheral
|
||||
drivers in ROM.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Curie (BLE)
|
||||
###########
|
||||
|
||||
The Intel® Curie* module includes Bluetooth LE to enable developers to interact with
|
||||
The Intel |reg| Curie* module includes Bluetooth LE to enable developers to interact with
|
||||
Bluetooth enabled devices such as phones and tablets.
|
||||
|
||||
See :ref:`arduino_101` for information how to use the BLE module with Zephyr on the Arduino
|
||||
|
|
|
|||
|
|
@ -9,15 +9,15 @@ Overview
|
|||
The B-L475E-IOT01A Discovery kit for IoT node allows users to develop
|
||||
applications with direct connection to cloud servers.
|
||||
The Discovery kit enables a wide diversity of applications by exploiting
|
||||
low-power communication, multiway sensing and ARM® Cortex® -M4 core-based
|
||||
low-power communication, multiway sensing and ARM |reg| Cortex |reg|-M4 core-based
|
||||
STM32L4 Series features.
|
||||
|
||||
This kit provides:
|
||||
|
||||
- 64-Mbit Quad-SPI (Macronix) Flash memory
|
||||
- Bluetooth® V4.1 module (SPBTLE-RF)
|
||||
- Bluetooth |reg| V4.1 module (SPBTLE-RF)
|
||||
- Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915)
|
||||
- Wi-Fi® module Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant)
|
||||
- Wi-Fi |reg| module Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant)
|
||||
- Dynamic NFC tag based on M24SR with its printed NFC antenna
|
||||
- 2 digital omni-directional microphones (MP34DT01)
|
||||
- Capacitive digital sensor for relative humidity and temperature (HTS221)
|
||||
|
|
@ -28,7 +28,7 @@ This kit provides:
|
|||
- 2 push-buttons (user and reset)
|
||||
- USB OTG FS with Micro-AB connector
|
||||
- Expansion connectors:
|
||||
- Arduino™ Uno V3
|
||||
- Arduino |trade| Uno V3
|
||||
- PMOD
|
||||
- Flexible power-supply options:
|
||||
- ST LINK USB VBUS or external sources
|
||||
|
|
@ -49,14 +49,15 @@ Hardware
|
|||
|
||||
The STM32L475RG SoC provides the following hardware IPs:
|
||||
|
||||
- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 μA/MHz run mode)
|
||||
- Core: ARM® 32-bit Cortex®-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
|
||||
- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 uA/MHz run mode)
|
||||
- Core: ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
|
||||
- Clock Sources:
|
||||
- 4 to 48 MHz crystal oscillator
|
||||
- 32 kHz crystal oscillator for RTC (LSE)
|
||||
- Internal 16 MHz factory-trimmed RC (±1%)
|
||||
- Internal low-power 32 kHz RC (±5%)
|
||||
- Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by LSE (better than ±0.25 % accuracy)
|
||||
- Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by
|
||||
LSE (better than ±0.25 % accuracy)
|
||||
- 3 PLLs for system clock, USB, audio, ADC
|
||||
- RTC with HW calendar, alarms and calibration
|
||||
- Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors
|
||||
|
|
@ -75,7 +76,7 @@ The STM32L475RG SoC provides the following hardware IPs:
|
|||
- Quad SPI memory interface
|
||||
- 4x digital filters for sigma delta modulator
|
||||
- Rich analog peripherals (independent supply)
|
||||
- 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 μA/MSPS
|
||||
- 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 uA/MSPS
|
||||
- 2x 12-bit DAC, low-power sample and hold
|
||||
- 2x operational amplifiers with built-in PGA
|
||||
- 2x ultra-low-power comparators
|
||||
|
|
@ -90,7 +91,7 @@ The STM32L475RG SoC provides the following hardware IPs:
|
|||
- 14-channel DMA controller
|
||||
- True random number generator
|
||||
- CRC calculation unit, 96-bit unique ID
|
||||
- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell™
|
||||
- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell |trade|
|
||||
|
||||
|
||||
More information about STM32L476RG can be found here:
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Hardware
|
|||
- RGB LED
|
||||
- FXOS8700CQ accelerometer and magnetometer
|
||||
- Two user push buttons
|
||||
- Flexible power supply option – OpenSDAv2 USB, Kinetis K64 USB, and external source
|
||||
- Flexible power supply option - OpenSDAv2 USB, Kinetis K64 USB, and external source
|
||||
- Easy access to MCU input/output through Arduino* R3 compatible I/O connectors
|
||||
- Programmable OpenSDAv2 debug circuit supporting the CMSIS-DAP Interface
|
||||
software that provides:
|
||||
|
|
|
|||
|
|
@ -6,14 +6,15 @@ NXP FRDM-KW41Z
|
|||
Overview
|
||||
********
|
||||
|
||||
The FRDM-KW41Z is a development kit enabled by the Kinetis® W series
|
||||
KW41Z/31Z/21Z (KW41Z) family built on ARM® Cortex®-M0+ processor with
|
||||
integrated 2.4 GHz transceiver supporting Bluetooth® Smart/Bluetooth®Low Energy
|
||||
(BLE) v4.2, Generic FSK, IEEE® 802.15.4 and Thread.
|
||||
The FRDM-KW41Z is a development kit enabled by the Kinetis |reg| W series
|
||||
KW41Z/31Z/21Z (KW41Z) family built on ARM |reg| Cortex |reg|-M0+ processor with
|
||||
integrated 2.4 GHz transceiver supporting Bluetooth |reg| Smart/Bluetooth
|
||||
|reg| Low Energy
|
||||
(BLE) v4.2, Generic FSK, IEEE |reg| 802.15.4 and Thread.
|
||||
|
||||
The FRDM-KW41Z kit contains two Freedom boards that can be used as a
|
||||
development board or a shield to connect to a host processor. The FRDM-KW41Z is
|
||||
form-factor compatible with the Arduino™ R3 pin layout for more expansion
|
||||
form-factor compatible with the Arduino |trade| R3 pin layout for more expansion
|
||||
options.
|
||||
|
||||
The FRDM-KW41Z highly-sensitive, optimized 2.4 GHz radio features a PCB
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Overview
|
|||
Hexiwear is powered by a Kinetis K64 microcontroller based on the ARM Cortex-M4
|
||||
core. Another Kinetis wireless MCU, the KW40Z, provides Bluetooth Low Energy
|
||||
connectivity. Hexiwear also integrates a wide variety of sensors, as well as a
|
||||
user interface consisting of a 1.1” 96px x 96px full color OLED display and six
|
||||
user interface consisting of a 1.1" 96px x 96px full color OLED display and six
|
||||
capacitive buttons with haptic feedback.
|
||||
|
||||
- Eye-catching Smart Watch form factor with powerful, low power Kinetis K6x MCU
|
||||
|
|
@ -17,7 +17,7 @@ capacitive buttons with haptic feedback.
|
|||
- Designed for wearable applications with the onboard rechargeable battery,
|
||||
OLED screen and onboard sensors such as optical heart rate, accelerometer,
|
||||
magnetometer and gyroscope.
|
||||
- Designed for IoT end node applications with the onboard sensor’s such as
|
||||
- Designed for IoT end node applications with the onboard sensor's such as
|
||||
temperature, pressure, humidity and ambient light.
|
||||
- Flexibility to let you add the sensors of your choice nearly 200 additional
|
||||
sensors through click boards.
|
||||
|
|
@ -39,7 +39,7 @@ Hardware
|
|||
- Li-Ion/Li-Po Battery Charger NXP MC34671
|
||||
- Optical heart rate sensor Maxim MAX30101
|
||||
- Ambient Light sensor, Humidity and Temperature sensor
|
||||
- 1.1” full color OLED display
|
||||
- 1.1" full color OLED display
|
||||
- Haptic feedback engine
|
||||
- 190 mAh 2C Li-Po battery
|
||||
- Capacitive touch interface
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Hardware
|
|||
Nucleo F401RE provides the following hardware components:
|
||||
|
||||
- STM32F401RET6 in LQFP64 package
|
||||
- ARM®32-bit Cortex®-M4 CPU with FPU
|
||||
- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
|
||||
- 84 MHz max CPU frequency
|
||||
- VDD from 1.7 V to 3.6 V
|
||||
- 512 KB Flash
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Hardware
|
|||
Nucleo F411RE provides the following hardware components:
|
||||
|
||||
- STM32F411RET6 in LQFP64 package
|
||||
- ARM®32-bit Cortex®-M4 CPU with FPU
|
||||
- ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
|
||||
- 100 MHz max CPU frequency
|
||||
- VDD from 1.7 V to 3.6 V
|
||||
- 512 KB Flash
|
||||
|
|
|
|||
|
|
@ -35,17 +35,18 @@ Hardware
|
|||
|
||||
The STM32L476RG SoC provides the following hardware IPs:
|
||||
|
||||
- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 μA/MHz run mode)
|
||||
- Core: ARM® 32-bit Cortex®-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
|
||||
- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 uA/MHz run mode)
|
||||
- Core: ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
|
||||
- Clock Sources:
|
||||
- 4 to 48 MHz crystal oscillator
|
||||
- 32 kHz crystal oscillator for RTC (LSE)
|
||||
- Internal 16 MHz factory-trimmed RC (±1%)
|
||||
- Internal low-power 32 kHz RC (±5%)
|
||||
- Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by LSE (better than ±0.25 % accuracy)
|
||||
- Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by
|
||||
LSE (better than ±0.25 % accuracy)
|
||||
- 3 PLLs for system clock, USB, audio, ADC
|
||||
- RTC with HW calendar, alarms and calibration
|
||||
- LCD 8 × 40 or 4 × 44 with step-up converter
|
||||
- LCD 8 x 40 or 4 x 44 with step-up converter
|
||||
- Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors
|
||||
- 16x timers:
|
||||
- 2x 16-bit advanced motor-control
|
||||
|
|
@ -62,7 +63,7 @@ The STM32L476RG SoC provides the following hardware IPs:
|
|||
- Quad SPI memory interface
|
||||
- 4x digital filters for sigma delta modulator
|
||||
- Rich analog peripherals (independent supply)
|
||||
- 3× 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 μA/MSPS
|
||||
- 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 uA/MSPS
|
||||
- 2x 12-bit DAC, low-power sample and hold
|
||||
- 2x operational amplifiers with built-in PGA
|
||||
- 2x ultra-low-power comparators
|
||||
|
|
@ -77,7 +78,7 @@ The STM32L476RG SoC provides the following hardware IPs:
|
|||
- 14-channel DMA controller
|
||||
- True random number generator
|
||||
- CRC calculation unit, 96-bit unique ID
|
||||
- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell™
|
||||
- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell |trade|
|
||||
|
||||
|
||||
More information about STM32L476RG can be found here:
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ the Nios II Gen 2 soft CPU.
|
|||
.. figure:: img/max_10_dev_kit_top_photo.jpg
|
||||
:width: 442px
|
||||
:align: center
|
||||
:alt: Altera’s MAX* 10
|
||||
:alt: Altera's MAX* 10
|
||||
|
||||
Altera’s MAX* 10 (Credit: Altera)
|
||||
Altera's MAX* 10 (Credit: Altera)
|
||||
|
||||
Hardware
|
||||
********
|
||||
|
|
@ -35,7 +35,7 @@ importance is SW2:
|
|||
.. image:: img/Altera_MAX10_switches.jpg
|
||||
:width: 442px
|
||||
:align: center
|
||||
:alt: Altera’s MAX* 10 Switches
|
||||
:alt: Altera's MAX* 10 Switches
|
||||
|
||||
Other switches are user switches, their position is application-specific.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Overview
|
|||
********
|
||||
|
||||
The Arduino/Genuino 101 is a learning and development board which contains an
|
||||
Intel® Curie™ Module. This board is designed to integrate the core's low
|
||||
Intel |reg| Curie |trade| Module. This board is designed to integrate the core's low
|
||||
power-consumption and high performance with the Arduino's ease-of-use. The
|
||||
Arduino 101 adds Bluetooth Low Energy capabilities and has an on-board 6-axis
|
||||
accelerometer/gyroscope, providing exciting opportunities for building creative
|
||||
|
|
@ -24,7 +24,7 @@ The Intel Quark* SE SoC in the Curie module contains a single core 32 MHz x86
|
|||
(Intel Quark* processor) and the 32 MHz Argonaut RISC Core (ARC)* EM processor.
|
||||
The two processors operate simultaneously and share memory. The ARC processor is
|
||||
also referenced as the digital signal processor (DSP) sensor hub or a sensor
|
||||
subsystem depending on what document you’re looking at. In theory, the DSP can
|
||||
subsystem depending on what document you're looking at. In theory, the DSP can
|
||||
run using a minimal amount of power, gathering and processing sensor data while
|
||||
the x86 processor waits in a low power mode, which would be ideal for always-on
|
||||
applications.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Quark D2000 Development Board
|
|||
Overview
|
||||
********
|
||||
|
||||
The Intel® Quark ™ microcontroller D2000 package is shipped as a 40-pin QFN
|
||||
The Intel |reg| Quark |trade| microcontroller D2000 package is shipped as a 40-pin QFN
|
||||
component.
|
||||
|
||||
.. image:: quark-d2000-developers-kit.png
|
||||
|
|
@ -14,7 +14,7 @@ component.
|
|||
:align: center
|
||||
:alt: Quark D2000 Development Board
|
||||
|
||||
Intel™ Quark® microcontroller D2000 contains the following items:
|
||||
Intel |reg| Quark |trade| microcontroller D2000 contains the following items:
|
||||
|
||||
- On-board components:
|
||||
|
||||
|
|
@ -23,11 +23,11 @@ Intel™ Quark® microcontroller D2000 contains the following items:
|
|||
|
||||
- Expansion options:
|
||||
|
||||
- “Arduino Uno” compatible SIL sockets ( 3.3V IO Only )
|
||||
- "Arduino Uno" compatible SIL sockets ( 3.3V IO Only )
|
||||
|
||||
- Other connectors:
|
||||
|
||||
- 1x USB 2.0 Device Port – micro Type B
|
||||
- 1x USB 2.0 Device Port - micro Type B
|
||||
- On-board coin cell battery holder
|
||||
- 5V input a screw terminal/header (external power or Li-ion)
|
||||
- EEMBC power input header
|
||||
|
|
@ -38,7 +38,7 @@ Hardware
|
|||
General information for the board can be found at the `Intel Website`_,
|
||||
which includes both `schematics`_ and BRD files.
|
||||
|
||||
The Intel® Quark™ Microcontroller D2000 Development Platform supports the
|
||||
The Intel |reg| Quark |trade| Microcontroller D2000 Development Platform supports the
|
||||
familiar open standard Arduino Uno Rev 3.0 physical interface and is
|
||||
mechanically compatible with Uno Rev 3.0. It does not support the 6 pin ICSP
|
||||
Header.
|
||||
|
|
|
|||
|
|
@ -20,8 +20,8 @@ See :ref:`arduino_101` for information how to use the tinyTILE board with Zephyr
|
|||
|
||||
Features of the tinyTILE include:
|
||||
|
||||
- Intel® Curie™ module dual-core (Intel® Quark* processor core and ARC* core)
|
||||
- Bluetooth® low energy, 6-axis combo sensor and pattern matching engine
|
||||
- Intel |reg| Curie |trade| module dual-core (Intel |reg| Quark* processor core and ARC* core)
|
||||
- Bluetooth |reg| low energy, 6-axis combo sensor and pattern matching engine
|
||||
- 14 digital input/output pins (four can be used as PWM output pins)
|
||||
- Four PWM output pins
|
||||
- Six analog input pins
|
||||
|
|
|
|||
|
|
@ -48,8 +48,8 @@ The frequency of the clock under simulation is set to 25MHz.
|
|||
System requirements
|
||||
*******************
|
||||
|
||||
Pre-requisites
|
||||
==============
|
||||
Prerequisites
|
||||
=============
|
||||
A Linux host system is required for Xtensa development work.
|
||||
We recommend using a __``Debian 9.x (Stretch)``__ or recent __``Ubuntu``__
|
||||
releases (with multilib support).
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ with basic priority inheritance.
|
|||
Alerts
|
||||
******
|
||||
|
||||
Alerts enable an application to perform asynchronous signalling,
|
||||
Alerts enable an application to perform asynchronous signaling,
|
||||
somewhat akin to Unix-style signals.
|
||||
(See :ref:`alerts_v2`.)
|
||||
|
||||
|
|
|
|||
|
|
@ -306,7 +306,8 @@ An application's :file:`.conf` file defines its default kernel configuration.
|
|||
The settings in this file override or augment the board configuration settings.
|
||||
|
||||
The board configuration settings can be viewed
|
||||
in :file:`$ZEPHYR_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
|
||||
LENGTHlWRONGEPHY
|
||||
_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
|||
|
|
@ -78,8 +78,8 @@ help prevent security violations and limit their impact:
|
|||
and permitted only in specific conditions defined by the system
|
||||
protection scheme, e.g., after successful authentication.
|
||||
Furthermore, default settings for services shall be chosen in a way
|
||||
to provide maximum security. This corresponds to the “Secure by
|
||||
Default” paradigm [MICRO12]_.
|
||||
to provide maximum security. This corresponds to the "Secure by
|
||||
Default" paradigm [MICRO12]_.
|
||||
|
||||
- **Separation of privilege** is the principle that two conditions or
|
||||
more need to be satisfied before access is granted. In the context
|
||||
|
|
@ -220,7 +220,7 @@ scripting, missing authentication, and missing authorization. See the
|
|||
Security Subcommittee
|
||||
=====================
|
||||
|
||||
There shall be a “security subcommittee”, responsible for
|
||||
There shall be a "security subcommittee", responsible for
|
||||
enforcing this guideline, monitoring reviews, and improving these
|
||||
guidelines.
|
||||
|
||||
|
|
@ -280,12 +280,12 @@ and approved by consensus.
|
|||
|
||||
.. _attack: http://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack-cause-outage-status-explained
|
||||
|
||||
.. [MICRO12] Microsoft Corporation, Security Development Lifecycle – SDL
|
||||
.. [MICRO12] Microsoft Corporation, Security Development Lifecycle - SDL
|
||||
Process Guidance Version 5.2, 2012.
|
||||
|
||||
.. [PAUL09] M. Paul, "The Ten Best Practices for Secure Software
|
||||
Development," International Information Systems Security Certification
|
||||
Consortium, Inc. [(ISC)2®], Palm Harbor, FL, USA, 2009.
|
||||
Consortium, Inc. [(ISC)2], Palm Harbor, FL, USA, 2009.
|
||||
|
||||
.. [SALT75] J. H. Saltzer and M. D. Schroeder, "The protection of
|
||||
information in computer systems," Proceedings of the IEEE,
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ Running a Sample Application in QEMU
|
|||
====================================
|
||||
|
||||
To perform rapid testing of an application in the development environment you
|
||||
can use the qemu emulation board configuration available for both X86 and ARM
|
||||
can use the QEMU emulation board configuration available for both X86 and ARM
|
||||
Cortex-M3 architectures. This can be easily accomplished by calling a special
|
||||
target when building an application that invokes QEMU once the build process is
|
||||
completed.
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ up:
|
|||
|
||||
.. note::
|
||||
|
||||
The ISSM toolset only supports development for Intel® Quark™
|
||||
The ISSM toolset only supports development for Intel |reg| Quark |trade|
|
||||
Microcontrollers, for example, the Arduino 101 board. (Check out the
|
||||
"Zephyr Development Environment
|
||||
Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.)
|
||||
|
|
@ -118,7 +118,7 @@ up:
|
|||
#. Finally, you can try building the :ref:`hello_world` sample to check things
|
||||
out.
|
||||
|
||||
To build for the Intel® Quark™ (x86-based) Arduino 101:
|
||||
To build for the Intel |reg| Quark |trade| (x86-based) Arduino 101:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ Windows, you will need to build or install a toolchain:
|
|||
|
||||
.. note::
|
||||
|
||||
The ISSM toolset only supports development for Intel® Quark™
|
||||
The ISSM toolset only supports development for Intel |reg| Quark |trade|
|
||||
Microcontrollers, for example, the Arduino 101 board. (Check out the
|
||||
"Zephyr Development Environment
|
||||
Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.)
|
||||
|
|
|
|||
|
|
@ -371,7 +371,7 @@ can examine the message descriptor to determine which thread sent the message,
|
|||
how much data was exchanged,
|
||||
and the application-defined info value supplied by the sending thread.
|
||||
|
||||
Any number of receiving threads may wait simultaneously on a mailboxes's
|
||||
Any number of receiving threads may wait simultaneously on a mailboxes'
|
||||
receive queue. The threads are sorted according to their priority;
|
||||
threads of equal priority are sorted so that the one that started waiting
|
||||
first can receive a message first.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Heap Memory Pool
|
||||
################
|
||||
|
||||
The :dfn:`heap memory pool` is a pre-defined memory pool object that allows
|
||||
The :dfn:`heap memory pool` is a predefined memory pool object that allows
|
||||
threads to dynamically allocate memory from a common memory region
|
||||
in a :cpp:func:`malloc()`-like manner.
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ is running.
|
|||
interrupted until it has explicitly unlocked its IRQ lock.
|
||||
|
||||
Alternatively, a thread may temporarily **disable** a specified IRQ
|
||||
so its associated ISR does not execute when the IRQ is signalled.
|
||||
so its associated ISR does not execute when the IRQ is signaled.
|
||||
The IRQ must be subsequently **enabled** to permit the ISR to execute.
|
||||
|
||||
.. important::
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ in system clock ticks. This change makes things more intuitive for most
|
|||
developers. However, the kernel still implements timeouts using the
|
||||
tick-based system clock.
|
||||
|
||||
The previous nanokernel timer and microkernel timer object types have beeni
|
||||
The previous nanokernel timer and microkernel timer object types have been
|
||||
merged into a single type.
|
||||
|
||||
Memory Allocation
|
||||
|
|
@ -123,7 +123,7 @@ from a heap data pool.
|
|||
Synchronization
|
||||
***************
|
||||
|
||||
The prevous nanokernel semaphore and microkernel semaphore object types have been
|
||||
The previous nanokernel semaphore and microkernel semaphore object types have been
|
||||
merged into a single type. The new type can now be used as a binary semaphore,
|
||||
as well as a counting semaphore.
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ non-blocking manner or use an additional mechanism, such as an event object,
|
|||
to signal the application that one of the semaphores is available.
|
||||
|
||||
The previous microkernel event object type is renamed to "alert" and is now presented as
|
||||
a relative to Unix-style signalling. Due to improvements to the implementation
|
||||
a relative to Unix-style signaling. Due to improvements to the implementation
|
||||
of semaphores, alerts are now less efficient to use for basic synchronization
|
||||
than semaphores; consequently, alerts should now be reserved for scenarios
|
||||
requiring the use of a callback function.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ features needed by your application, making it ideal for systems with limited
|
|||
amounts of memory (as little as 2 KB!) or with simple multi-threading
|
||||
requirements (such as a set of interrupt handlers and a single background task).
|
||||
Examples of such systems include: embedded sensor hubs, environmental sensors,
|
||||
simple LED wearables, and store inventory tags.
|
||||
simple LED wearable, and store inventory tags.
|
||||
|
||||
Applications requiring more memory (50 to 900 KB), multiple communication
|
||||
devices (like WiFi and Bluetooth Low Energy), and complex multi-threading,
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Alerts
|
|||
######
|
||||
|
||||
An :dfn:`alert` is a kernel object that allows an application to perform
|
||||
asynchronous signalling when a condition of interest occurs.
|
||||
asynchronous signaling when a condition of interest occurs.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
|
@ -19,7 +19,7 @@ its memory address.
|
|||
An alert has the following key properties:
|
||||
|
||||
* An **alert handler**, which specifies the action to be taken
|
||||
when the alert is signalled. The action may instruct the system workqueue
|
||||
when the alert is signaled. The action may instruct the system workqueue
|
||||
to execute a function to process the alert, mark the alert as pending
|
||||
so it can be processed later by a thread, or ignore the alert.
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ significant differences. The most notable of these are:
|
|||
* A Zephyr alert pends *after* it has been delivered to its alert handler,
|
||||
and only if an alert handler function does not consume the alert.
|
||||
|
||||
* Zephyr has no pre-defined alerts or actions. All alerts are application
|
||||
* Zephyr has no predefined alerts or actions. All alerts are application
|
||||
defined, and all have a default action that pends the alert.
|
||||
|
||||
Implementation
|
||||
|
|
@ -116,7 +116,7 @@ The following code has the same effect as the code segment above.
|
|||
Signaling an Alert
|
||||
==================
|
||||
|
||||
An alert is signalled by calling :cpp:func:`k_alert_send()`.
|
||||
An alert is signaled by calling :cpp:func:`k_alert_send()`.
|
||||
|
||||
The following code illustrates how an ISR can signal an alert
|
||||
to indicate that a key press has occurred.
|
||||
|
|
@ -137,7 +137,7 @@ to indicate that a key press has occurred.
|
|||
Handling an Alert
|
||||
=================
|
||||
|
||||
An alert handler function is used when a signalled alert should not be ignored
|
||||
An alert handler function is used when a signaled alert should not be ignored
|
||||
or immediately pended. It has the following form:
|
||||
|
||||
.. code-block:: c
|
||||
|
|
@ -162,7 +162,7 @@ key presses detected by an ISR (as shown in the previous section).
|
|||
/* do complex processing of the keystroke */
|
||||
...
|
||||
|
||||
/* signalled alert has been consumed */
|
||||
/* signaled alert has been consumed */
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
@ -189,10 +189,10 @@ only when a numeric key is pressed.
|
|||
if ((c >= '0') && (c <= '9')) {
|
||||
/* save key press information */
|
||||
...
|
||||
/* signalled alert should be pended */
|
||||
/* signaled alert should be pended */
|
||||
return 1;
|
||||
} else {
|
||||
/* signalled alert has been consumed */
|
||||
/* signaled alert has been consumed */
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
|
@ -219,7 +219,7 @@ work to a thread to reduce the amount of time interrupts are locked.
|
|||
Use an alert to allow the kernel's system workqueue to handle an alert,
|
||||
rather than defining an application thread to handle it.
|
||||
|
||||
Use an alert to allow the kernel's system workqueue to pre-process an alert,
|
||||
Use an alert to allow the kernel's system workqueue to preprocess an alert,
|
||||
prior to letting an application thread handle it.
|
||||
|
||||
Configuration Options
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ by another thread, the requesting thread may choose to wait for the mutex
|
|||
to be unlocked.
|
||||
|
||||
After locking a mutex, the thread may safely use the associated resource
|
||||
for as long as needed; however, it is considered good practise to hold the lock
|
||||
for as long as needed; however, it is considered good practice to hold the lock
|
||||
for as short a time as possible to avoid negatively impacting other threads
|
||||
that want to use the resource. When the thread no longer needs the resource
|
||||
it must **unlock** the mutex to allow other threads to use the resource.
|
||||
|
|
|
|||
|
|
@ -52,9 +52,9 @@ instructed to delay execution of the thread by specifying a timeout
|
|||
value -- for example, to allow device hardware used by the thread
|
||||
to become available.
|
||||
|
||||
The kernel allows a delayed start to be cancelled before the thread begins
|
||||
The kernel allows a delayed start to be canceled before the thread begins
|
||||
executing. A cancellation request has no effect if the thread has already
|
||||
started. A thread whose delayed start was successfully cancelled must be
|
||||
started. A thread whose delayed start was successfully canceled must be
|
||||
re-spawned before it can be used.
|
||||
|
||||
Thread Termination
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Attempting to cancel a delayed work item once its timeout has expired has
|
|||
no effect on the work item; the work item remains pending in the workqueue's
|
||||
queue, unless the work item has already been removed and processed by the
|
||||
workqueue's thread. Consequently, once a work item's timeout has expired
|
||||
the work item is always processed by the workqueue and cannot be cancelled.
|
||||
the work item is always processed by the workqueue and cannot be canceled.
|
||||
|
||||
System Workqueue
|
||||
================
|
||||
|
|
@ -224,7 +224,7 @@ A delayed work item is defined using a variable of type
|
|||
An initialized delayed work item can be submitted to the system workqueue by
|
||||
calling :cpp:func:`k_delayed_work_submit()`, or to a specified workqueue by
|
||||
calling :cpp:func:`k_delayed_work_submit_to_queue()`. A delayed work item
|
||||
that has been submitted but not yet consumed by its workqueue can be cancelled
|
||||
that has been submitted but not yet consumed by its workqueue can be canceled
|
||||
by calling :cpp:func:`k_delayed_work_cancel()`.
|
||||
|
||||
Suggested Uses
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ SoC Series
|
|||
----------
|
||||
|
||||
Moving closer to the SoC, the series is derived from an SoC family. A series is
|
||||
defined by a feautre set that serves the purpose of distinguishing different
|
||||
defined by a feature set that serves the purpose of distinguishing different
|
||||
SoCs belonging to the same family.
|
||||
|
||||
SoC
|
||||
|
|
|
|||
|
|
@ -83,9 +83,9 @@ Bluetooth
|
|||
Build and Infrastructure
|
||||
************************
|
||||
|
||||
- Added “qemugdb” target to start a local GDB on port 1234.
|
||||
- Added "qemugdb" target to start a local GDB on port 1234.
|
||||
- Added script to filter known issues in the build output.
|
||||
- Sanity: Added “-R” option to build all test with assertions.
|
||||
- Sanity: Added "-R" option to build all test with assertions.
|
||||
|
||||
Libraries
|
||||
*********
|
||||
|
|
@ -101,7 +101,7 @@ Documentation
|
|||
- Fixed several typos, trademarks and grammar.
|
||||
- Moved all the boards documentation to the wiki.
|
||||
- Moved Code Contribution documentation to the wiki.
|
||||
- Added package “ncurses” to the list of requirements.
|
||||
- Added package "ncurses" to the list of requirements.
|
||||
- Updated Mac OS X instructions.
|
||||
|
||||
Test and Samples
|
||||
|
|
|
|||
|
|
@ -700,9 +700,9 @@ Central Simultaneous BR/EDR and LE Transports
|
|||
============== ============== =======================================
|
||||
Parameter Name Selected Description
|
||||
============== ============== =======================================
|
||||
TSPC_GAP_44_1 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR
|
||||
TSPC_GAP_44_1 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
|
||||
Slave to the same device (C.1)
|
||||
TSPC_GAP_44_2 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR
|
||||
TSPC_GAP_44_2 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
|
||||
Master to the same device (C.1)
|
||||
============== ============== =======================================
|
||||
|
||||
|
|
@ -713,9 +713,9 @@ Peripheral Simultaneous BR/EDR and LE Transports
|
|||
============== ============== =======================================
|
||||
Parameter Name Selected Description
|
||||
============== ============== =======================================
|
||||
TSPC_GAP_45_1 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR
|
||||
TSPC_GAP_45_1 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
|
||||
Slave to the same device (C.1)
|
||||
TSPC_GAP_45_2 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR
|
||||
TSPC_GAP_45_2 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
|
||||
Master to the same device (C.1)
|
||||
============== ============== =======================================
|
||||
|
||||
|
|
|
|||
|
|
@ -112,15 +112,15 @@ TSPC_L2CAP_3_6 False (*) Support of flush timeout value for unreliable
|
|||
TSPC_L2CAP_3_7 False (*) Support of bi-directional quality of service
|
||||
(QoS) option field
|
||||
TSPC_L2CAP_3_8 False (*) Negotiate QoS service type
|
||||
TSPC_L2CAP_3_9 False (*) Negotiate and support service type ‘No traffic’
|
||||
TSPC_L2CAP_3_10 False (*) Negotiate and support service type ‘Best effort’
|
||||
TSPC_L2CAP_3_11 False (*) Negotiate and support service type ‘Guaranteed’
|
||||
TSPC_L2CAP_3_9 False (*) Negotiate and support service type 'No traffic'
|
||||
TSPC_L2CAP_3_10 False (*) Negotiate and support service type 'Best effort'
|
||||
TSPC_L2CAP_3_11 False (*) Negotiate and support service type 'Guaranteed'
|
||||
TSPC_L2CAP_3_12 True Support minimum MTU size 23 octets
|
||||
TSPC_L2CAP_3_13 False (*) Negotiate and support service type ‘No traffic’
|
||||
TSPC_L2CAP_3_13 False (*) Negotiate and support service type 'No traffic'
|
||||
for Extended Flow Specification
|
||||
TSPC_L2CAP_3_14 False (*) Negotiate and support service type ‘Best Effort'
|
||||
TSPC_L2CAP_3_14 False (*) Negotiate and support service type 'Best Effort'
|
||||
for Extended Flow Specification
|
||||
TSPC_L2CAP_3_15 False (*) Negotiate and support service type ‘Guaranteed’
|
||||
TSPC_L2CAP_3_15 False (*) Negotiate and support service type 'Guaranteed'
|
||||
for Extended Flow Specification
|
||||
TSPC_L2CAP_3_16 True Support Multiple Simultaneous LE Data Channels
|
||||
=============== =========== =======================================
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Parameter Name Selected Description
|
|||
TSPC_SM_5_1 True Encryption Setup using STK (C.3)
|
||||
TSPC_SM_5_2 True Encryption Setup using LTK (O)
|
||||
TSPC_SM_5_3 True Slave Initiated Security (C.1)
|
||||
TSPC_SM_5_4 True Slave Initiated Security – Master response(C.2)
|
||||
TSPC_SM_5_4 True Slave Initiated Security - Master response(C.2)
|
||||
=============== =========== =======================================
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20,14 +20,14 @@ application. The capacity of the kernel event logger is also configurable.
|
|||
By default, it has a ring buffer that can hold up to 128 32-bit words
|
||||
of event information.
|
||||
|
||||
The kernel event logger is capable of recording the following pre-defined
|
||||
The kernel event logger is capable of recording the following predefined
|
||||
event types:
|
||||
|
||||
* Interrupts.
|
||||
* Context switching of threads.
|
||||
* Kernel sleep events (i.e. entering and exiting a low power state).
|
||||
|
||||
The kernel event logger only records the pre-defined event types it has been
|
||||
The kernel event logger only records the predefined event types it has been
|
||||
configured to record. Each event type can be enabled independently.
|
||||
|
||||
An application can also define and record custom event types.
|
||||
|
|
@ -93,7 +93,7 @@ A **sleep event** has the following format:
|
|||
};
|
||||
|
||||
A **custom event** must have a type ID that does not conflict with
|
||||
any existing pre-defined event type ID. The format of a custom event
|
||||
any existing predefined event type ID. The format of a custom event
|
||||
is application-defined, but must contain at least one 32-bit data word.
|
||||
A custom event may utilize a variable size, to allow different events
|
||||
of a single type to record differing amounts of information.
|
||||
|
|
@ -101,7 +101,7 @@ of a single type to record differing amounts of information.
|
|||
Timestamps
|
||||
==========
|
||||
|
||||
By default, the timestamp recorded with each pre-defined event is obtained from
|
||||
By default, the timestamp recorded with each predefined event is obtained from
|
||||
the kernel's :ref:`hardware clock <clocks_v2>`. This 32-bit clock counts up
|
||||
extremely rapidly, which means the timestamp value wraps around frequently.
|
||||
(For example, the Lakemont APIC timer for Quark SE wraps every 134 seconds.)
|
||||
|
|
@ -176,7 +176,7 @@ Adding a Custom Event Type
|
|||
==========================
|
||||
|
||||
A custom event type must use an integer type ID that does not duplicate
|
||||
an existing type ID. The type IDs for the pre-defined events can be found
|
||||
an existing type ID. The type IDs for the predefined events can be found
|
||||
in :file:`include/logging/kernel_event_logger.h`. If dynamic recording of
|
||||
events is enabled, the event type ID must not exceed 32.
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ will be found in the `include/net/net_mgmt.h` header file. But in case
|
|||
of an L2 technology, let's say Ethernet, these would be found in
|
||||
`include/net/ethernet.h`
|
||||
|
||||
You define your handler modelled with this signature:
|
||||
You define your handler modeled with this signature:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.. _networking_with_qemu:
|
||||
|
||||
Networking with Qemu
|
||||
Networking with QEMU
|
||||
####################
|
||||
|
||||
This page describes how to set up a "virtual" networking between a (Linux) host
|
||||
|
|
@ -41,7 +41,7 @@ For the steps below, you will need at least 4 terminal windows:
|
|||
Step 1 - Create helper socket
|
||||
=============================
|
||||
|
||||
Before starting QEMU with network emulation, a unix socket for the emulation
|
||||
Before starting QEMU with network emulation, a Unix socket for the emulation
|
||||
should be created.
|
||||
|
||||
In terminal #2, type:
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ A shell interface exposing subsystem features is a shell module, multiple
|
|||
modules can be available at the same time.
|
||||
|
||||
`MODULE_NAME COMMAND`
|
||||
One of the available modules is “KERNEL”, for the Kernel module. More
|
||||
One of the available modules is "KERNEL", for the Kernel module. More
|
||||
information can be found in :c:macro:`SHELL_REGISTER`.
|
||||
|
||||
Help commands
|
||||
|
|
@ -48,7 +48,7 @@ Select module commands
|
|||
command, you will not need to enter module name in further commands. If
|
||||
the selected module has set a default shell prompt during its initialization,
|
||||
the prompt will be changed to that one. Otherwise, the prompt will be
|
||||
changed to the selected module’s name to reflect the current module in use.
|
||||
changed to the selected module's name to reflect the current module in use.
|
||||
|
||||
`select`
|
||||
Clears selected module. Restores prompt as well.
|
||||
|
|
@ -71,7 +71,7 @@ Example:
|
|||
|
||||
CONFIG_NET_SHELL=y
|
||||
|
||||
In the subsystem’s code, the shell usage depends on this config parameter.
|
||||
In the subsystem's code, the shell usage depends on this config parameter.
|
||||
This subsystem specific flag should also depend on :option:`CONFIG_CONSOLE_SHELL` flag.
|
||||
|
||||
Configuration steps to add shell functionality to a module
|
||||
|
|
@ -103,7 +103,7 @@ set a default module in code level. In this case, the function
|
|||
shell_register_default_module should be called after calling SHELL_REGISTER in
|
||||
application level. If the function shell_register_prompt_handler was called as
|
||||
well, the prompt will be changed to that one. Otherwise, the prompt will be
|
||||
changed to the selected module’s name, in order to reflect the current module in
|
||||
changed to the selected module's name, in order to reflect the current module in
|
||||
use.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ wget will show:
|
|||
Connecting to 192.168.1.101:80... connected.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: unspecified [text/html]
|
||||
Saving to: ‘index.html’
|
||||
Saving to: 'index.html'
|
||||
|
||||
The HTML file generated by Zephyr and downloaded by wget is:
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ wget will show:
|
|||
Connecting to 192.168.1.101:80... connected.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: unspecified [text/html]
|
||||
Saving to: ‘index.html’
|
||||
Saving to: 'index.html'
|
||||
|
||||
This is the HTML file generated by Zephyr and downloaded by wget:
|
||||
|
||||
|
|
@ -288,7 +288,7 @@ This will be shown on the screen
|
|||
Unable to locally verify the issuer's authority.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: unspecified [text/html]
|
||||
Saving to: ‘index.html’
|
||||
Saving to: 'index.html'
|
||||
|
||||
index.html [ <=> ]
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue