| Message ID | 1411324904-14881-2-git-send-email-linux@rempel-privat.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sunday 21 September 2014 20:41:37 Oleksij Rempel wrote: > it is low cost (?) SoC targeted for market in China and India which > trying to compete with AT91SAM9G25. > > Here is some info: > http://www.alphascale.com/index.asp?ics/615.html > > One of products: > http://www.aliexpress.com/store/product/2014-hot-sales-FREE-SHIPPING-new-Purple-core-ARM9-development-board-ASM9260T-SDRAM-power-line/433637_1931495721.html > > Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Thanks for the submission! It looks pretty good, but has one main mistake in being incompatible with ARCH_MULTIPLATFORM. I think that should be easy to fix. There are also a few minor issues that can be improved. > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 5918d40..1a71feb 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -379,6 +379,20 @@ config ARCH_AT91 > This enables support for systems based on Atmel > AT91RM9200 and AT91SAM9* processors. > > +config MACH_ASM9260 > + bool "Alphascale ASM9260" > + select ARCH_REQUIRE_GPIOLIB > + select COMMON_CLK > + select IRQ_DOMAIN > + select SPARSE_IRQ > + select MULTI_IRQ_HANDLER > + select GENERIC_IRQ_CHIP > + select GENERIC_CLOCKEVENTS > + select CLKSRC_MMIO > + select CPU_ARM926T > + help > + Support for Alpascale ASM9260 based platform. To enable multiplatform support, please move this to its own arch/arm/mach-asm9260/Kconfig file and make it depend on ARCH_MULTI_V5, then remove all 'select' statements that are implicitly enabled there already (most of the above). > diff --git a/arch/arm/mach-asm9260/Makefile b/arch/arm/mach-asm9260/Makefile > new file mode 100644 > index 0000000..4bd8ebd > --- /dev/null > +++ b/arch/arm/mach-asm9260/Makefile > @@ -0,0 +1,11 @@ > +# > +# Makefile for the linux kernel. > +# > + > +# Object file lists. > + > +obj-y := core.o > +obj-m := > +obj-n := > +obj- := You can remove most of these and just leave the one line. > diff --git a/arch/arm/mach-asm9260/Makefile.boot b/arch/arm/mach-asm9260/Makefile.boot > new file mode 100644 > index 0000000..c57b3b4 > --- /dev/null > +++ b/arch/arm/mach-asm9260/Makefile.boot > @@ -0,0 +1,2 @@ > +zreladdr-y := 0x20008000 This file should be removed, nowadays we use AUTO_ZRELADDR, which is implied by multiplatform. > +static struct map_desc asm9260_io_desc[] __initdata = { > + { /* IO space */ > + .virtual = (unsigned long)0xf0000000, > + .pfn = __phys_to_pfn(0x80000000), > + .length = 0x00800000, > + .type = MT_DEVICE > + }, > + { /* LCD IO space */ > + .virtual = (unsigned long)0xf0a00000, > + .pfn = __phys_to_pfn(0x80800000), > + .length = 0x00009000, > + .type = MT_DEVICE > + }, > + { /* GPIO IO space */ > + .virtual = (unsigned long)0xf0800000, > + .pfn = __phys_to_pfn(0x50000000), > + .length = 0x00100000, > + .type = MT_DEVICE > + }, > + { /* SRAM space Cacheable */ > + .virtual = (unsigned long)0xd0000000, > + .pfn = __phys_to_pfn(0x40000000), > + .length = 0x00100000, > +#ifdef CONFIG_SRAM_MEM_CACHED > + .type = MT_MEMORY > +#else > + .type = MT_DEVICE > +#endif > + }, > +}; This should not be necessary, as all drivers are supposed to ioremap their own device registers. For large register ranges that are used a lot, you could use these as an optimization to get 1 MB sections mapped using a large TLB entry, but usually the benefit is very small. > +static void __init asm9260_init(void) > +{ > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} When you don't do anything else in the init_machine callback, you can remove it entirely. Arnd
Am 22.09.2014 um 17:08 schrieb Arnd Bergmann: > On Sunday 21 September 2014 20:41:37 Oleksij Rempel wrote: >> it is low cost (?) SoC targeted for market in China and India which >> trying to compete with AT91SAM9G25. >> >> Here is some info: >> http://www.alphascale.com/index.asp?ics/615.html >> >> One of products: >> http://www.aliexpress.com/store/product/2014-hot-sales-FREE-SHIPPING-new-Purple-core-ARM9-development-board-ASM9260T-SDRAM-power-line/433637_1931495721.html >> >> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> > > Thanks for the submission! It looks pretty good, but has one main mistake > in being incompatible with ARCH_MULTIPLATFORM. I think that should be easy > to fix. There are also a few minor issues that can be improved. > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 5918d40..1a71feb 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -379,6 +379,20 @@ config ARCH_AT91 >> This enables support for systems based on Atmel >> AT91RM9200 and AT91SAM9* processors. >> >> +config MACH_ASM9260 >> + bool "Alphascale ASM9260" >> + select ARCH_REQUIRE_GPIOLIB >> + select COMMON_CLK >> + select IRQ_DOMAIN >> + select SPARSE_IRQ >> + select MULTI_IRQ_HANDLER >> + select GENERIC_IRQ_CHIP >> + select GENERIC_CLOCKEVENTS >> + select CLKSRC_MMIO >> + select CPU_ARM926T >> + help >> + Support for Alpascale ASM9260 based platform. > > To enable multiplatform support, please move this to its own > arch/arm/mach-asm9260/Kconfig file and make it depend on ARCH_MULTI_V5, > then remove all 'select' statements that are implicitly enabled there > already (most of the above). Should they be only in defconfig or selected by driver? >> diff --git a/arch/arm/mach-asm9260/Makefile b/arch/arm/mach-asm9260/Makefile >> new file mode 100644 >> index 0000000..4bd8ebd >> --- /dev/null >> +++ b/arch/arm/mach-asm9260/Makefile >> @@ -0,0 +1,11 @@ >> +# >> +# Makefile for the linux kernel. >> +# >> + >> +# Object file lists. >> + >> +obj-y := core.o >> +obj-m := >> +obj-n := >> +obj- := > > You can remove most of these and just leave the one line. > >> diff --git a/arch/arm/mach-asm9260/Makefile.boot b/arch/arm/mach-asm9260/Makefile.boot >> new file mode 100644 >> index 0000000..c57b3b4 >> --- /dev/null >> +++ b/arch/arm/mach-asm9260/Makefile.boot >> @@ -0,0 +1,2 @@ >> +zreladdr-y := 0x20008000 > > This file should be removed, nowadays we use AUTO_ZRELADDR, which is > implied by multiplatform. > >> +static struct map_desc asm9260_io_desc[] __initdata = { >> + { /* IO space */ >> + .virtual = (unsigned long)0xf0000000, >> + .pfn = __phys_to_pfn(0x80000000), >> + .length = 0x00800000, >> + .type = MT_DEVICE >> + }, >> + { /* LCD IO space */ >> + .virtual = (unsigned long)0xf0a00000, >> + .pfn = __phys_to_pfn(0x80800000), >> + .length = 0x00009000, >> + .type = MT_DEVICE >> + }, >> + { /* GPIO IO space */ >> + .virtual = (unsigned long)0xf0800000, >> + .pfn = __phys_to_pfn(0x50000000), >> + .length = 0x00100000, >> + .type = MT_DEVICE >> + }, >> + { /* SRAM space Cacheable */ >> + .virtual = (unsigned long)0xd0000000, >> + .pfn = __phys_to_pfn(0x40000000), >> + .length = 0x00100000, >> +#ifdef CONFIG_SRAM_MEM_CACHED >> + .type = MT_MEMORY >> +#else >> + .type = MT_DEVICE >> +#endif >> + }, >> +}; > > This should not be necessary, as all drivers are supposed to > ioremap their own device registers. For large register ranges > that are used a lot, you could use these as an optimization to > get 1 MB sections mapped using a large TLB entry, but usually > the benefit is very small. Do you mean only "SRAM space Cacheable" section? >> +static void __init asm9260_init(void) >> +{ >> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); >> +} > > When you don't do anything else in the init_machine callback, you can > remove it entirely. > > Arnd >
On Tuesday 23 September 2014 11:00:32 Oleksij Rempel wrote: > Am 22.09.2014 um 17:08 schrieb Arnd Bergmann: > > On Sunday 21 September 2014 20:41:37 Oleksij Rempel wrote: > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index 5918d40..1a71feb 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -379,6 +379,20 @@ config ARCH_AT91 > >> This enables support for systems based on Atmel > >> AT91RM9200 and AT91SAM9* processors. > >> > >> +config MACH_ASM9260 > >> + bool "Alphascale ASM9260" > >> + select ARCH_REQUIRE_GPIOLIB > >> + select COMMON_CLK > >> + select IRQ_DOMAIN > >> + select SPARSE_IRQ > >> + select MULTI_IRQ_HANDLER > >> + select GENERIC_IRQ_CHIP > >> + select GENERIC_CLOCKEVENTS > >> + select CLKSRC_MMIO > >> + select CPU_ARM926T > >> + help > >> + Support for Alpascale ASM9260 based platform. > > > > To enable multiplatform support, please move this to its own > > arch/arm/mach-asm9260/Kconfig file and make it depend on ARCH_MULTI_V5, > > then remove all 'select' statements that are implicitly enabled there > > already (most of the above). > > Should they be only in defconfig or selected by driver? The dependencies should match whatever the platform requires. Anything that is optional and user-selectable better goes into the defconfig. > >> +static struct map_desc asm9260_io_desc[] __initdata = { > >> + { /* IO space */ > >> + .virtual = (unsigned long)0xf0000000, > >> + .pfn = __phys_to_pfn(0x80000000), > >> + .length = 0x00800000, > >> + .type = MT_DEVICE > >> + }, > >> + { /* LCD IO space */ > >> + .virtual = (unsigned long)0xf0a00000, > >> + .pfn = __phys_to_pfn(0x80800000), > >> + .length = 0x00009000, > >> + .type = MT_DEVICE > >> + }, > >> + { /* GPIO IO space */ > >> + .virtual = (unsigned long)0xf0800000, > >> + .pfn = __phys_to_pfn(0x50000000), > >> + .length = 0x00100000, > >> + .type = MT_DEVICE > >> + }, > >> + { /* SRAM space Cacheable */ > >> + .virtual = (unsigned long)0xd0000000, > >> + .pfn = __phys_to_pfn(0x40000000), > >> + .length = 0x00100000, > >> +#ifdef CONFIG_SRAM_MEM_CACHED > >> + .type = MT_MEMORY > >> +#else > >> + .type = MT_DEVICE > >> +#endif > >> + }, > >> +}; > > > > This should not be necessary, as all drivers are supposed to > > ioremap their own device registers. For large register ranges > > that are used a lot, you could use these as an optimization to > > get 1 MB sections mapped using a large TLB entry, but usually > > the benefit is very small. > > Do you mean only "SRAM space Cacheable" section? No, all of them. Arnd
Am 23.09.2014 um 12:19 schrieb Arnd Bergmann: > On Tuesday 23 September 2014 11:00:32 Oleksij Rempel wrote: >> Am 22.09.2014 um 17:08 schrieb Arnd Bergmann: >>> On Sunday 21 September 2014 20:41:37 Oleksij Rempel wrote: >>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>>> index 5918d40..1a71feb 100644 >>>> --- a/arch/arm/Kconfig >>>> +++ b/arch/arm/Kconfig >>>> @@ -379,6 +379,20 @@ config ARCH_AT91 >>>> This enables support for systems based on Atmel >>>> AT91RM9200 and AT91SAM9* processors. >>>> >>>> +config MACH_ASM9260 >>>> + bool "Alphascale ASM9260" >>>> + select ARCH_REQUIRE_GPIOLIB >>>> + select COMMON_CLK >>>> + select IRQ_DOMAIN >>>> + select SPARSE_IRQ >>>> + select MULTI_IRQ_HANDLER >>>> + select GENERIC_IRQ_CHIP >>>> + select GENERIC_CLOCKEVENTS >>>> + select CLKSRC_MMIO >>>> + select CPU_ARM926T >>>> + help >>>> + Support for Alpascale ASM9260 based platform. >>> >>> To enable multiplatform support, please move this to its own >>> arch/arm/mach-asm9260/Kconfig file and make it depend on ARCH_MULTI_V5, >>> then remove all 'select' statements that are implicitly enabled there >>> already (most of the above). >> >> Should they be only in defconfig or selected by driver? > > The dependencies should match whatever the platform requires. Anything > that is optional and user-selectable better goes into the defconfig. > >>>> +static struct map_desc asm9260_io_desc[] __initdata = { >>>> + { /* IO space */ >>>> + .virtual = (unsigned long)0xf0000000, >>>> + .pfn = __phys_to_pfn(0x80000000), >>>> + .length = 0x00800000, >>>> + .type = MT_DEVICE >>>> + }, >>>> + { /* LCD IO space */ >>>> + .virtual = (unsigned long)0xf0a00000, >>>> + .pfn = __phys_to_pfn(0x80800000), >>>> + .length = 0x00009000, >>>> + .type = MT_DEVICE >>>> + }, >>>> + { /* GPIO IO space */ >>>> + .virtual = (unsigned long)0xf0800000, >>>> + .pfn = __phys_to_pfn(0x50000000), >>>> + .length = 0x00100000, >>>> + .type = MT_DEVICE >>>> + }, >>>> + { /* SRAM space Cacheable */ >>>> + .virtual = (unsigned long)0xd0000000, >>>> + .pfn = __phys_to_pfn(0x40000000), >>>> + .length = 0x00100000, >>>> +#ifdef CONFIG_SRAM_MEM_CACHED >>>> + .type = MT_MEMORY >>>> +#else >>>> + .type = MT_DEVICE >>>> +#endif >>>> + }, >>>> +}; >>> >>> This should not be necessary, as all drivers are supposed to >>> ioremap their own device registers. For large register ranges >>> that are used a lot, you could use these as an optimization to >>> get 1 MB sections mapped using a large TLB entry, but usually >>> the benefit is very small. >> >> Do you mean only "SRAM space Cacheable" section? > > No, all of them. By removing it i triggered one error which i don't really understand. It will be great if you can help me. By defaul kernel will do fallowing remapping, which will trigger: "Unable to handle kernel paging request at virtual address c2802174" phys addr ioremap range size ======================================= 0x80054000 -> c2800000 size: 0x200 0x80040000 -> c2802000 size: 0x204 0x80088000 -> c2808000 size: 0x4000 But if change second range from 0x204 to 0x4000, then it works fine. 0x80054000 -> c2800000 size: 0x200 0x80040000 -> c2808000 size: 0x4000 0x80088000 -> c2810000 size: 0x4000 Why?
On Wed, Sep 24, 2014 at 10:00:48AM +0200, Oleksij Rempel wrote: > Am 23.09.2014 um 12:19 schrieb Arnd Bergmann: > > No, all of them. > > By removing it i triggered one error which i don't really understand. It > will be great if you can help me. > > By defaul kernel will do fallowing remapping, which will trigger: > "Unable to handle kernel paging request at virtual address c2802174" > > phys addr ioremap range size > ======================================= > 0x80054000 -> c2800000 size: 0x200 > 0x80040000 -> c2802000 size: 0x204 > 0x80088000 -> c2808000 size: 0x4000 > > > But if change second range from 0x204 to 0x4000, then it works fine. > 0x80054000 -> c2800000 size: 0x200 > 0x80040000 -> c2808000 size: 0x4000 > 0x80088000 -> c2810000 size: 0x4000 > > Why? The "why" is in the text from your oops dump. That's precisely /why/ we print that text - so that we know /why/ the fault happened.
Am 24.09.2014 um 11:43 schrieb Russell King - ARM Linux: > On Wed, Sep 24, 2014 at 10:00:48AM +0200, Oleksij Rempel wrote: >> Am 23.09.2014 um 12:19 schrieb Arnd Bergmann: >>> No, all of them. >> >> By removing it i triggered one error which i don't really understand. It >> will be great if you can help me. >> >> By defaul kernel will do fallowing remapping, which will trigger: >> "Unable to handle kernel paging request at virtual address c2802174" >> >> phys addr ioremap range size >> ======================================= >> 0x80054000 -> c2800000 size: 0x200 >> 0x80040000 -> c2802000 size: 0x204 >> 0x80088000 -> c2808000 size: 0x4000 >> >> >> But if change second range from 0x204 to 0x4000, then it works fine. >> 0x80054000 -> c2800000 size: 0x200 >> 0x80040000 -> c2808000 size: 0x4000 >> 0x80088000 -> c2810000 size: 0x4000 >> >> Why? > > The "why" is in the text from your oops dump. That's precisely /why/ we > print that text - so that we know /why/ the fault happened. > Here is oops message: http://pastebin.com/qYWeAyfV i can avoid this oops by setting size at least 0x2000 per register range. Do it mean my TLB supports only 8 KiB pages?
On Wed, Sep 24, 2014 at 11:56:03AM +0200, Oleksij Rempel wrote: > Am 24.09.2014 um 11:43 schrieb Russell King - ARM Linux: > > The "why" is in the text from your oops dump. That's precisely /why/ we > > print that text - so that we know /why/ the fault happened. > > Here is oops message: > http://pastebin.com/qYWeAyfV > > i can avoid this oops by setting size at least 0x2000 per register > range. Do it mean my TLB supports only 8 KiB pages? No, it has nothing to do with the TLB. Unable to handle kernel paging request at virtual address c2802174 pgd = c0004000 [c2802174] *pgd=21805811, *pte=00000000, *ppte=00000000 Internal error: Oops: 7 [#1] PREEMPT ARM The number after the Oops: is the FSR value, which means "page translation fault", and sure enough, the pgd/pte values show that there is no page table entry at the faulting address. That's odd, because ioremap() aligns the size of the requested mapping up to a multiple of the page size, and inserts page table entries according to the rounded size. Where are you calling ioremap(), iounmap() etc? IOW, please show your code for this. I also notice that the unwinder failed to unwind the complete backtrace: [<c02bcb38>] (clk_gate_is_enabled) from [<c02b9a0c>] (clk_disable_unused_subtree+) [<c02b9a0c>] (clk_disable_unused_subtree) from [<c02b99c8>] (clk_disable_unused_s) which is really annoying. Maybe turning frame pointers on will get is a proper backtrace, though I don't think it's that important to this bug.
On Wednesday 24 September 2014 11:25:42 Russell King - ARM Linux wrote: > On Wed, Sep 24, 2014 at 11:56:03AM +0200, Oleksij Rempel wrote: > > Am 24.09.2014 um 11:43 schrieb Russell King - ARM Linux: > > > The "why" is in the text from your oops dump. That's precisely /why/ we > > > print that text - so that we know /why/ the fault happened. > > > > Here is oops message: > > http://pastebin.com/qYWeAyfV > > > > i can avoid this oops by setting size at least 0x2000 per register > > range. Do it mean my TLB supports only 8 KiB pages? > > No, it has nothing to do with the TLB. > > Unable to handle kernel paging request at virtual address c2802174 > pgd = c0004000 > [c2802174] *pgd=21805811, *pte=00000000, *ppte=00000000 > Internal error: Oops: 7 [#1] PREEMPT ARM > > The number after the Oops: is the FSR value, which means "page translation > fault", and sure enough, the pgd/pte values show that there is no page > table entry at the faulting address. > > That's odd, because ioremap() aligns the size of the requested mapping up > to a multiple of the page size, and inserts page table entries according > to the rounded size. > > Where are you calling ioremap(), iounmap() etc? IOW, please show your > code for this. It's the clock driver from patch 5. It starts out with an ioremap of the clock controller node: + acc: clock-controller@80040000 { + compatible = "alphascale,asm9260-clock-controller"; + #clock-cells = <1>; + clocks = <&osc24m>; + reg = <0x80040000 0x500>; + }; Oh, and there is the bug: + /* check for errors on leaf clocks */ + for (n = 0; n < MAX_CLKS; n++) { + if (!IS_ERR(clks[n])) + continue; + + pr_err("%s: Unable to register leaf clock %d\n", + np->full_name, n); + goto fail; + } + + /* register clk-provider */ + clk_data.clks = clks; + clk_data.clk_num = MAX_CLKS; + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data); +fail: + iounmap(base); +} There should be a 'return' in front of the 'fail:', otherwise it get unmapped unconditionally. Arnd
Am 24.09.2014 um 12:33 schrieb Arnd Bergmann: > On Wednesday 24 September 2014 11:25:42 Russell King - ARM Linux wrote: >> On Wed, Sep 24, 2014 at 11:56:03AM +0200, Oleksij Rempel wrote: >>> Am 24.09.2014 um 11:43 schrieb Russell King - ARM Linux: >>>> The "why" is in the text from your oops dump. That's precisely /why/ we >>>> print that text - so that we know /why/ the fault happened. >>> >>> Here is oops message: >>> http://pastebin.com/qYWeAyfV >>> >>> i can avoid this oops by setting size at least 0x2000 per register >>> range. Do it mean my TLB supports only 8 KiB pages? >> >> No, it has nothing to do with the TLB. >> >> Unable to handle kernel paging request at virtual address c2802174 >> pgd = c0004000 >> [c2802174] *pgd=21805811, *pte=00000000, *ppte=00000000 >> Internal error: Oops: 7 [#1] PREEMPT ARM >> >> The number after the Oops: is the FSR value, which means "page translation >> fault", and sure enough, the pgd/pte values show that there is no page >> table entry at the faulting address. >> >> That's odd, because ioremap() aligns the size of the requested mapping up >> to a multiple of the page size, and inserts page table entries according >> to the rounded size. >> >> Where are you calling ioremap(), iounmap() etc? IOW, please show your >> code for this. > > It's the clock driver from patch 5. It starts out with an ioremap of > the clock controller node: > > + acc: clock-controller@80040000 { > + compatible = "alphascale,asm9260-clock-controller"; > + #clock-cells = <1>; > + clocks = <&osc24m>; > + reg = <0x80040000 0x500>; > + }; > > Oh, and there is the bug: > > + /* check for errors on leaf clocks */ > + for (n = 0; n < MAX_CLKS; n++) { > + if (!IS_ERR(clks[n])) > + continue; > + > + pr_err("%s: Unable to register leaf clock %d\n", > + np->full_name, n); > + goto fail; > + } > + > + /* register clk-provider */ > + clk_data.clks = clks; > + clk_data.clk_num = MAX_CLKS; > + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data); > +fail: > + iounmap(base); > +} > > There should be a 'return' in front of the 'fail:', otherwise it > get unmapped unconditionally. Ouch... thank you!!! Still weird why it was not always oopsing.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5918d40..1a71feb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -379,6 +379,20 @@ config ARCH_AT91 This enables support for systems based on Atmel AT91RM9200 and AT91SAM9* processors. +config MACH_ASM9260 + bool "Alphascale ASM9260" + select ARCH_REQUIRE_GPIOLIB + select COMMON_CLK + select IRQ_DOMAIN + select SPARSE_IRQ + select MULTI_IRQ_HANDLER + select GENERIC_IRQ_CHIP + select GENERIC_CLOCKEVENTS + select CLKSRC_MMIO + select CPU_ARM926T + help + Support for Alpascale ASM9260 based platform. + config ARCH_CLPS711X bool "Cirrus Logic CLPS711x/EP721x/EP731x-based" select ARCH_REQUIRE_GPIOLIB diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 0ce9d0f..dda8f6d 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -146,6 +146,7 @@ textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000 # Machine directory name. This list is sorted alphanumerically # by CONFIG_* macro name. machine-$(CONFIG_ARCH_AT91) += at91 +machine-$(CONFIG_MACH_ASM9260) += asm9260 machine-$(CONFIG_ARCH_AXXIA) += axxia machine-$(CONFIG_ARCH_BCM) += bcm machine-$(CONFIG_ARCH_BERLIN) += berlin diff --git a/arch/arm/mach-asm9260/Makefile b/arch/arm/mach-asm9260/Makefile new file mode 100644 index 0000000..4bd8ebd --- /dev/null +++ b/arch/arm/mach-asm9260/Makefile @@ -0,0 +1,11 @@ +# +# Makefile for the linux kernel. +# + +# Object file lists. + +obj-y := core.o +obj-m := +obj-n := +obj- := + diff --git a/arch/arm/mach-asm9260/Makefile.boot b/arch/arm/mach-asm9260/Makefile.boot new file mode 100644 index 0000000..c57b3b4 --- /dev/null +++ b/arch/arm/mach-asm9260/Makefile.boot @@ -0,0 +1,2 @@ +zreladdr-y := 0x20008000 + diff --git a/arch/arm/mach-asm9260/core.c b/arch/arm/mach-asm9260/core.c new file mode 100644 index 0000000..331af96 --- /dev/null +++ b/arch/arm/mach-asm9260/core.c @@ -0,0 +1,77 @@ +/* + * Copyright (C) 2014 Oleksij Rempel <linux@rempel-privat.de> + * Co-author: Du Huanpeng <u74147@gmail.com> + * map_desc based on: + * linux/arch/arm/mach-asm9260/core.c + * Copyright (C) 2011-2014 Alphascale + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ + +#include <linux/of_platform.h> +#include <asm/mach/arch.h> +#include <asm/mach/map.h> + +static struct map_desc asm9260_io_desc[] __initdata = { + { /* IO space */ + .virtual = (unsigned long)0xf0000000, + .pfn = __phys_to_pfn(0x80000000), + .length = 0x00800000, + .type = MT_DEVICE + }, + { /* LCD IO space */ + .virtual = (unsigned long)0xf0a00000, + .pfn = __phys_to_pfn(0x80800000), + .length = 0x00009000, + .type = MT_DEVICE + }, + { /* GPIO IO space */ + .virtual = (unsigned long)0xf0800000, + .pfn = __phys_to_pfn(0x50000000), + .length = 0x00100000, + .type = MT_DEVICE + }, + { /* SRAM space Cacheable */ + .virtual = (unsigned long)0xd0000000, + .pfn = __phys_to_pfn(0x40000000), + .length = 0x00100000, +#ifdef CONFIG_SRAM_MEM_CACHED + .type = MT_MEMORY +#else + .type = MT_DEVICE +#endif + }, +}; + +static void __init asm9260_map_io(void) +{ + iotable_init(asm9260_io_desc, ARRAY_SIZE(asm9260_io_desc)); +} + +static void __init asm9260_init(void) +{ + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + +static const char * const asm9260_dt_board_compat[] __initconst = { + "alphascale,asm9260", + NULL +}; + +DT_MACHINE_START(ASM9260, "Alphascale ASM9260 (Device Tree Support)") + .map_io = asm9260_map_io, + .init_machine = asm9260_init, + .dt_compat = asm9260_dt_board_compat, +MACHINE_END
it is low cost (?) SoC targeted for market in China and India which trying to compete with AT91SAM9G25. Here is some info: http://www.alphascale.com/index.asp?ics/615.html One of products: http://www.aliexpress.com/store/product/2014-hot-sales-FREE-SHIPPING-new-Purple-core-ARM9-development-board-ASM9260T-SDRAM-power-line/433637_1931495721.html Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> --- arch/arm/Kconfig | 14 +++++++ arch/arm/Makefile | 1 + arch/arm/mach-asm9260/Makefile | 11 ++++++ arch/arm/mach-asm9260/Makefile.boot | 2 + arch/arm/mach-asm9260/core.c | 77 +++++++++++++++++++++++++++++++++++++ 5 files changed, 105 insertions(+) create mode 100644 arch/arm/mach-asm9260/Makefile create mode 100644 arch/arm/mach-asm9260/Makefile.boot create mode 100644 arch/arm/mach-asm9260/core.c