This removes one patch which was applied upstream with commit
67b9bcd36906e12a15ffec19463afbbd6a41660e. All other patches were
refreshed.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
SVN-Revision: 48203
`Build/ubnt-erx-factory-kernel` in `target\linux\ramips\image\Makefile`
references `$(KERNEL_INITRAMFS_IMAGE)`
which is not exported
Signed-off-by: YounJae Rho <luxflow@live.com>
SVN-Revision: 48116
For final output image names allow user to add an
extra string (which is sanitized). This is particularly
useful with ImageBuilder where you may generate multiple
images from the same base and for the same board,
with different package selections and additional files
(via FILES=).
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
SVN-Revision: 48083
We allow to configure the version distribution name;
let's also use it for the final image filenames.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
SVN-Revision: 48082
Use kernel arch for dts compilation.
Also use Image/BuildDTB to build dts for ramips.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
SVN-Revision: 47823
This patch introduces support of new boards with ARC cores.
[1] Synopsys SDP board
This is a new-generation development board from Synopsys that
consists of base-board and CPU tile-board (which might have a real
ASIC or FPGA with CPU image).
It sports a lot of DesignWare peripherals like GMAC, USB, SPI, I2C
etc and is intended to be used for early development of ARC-based
products.
[2] nSIM
This is a virtual board implemented in Synopsys proprietary
software simulator (even though available for free for open source
community). This board has only serial port as a peripheral and so
it is meant to be used for runtime testing which is especially
useful during bring-up of new tools and platforms.
What's also important ARC cores are very configurable so there're
many variations of options like cache sizes, their line lengths,
additional hardware blocks like multipliers, dividers etc. And this
board could be used to make sure built software still runs on
different HW configurations.
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Jo-Philipp Wich <jow@openwrt.org>
Cc: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
SVN-Revision: 47589
This includes binutils, gcc, gdb and uClibc-ng.
Latest release of ARC gcc (as of today it is "arc-2015.06")
is based on upstream gcc 4.8.4.
Sources are available on GitHub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc
Latest release of ARC binutils (as of today it is "arc-2015.06")
is based on upstream binutils 2.23.
Sources are available on GitHub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2015.06
Latest release of ARC GDB (as of today this is "arc-2015.06-gdb")
is based on upstream gdb 7.9.1.
Sources are available on GitHub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2015.06-gdb
Note that for binutils and gdb that come from unified git repository
(which is the case for upstream binutils/gdb today) we need to disable
building of gdb in binutils and binutils in gdb hence in binutils:
------>8------
--disable-sim
--disable-gdb
------>8------
and in gdb:
------>8------
--disable-binutils
--disable-ld
--disable-gas
------>8------
Also in gdb we disable sim because if the following breakage while
building with it:
------------>8------------
/usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \
-mono -fast -pbb -switch sem5-switch.c \
-cpu a5f -infile ./mloop5.in \
-outfile-suffix 5
unknown option: bash
Makefile:699: recipe for target 'stamp-5mloop' failed
make[7]: *** [stamp-5mloop] Error 1
------------>8------------
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: John Crispin <blogic@openwrt.org>
Cc: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
SVN-Revision: 47438
Some devices require the kernel to be in a JFFS2 file system. Make the
support for this more generic so that it can be used by other devices.
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
SVN-Revision: 47404
In case if we're interested in generation of non-binary images
(for example if we want images to be valid .elfs - and that's what we
want for ARC now) we have to instruct Device/Build/initramfs target to
use input file with some extension (in case of ARC it will be
essentially .elf).
Otherwise default binary vmlinux-initramfs (without extension) is used and
resulting images then are binaries instead of elfs.
Now having KERNEL_INITRAMFS_NAME variable it's possible to substitute
default $$(KERNEL_NAME)-initramfs with preferred option like
$$(KERNEL_NAME)-initramfs.elf.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: John Crispin <blogic@openwrt.org>
SVN-Revision: 47403
If "findstring" is used without leading and trailing spaces unexpected matches
may happen. For example consider ARC=arc then "findstring $(ARCH)" will
report a false match with "aarch64".
But "findstring $ARCH " (note trailing space) will correctly skip
matches for both "aarch64" and "aarch64_be".
This patch is built-tested against NetGear WNDR3800.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 47359
Making common code reusable as there's a lot of duplicate code in imx6,
kirkwood and oxnas archs.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
SVN-Revision: 47307
This change adds support for specifying a build ID for kernel modules.
This is done by setting PKG_BUILD_ID to a hexadecimal string, which will
then be passed to the kernel linker. In addition, when this flag is set,
the build ID debug symbol (.note.gnu.build-id) will not be stripped from
the kernel module. This symbol is exported in sysfs by the kernel (if
the kernel is compiled with CONFIG_KALLSYMS) and so can be used to
uniquely identify a version of a kernel module in a running kernel. This
is useful for keeping track of different versions of a module when doing
experiments and development.
Modules that specify the build ID will be ~100 bytes larger (depending
on the length of the build ID specified). There is no size difference
for kernel modules that do not set this variable.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
SVN-Revision: 47290
Hauke Mehrtens