[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Albin Tonnerre]

Nothing actually prevents support for boards based on these SoCs to be
compiled in the same kernel image, since the SAM9260 and SAM9G20 are
almost identical (AT91SAM9G20 adds some new features, but is otherwise
compatible with the AT91SAM9260).

Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
 arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index c015b68..d1eda58 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -26,8 +26,8 @@ config ARCH_AT91RM9200
 	select GENERIC_CLOCKEVENTS
 	select HAVE_AT91_USART3
 
-config ARCH_AT91SAM9260
-	bool "AT91SAM9260 or AT91SAM9XE"
+config ARCH_AT91SAM9260_VARIANTS
+	bool "AT91SAM9260 / AT91SAM9XE and AT91SAM9G20"
 	select CPU_ARM926T
 	select GENERIC_CLOCKEVENTS
 	select HAVE_AT91_USART3
@@ -61,15 +61,6 @@ config ARCH_AT91SAM9RL
 	select HAVE_AT91_USART3
 	select HAVE_FB_ATMEL
 
-config ARCH_AT91SAM9G20
-	bool "AT91SAM9G20"
-	select CPU_ARM926T
-	select GENERIC_CLOCKEVENTS
-	select HAVE_AT91_USART3
-	select HAVE_AT91_USART4
-	select HAVE_AT91_USART5
-	select HAVE_NET_MACB
-
 config ARCH_AT91SAM9G45
 	bool "AT91SAM9G45"
 	select CPU_ARM926T
@@ -193,15 +184,19 @@ endif
 
 # ----------------------------------------------------------
 
-if ARCH_AT91SAM9260
+if ARCH_AT91SAM9260_VARIANTS
 
-comment "AT91SAM9260 Variants"
+menu "AT91SAM9260 Variants"
 
-config ARCH_AT91SAM9260_SAM9XE
-	bool "AT91SAM9XE"
-	help
-	  Select this if you are using Atmel's AT91SAM9XE System-on-Chip.
-	  They are basically AT91SAM9260s with various sizes of embedded Flash.
+config ARCH_AT91SAM9260
+	bool "AT91SAM9260 / AT91SAM9XE"
+	default y
+
+config ARCH_AT91SAM9G20
+	bool "AT91SAM9G20"
+	default y
+
+endmenu
 
 comment "AT91SAM9260 / AT91SAM9XE Board Type"
 
-- 
1.7.2.3

[RFC 2/2] AT91: Update board-cpu9krea to support the 9260/9G20 variants in a single image

[Albin Tonnerre]

Since patch "Support SAM9260 and SAM9G20-based boards in the same kernel
image" makes it possible to support both types of SoCs, cpu9krea must be
updated to cope with that. Otherwise, selecting both the 9260 and 9G20
variants will result in only the 9260 variant being supported.

Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
 arch/arm/mach-at91/board-cpu9krea.c |   48 +++++++++++++++++++++++++++++------
 1 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-at91/board-cpu9krea.c b/arch/arm/mach-at91/board-cpu9krea.c
index 3838594..6d741bb 100644
--- a/arch/arm/mach-at91/board-cpu9krea.c
+++ b/arch/arm/mach-at91/board-cpu9krea.c
@@ -38,6 +38,7 @@
 #include <asm/mach/map.h>
 #include <asm/mach/irq.h>
 
+#include <mach/cpu.h>
 #include <mach/hardware.h>
 #include <mach/board.h>
 #include <mach/gpio.h>
@@ -120,7 +121,7 @@ static struct atmel_nand_data __initdata cpu9krea_nand_data = {
 };
 
 #ifdef CONFIG_MACH_CPU9260
-static struct sam9_smc_config __initdata cpu9krea_nand_smc_config = {
+static struct sam9_smc_config __initdata cpu9krea_9260_nand_smc_config = {
 	.ncs_read_setup		= 0,
 	.nrd_setup		= 1,
 	.ncs_write_setup	= 0,
@@ -138,8 +139,13 @@ static struct sam9_smc_config __initdata cpu9krea_nand_smc_config = {
 		| AT91_SMC_EXNWMODE_DISABLE | AT91_SMC_DBW_8,
 	.tdf_cycles		= 2,
 };
+#define CPU9KREA_9260_NAND_CFG (&cpu9krea_9260_nand_smc_config)
 #else
-static struct sam9_smc_config __initdata cpu9krea_nand_smc_config = {
+#define CPU9KREA_9260_NAND_CFG NULL
+#endif
+
+#ifdef CONFIG_MACH_CPU9G20
+static struct sam9_smc_config __initdata cpu9krea_9g20_nand_smc_config = {
 	.ncs_read_setup		= 0,
 	.nrd_setup		= 2,
 	.ncs_write_setup	= 0,
@@ -157,11 +163,17 @@ static struct sam9_smc_config __initdata cpu9krea_nand_smc_config = {
 		| AT91_SMC_EXNWMODE_DISABLE | AT91_SMC_DBW_8,
 	.tdf_cycles		= 3,
 };
+#define CPU9KREA_9G20_NAND_CFG (&cpu9krea_9g20_nand_smc_config)
+#else
+#define CPU9KREA_9G20_NAND_CFG NULL
 #endif
 
 static void __init cpu9krea_add_device_nand(void)
 {
-	sam9_smc_configure(3, &cpu9krea_nand_smc_config);
+	if (cpu_is_at91sam9260())
+		sam9_smc_configure(3, CPU9KREA_9260_NAND_CFG);
+	else
+		sam9_smc_configure(3, CPU9KREA_9G20_NAND_CFG);
 	at91_add_device_nand(&cpu9krea_nand_data);
 }
 
@@ -194,7 +206,7 @@ static struct platform_device cpu9krea_nor_flash = {
 };
 
 #ifdef CONFIG_MACH_CPU9260
-static struct sam9_smc_config __initdata cpu9krea_nor_smc_config = {
+static struct sam9_smc_config __initdata cpu9krea_9260_nor_smc_config = {
 	.ncs_read_setup		= 0,
 	.nrd_setup		= 1,
 	.ncs_write_setup	= 0,
@@ -213,8 +225,13 @@ static struct sam9_smc_config __initdata cpu9krea_nor_smc_config = {
 			| AT91_SMC_DBW_16,
 	.tdf_cycles		= 2,
 };
+#define CPU9KREA_9260_NOR_CFG (&cpu9krea_9260_nor_smc_config)
 #else
-static struct sam9_smc_config __initdata cpu9krea_nor_smc_config = {
+#define CPU9KREA_9260_NOR_CFG NULL
+#endif
+
+#ifdef CONFIG_MACH_CPU9G20
+static struct sam9_smc_config __initdata cpu9krea_9g20_nor_smc_config = {
 	.ncs_read_setup		= 0,
 	.nrd_setup		= 1,
 	.ncs_write_setup	= 0,
@@ -233,6 +250,9 @@ static struct sam9_smc_config __initdata cpu9krea_nor_smc_config = {
 			| AT91_SMC_DBW_16,
 	.tdf_cycles		= 2,
 };
+#define CPU9KREA_9G20_NOR_CFG (&cpu9krea_9g20_nor_smc_config)
+#else
+#define CPU9KREA_9G20_NOR_CFG NULL
 #endif
 
 static __init void cpu9krea_add_device_nor(void)
@@ -243,7 +263,10 @@ static __init void cpu9krea_add_device_nor(void)
 	at91_sys_write(AT91_MATRIX_EBICSA, csa | AT91_MATRIX_VDDIOMSEL_3_3V);
 
 	/* configure chip-select 0 (NOR) */
-	sam9_smc_configure(0, &cpu9krea_nor_smc_config);
+	if (cpu_is_at91sam9260())
+		sam9_smc_configure(0, CPU9KREA_9260_NOR_CFG);
+	else
+		sam9_smc_configure(0, CPU9KREA_9G20_NOR_CFG);
 
 	platform_device_register(&cpu9krea_nor_flash);
 }
@@ -371,9 +394,17 @@ static void __init cpu9krea_board_init(void)
 
 #ifdef CONFIG_MACH_CPU9260
 MACHINE_START(CPUAT9260, "Eukrea CPU9260")
-#else
-MACHINE_START(CPUAT9G20, "Eukrea CPU9G20")
+	/* Maintainer: Eric Benard - EUKREA Electromatique */
+	.boot_params	= AT91_SDRAM_BASE + 0x100,
+	.timer		= &at91sam926x_timer,
+	.map_io		= cpu9krea_map_io,
+	.init_irq	= cpu9krea_init_irq,
+	.init_machine	= cpu9krea_board_init,
+MACHINE_END
 #endif
+
+#ifdef CONFIG_MACH_CPU9G20
+MACHINE_START(CPUAT9G20, "Eukrea CPU9G20")
 	/* Maintainer: Eric Benard - EUKREA Electromatique */
 	.boot_params	= AT91_SDRAM_BASE + 0x100,
 	.timer		= &at91sam926x_timer,
@@ -381,3 +412,4 @@ MACHINE_START(CPUAT9G20, "Eukrea CPU9G20")
 	.init_irq	= cpu9krea_init_irq,
 	.init_machine	= cpu9krea_board_init,
 MACHINE_END
+#endif
-- 
1.7.2.3

[RFC 2/2] AT91: Update board-cpu9krea to support the 9260/9G20 variants in a single image

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:50 Sat 15 Jan     , Albin Tonnerre wrote:
> Since patch "Support SAM9260 and SAM9G20-based boards in the same kernel
> image" makes it possible to support both types of SoCs, cpu9krea must be
> updated to cope with that. Otherwise, selecting both the 9260 and 9G20
> variants will result in only the 9260 variant being supported.
> 
> Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> ---
do you really need 2 machine id?

Best Regards,
J.

[RFC 2/2] AT91: Update board-cpu9krea to support the 9260/9G20 variants in a single image

[Eric Bénard]

Hi Jean-Christophe,

On 17/01/2011 08:50, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:50 Sat 15 Jan     , Albin Tonnerre wrote:
>> Since patch "Support SAM9260 and SAM9G20-based boards in the same kernel
>> image" makes it possible to support both types of SoCs, cpu9krea must be
>> updated to cope with that. Otherwise, selecting both the 9260 and 9G20
>> variants will result in only the 9260 variant being supported.
>>
>> Signed-off-by: Albin Tonnerre<albin.tonnerre@free-electrons.com>
>> ---
> do you really need 2 machine id?
>
this was needed when 9260 & 9G20 were not merged.
Please if you change our platform files keep the 2 machine ID else that will 
break upgrade path on existing machines.

Thanks,
Eric

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:50 Sat 15 Jan     , Albin Tonnerre wrote:
> Nothing actually prevents support for boards based on these SoCs to be
> compiled in the same kernel image, since the SAM9260 and SAM9G20 are
> almost identical (AT91SAM9G20 adds some new features, but is otherwise
> compatible with the AT91SAM9260).
> 
> Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> ---
>  arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
>  1 files changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index c015b68..d1eda58 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -26,8 +26,8 @@ config ARCH_AT91RM9200
>  	select GENERIC_CLOCKEVENTS
>  	select HAVE_AT91_USART3
>  
> -config ARCH_AT91SAM9260
> -	bool "AT91SAM9260 or AT91SAM9XE"
> +config ARCH_AT91SAM9260_VARIANTS
sos so

I'm working on a similar patch but ARCH_AT91SAM9260_VARIANTS seems so so

I get in mind to get rid of ARCH_AT91SAM92G20

and detect it

Best Regards,
J.

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Albin Tonnerre]

On Mon, 17 Jan 2011 08:57 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote :
> On 18:50 Sat 15 Jan     , Albin Tonnerre wrote:
> > Nothing actually prevents support for boards based on these SoCs to be
> > compiled in the same kernel image, since the SAM9260 and SAM9G20 are
> > almost identical (AT91SAM9G20 adds some new features, but is otherwise
> > compatible with the AT91SAM9260).
> > 
> > Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> > ---
> >  arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
> >  1 files changed, 13 insertions(+), 18 deletions(-)
> > 
> > diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> > index c015b68..d1eda58 100644
> > --- a/arch/arm/mach-at91/Kconfig
> > +++ b/arch/arm/mach-at91/Kconfig
> > @@ -26,8 +26,8 @@ config ARCH_AT91RM9200
> >  	select GENERIC_CLOCKEVENTS
> >  	select HAVE_AT91_USART3
> >  
> > -config ARCH_AT91SAM9260
> > -	bool "AT91SAM9260 or AT91SAM9XE"
> > +config ARCH_AT91SAM9260_VARIANTS
> sos so
> 
> I'm working on a similar patch but ARCH_AT91SAM9260_VARIANTS seems so so
> 
> I get in mind to get rid of ARCH_AT91SAM92G20
> 
> and detect it

I'm sorry, I can't quite parse your answer. Would you please mind elaborating a
bit?

Cheers,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:00 Tue 18 Jan     , Albin Tonnerre wrote:
> On Mon, 17 Jan 2011 08:57 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote :
> > On 18:50 Sat 15 Jan     , Albin Tonnerre wrote:
> > > Nothing actually prevents support for boards based on these SoCs to be
> > > compiled in the same kernel image, since the SAM9260 and SAM9G20 are
> > > almost identical (AT91SAM9G20 adds some new features, but is otherwise
> > > compatible with the AT91SAM9260).
> > > 
> > > Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> > > ---
> > >  arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
> > >  1 files changed, 13 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> > > index c015b68..d1eda58 100644
> > > --- a/arch/arm/mach-at91/Kconfig
> > > +++ b/arch/arm/mach-at91/Kconfig
> > > @@ -26,8 +26,8 @@ config ARCH_AT91RM9200
> > >  	select GENERIC_CLOCKEVENTS
> > >  	select HAVE_AT91_USART3
> > >  
> > > -config ARCH_AT91SAM9260
> > > -	bool "AT91SAM9260 or AT91SAM9XE"
> > > +config ARCH_AT91SAM9260_VARIANTS
> > sos so
> > 
> > I'm working on a similar patch but ARCH_AT91SAM9260_VARIANTS seems so so
> > 
> > I get in mind to get rid of ARCH_AT91SAM92G20
> > 
> > and detect it
> 
> I'm sorry, I can't quite parse your answer. Would you please mind elaborating a
> bit?
this idea is to do not have CONFIG_ARCH_AT91SAM9G20 anymore only 9260

and detect it

but the man issue is the CLOCK_TICK_RATE which is different between both of
them except if we use a common one for those soc or the sam9/11 we could not
put them in the same kernel

so we need to fix this first

Best Regards,
J.

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Russell King - ARM Linux]

On Tue, Jan 18, 2011 at 04:00:30PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> this idea is to do not have CONFIG_ARCH_AT91SAM9G20 anymore only 9260
> 
> and detect it
> 
> but the man issue is the CLOCK_TICK_RATE which is different between both of
> them except if we use a common one for those soc or the sam9/11 we could not
> put them in the same kernel

If you switch to clocksource/clockevents, then I think CLOCK_TICK_RATE
is irrelevant as time advances according to the interval measured by
the previous and current clocksource read, rather than 1/HZ intervals.

However, I'm never happy to say "just set CLOCK_TICK_RATE to some random
value that's a multiple of HZ" because I can't convince myself that these
don't have any effect when using clocksources.  The list of symbols which
depend on CLOCK_TICK_RATE are:

ACTHZ
LATCH
TICK_NSEC
TICK_USEC_TO_NSEC
LOW_RES_NSEC
MONOTONIC_RES_NSEC
NSEC_PER_JIFFY
KTIME_LOW_RES

and if you grep for those outside of arch/, you find them being used in
a fair amount of code under kernel/, as well as the odd driver here and
there.

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Gilles Chanteperdrix]

Russell King - ARM Linux wrote:
> On Tue, Jan 18, 2011 at 04:00:30PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> this idea is to do not have CONFIG_ARCH_AT91SAM9G20 anymore only 9260
>>
>> and detect it
>>
>> but the man issue is the CLOCK_TICK_RATE which is different between both of
>> them except if we use a common one for those soc or the sam9/11 we could not
>> put them in the same kernel
> 
> If you switch to clocksource/clockevents, then I think CLOCK_TICK_RATE
> is irrelevant as time advances according to the interval measured by
> the previous and current clocksource read, rather than 1/HZ intervals.
> 
> However, I'm never happy to say "just set CLOCK_TICK_RATE to some random
> value that's a multiple of HZ" because I can't convince myself that these
> don't have any effect when using clocksources.  The list of symbols which
> depend on CLOCK_TICK_RATE are:
> 
> ACTHZ
> LATCH
> TICK_NSEC
> TICK_USEC_TO_NSEC
> LOW_RES_NSEC
> MONOTONIC_RES_NSEC
> NSEC_PER_JIFFY
> KTIME_LOW_RES
> 
> and if you grep for those outside of arch/, you find them being used in
> a fair amount of code under kernel/, as well as the odd driver here and
> there.

at91rm9200_time.c even seems to use LATCH, even though the clockevent
frequency is not explicitly set to CLOCK_TICK_RATE.

-- 
                                                                Gilles.

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Russell King - ARM Linux]

On Tue, Jan 18, 2011 at 06:18:14PM +0100, Gilles Chanteperdrix wrote:
> Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:00:30PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> this idea is to do not have CONFIG_ARCH_AT91SAM9G20 anymore only 9260
> >>
> >> and detect it
> >>
> >> but the man issue is the CLOCK_TICK_RATE which is different between both of
> >> them except if we use a common one for those soc or the sam9/11 we could not
> >> put them in the same kernel
> > 
> > If you switch to clocksource/clockevents, then I think CLOCK_TICK_RATE
> > is irrelevant as time advances according to the interval measured by
> > the previous and current clocksource read, rather than 1/HZ intervals.
> > 
> > However, I'm never happy to say "just set CLOCK_TICK_RATE to some random
> > value that's a multiple of HZ" because I can't convince myself that these
> > don't have any effect when using clocksources.  The list of symbols which
> > depend on CLOCK_TICK_RATE are:
> > 
> > ACTHZ
> > LATCH
> > TICK_NSEC
> > TICK_USEC_TO_NSEC
> > LOW_RES_NSEC
> > MONOTONIC_RES_NSEC
> > NSEC_PER_JIFFY
> > KTIME_LOW_RES
> > 
> > and if you grep for those outside of arch/, you find them being used in
> > a fair amount of code under kernel/, as well as the odd driver here and
> > there.
> 
> at91rm9200_time.c even seems to use LATCH, even though the clockevent
> frequency is not explicitly set to CLOCK_TICK_RATE.

Well, it seems I'm not entirely right - some things only advance one
tick:

void tick_handle_periodic(struct clock_event_device *dev)
{
        int cpu = smp_processor_id();
        ktime_t next;

        tick_periodic(cpu);

...
static void tick_periodic(int cpu)
{
        if (tick_do_timer_cpu == cpu) {
                write_seqlock(&xtime_lock);

                /* Keep track of the next tick event */
                tick_next_period = ktime_add(tick_next_period, tick_period);

                do_timer(1);
                write_sequnlock(&xtime_lock);
        }

        update_process_times(user_mode(get_irq_regs()));
        profile_tick(CPU_PROFILING);
}

void do_timer(unsigned long ticks)
{
        jiffies_64 += ticks;
        update_wall_time();
        calc_global_load(ticks);
}

but update_wall_time() will advance by the delta between the last
clocksource read and the current clocksource read:

void update_wall_time(void)
{
        clock = timekeeper.clock;

#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
        offset = timekeeper.cycle_interval;
#else
        offset = (clock->read(clock) - clock->cycle_last) & clock->mask;
#endif

and it then uses 'offset' to adjust current time.

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:18 Tue 18 Jan     , Gilles Chanteperdrix wrote:
> Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:00:30PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> this idea is to do not have CONFIG_ARCH_AT91SAM9G20 anymore only 9260
> >>
> >> and detect it
> >>
> >> but the man issue is the CLOCK_TICK_RATE which is different between both of
> >> them except if we use a common one for those soc or the sam9/11 we could not
> >> put them in the same kernel
> > 
> > If you switch to clocksource/clockevents, then I think CLOCK_TICK_RATE
> > is irrelevant as time advances according to the interval measured by
> > the previous and current clocksource read, rather than 1/HZ intervals.
> > 
> > However, I'm never happy to say "just set CLOCK_TICK_RATE to some random
> > value that's a multiple of HZ" because I can't convince myself that these
> > don't have any effect when using clocksources.  The list of symbols which
> > depend on CLOCK_TICK_RATE are:
> > 
> > ACTHZ
> > LATCH
> > TICK_NSEC
> > TICK_USEC_TO_NSEC
> > LOW_RES_NSEC
> > MONOTONIC_RES_NSEC
> > NSEC_PER_JIFFY
> > KTIME_LOW_RES
> > 
> > and if you grep for those outside of arch/, you find them being used in
> > a fair amount of code under kernel/, as well as the odd driver here and
> > there.
> 
> at91rm9200_time.c even seems to use LATCH, even though the clockevent
> frequency is not explicitly set to CLOCK_TICK_RATE.
we can fix it but the main idea is to allow the sam9/11 to be compiled
together in the same kernel
and the rm9200 is not a arm926ejs but a arm920t.

So the issue is not really important for this possiblity

Best Regards,
J.

[RFC 1/2] AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

[Russell King - ARM Linux]

On Tue, Jan 18, 2011 at 07:52:32PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> we can fix it but the main idea is to allow the sam9/11 to be compiled
> together in the same kernel
> and the rm9200 is not a arm926ejs but a arm920t.

The CPU type really doesn't matter.  We already have had fully working
core support for dynamic CPU selection since well before AT91 ever
appeared, covering ARMv3 to ARMv5, and separately ARMv6 to ARMv7 UP
(*not* SMP - until a set of fixes for that area merged).

The question is whether the code for the SoC bits around the CPU can
be structured to allow it.