| Age | Commit message (Collapse) | Author |
|---|
|
@upstream
|
|
|
|
|
|
This reuires a external gcc patch, which I no longer add to newer gcc.
A lot of packages already need to disable the usage of -fhonour-copts, because
it doesn't work without patching. May be we need something like Buildroot
is using, a gcc wrapper to see poisened include or library paths while
cross-compiling.
|
|
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
|
|
FETCHCMD is added to prereq.mk, so ADK_WGET_TIMEOUT
is unused nowadays.
|
|
This works by using git as backend for all the dirty work. This means
that patches are not just applied, but committed separately on top of the
base sources (which are put into an initial commit). A final empty commit
marks the end of the applied patch series, which allows to have multiple
sets of patches to apply on top of each other. So a git history might
look like this:
- OpenADK patch marker: 0000
(this is the initial commit, containing the unpatched sources)
- patch 1 of series 1
- patch 2 of series 1
- patch 3 of series 1
- OpenADK patch marker: 0001
- patch 1 of series 2
- patch 2 of series 2
- OpenADK patch marker: 0002
In addition to the separating empty commits, for every patch series
metadata files are added (which are used for update-patches):
__patchfiles__: A list of the patches' file names
__patchdir__: The directory containing the applied patches
Since patches might have to be unzipped first and in order to allow
calling git-am just once for each patch series, the patches (along with
above metadata files) are cached in dedicated directories:
.git/patch_tmp/NNNN (where NNNN is the series number with leading zeroes
[so shell globbing returns them in the right order]).
In case update-patches is called later, update_patches.sh works it's way
reverse through the git history, searching for commits named 'OpenADK
patch marker: NNNN'. For each one it finds, it uses the metadata info to
first remove all source patch files, then export the history in between
using git-format-patch.
To change patches or add new ones, the user has to use git-rebase in
order to get things where they need to be for update_patches.sh to put
stuff at the right place. For an example, here is how to change patch 3
of series 1 in the sample history above:
- make desired code changes
- commit them, ideally using --fixup option
- call 'git rebase -i --autosquash <hash of OpenADK patch marker: 0000>'
Using --fixup and --autosquash is convenient, since it automatically
edits the rebase todo as intended. It's optional though, editing the todo
manually will do just fine as well.
Signed-off-by: Phil Sutter <phil@nwl.cc>
|
|
After the addition of bare metal toolchains the menu system allowed
to create non-valid configurations. I reworked it so we can also
add other operating system support if we wish.
So first you choose your operating system, then your architecture
and endianess, after that your embedded system, emulator or
generic device and then you choose your task you want to run.
Tasks may be toolchain, a new appliance/application or some preconfigured
sets of packages and configurations as kodi, mpd, firefox and more.
The tasks are limited to a plausible choice of hardware and software.
Deduplicate CPU configuration.
You don't wanna compile Kodi for a H8/300 microcontroller ;)
|
|
The new prereq check is completely implemented in
POSIX shell in scripts/prereq.sh.
It combines the old features from Makefile, scan-tools.sh,
scan-pkgs.sh, reloc.sh and some wrappers for tools.
The big benefit is to have all portability stuff in one place.
Furthermore we can compile GNU make and bash on the fly, for
systems lacking the required tools.
All changes on the host are detected on the fly, no make
prereq required anymore.
The build process is separated in following three phases:
1. small wrapper Makefile is used for BSD make or GNU make
2. prereq.sh is called, doing all checking, calling Makefile.adk
3. old logic in Makefile.adk or mk/build.mk is used
Tested successfully on Linux, MacOS X, Cygwin, FreeBSD, OpenBSD
and NetBSD.
An old depmaker bug was fixed, only optional host tools are compiled.
For example, even when a host provides xz, a local xz was compiled
in the past, because other packages had a build dependency on it.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
This reverts commit fba2ff31928b18364c1934654169806f5c800e23.
|
|
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
|
|
|
|
The new symbol will hide experimental stuff, so that
only known to work combinations are allowed to choose,
when ADK_EXPERIMENTAL disabled.
|
|
|
|
As mentioned by Phil, a lot of disk space is needed nowadays
to build OpenADK. Switch to non debug builds as default to
save 2 GB for each default build.
|
|
build system
|
|
Use one place and not hard coded for each device.
There exist use cases where on a specific device
like raspberry pi, not the default 115200 baud rate
is used.
|
|
- Sync with Kernel upstream Kconfig
- use new feature visible
- add a patch for select on choices
https://lkml.org/lkml/2011/2/17/379
- rename ADK_LINUX -> ADK_TARGET_ARCH
- remove package collection feature
- add appliance feature to define a appliance
more complete
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is more commonly known as 32bit userland support on 64bit
architectures.
For simplicity's sake though, this implementation works the other way
round: just build a 64bit-able linker and compiler, but no
64bit-libraries at all (i.e., no multilib). This is then just enough to
compile a 64bit kernel, as that doesn't link to anything. The
alternative would have been to build a native 64bit compiler with
multilib-support in order to cross-compile a 32bit userland, resulting
in a multilib system without need for it.
In order to allow compilation of a 64bit kernel for a given target
system, have it select ADK_TARGET_KERNEL_MAY_64BIT. Upon selection of
that target, the symbol ADK_64BIT_KERNEL will occur in the "Global
settings" menu. Since certain aspects of the 64bit kernel .config may
greatly differ from it's 32bit counterpart, it has to be shipped
separately: target/<arch>/kernel64.config is the place to be.
Conflicts:
target/Makefile
toolchain/gcc/Makefile
Untested, due to conflicts (original patch conflicts with
multiple kernel version support).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make configuration of new targets cheap.
Just add a new file in target/arch/sys-enabled/foo.
See other files for syntax. While doing runtime tests
with the new infrastructure I've updated a lot of other
stuff:
- gcc 4.5.2
- uClibc 0.9.32-rc1 (NPTL)
- strongswan, php, miredo, parted, util-linux-ng, e2fsprogs
I promise, this is the last big fat commit this year ;)
|
