search for: device_tree

This series of patches makes Xen pass a (somewhat) valid device tree to dom0. The device tree for dom0 is the same as the one supplied to Xen except the memory and chosen nodes are adjusted appropriately. We don''t yet make use of the device tree to map MMIO regions or setup interrupts for the guest and we still include the UART used for Xen''s console. Note that loading Linux

...ch/arm/Rules.mk | 16 + xen/arch/arm/arm32/debug-8250.inc | 41 +++ xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/omap5.c | 117 ++++++++ xen/arch/arm/time.c | 7 +- xen/common/device_tree.c | 15 + xen/drivers/char/Makefile | 1 + xen/drivers/char/ns16550.c | 2 +- xen/drivers/char/omap-uart.c | 374 ++++++++++++++++++++++++ xen/include/asm-arm/platforms/omap5.h | 25 ++ xen/include/...

...is program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <xen/config.h> +#include <xen/device_tree.h> +#include <xen/domain_page.h> +#include <xen/mm.h> +#include <xen/vmap.h> +#include <asm/platform.h> + +static uint32_t xgene_storm_quirks(void) +{ + return PLATFORM_QUIRK_DOM0_MAPPING_11; +} + + +static const char const *xgene_storm_dt_compat[] __initdata = +{ +...

...specify loglevel in printk; - call fb_free on error in fb_alloc; - no __init on declarations; - do not break messages to fit 80 columns; - remove "preserve DTB mappings"; - introduce a new "move setup_mm right after setup_pagetables" patch; - stop iterating over the DT nodes in device_tree_for_each_node if func returns a value != 0; - return 1 from _find_compatible_node when a node is found; - move the wait loop and the syscfg cfgctrl write into a separate function; - fix comments; - define all registers in write; - move platform_vexpress.c to platforms/vexpress.c; - move platform_ve...

...3 + xen/arch/arm/arm64/head.S | 3 +- xen/arch/arm/gic.c | 64 +++++++++++++++++----- xen/arch/arm/setup.c | 112 +++++++++++++++++++++++++++++++++++++- xen/arch/arm/smpboot.c | 26 ++++++--- xen/arch/arm/time.c | 6 +- xen/common/device_tree.c | 48 ---------------- xen/include/asm-arm/gic.h | 3 +- xen/include/asm-arm/init.h | 8 +++ xen/include/asm-arm/processor.h | 4 ++ 12 files changed, 206 insertions(+), 78 deletions(-) -- 1.7.10.4

I''m afraid this series is rather a grab bag and it is distressingly large at this stage. With this series I can boot an Xgene board until it fails to find its SATA controller. This is a dom0 issue for which patches are pending from APM (/me nudges Anup). As well as the APM specific platform stuff there are also some generic improvements which were either necessary or useful during this

George has release acked all of these. Otherwise mostly minor updates this time around. Summary: A == acked, M == modified A xen: arm64: Add 8250 earlyprintk support A xen: arm64: Add Basic Platform support for APM X-Gene Storm. A xen: arm64: Add APM implementor id to processor implementers. M xen: arm: add a quirk to handle platforms with unusual GIC layout A xen: arm: allow platform

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. With this rebase I''ve picked up some patches from Julien which were required to do things properly, so the gic v7 and device blacklisting patches have been changed to use the proper mechanisms. Previously I was able to boot

...gic_dump_info(v); + gic_dump_info_guest(v); } } diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 9711f5d..1f32e99 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -28,6 +28,7 @@ #include <xen/softirq.h> #include <xen/list.h> #include <xen/device_tree.h> +#include <xen/keyhandler.h> #include <asm/p2m.h> #include <asm/domain.h> #include <asm/platform.h> @@ -386,6 +387,77 @@ int gic_irq_xlate(const u32 *intspec, unsigned int intsize, return 0; } + +static void do_dump_gic(unsigned char key) +{ + int irq; +...

Hey guys, Here are my thoughts about current Xen boot infrastructure and some changes proposal. It is linked with EFI development but not only. Since the beginning Xen image and other needed stuff could be loaded into memory according to multiboot protocol. (e.g. implemented by GRUB). It means that current implementation of Xen takes info about current system config from multiboot_info_t

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. As before several of the patches are not to be applied because they can be done better using infrastructure from Julien''s "Allow Xen to boot with a raw Device Tree" patch. They are included for completeness. With

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I