[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] ARM/multiboot: use more flexible node naming
On 09/05/2013 04:59 PM, Ian Campbell wrote:
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.
I think the whole discussion is somewhat moot here, as NetBSD does not
seem to support device trees. I see FreeBSD has support for it, but with
some quick googling I cannot find anything in NetBSD.
Regards,
Andre.
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
|
