[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.8.

----------------------------------------------------------------
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git defconfig

for you to fetch changes up to 9a32fd6529e90d1dde157d155ae8e3fca61c31f7:

  ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig (2012-10-15 10:23:59 +0900)

----------------------------------------------------------------
Kuninori Morimoto (2):
      ARM: shmobile: mackerel: defconfig update
      ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig

 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 arch/arm/configs/mackerel_defconfig        |   18 ++++++++++++++++--
 2 files changed, 17 insertions(+), 3 deletions(-)

[PATCH 1/2] ARM: shmobile: mackerel: defconfig update

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch enables following devices by default
 - I2C
 - HDMI
 - USB (host/gadget)
 - ALSA (FSI)
 - DMAEngine

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/mackerel_defconfig |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 306a2e2..7b79a0b 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -70,17 +70,31 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=8
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 # CONFIG_MFD_SUPPORT is not set
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SH_MOBILE_LCDC=y
+CONFIG_FB_SH_MOBILE_HDMI=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_CLUT224 is not set
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
+# CONFIG_SND_SUPPORT_OLD_API is not set
+# CONFIG_SND_VERBOSE_PROCFS is not set
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+CONFIG_SND_SOC_SH4_FSI=y
+CONFIG_USB=y
+CONFIG_USB_RENESAS_USBHS_HCD=y
+CONFIG_USB_RENESAS_USBHS=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_RENESAS_USBHS_UDC=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
-- 
1.7.10.4

[PATCH 2/2] ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index f78d259..a18593d 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -20,7 +20,7 @@ CONFIG_MACH_ARMADILLO800EVA=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_ARM_THUMB=y
 CONFIG_CPU_BPREDICT_DISABLE=y
-# CONFIG_CACHE_L2X0 is not set
+CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
-- 
1.7.10.4

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Wednesday 17 October 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following defconfig enhancements for 3.8.

These look good to me, but I wonder what happened to the plan to reduce
the number of defconfig files we discussed before. Since you can build
a combined kernel that runs on all (or most) of the supported boards,
can you add a combined shmobile_defconfig that is able to work on
a wide variety of hardware and drop some of the less common defconfig
files?

Most of the modern platforms nowadays have just one defconfig that
covers everything.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> On Wednesday 17 October 2012, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > please consider the following defconfig enhancements for 3.8.
> 
> These look good to me, but I wonder what happened to the plan to reduce
> the number of defconfig files we discussed before. Since you can build
> a combined kernel that runs on all (or most) of the supported boards,
> can you add a combined shmobile_defconfig that is able to work on
> a wide variety of hardware and drop some of the less common defconfig
> files?
> 
> Most of the modern platforms nowadays have just one defconfig that
> covers everything.

Hi Arnd,

I wonder if such consolidation only makes sense for boards that
make use of DT. If so, I can see that we may be able to come
up with a single configuration for the Armadillo800eva, KZM9G
and KZM9D boards. But not for older boards such as the Mackerel which
have not been converted to use DT.

I am also wondering if more of the drivers that SH Mobile uses need to
become DT aware before a consolidated configuration can work.  In
particular, I am thinking about the SCI serial driver and the location of
the serial port that can be used for serial console and early printk - this
features in the kernel command line of the per-board defconfigs and is
relied on by developers.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > On Wednesday 17 October 2012, Simon Horman wrote:
> > > Hi Olof, Hi Arnd,
> > > 
> > > please consider the following defconfig enhancements for 3.8.
> > 
> > These look good to me, but I wonder what happened to the plan to reduce
> > the number of defconfig files we discussed before. Since you can build
> > a combined kernel that runs on all (or most) of the supported boards,
> > can you add a combined shmobile_defconfig that is able to work on
> > a wide variety of hardware and drop some of the less common defconfig
> > files?
> > 
> > Most of the modern platforms nowadays have just one defconfig that
> > covers everything.
> 
> Hi Arnd,
> 
> I wonder if such consolidation only makes sense for boards that
> make use of DT. If so, I can see that we may be able to come
> up with a single configuration for the Armadillo800eva, KZM9G
> and KZM9D boards. But not for older boards such as the Mackerel which
> have not been converted to use DT.

Usually you should just be able to enable any boards together,
independent of whether they are using DT or not. It's possible
that shmobile does something different from the other platforms
that I'm not aware of, of course. If you look at e.g.
omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
all the available boards.

> I am also wondering if more of the drivers that SH Mobile uses need to
> become DT aware before a consolidated configuration can work.  In
> particular, I am thinking about the SCI serial driver and the location of
> the serial port that can be used for serial console and early printk - this
> features in the kernel command line of the per-board defconfigs and is
> relied on by developers.

Device drivers that don't use DT should get their configuration from
platform_data. The command line can be used to override those, but it's
also normally passed by the boot loader, which also has to configure
e.g. how much memory is present or which uart to use.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Thu, Oct 18, 2012 at 07:29:30AM +0000, Arnd Bergmann wrote:
> On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> > On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > > On Wednesday 17 October 2012, Simon Horman wrote:
> > > > Hi Olof, Hi Arnd,
> > > > 
> > > > please consider the following defconfig enhancements for 3.8.
> > > 
> > > These look good to me, but I wonder what happened to the plan to reduce
> > > the number of defconfig files we discussed before. Since you can build
> > > a combined kernel that runs on all (or most) of the supported boards,
> > > can you add a combined shmobile_defconfig that is able to work on
> > > a wide variety of hardware and drop some of the less common defconfig
> > > files?
> > > 
> > > Most of the modern platforms nowadays have just one defconfig that
> > > covers everything.
> > 
> > Hi Arnd,
> > 
> > I wonder if such consolidation only makes sense for boards that
> > make use of DT. If so, I can see that we may be able to come
> > up with a single configuration for the Armadillo800eva, KZM9G
> > and KZM9D boards. But not for older boards such as the Mackerel which
> > have not been converted to use DT.
> 
> Usually you should just be able to enable any boards together,
> independent of whether they are using DT or not. It's possible
> that shmobile does something different from the other platforms
> that I'm not aware of, of course. If you look at e.g.
> omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
> all the available boards.

Thanks, I'll see what I can do within the scope of the boards
that I have access to.

> > I am also wondering if more of the drivers that SH Mobile uses need to
> > become DT aware before a consolidated configuration can work.  In
> > particular, I am thinking about the SCI serial driver and the location of
> > the serial port that can be used for serial console and early printk - this
> > features in the kernel command line of the per-board defconfigs and is
> > relied on by developers.
> 
> Device drivers that don't use DT should get their configuration from
> platform_data. The command line can be used to override those, but it's
> also normally passed by the boot loader, which also has to configure
> e.g. how much memory is present or which uart to use.

Understood.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 07:29:30AM +0000, Arnd Bergmann wrote:
> > On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> > > On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > > > On Wednesday 17 October 2012, Simon Horman wrote:
> > > > > Hi Olof, Hi Arnd,
> > > > > 
> > > > > please consider the following defconfig enhancements for 3.8.
> > > > 
> > > > These look good to me, but I wonder what happened to the plan to reduce
> > > > the number of defconfig files we discussed before. Since you can build
> > > > a combined kernel that runs on all (or most) of the supported boards,
> > > > can you add a combined shmobile_defconfig that is able to work on
> > > > a wide variety of hardware and drop some of the less common defconfig
> > > > files?
> > > > 
> > > > Most of the modern platforms nowadays have just one defconfig that
> > > > covers everything.
> > > 
> > > Hi Arnd,
> > > 
> > > I wonder if such consolidation only makes sense for boards that
> > > make use of DT. If so, I can see that we may be able to come
> > > up with a single configuration for the Armadillo800eva, KZM9G
> > > and KZM9D boards. But not for older boards such as the Mackerel which
> > > have not been converted to use DT.
> > 
> > Usually you should just be able to enable any boards together,
> > independent of whether they are using DT or not. It's possible
> > that shmobile does something different from the other platforms
> > that I'm not aware of, of course. If you look at e.g.
> > omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
> > all the available boards.
> 
> Thanks, I'll see what I can do within the scope of the boards
> that I have access to.
> 
> > > I am also wondering if more of the drivers that SH Mobile uses need to
> > > become DT aware before a consolidated configuration can work.  In
> > > particular, I am thinking about the SCI serial driver and the location of
> > > the serial port that can be used for serial console and early printk - this
> > > features in the kernel command line of the per-board defconfigs and is
> > > relied on by developers.
> > 
> > Device drivers that don't use DT should get their configuration from
> > platform_data. The command line can be used to override those, but it's
> > also normally passed by the boot loader, which also has to configure
> > e.g. how much memory is present or which uart to use.
> 
> Understood.

I have made a limited amount of progress on this trying to create a
defconfig that will work on both the Marzen and Armadillo 800 EVA boards.

* Serial console appears to work, although for the Marzen at
  least enabling earlyprintk seems to require the bootloader to specify
  e.g.  console=ttySC2,115200 earlyprintk

  This is done by fully specifying bootargs in U-Boot.
  The boodloaders on the Marzen board has an ampty bootargs by default.

  I guess I can live without earlyprink by default,
  though it does seem to be a regression in the user experience.

* A more significant problem seems to be the use of CONFIG_MEMORY_START
  to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h

  I'm not sure that I see an easy way to get around this one.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Friday 19 October 2012, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> I have made a limited amount of progress on this trying to create a
> defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> 
> * Serial console appears to work, although for the Marzen at
>   least enabling earlyprintk seems to require the bootloader to specify
>   e.g.  console=ttySC2,115200 earlyprintk
> 
>   This is done by fully specifying bootargs in U-Boot.
>   The boodloaders on the Marzen board has an ampty bootargs by default.
>
>   I guess I can live without earlyprink by default,
>   though it does seem to be a regression in the user experience.

Right. So who is using the defconfig for these boards? Usually most
people using it actually have their own configuration files that are
tuned for their needs, and you often also need to change the command
line in order to configure the root partition etc.

> * A more significant problem seems to be the use of CONFIG_MEMORY_START
>   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> 
>   I'm not sure that I see an easy way to get around this one.

ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> On Friday 19 October 2012, Simon Horman wrote:
> > On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> > I have made a limited amount of progress on this trying to create a
> > defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> > 
> > * Serial console appears to work, although for the Marzen at
> >   least enabling earlyprintk seems to require the bootloader to specify
> >   e.g.  console=ttySC2,115200 earlyprintk
> > 
> >   This is done by fully specifying bootargs in U-Boot.
> >   The boodloaders on the Marzen board has an ampty bootargs by default.
> >
> >   I guess I can live without earlyprink by default,
> >   though it does seem to be a regression in the user experience.
> 
> Right. So who is using the defconfig for these boards? Usually most
> people using it actually have their own configuration files that are
> tuned for their needs, and you often also need to change the command
> line in order to configure the root partition etc.

I imagine they are primarily used by developers, like myself, but
to be honest I am unsure. Ideally I would like the defconfig to be as
useful as possible out of the box. But I agree that most users probably
end up making some customisations, e.g. to the location of the rootfs.

> > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > 
> >   I'm not sure that I see an easy way to get around this one.
> 
> ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

Thanks, I will look into that.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > On Friday 19 October 2012, Simon Horman wrote:
> > > On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> > > I have made a limited amount of progress on this trying to create a
> > > defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> > > 
> > > * Serial console appears to work, although for the Marzen at
> > >   least enabling earlyprintk seems to require the bootloader to specify
> > >   e.g.  console=ttySC2,115200 earlyprintk
> > > 
> > >   This is done by fully specifying bootargs in U-Boot.
> > >   The boodloaders on the Marzen board has an ampty bootargs by default.
> > >
> > >   I guess I can live without earlyprink by default,
> > >   though it does seem to be a regression in the user experience.
> > 
> > Right. So who is using the defconfig for these boards? Usually most
> > people using it actually have their own configuration files that are
> > tuned for their needs, and you often also need to change the command
> > line in order to configure the root partition etc.
> 
> I imagine they are primarily used by developers, like myself, but
> to be honest I am unsure. Ideally I would like the defconfig to be as
> useful as possible out of the box. But I agree that most users probably
> end up making some customisations, e.g. to the location of the rootfs.
> 
> > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > 
> > >   I'm not sure that I see an easy way to get around this one.
> > 
> > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

I believe that this leaves mach-shmobile with three areas
where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

* arch/arm/mach-shmobile/headsmp.S

  This uses PLAT_PHYS_OFFSET.

  I believe this can be replaced with a run-time calculation. Though I
  haven't thought about the details yet.

* arch/arm/boot/compressed/head-shmobile.S

  This makes use of CONFIG_MEMORY_START.

  This is only used if CONFIG_ZBOOT_ROM is set.

  I'm unsure if this can be replaced with a run-time calculation or not.
  But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
  the default at this time.


* arch/arm/mach-shmobile/Makefile.boot

 This makes use of CONFIG_MEMORY_START to set zreladdr.

 I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
 However, it is not yet clear to me how that can be used in conjunction
 with a uImage.  As I understand it the boot loader on many of our boards,
 including the Marzen board which is my first target for this work, boot
 uImage imagess.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

(adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)

On Monday 22 October 2012, Simon Horman wrote:
> On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > On Friday 19 October 2012, Simon Horman wrote:
> > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > 
> > > >   I'm not sure that I see an easy way to get around this one.
> > > 
> > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> 
> I believe that this leaves mach-shmobile with three areas
> where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

Hmm, I just noticed that in fact shmobile is the only remaining
platform that uses CONFIG_MEMORY_START with a per-board or per-soc
setting.

> * arch/arm/mach-shmobile/headsmp.S
> 
>   This uses PLAT_PHYS_OFFSET.
> 
>   I believe this can be replaced with a run-time calculation. Though I
>   haven't thought about the details yet.
> 
> * arch/arm/boot/compressed/head-shmobile.S
> 
>   This makes use of CONFIG_MEMORY_START.
> 
>   This is only used if CONFIG_ZBOOT_ROM is set.
> 
>   I'm unsure if this can be replaced with a run-time calculation or not.
>   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
>   the default at this time.

Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

> * arch/arm/mach-shmobile/Makefile.boot
> 
>  This makes use of CONFIG_MEMORY_START to set zreladdr.
> 
>  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
>  However, it is not yet clear to me how that can be used in conjunction
>  with a uImage.  As I understand it the boot loader on many of our boards,
>  including the Marzen board which is my first target for this work, boot
>  uImage imagess.

If this doesn't work, we probably also need to find a solution to
build multiple uImage files from the same vmlinux when building a
multiplatform kernel.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Nicolas Pitre]

On Mon, 22 Oct 2012, Arnd Bergmann wrote:

> (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
> 
> On Monday 22 October 2012, Simon Horman wrote:
> > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > > 
> > > > >   I'm not sure that I see an easy way to get around this one.
> > > > 
> > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> > 
> > I believe that this leaves mach-shmobile with three areas
> > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
> 
> Hmm, I just noticed that in fact shmobile is the only remaining
> platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> setting.
> 
> > * arch/arm/mach-shmobile/headsmp.S
> > 
> >   This uses PLAT_PHYS_OFFSET.
> > 
> >   I believe this can be replaced with a run-time calculation. Though I
> >   haven't thought about the details yet.

What about this (untested):

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index b202c12725..9293319fcb 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
 	mov	pc, lr
 ENDPROC(v7_invalidate_l1)
 
-ENTRY(shmobile_invalidate_start)
+ENTRY(shmobile_secondary_entry)
 	bl	v7_invalidate_l1
 	b	secondary_startup
-ENDPROC(shmobile_invalidate_start)
+ENDPROC(shmobile_secondary_entry)
 
 /*
  * Reset vector for secondary CPUs.
  * This will be mapped at address 0 by SBAR register.
  * We need _long_ jump to the physical address.
+ * the loaded address is initialized to the physical address of
+ * shmobile_secondary_entry
+ * in platform_secondary_init().
  */
+	.data
 	.align  12
+	.arm
 ENTRY(shmobile_secondary_vector)
 	ldr     pc, 1f
-1:	.long   shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
+1:	.long   0
 ENDPROC(shmobile_secondary_vector)
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index fde0d23121..356f82da16 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
 
 void __cpuinit platform_secondary_init(unsigned int cpu)
 {
+	long shmobile_secondary_address;
+
 	trace_hardirqs_off();
 
+	shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
+	*shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
+	__cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
+
 	if (is_sh73a0())
 		sh73a0_secondary_init(cpu);
 

> > * arch/arm/boot/compressed/head-shmobile.S
> > 
> >   This makes use of CONFIG_MEMORY_START.
> >   This is only used if CONFIG_ZBOOT_ROM is set.
> > 
> >   I'm unsure if this can be replaced with a run-time calculation or not.
> >   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> >   the default at this time.

This code is meant to be executed from ROM which means a very tailored 
kernel configuration.  In that case it makes little sense to have 
CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.

> Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

The right dependency would be CONFIG_AUTO_ZRELADDR, not 
ARM_PATCH_PHYS_VIRT.  The later concerns the final kernel image, not the 
decompressor.

> > * arch/arm/mach-shmobile/Makefile.boot
> > 
> >  This makes use of CONFIG_MEMORY_START to set zreladdr.
> > 
> >  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> >  However, it is not yet clear to me how that can be used in conjunction
> >  with a uImage.  As I understand it the boot loader on many of our boards,
> >  including the Marzen board which is my first target for this work, boot
> >  uImage imagess.
> 
> If this doesn't work, we probably also need to find a solution to
> build multiple uImage files from the same vmlinux when building a
> multiplatform kernel.

The right solution to the U-Boot problem is to remove uImage creation 
from the kernel entirely.  The U-Boot image format should be created at 
_installation_ time, not at build time.  The fact that the U-Boot image 
format is (or was until very recently) inflexible is not Linux's fault.

If the uImage build target is to remain in the kernel, it should be 
marked incompatible with a multi-arch config.  There is no point 
distributing a multi-arch kernel image when wrapped into a uImage 
format.


Nicolas

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Mon, Oct 22, 2012 at 02:20:31PM -0400, Nicolas Pitre wrote:
> On Mon, 22 Oct 2012, Arnd Bergmann wrote:
> 
> > (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
> > 
> > On Monday 22 October 2012, Simon Horman wrote:
> > > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > > > 
> > > > > >   I'm not sure that I see an easy way to get around this one.
> > > > > 
> > > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> > > 
> > > I believe that this leaves mach-shmobile with three areas
> > > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
> > 
> > Hmm, I just noticed that in fact shmobile is the only remaining
> > platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> > setting.
> > 
> > > * arch/arm/mach-shmobile/headsmp.S
> > > 
> > >   This uses PLAT_PHYS_OFFSET.
> > > 
> > >   I believe this can be replaced with a run-time calculation. Though I
> > >   haven't thought about the details yet.
> 
> What about this (untested):

Thanks. I have not managed to successfully test this yet,
but I think something like this is the right direction.
I will try and massage it into a working version.

> 
> diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
> index b202c12725..9293319fcb 100644
> --- a/arch/arm/mach-shmobile/headsmp.S
> +++ b/arch/arm/mach-shmobile/headsmp.S
> @@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
>  	mov	pc, lr
>  ENDPROC(v7_invalidate_l1)
>  
> -ENTRY(shmobile_invalidate_start)
> +ENTRY(shmobile_secondary_entry)
>  	bl	v7_invalidate_l1
>  	b	secondary_startup
> -ENDPROC(shmobile_invalidate_start)
> +ENDPROC(shmobile_secondary_entry)
>  
>  /*
>   * Reset vector for secondary CPUs.
>   * This will be mapped at address 0 by SBAR register.
>   * We need _long_ jump to the physical address.
> + * the loaded address is initialized to the physical address of
> + * shmobile_secondary_entry
> + * in platform_secondary_init().
>   */
> +	.data
>  	.align  12
> +	.arm
>  ENTRY(shmobile_secondary_vector)
>  	ldr     pc, 1f
> -1:	.long   shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +1:	.long   0
>  ENDPROC(shmobile_secondary_vector)
> diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
> index fde0d23121..356f82da16 100644
> --- a/arch/arm/mach-shmobile/platsmp.c
> +++ b/arch/arm/mach-shmobile/platsmp.c
> @@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
>  
>  void __cpuinit platform_secondary_init(unsigned int cpu)
>  {
> +	long shmobile_secondary_address;
> +
>  	trace_hardirqs_off();
>  
> +	shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
> +	*shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
> +	__cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
> +
>  	if (is_sh73a0())
>  		sh73a0_secondary_init(cpu);
>  
> 
> > > * arch/arm/boot/compressed/head-shmobile.S
> > > 
> > >   This makes use of CONFIG_MEMORY_START.
> > >   This is only used if CONFIG_ZBOOT_ROM is set.
> > > 
> > >   I'm unsure if this can be replaced with a run-time calculation or not.
> > >   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> > >   the default at this time.
> 
> This code is meant to be executed from ROM which means a very tailored 
> kernel configuration.  In that case it makes little sense to have 
> CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.

Agreed.

> > Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> > CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT
> 
> The right dependency would be CONFIG_AUTO_ZRELADDR, not 
> ARM_PATCH_PHYS_VIRT.  The later concerns the final kernel image, not the 
> decompressor.

Thanks.

> > > * arch/arm/mach-shmobile/Makefile.boot
> > > 
> > >  This makes use of CONFIG_MEMORY_START to set zreladdr.
> > > 
> > >  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> > >  However, it is not yet clear to me how that can be used in conjunction
> > >  with a uImage.  As I understand it the boot loader on many of our boards,
> > >  including the Marzen board which is my first target for this work, boot
> > >  uImage imagess.
> > 
> > If this doesn't work, we probably also need to find a solution to
> > build multiple uImage files from the same vmlinux when building a
> > multiplatform kernel.
> 
> The right solution to the U-Boot problem is to remove uImage creation 
> from the kernel entirely.  The U-Boot image format should be created at 
> _installation_ time, not at build time.  The fact that the U-Boot image 
> format is (or was until very recently) inflexible is not Linux's fault.
> 
> If the uImage build target is to remain in the kernel, it should be 
> marked incompatible with a multi-arch config.  There is no point 
> distributing a multi-arch kernel image when wrapped into a uImage 
> format.

I agree with you reasoning, and that in the long term removing uImage as a
target and having an install-time mechanism would be a nice goal. However,
I wonder what the way forward is. Provide install-scripts in the kernel
tree somewhere? Provide information on the start address under
Documentation/ somewhere?

While I am more than happy to help address the issues raised in this
thread, and others that arise. There do seem to be a number of issues
between where we are now and a more generic shmobile_defconfig. I would
like consideration given to allowing the exixting, working, well-maintained,
per-board defconfigs to be updated until these issues have been resolved.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Tuesday 30 October 2012, Simon Horman wrote:
> While I am more than happy to help address the issues raised in this
> thread, and others that arise. There do seem to be a number of issues
> between where we are now and a more generic shmobile_defconfig. I would
> like consideration given to allowing the exixting, working, well-maintained,
> per-board defconfigs to be updated until these issues have been resolved.

Yes, no problem. This seemed like a low-hanging fruit initially but has
turned into something much bigger now.

Instead of attacking all these at ones, we can leave them as something
worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.

Maybe it's possible to consolidate all or some of the others first, since
they should still work with the same uImage at the expense of just making
the early debugging a little harder, as we discussed earlier.

For all I know, these three boards are also the ones seeing the most
ongoing development, so you could start by using a shared defconfig
for the oldest (ARM11 based) boards at first that are also less likely
to impact new development starting from the defconfig.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Tue, Oct 30, 2012 at 09:41:27PM +0000, Arnd Bergmann wrote:
> On Tuesday 30 October 2012, Simon Horman wrote:
> > While I am more than happy to help address the issues raised in this
> > thread, and others that arise. There do seem to be a number of issues
> > between where we are now and a more generic shmobile_defconfig. I would
> > like consideration given to allowing the exixting, working, well-maintained,
> > per-board defconfigs to be updated until these issues have been resolved.
> 
> Yes, no problem. This seemed like a low-hanging fruit initially but has
> turned into something much bigger now.
> 
> Instead of attacking all these at ones, we can leave them as something
> worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
> only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.
> 
> Maybe it's possible to consolidate all or some of the others first, since
> they should still work with the same uImage at the expense of just making
> the early debugging a little harder, as we discussed earlier.
> 
> For all I know, these three boards are also the ones seeing the most
> ongoing development, so you could start by using a shared defconfig
> for the oldest (ARM11 based) boards at first that are also less likely
> to impact new development starting from the defconfig.

Thanks, good observations. I will look into that.

My expectation is that marzen and kzm9g will continue to see
heavy development in the near future.