AT91: Support SAM9260 and SAM9G20-based boards in the same kernel image

RFC New Albin Tonnerre 5 participants 12 messages Jan 15, 2011 – Jan 18, 2011

Subsystems (3)

Arm (32-bit) Arm sub-architectures Arm/Microchip (AT91) SoC support

lore

Share & tools

lore

Albin Tonnerre

author

2011-01-15 17:50 UTC #0 lore raw

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

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 <[email protected]>

---
 arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)

arch/arm/mach-at91/Kconfig +13 ~~-18~~

index c015b68..d1eda58 100644
@@ -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"

Signature · 1 line

1.7.2.3

Albin Tonnerre

author

2011-01-15 17:50 UTC #1 lore raw

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

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 <[email protected]>

---
 arch/arm/mach-at91/board-cpu9krea.c |   48 +++++++++++++++++++++++++++++------
 1 files changed, 40 insertions(+), 8 deletions(-)

arch/arm/mach-at91/board-cpu9krea.c +40 -8

index 3838594..6d741bb 100644
@@ -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

Signature · 1 line

1.7.2.3

Jean-Christophe PLAGNIOL-VILLARD

2011-01-17 07:50 UTC #2 lore raw

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

Quoted 7 lines · 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 <[email protected]>
---

do you really need 2 machine id?

Best Regards,
J.

Eric Bénard

2011-01-17 09:02 UTC #3 lore raw

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

Hi Jean-Christophe,

Quoted 10 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 7 lines · 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<[email protected]>
---
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

Jean-Christophe PLAGNIOL-VILLARD

2011-01-17 07:57 UTC #4 lore raw

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

In reply to Albin Tonnerre

Quoted 15 lines · 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 <[email protected]>
---
 arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)
arch/arm/mach-at91/Kconfig +0 -0
index c015b68..d1eda58 100644

arch/arm/mach-at91/Kconfig config ARCH_AT91RM9200 · line 29

Quoted 6 lines

arch/arm/mach-at91/Kconfig +1 -2

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

Albin Tonnerre

author

2011-01-18 07:00 UTC #5 lore raw

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

Quoted 24 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 15 lines · 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 <[email protected]>
---
 arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)
arch/arm/mach-at91/Kconfig +0 -0
index c015b68..d1eda58 100644
arch/arm/mach-at91/Kconfig config ARCH_AT91RM9200 · line 29
Quoted 6 lines
arch/arm/mach-at91/Kconfig +1 -2
@@ -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

Quoted 5 lines

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,

Signature · 4 lines

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

Jean-Christophe PLAGNIOL-VILLARD

2011-01-18 15:00 UTC #6 lore raw

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

Quoted 25 lines · Albin Tonnerre

Quoted 24 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 15 lines · 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 <[email protected]>
---
 arch/arm/mach-at91/Kconfig |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)
arch/arm/mach-at91/Kconfig +0 -0
index c015b68..d1eda58 100644
arch/arm/mach-at91/Kconfig config ARCH_AT91RM9200 · line 29
Quoted 6 lines
arch/arm/mach-at91/Kconfig +1 -2
@@ -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

Quoted 8 lines

Quoted 5 lines
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.

Russell King - ARM Linux

2011-01-18 15:32 UTC #7 lore raw

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

Quoted 7 lines · Jean-Christophe PLAGNIOL-VILLARD

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.

Gilles Chanteperdrix

2011-01-18 17:18 UTC #8 lore raw

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

Quoted 27 lines · Russell King - ARM Linux

Quoted 7 lines · Jean-Christophe PLAGNIOL-VILLARD
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

Quoted 3 lines

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.

Signature · 1 line

                                                                Gilles.

Russell King - ARM Linux

2011-01-18 17:43 UTC #9 lore raw

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

Quoted 28 lines · Gilles Chanteperdrix

Quoted 27 lines · Russell King - ARM Linux
Quoted 7 lines · Jean-Christophe PLAGNIOL-VILLARD
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

Quoted 6 lines

Quoted 3 lines
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.

Jean-Christophe PLAGNIOL-VILLARD

2011-01-18 18:52 UTC #10 lore raw

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

In reply to Gilles Chanteperdrix

Quoted 28 lines · Gilles Chanteperdrix

Quoted 27 lines · Russell King - ARM Linux
Quoted 7 lines · Jean-Christophe PLAGNIOL-VILLARD
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

Quoted 6 lines

Quoted 3 lines
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.

Russell King - ARM Linux

2011-01-18 19:35 UTC #11 lore raw

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

Quoted 3 lines · Jean-Christophe PLAGNIOL-VILLARD

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.