Failure to boot...

Having spent today sorting out the Realview EB boot, the last thing I expected to find was that both my OMAP platforms are unbootable to the point that absolutely nothing happens after the boot loader transfers control.

I've not been running the boots for about a month, so I'm not sure when this breakage crept in.

You can see the results in the boot logs on the website. Please investigate. And I'll try without arm-soc tomorrow.

Very disappointed that the ARM kernel seems to be rather screwed at the moment across multiple sub-arches.

My Panda ES works with omap2plus_defconfig, but I just noticed that the in-kernel uImage target will use a bad load/entry address so loading and booting that uImage will hang u-boot:

Image Name:   Linux-3.8.0-rc5-00389-g120d4a8
Created:      Wed Jan 30 18:30:39 2013
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    3843912 Bytes = 3753.82 kB = 3.67 MB
Load Address: fffffff2
Entry Point:  fffffff2

Looking at the latest build and boot log for SDP (oldconfig) on your build status site verifies that you hit that case too. :(

Wrapping by hand (which my scripts already do) produces a bootable image; just verified both with and without device-tree on my panda.

git bisect points at a069486162a59513053cf772515217ca61727704 (ARM: OMAP2+:
Enable ARCH_MULTIPLATFORM support)

Hmm. This happens because nothing sources arch/arm/mach-*/Makefile.boot for CONFIG_ARCH_MULTIPLATFORM builds, even if only a single platform is enabled, since $MACHINE is empty.

It seems like most of the available options to deal with this are bad. One thing we should never do though, is to pretend to make a working uImage when we're not. Maybe abort building just like in the case of multiple load addresses?

arch/arm/boot/Makefile +0 -0

index abfce28..71768b8 100644

Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly.

Quoted 2 lines · Nicolas Pitre

Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly.

I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos.

TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but...

Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there.

So, I'm _stuck_ with uImages for these platforms.

Quoted 19 lines · Russell King - ARM Linux

Quoted 2 lines · Nicolas Pitre

Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly.

I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos.

TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but...

Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there.

Quoted 1 line

So, I'm _stuck_ with uImages for these platforms.

Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story.

Quoted 20 lines · Russell King - ARM Linux

Quoted 19 lines · Russell King - ARM Linux

Quoted 2 lines · Nicolas Pitre

Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly.

I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos.

TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but...

Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there.

Quoted 5 lines

Quoted 1 line

So, I'm _stuck_ with uImages for these platforms.

Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story.

I just tried latest mainline (commit: 04c2eee5) and default config just boots fine.

I was looking at your build system output which shows the boot state "OMAP4430 SDP: fail". Your config seems to be with CONFIG_ARCH_MULTIPLATFORM=y and indeed this kernel doesn't boot. Seems to abort very early in boot. Am looking at it.

P.S Btw, the load address issue with multi-platform build was highlighted on the list in past by Tony [1]

[1] http://www.spinics.net/lists/linux-omap/msg84146.html

Quoted 21 lines · Santosh Shilimkar

Quoted 20 lines · Russell King - ARM Linux

Quoted 19 lines · Russell King - ARM Linux

Quoted 2 lines · Nicolas Pitre

Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly.

I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos.

TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but...

Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there.

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

So, I'm _stuck_ with uImages for these platforms.

Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story.

I just tried latest mainline (commit: 04c2eee5) and default config just boots fine.

Please read the notes at the bottom of the page, specifically:
* Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's development tip and arm-soc for-next branches.

This system does *not* build and boot vanilla mainline kernels. It is (as the above says):

- Linus' tip
- My for-next plus a few other bits
- arm-soc for-next

all merged together.

Quoted 46 lines · Russell King - ARM Linux

Quoted 25 lines · Santosh Shilimkar

Quoted 24 lines · Russell King - ARM Linux

Quoted 22 lines · Russell King - ARM Linux

Quoted 2 lines · Nicolas Pitre

Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly.

I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos.

TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but...

Moreover, I doubt that the 3430LDP, of which there are multiple versions,
will ever see a uboot update. It already suffers from a lack of correct
kernel support due to random wiring changes between these versions (the
keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there.

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

So, I'm _stuck_ with uImages for these platforms.

Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story.

I just tried latest mainline (commit: 04c2eee5) and default config just boots fine.

Please read the notes at the bottom of the page, specifically:
* Build tree is currently created on an ad-hoc basis from Linus'
tip, rmk's
development tip and arm-soc for-next branches.

This system does *not* build and boot vanilla mainline kernels. It is (as the above says):

- Linus' tip
- My for-next plus a few other bits
- arm-soc for-next

Quoted 2 lines

all merged together.

Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP.

Now trying to merge your for-next and test.

Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP.

Now trying to merge your for-next and test.

Quoted 5 lines · Santosh Shilimkar

Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP.

Now trying to merge your for-next and test.

Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine.

Hang on...

# CONFIG_ARCH_OMAP2PLUS is not set
CONFIG_ARCH_VEXPRESS=y

which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support.

Quoted 10 lines · Russell King - ARM Linux

Quoted 5 lines · Santosh Shilimkar

Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP.

Now trying to merge your for-next and test.

Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine.

Quoted 7 lines

Hang on...

# CONFIG_ARCH_OMAP2PLUS is not set
CONFIG_ARCH_VEXPRESS=y

which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support.

And no, the instructions given last time around to add:

# 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y

don't fix it either, it needs more options defined...

Quoted 21 lines · Russell King - ARM Linux

Quoted 10 lines · Russell King - ARM Linux

Quoted 5 lines · Santosh Shilimkar

Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP.

Now trying to merge your for-next and test.

Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine.

Quoted 7 lines

Hang on...

# CONFIG_ARCH_OMAP2PLUS is not set
CONFIG_ARCH_VEXPRESS=y

which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support.

And no, the instructions given last time around to add:

Quoted 6 lines

# 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y

don't fix it either, it needs more options defined...

Linus' tip + Tony's pull [1] request also makes things work on OMAP.

Quoted 22 lines · Santosh Shilimkar

Quoted 21 lines · Russell King - ARM Linux

Quoted 10 lines · Russell King - ARM Linux

Quoted 5 lines · Santosh Shilimkar

Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP.

Now trying to merge your for-next and test.

Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine.

Quoted 7 lines

Hang on...

# CONFIG_ARCH_OMAP2PLUS is not set
CONFIG_ARCH_VEXPRESS=y

which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support.

And no, the instructions given last time around to add:

Quoted 8 lines

Quoted 6 lines

# 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y

don't fix it either, it needs more options defined...

Linus' tip + Tony's pull [1] request also makes things work on OMAP.

Thanks to all this multiplatform stuff, the autobuilder has been building nothing but Versatile Express kernels for the last 20 days. That totally explains why it won't boot.

The only thing I was told is to add the above two config symbols. That is not the complete story. There's also other symbols which need adding too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous.

And... fixing the config finally results in something that boots on the SDP4430.

Quoted 6 lines · Russell King - ARM Linux

Quoted 6 lines

Quoted 6 lines

# 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y

don't fix it either, it needs more options defined...

Quoted 6 lines · Santosh Shilimkar

Quoted 5 lines · Russell King - ARM Linux

Quoted 5 lines

Quoted 5 lines

# 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

don't fix it either, it needs more options defined...

Just trying to figure out what was the missing entry in case others have the same problem.

In addition to the ones above, I had also CONFIG_ARCH_OMAP2PLUS=y listed in my comments. Did you also need something else added manually?

too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous.

Quoted 2 lines · Russell King - ARM Linux

too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous.

Should we go with this approach?
https://patchwork.kernel.org/patch/1774521/

Quoted 8 lines · Fabio Estevam

Quoted 2 lines · Russell King - ARM Linux

too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous.

Should we go with this approach?
https://patchwork.kernel.org/patch/1774521/

We need to go with an approach which isn't going to break allnoconfig and randconfig.

I've suggested that we should have a basic, minimalist platform always built in for DT supporting kernels. I've actually suggested that we should end up not having a machine_desc at all once the DT conversion is complete. Either of those solves the problem of us ending up with no platform support built with these configurations.

The alternative is we end up with quite a long disgusting Kconfig option which becomes enabled when everything but Versatile Express is disabled...

This is what I think it would look like to do a default platform with an empty machine descriptor on ARM. It makes the few required entries in the descriptor optional by using the new irqchip_init() and clocksource_of_init() functions as defaults, and adds a fallback for the DT case to customize_machine to probe all the default devices.

For the case that CONFIG_MULTIPLATFORM is enabled, it then adds a machine descriptor that never matches any machine but is used as a fallback if nothing else matches.

arch/arm/kernel/setup.c +1 -1

 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*

With that change, we can remove the custom .init_machine() functions for all of Tegra, since they just do that:-)

drivers/irqchip/irqchip.c irqchip_of_match_end __used __section(__irqchip_of_end); · line 36

Quoted 12 lines

drivers/irqchip/irqchip.c +6 -0

 
+#ifdef CONFIG_IRQCHIP
 void __init irqchip_init(void)
 {
 	of_irq_init(__irqchip_begin);
 }
+#else
+static inline void irqchip_init(void)
+{
+}
+#endif

That'd need to go in a header file.

This is what I think it would look like to do a default platform with an empty machine descriptor on ARM. It makes the few required entries in the descriptor optional by using the new irqchip_init() and clocksource_of_init() functions as defaults, and adds a fallback for the DT case to customize_machine to probe all the default devices.

For the case that CONFIG_MULTIPLATFORM is enabled, it then adds a machine descriptor that never matches any machine but is used as a fallback if nothing else matches.

Signed-off-by Arnd Bergmann <[email protected]>

arch/arm/Kconfig +0 -1

index 3e3444e..8ff1d38 100644
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7

arch/arm/kernel/devtree.c +8 -1

index 70f1bde..e6e34ba 100644
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+	if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+		DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+		MACHINE_END
+
+		mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+	}
+
 	if (!dt_phys)
 		return NULL;
 

@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 			mdesc_score = score;
 		}
 	}
-	if (!mdesc_best) {
+	if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
 		const char *prop;
 		long size;
 

arch/arm/kernel/irq.c +5 -1

index 8e4ef4c..df6f9a1 100644
@@ -26,6 +26,7 @@
 #include <linux/ioport.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/irqchip.h>
 #include <linux/random.h>
 #include <linux/smp.h>
 #include <linux/init.h>

@@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
 
 void __init init_IRQ(void)
 {
-	machine_desc->init_irq();
+	if (machine_desc->init_irq)
+		machine_desc->init_irq();
+	else
+		irqchip_init();
 }
 
 #ifdef CONFIG_MULTI_IRQ_HANDLER

arch/arm/kernel/setup.c +11 -2

index 3f6cbb2..1d40c9d 100644
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>

@@ -640,9 +641,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);

@@ -732,7 +741,7 @@ void __init setup_arch(char **cmdline_p)
 
 	setup_processor();
 	mdesc = setup_machine_fdt(__atags_pointer);
-	if (!mdesc)
+	if (!mdesc && __machine_arch_type != ~0)
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
 	machine_desc = mdesc;
 	machine_name = mdesc->name;

arch/arm/kernel/time.c +6 -1

index 955d92d..abff4e9 100644
@@ -22,6 +22,7 @@
 #include <linux/errno.h>
 #include <linux/profile.h>
 #include <linux/timer.h>
+#include <linux/clocksource.h>
 #include <linux/irq.h>
 
 #include <asm/thread_info.h>

@@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn read_boot,
 
 void __init time_init(void)
 {
-	machine_desc->init_time();
+	if (machine_desc->init_time)
+		machine_desc->init_time();
+	else
+		clocksource_of_init();
+
 	sched_clock_postinit();
 }

drivers/irqchip/irqchip.c +6 -0

index f496afc..c5e7a45 100644
@@ -24,7 +24,13 @@ irqchip_of_match_end __used __section(__irqchip_of_end);
 
 extern struct of_device_id __irqchip_begin[];
 
+#ifdef CONFIG_IRQCHIP
 void __init irqchip_init(void)
 {
 	of_irq_init(__irqchip_begin);
 }
+#else
+static inline void irqchip_init(void)
+{
+}
+#endif

include/linux/clocksource.h +4 -0

index 7944f14..b14d224 100644
@@ -339,6 +339,10 @@ extern void clocksource_of_init(void);
 	static const struct of_device_id __clksrc_of_table_##name	\
 		__used __section(__clksrc_of_table)			\
 		 = { .compatible = compat, .data = fn };
+#else
+static inline void clocksource_of_init(void)
+{
+}
 #endif
 
 #endif /* _LINUX_CLOCKSOURCE_H */

This is what I think it would look like to do a default platform with an empty machine descriptor on ARM. It makes the few required entries in the descriptor optional by using the new irqchip_init() and clocksource_of_init() functions as defaults, and adds a fallback for the DT case to customize_machine to probe all the default devices.

For the case that CONFIG_MULTIPLATFORM is enabled, it then adds a machine descriptor that never matches any machine but is used as a fallback if nothing else matches.

Signed-off-by Arnd Bergmann <[email protected]>

This is indeed a nice update towards consolidation. Though on OMAP, we need to do some work to effectively get rid of machine, time and irq inits. Will add this task in my TODO queue.

This is what I think it would look like to do a default platform with an empty machine descriptor on ARM. It makes the few required entries in the descriptor optional by using the new irqchip_init() and clocksource_of_init() functions as defaults, and adds a fallback for the DT case to customize_machine to probe all the default devices.

For the case that CONFIG_MULTIPLATFORM is enabled, it then adds a machine descriptor that never matches any machine but is used as a fallback if nothing else matches.

Signed-off-by Arnd Bergmann <[email protected]>

arch/arm/Kconfig +0 -1

index 3e3444e..8ff1d38 100644
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
  bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
  default y
  select ARCH_MULTI_V6_V7
- select ARCH_VEXPRESS
  select CPU_V7
 
 config ARCH_MULTI_V6_V7

arch/arm/kernel/devtree.c +0 -0

index 70f1bde..e6e34ba 100644

arch/arm/kernel/devtree.c +5 -1

+
+ mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+ }
+
  if (!dt_phys)
  return NULL;
 

@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
  mdesc_score = score;
  }
  }
- if (!mdesc_best) {
+ if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
  const char *prop;
  long size;
 

arch/arm/kernel/irq.c +5 -1

index 8e4ef4c..df6f9a1 100644
@@ -26,6 +26,7 @@
 #include <linux/ioport.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/irqchip.h>
 #include <linux/random.h>
 #include <linux/smp.h>
 #include <linux/init.h>

@@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
 
 void __init init_IRQ(void)
 {
- machine_desc->init_irq();
+ if (machine_desc->init_irq)
+ machine_desc->init_irq();
+ else
+ irqchip_init();
 }
 
 #ifdef CONFIG_MULTI_IRQ_HANDLER

arch/arm/kernel/setup.c +2 -1

index 3f6cbb2..1d40c9d 100644
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>

@@ -640,9 +641,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
- /* customizes platform devices, or adds new ones */
+ /*

Quoted 4 lines

+ if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+ DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+ MACHINE_END

I assume this works, but it looks a bit strange declared here.

Quoted 6 lines

static int __init customize_machine(void)
{
- /* customizes platform devices, or adds new ones */
+ /*
+ * customizes platform devices, or adds new ones
+ * On DT based machines, we fall back to populating the

Quoted 8 lines

+ * machine from the device tree, if no callback is provided,
+ * otherwise we would always need an init_machine callback.
+ */
if (machine_desc->init_machine) machine_desc->init_machine();
+ else
+ of_platform_populate(NULL, of_default_bus_match_table,
+ NULL, NULL);

Could this be unconditional? It should be safe to call multiple times if a platform calls this first because ordering matters or there are custom match tables. I would guess any ordering requirements need to happen before this call anyway.

This is what I think it would look like to do a default platform with an empty machine descriptor on ARM. It makes the few required entries in the descriptor optional by using the new irqchip_init() and clocksource_of_init() functions as defaults, and adds a fallback for the DT case to customize_machine to probe all the default devices.

For the case that CONFIG_MULTIPLATFORM is enabled, it then adds a machine descriptor that never matches any machine but is used as a fallback if nothing else matches.

Signed-off-by Arnd Bergmann <[email protected]>

This is what I think it would look like to do a default platform with an empty machine descriptor on ARM. It makes the few required entries in the descriptor optional by using the new irqchip_init() and clocksource_of_init() functions as defaults, and adds a fallback for the DT case to customize_machine to probe all the default devices.

For the case that CONFIG_MULTIPLATFORM is enabled, it then adds a machine descriptor that never matches any machine but is used as a fallback if nothing else matches.

Signed-off-by Arnd Bergmann <[email protected]>

arch/arm/Kconfig +0 -1

index 3e3444e..8ff1d38 100644
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7

arch/arm/kernel/devtree.c +8 -1

index 70f1bde..e6e34ba 100644
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+	if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+		DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+		MACHINE_END
+
+		mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+	}
+
 	if (!dt_phys)
 		return NULL;
 

@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 			mdesc_score = score;
 		}
 	}
-	if (!mdesc_best) {
+	if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
 		const char *prop;
 		long size;
 

arch/arm/kernel/irq.c +5 -1

index 8e4ef4c..df6f9a1 100644
@@ -26,6 +26,7 @@
 #include <linux/ioport.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/irqchip.h>
 #include <linux/random.h>
 #include <linux/smp.h>
 #include <linux/init.h>

@@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
 
 void __init init_IRQ(void)
 {
-	machine_desc->init_irq();
+	if (machine_desc->init_irq)
+		machine_desc->init_irq();
+	else
+		irqchip_init();
 }
 
 #ifdef CONFIG_MULTI_IRQ_HANDLER

arch/arm/kernel/setup.c +11 -2

index 3f6cbb2..1d40c9d 100644
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>

@@ -640,9 +641,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);

@@ -732,7 +741,7 @@ void __init setup_arch(char **cmdline_p)
 
 	setup_processor();
 	mdesc = setup_machine_fdt(__atags_pointer);
-	if (!mdesc)
+	if (!mdesc && __machine_arch_type != ~0)
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
 	machine_desc = mdesc;
 	machine_name = mdesc->name;

arch/arm/kernel/time.c +6 -1

index 955d92d..abff4e9 100644
@@ -22,6 +22,7 @@
 #include <linux/errno.h>
 #include <linux/profile.h>
 #include <linux/timer.h>
+#include <linux/clocksource.h>
 #include <linux/irq.h>
 
 #include <asm/thread_info.h>

@@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn read_boot,
 
 void __init time_init(void)
 {
-	machine_desc->init_time();
+	if (machine_desc->init_time)
+		machine_desc->init_time();
+	else
+		clocksource_of_init();
+
 	sched_clock_postinit();
 }

drivers/irqchip/irqchip.c +6 -0

index f496afc..c5e7a45 100644
@@ -24,7 +24,13 @@ irqchip_of_match_end __used __section(__irqchip_of_end);
 
 extern struct of_device_id __irqchip_begin[];
 
+#ifdef CONFIG_IRQCHIP
 void __init irqchip_init(void)
 {
 	of_irq_init(__irqchip_begin);
 }
+#else
+static inline void irqchip_init(void)
+{
+}
+#endif

include/linux/clocksource.h +4 -0

index 7944f14..b14d224 100644
@@ -339,6 +339,10 @@ extern void clocksource_of_init(void);
 	static const struct of_device_id __clksrc_of_table_##name	\
 		__used __section(__clksrc_of_table)			\
 		 = { .compatible = compat, .data = fn };
+#else
+static inline void clocksource_of_init(void)
+{
+}
 #endif
 
 #endif /* _LINUX_CLOCKSOURCE_H */

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel