These aren't used, and are not obvious useful either.
tools/ does have some logic which works on $(XEN_OS) directly, and some on
CONFIG_$(XEN_OS) too, but this isn't how we typically refer to things.
The only user ever of this scheme (AFAICT) was introduced in
c0fd920e98 (2006) and deleted in fa2244104b (2010).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Jiamei Xie <jiamei.xie@arm.com>
The build option CONFIG_LOAD_ADDRESS is defined but never plumbed
through.
Signed-off-by: Julien Grall <julien.gralL@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
There are several aspects to this:
- Correctly conditionalise use of PCI
- Correctly conditionalise use of IO ports
- Add discovery via device tree
- Support different registers shift/stride and widths
- Add vuart hooks.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Frser <keir@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Cc: PranavkumarSawargaonkar<pranavkumar@linaro.org>
TI OMAP UART introduces some features such as register access modes, which
makes its configuration and interrupt handling differs from 8250 compatible
UART. Thus, we seperate this driver from ns16550's implementation.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring due
to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu gcc
bug, hwever when investigating I found that this option was not necessary at
all since we provide an explicit linker script when linking the hypervisor
(AFAICT all -m<foo> does is override the default linker script).
LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files but
-m<emulatin> is not needed for this since it isn't linking the final image and
we are calling the linker with the correct, cross if necessary, name.
However it does appear to be potentially useful to supply -EL in both cases to
ensure that we get little endian images. (I just happened to spot that Linux
does this, for both arm and arm64, although I expect we are unlikely to trip
over such toolchains these days).
Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
This is a follow up to "xen: arm: make zImage the default target which we
install".
On ARM the xen.gz binary installed into /boot is not immediately useful because
bootloaders (e.g. u-boot) do not unconditionally support decompression (except
via the uImage wrapper, which we currently do not support via our build system)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
- move 32-bit specific files into subarch specific arm32 subdirectory.
- move gic.h to xen/include/asm-arm (it is needed from both subarch
and generic code).
- make the appropriate build and config file changes to support
XEN_TARGET_ARCH=arm32.
This prepares us for an eventual 64-bit subarch.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Andrew Cooper