d187861a28
ChangeLog:
Version 2.16.01
_This is a documentation update release only._
(*) Fix the creation of the table of contents in the HTML version of
the documentation.
Version 2.16
(*) Support for the `rdf' format has been discontinued and all the
RDOFF utilities has been removed.
(*) The `--reproducible' option now leaves the filename field in the
COFF object format blank. This was always rather useless since
it is only 18 characters long; as such debug formats have to
carry their own filename information anyway.
(*) Fix handling of MASM-syntax reserved memory (e.g. `dw ?') when
used in structure definitions.
(*) The preprocessor now supports functions, which can be less
verbose and more convenient than the equivalent code implemented
using directives. See section 4.4.
(*) Fix the handling of `%00' in the preprocessor.
(*) Fix incorrect handling of path names affecting error messages,
dependency generation, and debug format output.
(*) Support for the RDOFF output format and the RDOFF tools have
been removed. The RDOFF tools had already been broken since at
least NASM 2.14. For flat code the ELF output format
recommended; for segmented code the `obj' (OMF) output format.
(*) New facility: preprocessor functions. Preprocessor functions,
which are expanded similarly to single-line macros, can greatly
simplify code that in the past would have required a lengthy
list of directives and intermediate macros. See section 4.4.
(*) Single-line macros can now declare parameters (using a `&&'
prefix) that creates a quoted string, but does _not_ requote an
already quoted string. See section 4.2.1.
(*) Instruction table updated per public information available as of
November 2022.
(*) All warnings in the preprocessor have now been assigned warning
classes. See appendix A.
(*) Fix the invalid use of `RELA'-type relocations instead of `REL'-
type relocations when generating DWARF debug information for the
`elf32' output format.
(*) Fix the handling `at' in `istruc' when the structure contains
local labels. See section 5.9.2.
(*) When assembling with `--reproducible', don't encode the filename
in the COFF header for the `coff', `win32' or `win64' output
formats. The COFF header only has space for an 18-character
filename, which makes this field rather useless in the first
place. Debug output data, if enabled, is not affected.
(*) Fix incorrect size calculation when using MASM syntax for non-
byte reservations (e.g. `dw ?'.)
(*) Allow forcing an instruction in 64-bit mode to have a (possibly
redundant) REX prefix, using the syntax `{rex}' as a prefix.
(*) Add a `{vex}' prefix to enforce VEX (AVX) encoding of an
instruction, either using the 2- or 3-byte VEX prefixes.
(*) The `CPU' directive has been augmented to allow control of
generation of VEX (AVX) versus EVEX (AVX-512) instruction
formats, see section 7.11.
(*) Some recent instructions that previously have been only
available using EVEX encodings are now also encodable using VEX
(AVX) encodings. For backwards compatibility these encodings are
not enabled by default, but can be generated either via an
explicit `{vex}' prefix or by specifying either `CPU LATEVEX' or
`CPU NOEVEX'; see section 7.11.
(*) Document the already existing `%unimacro' directive. See section
4.5.12.
(*) Fix a code range generation bug in the DWARF debug format
(incorrect information in the `DW_AT_high_pc' field) for the ELF
output formats. This bug happened to cancel out with a bug in
older versions of the GNU binutils linker, but breaks with other
linkers and updated or other linkers that expect the spec to be
followed.
(*) Fix segment symbols with addends, e.g. `jmp _TEXT+10h:0' in
output formats that support segment relocations, e.g. the `obj'
format.
(*) Fix various crashes and hangs on invalid input.
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it; for users this means the ability for full customization, to use the device in ways never envisioned.
Sunshine!
Download
Built firmware images are available for many architectures and come with a package selection to be used as WiFi home router. To quickly find a factory image usable to migrate from a vendor stock firmware to OpenWrt, try the Firmware Selector.
If your device is supported, please follow the Info link to see install instructions or consult the support resources listed below.
An advanced user may require additional or specific package. (Toolchain, SDK, ...) For everything else than simple firmware download, try the wiki download page:
Development
To build your own firmware you need a GNU/Linux, BSD or MacOSX system (case sensitive filesystem required). Cygwin is unsupported because of the lack of a case sensitive file system.
Requirements
You need the following tools to compile OpenWrt, the package names vary between distributions. A complete list with distribution specific packages is found in the Build System Setup documentation.
binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev
make4.1+ perl python3.6+ rsync subversion unzip which
Quickstart
-
Run
./scripts/feeds update -ato obtain all the latest package definitions defined in feeds.conf / feeds.conf.default -
Run
./scripts/feeds install -ato install symlinks for all obtained packages into package/feeds/ -
Run
make menuconfigto select your preferred configuration for the toolchain, target system & firmware packages. -
Run
maketo build your firmware. This will download all sources, build the cross-compile toolchain and then cross-compile the GNU/Linux kernel & all chosen applications for your target system.
Related Repositories
The main repository uses multiple sub-repositories to manage packages of
different categories. All packages are installed via the OpenWrt package
manager called opkg. If you're looking to develop the web interface or port
packages to OpenWrt, please find the fitting repository below.
-
LuCI Web Interface: Modern and modular interface to control the device via a web browser.
-
OpenWrt Packages: Community repository of ported packages.
-
OpenWrt Routing: Packages specifically focused on (mesh) routing.
-
OpenWrt Video: Packages specifically focused on display servers and clients (Xorg and Wayland).
Support Information
For a list of supported devices see the OpenWrt Hardware Database
Documentation
Support Community
- Forum: For usage, projects, discussions and hardware advise.
- Support Chat: Channel
#openwrton oftc.net.
Developer Community
- Bug Reports: Report bugs in OpenWrt
- Dev Mailing List: Send patches
- Dev Chat: Channel
#openwrt-develon oftc.net.
License
OpenWrt is licensed under GPL-2.0