[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] ARM/multiboot: use more flexible node naming
On Thu, 2013-09-05 at 16:22 +0200, Egger, Christoph wrote: > On 05.09.13 16:03, Ian Campbell wrote: > > On Thu, 2013-09-05 at 15:54 +0200, Egger, Christoph wrote: > >> Is there a chance to get NetBSD Dom0 [1] to boot to justify that your > >> approach is *really* generic. > >> > >> xen,linux-zimage and xen,linux-initrd do not sound generic > >> but xen,dom0-kernel and xen,ramdisk do sound generic at least. > > > > Does NetBSD follow the Linux zImage boot protocol > > (Documentation/arm/Booting.txt in a Linux source tree)? > > > > If not then you need to define (or link to) the NetBSD boot protocol and > > we probably will eventually need xen,netbsd-fooimg and suitable code in > > Xen to handle that format. > > > >> [1] NetBSD Dom0 hasn't been ported to ARM yet. > > > > So surely you have answered your own question then, unless you are > > asking Andre to port NetBSD to ARM? I don't think that is a reasonable > > prerequisite for this patch. > > No, it is not a prerequisite. My question is related to the design > if it is "I allow Linux only to boot" or "I allow any Dom0 to boot". The design allows for any dom0, since it includes a compatibility string which corresponds to the boot protocol to use. The implementation currently only covers Linux though. > Christoph > > > > >> > >> > >> On 05.09.13 15:43, Andre Przywara wrote: > >>> For the current "multiboot" on ARM support we look for a compatible > >>> string of "xen,multiboot-module" in the device tree, and then > >>> use "xen,linux-zimage" and "xen,linux-initrd" to differentiate > >>> between the two supported module types. > >>> To meet the more generic multiboot proposal in the device tree [1], > >>> allow Xen to be more flexible in the compatible naming and also use > >>> the new generic base name "boot,module". > >>> The mapping to either Dom0 kernel or RAM disk works either by > >>> providing a more specific name ("xen,dom0-kernel" and "xen,ramdisk"), > >>> or by using the enumeration order of the device tree nodes > >>> (module@0 = kernel, module@1 = initrd). This allows bootloaders > >>> without any specific Xen knowledge to boot Xen anyways. > >>> > >>> [1] http://lists.xen.org/archives/html/xen-devel/2013-09/msg00083.html > >>> > >>> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx> > >>> --- > >>> xen/common/device_tree.c | 57 > >>> ++++++++++++++++++++++++++++++++++++++++++------ > >>> 1 file changed, 50 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c > >>> index ec0d5e2..e10c035 100644 > >>> --- a/xen/common/device_tree.c > >>> +++ b/xen/common/device_tree.c > >>> @@ -439,22 +439,63 @@ static void __init process_cpu_node(const void > >>> *fdt, int node, > >>> cpumask_set_cpu(start, &cpu_possible_map); > >>> } > >>> > >>> +static const char * const kernel_module_names[] = { > >>> + "xen,linux-zimage", > >>> + "xen,dom0-kernel", > >>> + "boot,kernel", > >>> + NULL > >>> +}; > >>> + > >>> +static const char * const initrd_module_names[] = { > >>> + "xen,linux-initrd", > >>> + "xen,ramdisk", > >>> + "boot,ramdisk", > >>> + NULL > >>> +}; > >>> + > >>> static void __init process_multiboot_node(const void *fdt, int node, > >>> const char *name, > >>> u32 address_cells, u32 > >>> size_cells) > >>> { > >>> const struct fdt_property *prop; > >>> const u32 *cell; > >>> - int nr; > >>> + int nr = -1; > >>> struct dt_mb_module *mod; > >>> int len; > >>> + const char* const * name_list; > >>> > >>> - if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ) > >>> - nr = MOD_KERNEL; > >>> - else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") > >>> == 0) > >>> - nr = MOD_INITRD; > >>> - else > >>> - early_panic("%s not a known xen multiboot type\n", name); > >>> + for (name_list = kernel_module_names; *name_list != NULL; > >>> name_list++) > >>> + if ( fdt_node_check_compatible(fdt, node, *name_list) == 0 ) { > >>> + nr = MOD_KERNEL; > >>> + break; > >>> + } > >>> + > >>> + for (name_list = initrd_module_names; *name_list != NULL; > >>> name_list++) > >>> + if ( fdt_node_check_compatible(fdt, node, *name_list) == 0 ) { > >>> + nr = MOD_INITRD; > >>> + break; > >>> + } > >>> + > >>> + if (nr == -1) { > >>> + char *s; > >>> + > >>> + if ( fdt_node_check_compatible(fdt, node, "boot,module") != 0 ) { > >>> + early_panic("%s not a known xen multiboot type\n", name); > >>> + return; > >>> + } > >>> + s = strchr(name, '@'); > >>> + if (s == NULL) > >>> + nr = early_info.modules.nr_mods + 1; > >>> + else { > >>> + nr = simple_strtoll(s + 1, NULL, 10) + 1; > >>> + } > >>> + } > >>> + > >>> + if (nr >= NR_MODULES) { > >>> + early_panic("only supporting %d multiboot modules\n", > >>> + NR_MODULES - MOD_DISCARD_FIRST); > >>> + return; > >>> + } > >>> > >>> mod = &early_info.modules.module[nr]; > >>> > >>> @@ -492,6 +533,8 @@ static int __init early_scan_node(const void *fdt, > >>> process_cpu_node(fdt, node, name, address_cells, size_cells); > >>> else if ( device_tree_node_compatible(fdt, node, > >>> "xen,multiboot-module" ) ) > >>> process_multiboot_node(fdt, node, name, address_cells, > >>> size_cells); > >>> + else if ( device_tree_node_compatible(fdt, node, "boot,module" ) ) > >>> + process_multiboot_node(fdt, node, name, address_cells, > >>> size_cells); > >>> > >>> return 0; > >>> } > >>> > >> > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |