Failure to boot...

Failure to boot...

[Russell King - ARM Linux]

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.

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Olof Johansson]

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

Failure to boot...

[Olof Johansson]

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

Re: Failure to boot...

[Nicolas Pitre]

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

Failure to boot...

[Nicolas Pitre]

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

Re: Failure to boot...

[Russell King - ARM Linux]

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.

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Russell King - ARM Linux]

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.

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Santosh Shilimkar]

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

Failure to boot...

[Santosh Shilimkar]

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

Re: Failure to boot...

[Russell King - ARM Linux]

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

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Santosh Shilimkar]

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

Failure to boot...

[Santosh Shilimkar]

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

Re: Failure to boot...

[Santosh Shilimkar]

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

Failure to boot...

[Santosh Shilimkar]

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

Re: Failure to boot...

[Russell King - ARM Linux]

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.

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Russell King - ARM Linux]

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...

Failure to boot...

[Russell King - ARM Linux]

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...

Re: Failure to boot...

[Santosh Shilimkar]

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

Failure to boot...

[Santosh Shilimkar]

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

Re: Failure to boot...

[Russell King - ARM Linux]

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.

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Santosh Shilimkar]

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

Failure to boot...

[Santosh Shilimkar]

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

Re: Failure to boot...

[Tony Lindgren]

* 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

Failure to boot...

[Tony Lindgren]

* 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

Re: Failure to boot...

[Fabio Estevam]

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/

Failure to boot...

[Fabio Estevam]

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/

Re: Failure to boot...

[Russell King - ARM Linux]

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...

Failure to boot...

[Russell King - ARM Linux]

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...

Re: Failure to boot...

[Russell King - ARM Linux]

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.

Failure to boot...

[Russell King - ARM Linux]

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.

Re: Failure to boot...

[Arnd Bergmann]

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

Failure to boot...

[Arnd Bergmann]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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 */

[PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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 */

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Stephen Warren]

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.

[PATCH, RFC] default machine descriptor for multiplatform

[Stephen Warren]

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.

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Nicolas Pitre]

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 */
> 

[PATCH, RFC] default machine descriptor for multiplatform

[Nicolas Pitre]

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 */
> 

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Santosh Shilimkar]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Santosh Shilimkar]

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

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Rob Herring]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Rob Herring]

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

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Olof Johansson]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Olof Johansson]

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

Re: [PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Arnd Bergmann]

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

[PATCH, RFC] default machine descriptor for multiplatform

[Rob Herring]

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
>