* Failure to boot... @ 2013-01-31 1:49 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 1:49 UTC (permalink / raw) To: linux-arm-kernel, linux-omap, Tony Lindgren; +Cc: Nicolas Pitre, arm 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 1:49 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 1:49 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 1:49 ` Russell King - ARM Linux @ 2013-01-31 3:02 ` Olof Johansson -1 siblings, 0 replies; 57+ messages in thread From: Olof Johansson @ 2013-01-31 3:02 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-arm-kernel, linux-omap, Tony Lindgren, Nicolas Pitre, arm On Thu, Jan 31, 2013 at 01:49:12AM +0000, Russell King - ARM Linux wrote: > 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? diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile index abfce28..71768b8 100644 --- a/arch/arm/boot/Makefile +++ b/arch/arm/boot/Makefile @@ -68,8 +68,8 @@ else endif check_for_multiple_loadaddr = \ -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ echo 'This is incompatible with uImages'; \ echo 'Specify LOADADDR on the commandline to build an uImage'; \ false; \ -Olof ^ permalink raw reply related [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 3:02 ` Olof Johansson 0 siblings, 0 replies; 57+ messages in thread From: Olof Johansson @ 2013-01-31 3:02 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 01:49:12AM +0000, Russell King - ARM Linux wrote: > 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? diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile index abfce28..71768b8 100644 --- a/arch/arm/boot/Makefile +++ b/arch/arm/boot/Makefile @@ -68,8 +68,8 @@ else endif check_for_multiple_loadaddr = \ -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ echo 'This is incompatible with uImages'; \ echo 'Specify LOADADDR on the commandline to build an uImage'; \ false; \ -Olof ^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 3:02 ` Olof Johansson @ 2013-01-31 4:19 ` Nicolas Pitre -1 siblings, 0 replies; 57+ messages in thread From: Nicolas Pitre @ 2013-01-31 4:19 UTC (permalink / raw) To: Olof Johansson Cc: Russell King - ARM Linux, linux-arm-kernel, linux-omap, Tony Lindgren, arm On Wed, 30 Jan 2013, Olof Johansson wrote: > 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. The uImage format is incompatible with multi-platform builds, period. The uImage wrapping should be done at kernel _installation_ time, not at _build_ time. That is, people shoud get into the habit of distributing a zImage binary, and the installation procedure on a particular platform should take care of running mkimage on it. Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. > 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? Absolutely. > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile > index abfce28..71768b8 100644 > --- a/arch/arm/boot/Makefile > +++ b/arch/arm/boot/Makefile > @@ -68,8 +68,8 @@ else > endif > > check_for_multiple_loadaddr = \ > -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ > - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ > +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ > + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ > echo 'This is incompatible with uImages'; \ > echo 'Specify LOADADDR on the commandline to build an uImage'; \ > false; \ Acked-by: Nicolas Pitre <nico@linaro.org> Nicolas ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 4:19 ` Nicolas Pitre 0 siblings, 0 replies; 57+ messages in thread From: Nicolas Pitre @ 2013-01-31 4:19 UTC (permalink / raw) To: linux-arm-kernel On Wed, 30 Jan 2013, Olof Johansson wrote: > 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. The uImage format is incompatible with multi-platform builds, period. The uImage wrapping should be done at kernel _installation_ time, not at _build_ time. That is, people shoud get into the habit of distributing a zImage binary, and the installation procedure on a particular platform should take care of running mkimage on it. Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. > 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? Absolutely. > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile > index abfce28..71768b8 100644 > --- a/arch/arm/boot/Makefile > +++ b/arch/arm/boot/Makefile > @@ -68,8 +68,8 @@ else > endif > > check_for_multiple_loadaddr = \ > -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ > - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ > +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ > + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ > echo 'This is incompatible with uImages'; \ > echo 'Specify LOADADDR on the commandline to build an uImage'; \ > false; \ Acked-by: Nicolas Pitre <nico@linaro.org> Nicolas ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 4:19 ` Nicolas Pitre @ 2013-01-31 9:20 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 9:20 UTC (permalink / raw) To: Nicolas Pitre Cc: Olof Johansson, linux-arm-kernel, linux-omap, Tony Lindgren, arm On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: > 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 9:20 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 9:20 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: > 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 9:20 ` Russell King - ARM Linux @ 2013-01-31 10:40 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 10:40 UTC (permalink / raw) To: Nicolas Pitre Cc: Olof Johansson, linux-arm-kernel, linux-omap, Tony Lindgren, arm On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: > On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: > > 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. 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 10:40 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 10:40 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: > On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: > > 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. 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 10:40 ` Russell King - ARM Linux @ 2013-01-31 12:49 ` Santosh Shilimkar -1 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 12:49 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>> 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. > > 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. Regards, Santosh 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 ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 12:49 ` Santosh Shilimkar 0 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 12:49 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>> 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. > > 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. Regards, Santosh 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 ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 12:49 ` Santosh Shilimkar @ 2013-01-31 13:04 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 13:04 UTC (permalink / raw) To: Santosh Shilimkar Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>> 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. >> >> 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. Here's the diffstat between my for-next and the remainder of other stuff that gets built: arch/arm/mach-realview/core.c | 212 ++++++++ arch/arm/mach-realview/core.h | 2 + arch/arm/mach-realview/include/mach/platform.h | 2 + arch/arm/mach-realview/realview_eb.c | 37 ++- arch/arm/mach-realview/realview_pb11mp.c | 33 ++- arch/arm/mach-realview/realview_pba8.c | 3 +- arch/arm/mach-realview/realview_pbx.c | 3 +- arch/arm/mach-versatile/core.c | 482 ++++++++++++++++++- arch/arm/mach-versatile/include/mach/platform.h | 6 + arch/arm/mach-versatile/versatile_pb.c | 17 +- drivers/dma/amba-pl08x.c | 26 +- drivers/tty/serial/omap-serial.c | 30 ++ drivers/tty/serial/serial_core.c | 23 +- include/linux/serial_core.h | 2 + include/sound/soc-dmaengine.h | 26 + sound/soc/Kconfig | 5 + sound/soc/Makefile | 3 + sound/soc/sa11x0/Kconfig | 14 + sound/soc/sa11x0/Makefile | 5 + sound/soc/sa11x0/sa11x0-assabet.c | 432 +++++++++++++++++ sound/soc/sa11x0/sa11x0-ssp.c | 345 +++++++++++++ sound/soc/sa11x0/sa11x0-ssp.h | 11 + sound/soc/soc-dmaengine.c | 591 +++++++++++++++++++++++ 23 files changed, 2283 insertions(+), 27 deletions(-) As far as OMAP goes, that's basically additional bits for serial DMA support that I was working on, best pieced back together before the serial driver was majorly reworked a couple of merge windows ago. These have been there for at least the last three months. The rest are for SA11x0 Assabet sound support, and DMA support on Versatile/Realview platforms. > 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. Thanks. > 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 That's no good to me if it only goes to linux-omap. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 13:04 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 13:04 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>> 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. >> >> 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. Here's the diffstat between my for-next and the remainder of other stuff that gets built: arch/arm/mach-realview/core.c | 212 ++++++++ arch/arm/mach-realview/core.h | 2 + arch/arm/mach-realview/include/mach/platform.h | 2 + arch/arm/mach-realview/realview_eb.c | 37 ++- arch/arm/mach-realview/realview_pb11mp.c | 33 ++- arch/arm/mach-realview/realview_pba8.c | 3 +- arch/arm/mach-realview/realview_pbx.c | 3 +- arch/arm/mach-versatile/core.c | 482 ++++++++++++++++++- arch/arm/mach-versatile/include/mach/platform.h | 6 + arch/arm/mach-versatile/versatile_pb.c | 17 +- drivers/dma/amba-pl08x.c | 26 +- drivers/tty/serial/omap-serial.c | 30 ++ drivers/tty/serial/serial_core.c | 23 +- include/linux/serial_core.h | 2 + include/sound/soc-dmaengine.h | 26 + sound/soc/Kconfig | 5 + sound/soc/Makefile | 3 + sound/soc/sa11x0/Kconfig | 14 + sound/soc/sa11x0/Makefile | 5 + sound/soc/sa11x0/sa11x0-assabet.c | 432 +++++++++++++++++ sound/soc/sa11x0/sa11x0-ssp.c | 345 +++++++++++++ sound/soc/sa11x0/sa11x0-ssp.h | 11 + sound/soc/soc-dmaengine.c | 591 +++++++++++++++++++++++ 23 files changed, 2283 insertions(+), 27 deletions(-) As far as OMAP goes, that's basically additional bits for serial DMA support that I was working on, best pieced back together before the serial driver was majorly reworked a couple of merge windows ago. These have been there for at least the last three months. The rest are for SA11x0 Assabet sound support, and DMA support on Versatile/Realview platforms. > 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. Thanks. > 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 That's no good to me if it only goes to linux-omap. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 13:04 ` Russell King - ARM Linux @ 2013-01-31 14:00 ` Santosh Shilimkar -1 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:00 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: >> On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >>>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>>> 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. >>> >>> 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. > 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. Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83084.html ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:00 ` Santosh Shilimkar 0 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:00 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: >> On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >>>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>>> 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. >>> >>> 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. > 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. Regards, Santosh [1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg83084.html ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:00 ` Santosh Shilimkar @ 2013-01-31 14:10 ` Santosh Shilimkar -1 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:10 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nicolas Pitre, Tony Lindgren, arm, Olof Johansson, linux-omap, linux-arm-kernel On Thursday 31 January 2013 07:30 PM, Santosh Shilimkar wrote: > On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: >>> On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >>>> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux >>>> wrote: >>>>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>>>> 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. >>>> >>>> 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. >> > 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. > This is fine as well. I think the issue is the way uImage is created. 'make LOADADDRESS=XXXX uImage' actually doesn't work. Am using below method to create an uImage. mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage Will you be able to try this out please ? Regards, Santosh ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:10 ` Santosh Shilimkar 0 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:10 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 07:30 PM, Santosh Shilimkar wrote: > On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: >>> On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >>>> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux >>>> wrote: >>>>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>>>> 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. >>>> >>>> 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. >> > 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. > This is fine as well. I think the issue is the way uImage is created. 'make LOADADDRESS=XXXX uImage' actually doesn't work. Am using below method to create an uImage. mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage Will you be able to try this out please ? Regards, Santosh ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:00 ` Santosh Shilimkar @ 2013-01-31 14:13 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 14:13 UTC (permalink / raw) To: Santosh Shilimkar Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:13 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 14:13 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:13 ` Russell King - ARM Linux @ 2013-01-31 14:16 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 14:16 UTC (permalink / raw) To: Santosh Shilimkar Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > > 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. 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... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:16 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 14:16 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > > 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. 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... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:16 ` Russell King - ARM Linux @ 2013-01-31 14:20 ` Santosh Shilimkar -1 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:20 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>> 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. > > 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... > Linus' tip + Tony's pull [1] request also makes things work on OMAP. Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83084.html ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:20 ` Santosh Shilimkar 0 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:20 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>> 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. > > 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... > Linus' tip + Tony's pull [1] request also makes things work on OMAP. Regards, Santosh [1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg83084.html ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:20 ` Santosh Shilimkar @ 2013-01-31 14:27 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 14:27 UTC (permalink / raw) To: Santosh Shilimkar Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>>> 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. >> >> 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... >> > 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:27 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 14:27 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>>> 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. >> >> 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... >> > 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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:27 ` Russell King - ARM Linux @ 2013-01-31 14:43 ` Santosh Shilimkar -1 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:43 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nicolas Pitre, Olof Johansson, Tony Lindgren, linux-omap, arm, linux-arm-kernel On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: >> On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >>>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>>>> 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. >>> >>> 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... >>> >> 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. > Great. Thanks for the confirmation. Regards, Santosh ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 14:43 ` Santosh Shilimkar 0 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-01-31 14:43 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: >> On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >>>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>>>> 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. >>> >>> 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... >>> >> 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. > Great. Thanks for the confirmation. Regards, Santosh ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:43 ` Santosh Shilimkar @ 2013-01-31 16:00 ` Tony Lindgren -1 siblings, 0 replies; 57+ messages in thread From: Tony Lindgren @ 2013-01-31 16:00 UTC (permalink / raw) To: Santosh Shilimkar Cc: Russell King - ARM Linux, Nicolas Pitre, Olof Johansson, linux-omap, arm, linux-arm-kernel * Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]: > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > >>> > >>># 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... 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? Regards, Tony ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 16:00 ` Tony Lindgren 0 siblings, 0 replies; 57+ messages in thread From: Tony Lindgren @ 2013-01-31 16:00 UTC (permalink / raw) To: linux-arm-kernel * Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]: > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > >>> > >>># 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... 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? Regards, Tony ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 16:00 ` Tony Lindgren @ 2013-01-31 16:19 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 16:19 UTC (permalink / raw) To: Tony Lindgren Cc: Santosh Shilimkar, Nicolas Pitre, arm, Olof Johansson, linux-omap, linux-arm-kernel On Thu, Jan 31, 2013 at 08:00:02AM -0800, Tony Lindgren wrote: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]: > > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > > >>> > > >>># 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... > > 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? Interesting, that's the one which got missed. The ones which did get updated on the 13th were just the noconfigs which were failing to build, and not the two oldconfigs which are the booted ones. The noconfigs already had OMAP2PLUS enabled in them which is probably how it got lost. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 16:19 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 16:19 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 08:00:02AM -0800, Tony Lindgren wrote: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]: > > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > > >>> > > >>># 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... > > 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? Interesting, that's the one which got missed. The ones which did get updated on the 13th were just the noconfigs which were failing to build, and not the two oldconfigs which are the booted ones. The noconfigs already had OMAP2PLUS enabled in them which is probably how it got lost. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 14:27 ` Russell King - ARM Linux @ 2013-01-31 16:01 ` Fabio Estevam -1 siblings, 0 replies; 57+ messages in thread From: Fabio Estevam @ 2013-01-31 16:01 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Santosh Shilimkar, Nicolas Pitre, Tony Lindgren, arm, Olof Johansson, linux-omap, linux-arm-kernel On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > 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/ ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 16:01 ` Fabio Estevam 0 siblings, 0 replies; 57+ messages in thread From: Fabio Estevam @ 2013-01-31 16:01 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > 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/ ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 16:01 ` Fabio Estevam @ 2013-01-31 16:18 ` Russell King - ARM Linux -1 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 16:18 UTC (permalink / raw) To: Fabio Estevam Cc: Santosh Shilimkar, Nicolas Pitre, Tony Lindgren, arm, Olof Johansson, linux-omap, linux-arm-kernel On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > 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... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 16:18 ` Russell King - ARM Linux 0 siblings, 0 replies; 57+ messages in thread From: Russell King - ARM Linux @ 2013-01-31 16:18 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > 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... ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Failure to boot... 2013-01-31 16:18 ` Russell King - ARM Linux @ 2013-01-31 16:27 ` Arnd Bergmann -1 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-01-31 16:27 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Fabio Estevam, Santosh Shilimkar, Nicolas Pitre, Tony Lindgren, arm, Olof Johansson, linux-omap, linux-arm-kernel On Thursday 31 January 2013 16:18:23 Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > > <linux@arm.linux.org.uk> wrote: > > > > > 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. Yes, I like the idea a lot. I think we should be pretty close to being able to do that just now, with generic hooks to initialize the interrupt controller and clocksouroce drivers. > The alternative is we end up with quite a long disgusting Kconfig > option which becomes enabled when everything but Versatile Express > is disabled... Yes, I've tried that in the past, it wasn't nice. It also gets much more complex if you want to do it for all configurations instead of just those that enable ARMv7. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* Failure to boot... @ 2013-01-31 16:27 ` Arnd Bergmann 0 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-01-31 16:27 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 16:18:23 Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > > <linux@arm.linux.org.uk> wrote: > > > > > 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. Yes, I like the idea a lot. I think we should be pretty close to being able to do that just now, with generic hooks to initialize the interrupt controller and clocksouroce drivers. > The alternative is we end up with quite a long disgusting Kconfig > option which becomes enabled when everything but Versatile Express > is disabled... Yes, I've tried that in the past, it wasn't nice. It also gets much more complex if you want to do it for all configurations instead of just those that enable ARMv7. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 16:27 ` Arnd Bergmann @ 2013-01-31 17:51 ` Arnd Bergmann -1 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-01-31 17:51 UTC (permalink / raw) To: linux-arm-kernel, Santosh Shilimkar Cc: Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam 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 <arnd@arndb.de> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3e3444e..8ff1d38 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -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 diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index 70f1bde..e6e34ba 100644 --- a/arch/arm/kernel/devtree.c +++ b/arch/arm/kernel/devtree.c @@ -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; diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c index 8e4ef4c..df6f9a1 100644 --- a/arch/arm/kernel/irq.c +++ b/arch/arm/kernel/irq.c @@ -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 diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 3f6cbb2..1d40c9d 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -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; diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index 955d92d..abff4e9 100644 --- a/arch/arm/kernel/time.c +++ b/arch/arm/kernel/time.c @@ -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(); } diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index f496afc..c5e7a45 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -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 diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h index 7944f14..b14d224 100644 --- a/include/linux/clocksource.h +++ b/include/linux/clocksource.h @@ -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 */ ^ permalink raw reply related [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-01-31 17:51 ` Arnd Bergmann 0 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-01-31 17:51 UTC (permalink / raw) To: linux-arm-kernel 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 <arnd@arndb.de> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3e3444e..8ff1d38 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -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 diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index 70f1bde..e6e34ba 100644 --- a/arch/arm/kernel/devtree.c +++ b/arch/arm/kernel/devtree.c @@ -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; diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c index 8e4ef4c..df6f9a1 100644 --- a/arch/arm/kernel/irq.c +++ b/arch/arm/kernel/irq.c @@ -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 diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 3f6cbb2..1d40c9d 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -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; diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index 955d92d..abff4e9 100644 --- a/arch/arm/kernel/time.c +++ b/arch/arm/kernel/time.c @@ -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(); } diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index f496afc..c5e7a45 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -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 diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h index 7944f14..b14d224 100644 --- a/include/linux/clocksource.h +++ b/include/linux/clocksource.h @@ -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 */ ^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 17:51 ` Arnd Bergmann @ 2013-01-31 18:52 ` Stephen Warren -1 siblings, 0 replies; 57+ messages in thread From: Stephen Warren @ 2013-01-31 18:52 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Santosh Shilimkar, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On 01/31/2013 10:51 AM, Arnd Bergmann wrote: > 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. > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > 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); With that change, we can remove the custom .init_machine() functions for all of Tegra, since they just do that:-) > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > +#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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-01-31 18:52 ` Stephen Warren 0 siblings, 0 replies; 57+ messages in thread From: Stephen Warren @ 2013-01-31 18:52 UTC (permalink / raw) To: linux-arm-kernel On 01/31/2013 10:51 AM, Arnd Bergmann wrote: > 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. > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > 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); With that change, we can remove the custom .init_machine() functions for all of Tegra, since they just do that:-) > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > +#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. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 18:52 ` Stephen Warren @ 2013-01-31 20:57 ` Arnd Bergmann -1 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-01-31 20:57 UTC (permalink / raw) To: Stephen Warren Cc: linux-arm-kernel, Santosh Shilimkar, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On Thursday 31 January 2013, Stephen Warren wrote: > With that change, we can remove the custom .init_machine() functions for > all of Tegra, since they just do that:-) Yes, actually quite a lot of them have the same code, and we also have an increasing number of users of the irqchip_init and clocksource_of_init, so those can also be cleaned up as a follow-on to this patch. The main thing that has to remain for a lot of the platforms is SMP support, and I don't see a good way around that yet. > > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > > > +#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. Yep, you're right, my mistake. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-01-31 20:57 ` Arnd Bergmann 0 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-01-31 20:57 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013, Stephen Warren wrote: > With that change, we can remove the custom .init_machine() functions for > all of Tegra, since they just do that:-) Yes, actually quite a lot of them have the same code, and we also have an increasing number of users of the irqchip_init and clocksource_of_init, so those can also be cleaned up as a follow-on to this patch. The main thing that has to remain for a lot of the platforms is SMP support, and I don't see a good way around that yet. > > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > > > +#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. Yep, you're right, my mistake. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 17:51 ` Arnd Bergmann @ 2013-01-31 20:34 ` Nicolas Pitre -1 siblings, 0 replies; 57+ messages in thread From: Nicolas Pitre @ 2013-01-31 20:34 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Santosh Shilimkar, Russell King - ARM Linux, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On Thu, 31 Jan 2013, Arnd Bergmann wrote: > 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 <arnd@arndb.de> Looks sensible. Acked-by: Nicolas Pitre <nico@linaro.org> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3e3444e..8ff1d38 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 70f1bde..e6e34ba 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -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; > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index 8e4ef4c..df6f9a1 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -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 > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > index 3f6cbb2..1d40c9d 100644 > --- a/arch/arm/kernel/setup.c > +++ b/arch/arm/kernel/setup.c > @@ -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; > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c > index 955d92d..abff4e9 100644 > --- a/arch/arm/kernel/time.c > +++ b/arch/arm/kernel/time.c > @@ -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(); > } > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > index f496afc..c5e7a45 100644 > --- a/drivers/irqchip/irqchip.c > +++ b/drivers/irqchip/irqchip.c > @@ -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 > diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h > index 7944f14..b14d224 100644 > --- a/include/linux/clocksource.h > +++ b/include/linux/clocksource.h > @@ -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 */ > ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-01-31 20:34 ` Nicolas Pitre 0 siblings, 0 replies; 57+ messages in thread From: Nicolas Pitre @ 2013-01-31 20:34 UTC (permalink / raw) To: linux-arm-kernel On Thu, 31 Jan 2013, Arnd Bergmann wrote: > 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 <arnd@arndb.de> Looks sensible. Acked-by: Nicolas Pitre <nico@linaro.org> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3e3444e..8ff1d38 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 70f1bde..e6e34ba 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -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; > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index 8e4ef4c..df6f9a1 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -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 > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > index 3f6cbb2..1d40c9d 100644 > --- a/arch/arm/kernel/setup.c > +++ b/arch/arm/kernel/setup.c > @@ -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; > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c > index 955d92d..abff4e9 100644 > --- a/arch/arm/kernel/time.c > +++ b/arch/arm/kernel/time.c > @@ -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(); > } > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > index f496afc..c5e7a45 100644 > --- a/drivers/irqchip/irqchip.c > +++ b/drivers/irqchip/irqchip.c > @@ -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 > diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h > index 7944f14..b14d224 100644 > --- a/include/linux/clocksource.h > +++ b/include/linux/clocksource.h > @@ -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 */ > ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 17:51 ` Arnd Bergmann @ 2013-02-01 11:47 ` Santosh Shilimkar -1 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-02-01 11:47 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On Thursday 31 January 2013 11:21 PM, Arnd Bergmann wrote: > 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 <arnd@arndb.de> > 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. Regards, Santosh ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-02-01 11:47 ` Santosh Shilimkar 0 siblings, 0 replies; 57+ messages in thread From: Santosh Shilimkar @ 2013-02-01 11:47 UTC (permalink / raw) To: linux-arm-kernel On Thursday 31 January 2013 11:21 PM, Arnd Bergmann wrote: > 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 <arnd@arndb.de> > 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. Regards, Santosh ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-02-01 11:47 ` Santosh Shilimkar @ 2013-02-01 12:34 ` Arnd Bergmann -1 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-02-01 12:34 UTC (permalink / raw) To: Santosh Shilimkar Cc: linux-arm-kernel, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On Friday 01 February 2013, Santosh Shilimkar wrote: > 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. There is no urgent need to get all board files to have empty machine descriptors, I would not expect that to happen for the more complex platforms like omap any time soon. You currently use quite a number of callbacks: DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)") .reserve = omap_reserve, .smp = smp_ops(omap4_smp_ops), .map_io = omap5_map_io, .init_early = omap5_init_early, .init_irq = omap_gic_of_init, .handle_irq = gic_handle_irq, .init_machine = omap_generic_init, .timer = &omap5_timer, .dt_compat = omap5_boards_compat, .restart = omap44xx_restart, MACHINE_END and I see nothing wrong with that. For simpler platforms that after migrating out init_irq and init_timer have only one or two callbacks left, it may be more interesting to actually go all the way and remove all of them if possible. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-02-01 12:34 ` Arnd Bergmann 0 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-02-01 12:34 UTC (permalink / raw) To: linux-arm-kernel On Friday 01 February 2013, Santosh Shilimkar wrote: > 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. There is no urgent need to get all board files to have empty machine descriptors, I would not expect that to happen for the more complex platforms like omap any time soon. You currently use quite a number of callbacks: DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)") .reserve = omap_reserve, .smp = smp_ops(omap4_smp_ops), .map_io = omap5_map_io, .init_early = omap5_init_early, .init_irq = omap_gic_of_init, .handle_irq = gic_handle_irq, .init_machine = omap_generic_init, .timer = &omap5_timer, .dt_compat = omap5_boards_compat, .restart = omap44xx_restart, MACHINE_END and I see nothing wrong with that. For simpler platforms that after migrating out init_irq and init_timer have only one or two callbacks left, it may be more interesting to actually go all the way and remove all of them if possible. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 17:51 ` Arnd Bergmann @ 2013-02-05 21:37 ` Rob Herring -1 siblings, 0 replies; 57+ messages in thread From: Rob Herring @ 2013-02-05 21:37 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Santosh Shilimkar, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On 01/31/2013 11:51 AM, Arnd Bergmann wrote: > 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 <arnd@arndb.de> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3e3444e..8ff1d38 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 70f1bde..e6e34ba 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -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 I assume this works, but it looks a bit strange declared here. > + > + 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; > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index 8e4ef4c..df6f9a1 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -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 > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > index 3f6cbb2..1d40c9d 100644 > --- a/arch/arm/kernel/setup.c > +++ b/arch/arm/kernel/setup.c > @@ -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); 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. Rob ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-02-05 21:37 ` Rob Herring 0 siblings, 0 replies; 57+ messages in thread From: Rob Herring @ 2013-02-05 21:37 UTC (permalink / raw) To: linux-arm-kernel On 01/31/2013 11:51 AM, Arnd Bergmann wrote: > 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 <arnd@arndb.de> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3e3444e..8ff1d38 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 70f1bde..e6e34ba 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -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 I assume this works, but it looks a bit strange declared here. > + > + 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; > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index 8e4ef4c..df6f9a1 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -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 > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > index 3f6cbb2..1d40c9d 100644 > --- a/arch/arm/kernel/setup.c > +++ b/arch/arm/kernel/setup.c > @@ -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); 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. Rob ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-02-05 21:37 ` Rob Herring @ 2013-02-05 22:23 ` Arnd Bergmann -1 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-02-05 22:23 UTC (permalink / raw) To: Rob Herring Cc: linux-arm-kernel, Santosh Shilimkar, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, Olof Johansson, linux-omap, Fabio Estevam On Tuesday 05 February 2013, Rob Herring wrote: > > > > + 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. Yes, I was wondering whether it should be global instead, but that would require an #ifdef, or enabling it for all DT-based builds, not just those with ARCH_MULTIPLATFORM. > > 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); > > 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. Yes, possible, but that needs more testing to avoid potential regressions. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-02-05 22:23 ` Arnd Bergmann 0 siblings, 0 replies; 57+ messages in thread From: Arnd Bergmann @ 2013-02-05 22:23 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 05 February 2013, Rob Herring wrote: > > > > + 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. Yes, I was wondering whether it should be global instead, but that would require an #ifdef, or enabling it for all DT-based builds, not just those with ARCH_MULTIPLATFORM. > > 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); > > 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. Yes, possible, but that needs more testing to avoid potential regressions. Arnd ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 17:51 ` Arnd Bergmann @ 2013-02-05 21:39 ` Olof Johansson -1 siblings, 0 replies; 57+ messages in thread From: Olof Johansson @ 2013-02-05 21:39 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Santosh Shilimkar, Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren, linux-omap, Fabio Estevam On Thu, Jan 31, 2013 at 9:51 AM, Arnd Bergmann <arnd@arndb.de> wrote: > 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 <arnd@arndb.de> Nice! Acked-by: Olof Johansson <olof@lixom.net> (Besides what Stephen already pointed out) -Olof ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform @ 2013-02-05 21:39 ` Olof Johansson 0 siblings, 0 replies; 57+ messages in thread From: Olof Johansson @ 2013-02-05 21:39 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jan 31, 2013 at 9:51 AM, Arnd Bergmann <arnd@arndb.de> wrote: > 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 <arnd@arndb.de> Nice! Acked-by: Olof Johansson <olof@lixom.net> (Besides what Stephen already pointed out) -Olof ^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH, RFC] default machine descriptor for multiplatform 2013-01-31 17:51 ` Arnd Bergmann ` (5 preceding siblings ...) (?) @ 2013-03-03 13:27 ` Rob Herring -1 siblings, 0 replies; 57+ messages in thread From: Rob Herring @ 2013-03-03 13:27 UTC (permalink / raw) To: linux-arm-kernel On 01/31/2013 11:51 AM, Arnd Bergmann wrote: > 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 <arnd@arndb.de> This breaks on !OF builds: arch/arm/kernel/setup.c:653:30: error: 'of_default_bus_match_table' undeclared (first use in this function) arch/arm/kernel/time.c:122:3: error: implicit declaration of function 'clocksource_of_init' [-Werror=implicit-function-declaration] And irqchip_init gives a linker error. All easily fixed, but what's your plan for this patch? I got patches for sp804, twd, and arch timers to use CLKSRC_OF and which can take advantage of this and remove the init_time machine ptrs. Rob > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3e3444e..8ff1d38 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 70f1bde..e6e34ba 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -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; > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index 8e4ef4c..df6f9a1 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -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 > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > index 3f6cbb2..1d40c9d 100644 > --- a/arch/arm/kernel/setup.c > +++ b/arch/arm/kernel/setup.c > @@ -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; > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c > index 955d92d..abff4e9 100644 > --- a/arch/arm/kernel/time.c > +++ b/arch/arm/kernel/time.c > @@ -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(); > } > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > index f496afc..c5e7a45 100644 > --- a/drivers/irqchip/irqchip.c > +++ b/drivers/irqchip/irqchip.c > @@ -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 > diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h > index 7944f14..b14d224 100644 > --- a/include/linux/clocksource.h > +++ b/include/linux/clocksource.h > @@ -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 > ^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2013-03-03 13:27 UTC | newest] Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-31 1:49 Failure to boot Russell King - ARM Linux 2013-01-31 1:49 ` Russell King - ARM Linux 2013-01-31 3:02 ` Olof Johansson 2013-01-31 3:02 ` Olof Johansson 2013-01-31 4:19 ` Nicolas Pitre 2013-01-31 4:19 ` Nicolas Pitre 2013-01-31 9:20 ` Russell King - ARM Linux 2013-01-31 9:20 ` Russell King - ARM Linux 2013-01-31 10:40 ` Russell King - ARM Linux 2013-01-31 10:40 ` Russell King - ARM Linux 2013-01-31 12:49 ` Santosh Shilimkar 2013-01-31 12:49 ` Santosh Shilimkar 2013-01-31 13:04 ` Russell King - ARM Linux 2013-01-31 13:04 ` Russell King - ARM Linux 2013-01-31 14:00 ` Santosh Shilimkar 2013-01-31 14:00 ` Santosh Shilimkar 2013-01-31 14:10 ` Santosh Shilimkar 2013-01-31 14:10 ` Santosh Shilimkar 2013-01-31 14:13 ` Russell King - ARM Linux 2013-01-31 14:13 ` Russell King - ARM Linux 2013-01-31 14:16 ` Russell King - ARM Linux 2013-01-31 14:16 ` Russell King - ARM Linux 2013-01-31 14:20 ` Santosh Shilimkar 2013-01-31 14:20 ` Santosh Shilimkar 2013-01-31 14:27 ` Russell King - ARM Linux 2013-01-31 14:27 ` Russell King - ARM Linux 2013-01-31 14:43 ` Santosh Shilimkar 2013-01-31 14:43 ` Santosh Shilimkar 2013-01-31 16:00 ` Tony Lindgren 2013-01-31 16:00 ` Tony Lindgren 2013-01-31 16:19 ` Russell King - ARM Linux 2013-01-31 16:19 ` Russell King - ARM Linux 2013-01-31 16:01 ` Fabio Estevam 2013-01-31 16:01 ` Fabio Estevam 2013-01-31 16:18 ` Russell King - ARM Linux 2013-01-31 16:18 ` Russell King - ARM Linux 2013-01-31 16:27 ` Arnd Bergmann 2013-01-31 16:27 ` Arnd Bergmann 2013-01-31 17:51 ` [PATCH, RFC] default machine descriptor for multiplatform Arnd Bergmann 2013-01-31 17:51 ` Arnd Bergmann 2013-01-31 18:52 ` Stephen Warren 2013-01-31 18:52 ` Stephen Warren 2013-01-31 20:57 ` Arnd Bergmann 2013-01-31 20:57 ` Arnd Bergmann 2013-01-31 20:34 ` Nicolas Pitre 2013-01-31 20:34 ` Nicolas Pitre 2013-02-01 11:47 ` Santosh Shilimkar 2013-02-01 11:47 ` Santosh Shilimkar 2013-02-01 12:34 ` Arnd Bergmann 2013-02-01 12:34 ` Arnd Bergmann 2013-02-05 21:37 ` Rob Herring 2013-02-05 21:37 ` Rob Herring 2013-02-05 22:23 ` Arnd Bergmann 2013-02-05 22:23 ` Arnd Bergmann 2013-02-05 21:39 ` Olof Johansson 2013-02-05 21:39 ` Olof Johansson 2013-03-03 13:27 ` Rob Herring
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.