* [RFC][PATCH v1.0] Update and enhance TS-7XXX support
@ 2009-10-04 1:14 Christian Gagneraud
2009-10-04 1:14 ` [PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg Christian Gagneraud
` (3 more replies)
0 siblings, 4 replies; 28+ messages in thread
From: Christian Gagneraud @ 2009-10-04 1:14 UTC (permalink / raw)
To: linux-arm-kernel
This is the very first patch needed to uptdate and enhance support for the
TS-72XX boards (See http://www.embeddedarm.com).
These few patches are the ones that affect all EP93XX platforms. As I'm sure
they are not yet quite right for now, any comments are very welcome.
These patch have been collected and maintained mainly by Matthieu Crapet
(http://mcrapet.free.fr/). Tests and contributions are made by the community
on yahoo groups (http://tech.groups.yahoo.com/group/ts-7000).
Thanks to Russel King for spoting the bug that made the sparsemem patch useless.
Now we can enjoy a recent kernel with 64MB of RAM! :)
Patch set statistics:
arch/arm/Kconfig | 1 +
arch/arm/include/asm/memory.h | 2 ++
arch/arm/kernel/head.S | 3 ++
arch/arm/mach-ep93xx/Kconfig | 16 ++++++++++++
arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 15 ++++++++++++
arch/arm/mach-ep93xx/include/mach/memory.h | 30 +++++++++++++++++++++++
arch/arm/mm/proc-arm920.S | 3 ++
7 files changed, 70 insertions(+), 0 deletions(-)
^ permalink raw reply [flat|nested] 28+ messages in thread* [PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg 2009-10-04 1:14 [RFC][PATCH v1.0] Update and enhance TS-7XXX support Christian Gagneraud @ 2009-10-04 1:14 ` Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud ` (2 subsequent siblings) 3 siblings, 0 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-04 1:14 UTC (permalink / raw) To: linux-arm-kernel Usually this is set by the bootrom. If it is not set, then the CPU core will run from HCLK instead of FCLK, and performance will suffer. Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> --- arch/arm/mach-ep93xx/Kconfig | 9 +++++++++ arch/arm/mm/proc-arm920.S | 3 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig index 9167c3d..303c4f8 100644 --- a/arch/arm/mach-ep93xx/Kconfig +++ b/arch/arm/mach-ep93xx/Kconfig @@ -7,6 +7,15 @@ config CRUNCH help Enable kernel support for MaverickCrunch. +config CR1_NFBIT + bool "Turn on nF bit in ControlRegister 1" + help + Say 'Y' here to force the nF bit on. Usually this is set + by the bootrom. If it is not set, then the CPU core will + run from HCLK instead of FCLK, and performance will suffer. + If you see BogoMIPS of about 1/4 of your CPU clock, try + turning this on; your performance should double. + comment "EP93xx Platforms" choice diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S index 914d688..9f030ee 100644 --- a/arch/arm/mm/proc-arm920.S +++ b/arch/arm/mm/proc-arm920.S @@ -373,6 +373,9 @@ __arm920_setup: mrc p15, 0, r0, c1, c0 @ get control register v4 bic r0, r0, r5 orr r0, r0, r6 +#ifdef CONFIG_CR1_NFBIT + orr r0, r0, #0x40000000 @ set nF +#endif mov pc, lr .size __arm920_setup, . - __arm920_setup ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 1:14 [RFC][PATCH v1.0] Update and enhance TS-7XXX support Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg Christian Gagneraud @ 2009-10-04 1:14 ` Christian Gagneraud 2009-10-04 11:05 ` Matthieu Crapet ` (3 more replies) 2009-10-04 1:14 ` [PATCH v1.0 3/4] EP93XX: Add more register definition Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem Christian Gagneraud 3 siblings, 4 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-04 1:14 UTC (permalink / raw) To: linux-arm-kernel From: Matthieu Crapet <mcrapet@gmail.com> In early days Technologic Systems fixed the 0x163 value in redboot instead of 0x2a1, this patch allow to overwrite it. Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> --- arch/arm/kernel/head.S | 3 +++ arch/arm/mach-ep93xx/Kconfig | 7 +++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 38ccbe1..c2e4514 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -82,6 +82,9 @@ ENTRY(stext) bl __lookup_processor_type @ r5=procinfo r9=cpuid movs r10, r5 @ invalid processor (r5=0)? beq __error_p @ yes, error 'p' +#ifdef CONFIG_MACH_TS72XX_FORCE_MACHINEID + ldr r1, =0x2a1 +#endif bl __lookup_machine_type @ r5=machinfo movs r8, r5 @ invalid machine (r5=0)? beq __error_a @ yes, error 'a' diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig index 303c4f8..a909303 100644 --- a/arch/arm/mach-ep93xx/Kconfig +++ b/arch/arm/mach-ep93xx/Kconfig @@ -191,6 +191,13 @@ config EP93XX_EARLY_UART3 endchoice +config MACH_TS72XX_FORCE_MACHINEID + bool "Force Machine ID" + depends on MACH_TS72XX + help + Say 'Y' here to force Machine ID to 0x2A1 (MACH_TYPE_TS72XX legacy value) + In early days Technologic Systems fixed the 0x163 value in redboot. + endmenu endif ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud @ 2009-10-04 11:05 ` Matthieu Crapet 2009-10-04 11:13 ` Alexander Clouter ` (2 subsequent siblings) 3 siblings, 0 replies; 28+ messages in thread From: Matthieu Crapet @ 2009-10-04 11:05 UTC (permalink / raw) To: linux-arm-kernel Christian, This can't be acked, it's pure hack! Christian Gagneraud wrote: > From: Matthieu Crapet <mcrapet@gmail.com> > > In early days Technologic Systems fixed the 0x163 value in redboot > instead of 0x2a1, this patch allow to overwrite it. > > Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > --- > > arch/arm/kernel/head.S | 3 +++ > arch/arm/mach-ep93xx/Kconfig | 7 +++++++ > 2 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > index 38ccbe1..c2e4514 100644 > --- a/arch/arm/kernel/head.S > +++ b/arch/arm/kernel/head.S > @@ -82,6 +82,9 @@ ENTRY(stext) > bl __lookup_processor_type @ r5=procinfo r9=cpuid > movs r10, r5 @ invalid processor (r5=0)? > beq __error_p @ yes, error 'p' > +#ifdef CONFIG_MACH_TS72XX_FORCE_MACHINEID > + ldr r1, =0x2a1 > +#endif > bl __lookup_machine_type @ r5=machinfo > movs r8, r5 @ invalid machine (r5=0)? > beq __error_a @ yes, error 'a' > diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig > index 303c4f8..a909303 100644 > --- a/arch/arm/mach-ep93xx/Kconfig > +++ b/arch/arm/mach-ep93xx/Kconfig > @@ -191,6 +191,13 @@ config EP93XX_EARLY_UART3 > > endchoice > > +config MACH_TS72XX_FORCE_MACHINEID > + bool "Force Machine ID" > + depends on MACH_TS72XX > + help > + Say 'Y' here to force Machine ID to 0x2A1 (MACH_TYPE_TS72XX legacy value) > + In early days Technologic Systems fixed the 0x163 value in redboot. > + > endmenu > > endif > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud 2009-10-04 11:05 ` Matthieu Crapet @ 2009-10-04 11:13 ` Alexander Clouter 2009-10-04 18:34 ` Bill Gatliff 2009-10-04 18:35 ` Bill Gatliff 2009-10-04 11:21 ` Russell King - ARM Linux 2009-10-04 23:03 ` H Hartley Sweeten 3 siblings, 2 replies; 28+ messages in thread From: Alexander Clouter @ 2009-10-04 11:13 UTC (permalink / raw) To: linux-arm-kernel Christian Gagneraud <cgagneraud@techworks.ie> wrote: < > From: Matthieu Crapet <mcrapet@gmail.com> > > In early days Technologic Systems fixed the 0x163 value in redboot > instead of 0x2a1, this patch allow to overwrite it. > > Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > --- > > arch/arm/kernel/head.S | 3 +++ > arch/arm/mach-ep93xx/Kconfig | 7 +++++++ > 2 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > index 38ccbe1..c2e4514 100644 > --- a/arch/arm/kernel/head.S > +++ b/arch/arm/kernel/head.S > @@ -82,6 +82,9 @@ ENTRY(stext) > bl __lookup_processor_type @ r5=procinfo r9=cpuid > movs r10, r5 @ invalid processor (r5=0)? > beq __error_p @ yes, error 'p' > +#ifdef CONFIG_MACH_TS72XX_FORCE_MACHINEID > + ldr r1, =0x2a1 > +#endif > bl __lookup_machine_type @ r5=machinfo > movs r8, r5 @ invalid machine (r5=0)? > beq __error_a @ yes, error 'a' > Brace yourself for Russell giving you a FPSesque "DENIED" here. I suggested a similar patch over a year ago for my TS78XX board and got (rightly) gunned down. :) If you are compiling your own kernels the best solution I have seen[1] is to simply patch the kernel image with: http://ts78xx.digriz.org.uk/booting-woes You will need to use the following devio line instead: devio 'wl 0xe3a01c02,4' 'wl 0xe38110a1,4' Cheers [1] something I first saw on the NAS Buffolo site but then heavily prompted by the orion5x Debian installer maintainers -- Alexander Clouter .sigmonster says: Acceptance testing: An unsuccessful attempt to find bugs. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 11:13 ` Alexander Clouter @ 2009-10-04 18:34 ` Bill Gatliff 2009-10-04 18:35 ` Bill Gatliff 1 sibling, 0 replies; 28+ messages in thread From: Bill Gatliff @ 2009-10-04 18:34 UTC (permalink / raw) To: linux-arm-kernel Alexander Clouter wrote: > > [1] something I first saw on the NAS Buffolo site but then heavily > prompted by the orion5x Debian installer maintainers > > Yea, a lot of the IOP machines that use RedBoot have to do this junk too... Like the N4100. :( I mean, I could "lie" and say that I'm an N2100. In fact, that plus a big comment in the machine descriptor that says "the crappy bootloader for this board passes the wrong machine identifier, so we lie to it in order to bring the system up" might be a better way to deal with it than an out-of-mainline asm hack that keeps coming back to you with each kernel release. Could you tolerate that, rmk? Just one commented line in the machine descriptor that looks kind of strange? b.g. -- Bill Gatliff bgat at billgatliff.com ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 11:13 ` Alexander Clouter 2009-10-04 18:34 ` Bill Gatliff @ 2009-10-04 18:35 ` Bill Gatliff 1 sibling, 0 replies; 28+ messages in thread From: Bill Gatliff @ 2009-10-04 18:35 UTC (permalink / raw) To: linux-arm-kernel Alexander Clouter wrote: > Brace yourself for Russell giving you a FPSesque "DENIED" here. Does that stand for "First Person Shooter"? Yes, that would be a NAK that would leave a mark. :) b.g. -- Bill Gatliff bgat at billgatliff.com ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud 2009-10-04 11:05 ` Matthieu Crapet 2009-10-04 11:13 ` Alexander Clouter @ 2009-10-04 11:21 ` Russell King - ARM Linux 2009-10-04 11:55 ` Christian Gagneraud 2009-10-04 23:03 ` H Hartley Sweeten 3 siblings, 1 reply; 28+ messages in thread From: Russell King - ARM Linux @ 2009-10-04 11:21 UTC (permalink / raw) To: linux-arm-kernel On Sun, Oct 04, 2009 at 02:14:24AM +0100, Christian Gagneraud wrote: > In early days Technologic Systems fixed the 0x163 value in redboot > instead of 0x2a1, this patch allow to overwrite it. This is where ensuring that the machine number is not hard coded into the boot loader, having it as a script-settable variable or a run-time configuration option is a win-win situation. Patch is not suitable for the mainline kernel. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 11:21 ` Russell King - ARM Linux @ 2009-10-04 11:55 ` Christian Gagneraud 0 siblings, 0 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-04 11:55 UTC (permalink / raw) To: linux-arm-kernel Russell King - ARM Linux wrote: > On Sun, Oct 04, 2009 at 02:14:24AM +0100, Christian Gagneraud wrote: >> In early days Technologic Systems fixed the 0x163 value in redboot >> instead of 0x2a1, this patch allow to overwrite it. > > This is where ensuring that the machine number is not hard coded into > the boot loader, having it as a script-settable variable or a run-time > configuration option is a win-win situation. > > Patch is not suitable for the mainline kernel. OK, fair enough. At least I tried! ;) Chris. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud ` (2 preceding siblings ...) 2009-10-04 11:21 ` Russell King - ARM Linux @ 2009-10-04 23:03 ` H Hartley Sweeten 2009-10-05 12:17 ` Christian Gagneraud 3 siblings, 1 reply; 28+ messages in thread From: H Hartley Sweeten @ 2009-10-04 23:03 UTC (permalink / raw) To: linux-arm-kernel On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: > From: Matthieu Crapet <mcrapet@gmail.com> > > In early days Technologic Systems fixed the 0x163 value in redboot > instead of 0x2a1, this patch allow to overwrite it. > > Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> As others have already pointed out, this is a pure hack and not suitable for mainline. The bootloader for systems that needs this really should be updated. Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based system and doesn't even have a platform init in mainline. NAK. Regards, Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-04 23:03 ` H Hartley Sweeten @ 2009-10-05 12:17 ` Christian Gagneraud 2009-10-05 14:10 ` Alexander Clouter 2009-10-05 15:15 ` Mikael Pettersson 0 siblings, 2 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-05 12:17 UTC (permalink / raw) To: linux-arm-kernel H Hartley Sweeten wrote: > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: >> From: Matthieu Crapet <mcrapet@gmail.com> >> >> In early days Technologic Systems fixed the 0x163 value in redboot >> instead of 0x2a1, this patch allow to overwrite it. >> >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > > As others have already pointed out, this is a pure hack and not > suitable for mainline. > > The bootloader for systems that needs this really should be updated. > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based > system and doesn't even have a platform init in mainline. I see your point, but what if the bootloader can't be updated? Does that mean that people using these boards will have to bother with applying patches on mainline kernel for ever? Can't we find a way to address this issue, I'm pretty sure this is not the only board that need this kind of asm hack. Regards, Chris > > NAK. > > Regards, > Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-05 12:17 ` Christian Gagneraud @ 2009-10-05 14:10 ` Alexander Clouter 2009-10-05 15:15 ` Mikael Pettersson 1 sibling, 0 replies; 28+ messages in thread From: Alexander Clouter @ 2009-10-05 14:10 UTC (permalink / raw) To: linux-arm-kernel Christian Gagneraud <cgagneraud@techworks.ie> wrote: > > H Hartley Sweeten wrote: > >> On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: >>> From: Matthieu Crapet <mcrapet@gmail.com> >>> >>> In early days Technologic Systems fixed the 0x163 value in redboot >>> instead of 0x2a1, this patch allow to overwrite it. >>> >>> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> >>> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> >> >> As others have already pointed out, this is a pure hack and not >> suitable for mainline. >> >> The bootloader for systems that needs this really should be updated. >> Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based >> system and doesn't even have a platform init in mainline. > > I see your point, but what if the bootloader can't be updated? Does > that mean that people using these boards will have to bother with > applying patches on mainline kernel for ever? > The price for buying broken hardware and not grumbling at the venduh. Fortunately I have already grumbled at TS in the past and they promised to fix this for their new boards. > Can't we find a way to address this issue, I'm pretty sure this is not > the only board that need this kind of asm hack. > It's not the only board, but as the 'asm hack' is something that can be done in userspace as a post-kernel compiling process. You have to do <something> to get it onto the FLASH of the board, no harm inserting a very trivial step. The moment you start being 'liberal' with machine id's from borkened bootloaders you remove the point of having them altogether. Without them you cannot have the same kernel boot *every* ep93xx SoC... Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #447: According to Microsoft, it's by design ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-05 12:17 ` Christian Gagneraud 2009-10-05 14:10 ` Alexander Clouter @ 2009-10-05 15:15 ` Mikael Pettersson 2009-10-05 16:01 ` Marek Vasut 1 sibling, 1 reply; 28+ messages in thread From: Mikael Pettersson @ 2009-10-05 15:15 UTC (permalink / raw) To: linux-arm-kernel Christian Gagneraud writes: > H Hartley Sweeten wrote: > > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: > >> From: Matthieu Crapet <mcrapet@gmail.com> > >> > >> In early days Technologic Systems fixed the 0x163 value in redboot > >> instead of 0x2a1, this patch allow to overwrite it. > >> > >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > > > > As others have already pointed out, this is a pure hack and not > > suitable for mainline. > > > > The bootloader for systems that needs this really should be updated. > > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based > > system and doesn't even have a platform init in mainline. > > I see your point, but what if the bootloader can't be updated? Does > that mean that people using these boards will have to bother with > applying patches on mainline kernel for ever? > Can't we find a way to address this issue, I'm pretty sure this is not > the only board that need this kind of asm hack. All you need to do is to wrap the kernel binary image with a small shim that corrects the Machine ID in r1. devio can do that, as can (I think) printf(1). No need to replace the bootloader or hack the kernel. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-05 15:15 ` Mikael Pettersson @ 2009-10-05 16:01 ` Marek Vasut 2009-10-05 18:34 ` Christian Gagneraud 0 siblings, 1 reply; 28+ messages in thread From: Marek Vasut @ 2009-10-05 16:01 UTC (permalink / raw) To: linux-arm-kernel Dne Po 5. ??jna 2009 17:15:55 Mikael Pettersson napsal(a): > Christian Gagneraud writes: > > H Hartley Sweeten wrote: > > > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: > > >> From: Matthieu Crapet <mcrapet@gmail.com> > > >> > > >> In early days Technologic Systems fixed the 0x163 value in redboot > > >> instead of 0x2a1, this patch allow to overwrite it. > > >> > > >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > > >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > > > > > > As others have already pointed out, this is a pure hack and not > > > suitable for mainline. > > > > > > The bootloader for systems that needs this really should be updated. > > > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based > > > system and doesn't even have a platform init in mainline. > > > > I see your point, but what if the bootloader can't be updated? Does > > that mean that people using these boards will have to bother with > > applying patches on mainline kernel for ever? > > Can't we find a way to address this issue, I'm pretty sure this is not > > the only board that need this kind of asm hack. > > All you need to do is to wrap the kernel binary image with > a small shim that corrects the Machine ID in r1. devio can > do that, as can (I think) printf(1). > > No need to replace the bootloader or hack the kernel. devio 'wl 0xe59f1000,4' 'wl 0xe28ff004,4' 'wl $MACH,4' >> id.bin cat id.bin zImage > zImage.crippled Like this (I used this on Toradex board where those morons fixed machine id too). > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 2/4] TS72XX: Allow to override machine ID 2009-10-05 16:01 ` Marek Vasut @ 2009-10-05 18:34 ` Christian Gagneraud 0 siblings, 0 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-05 18:34 UTC (permalink / raw) To: linux-arm-kernel Marek Vasut wrote: > Dne Po 5. ??jna 2009 17:15:55 Mikael Pettersson napsal(a): >> Christian Gagneraud writes: >> > H Hartley Sweeten wrote: >> > > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: >> > >> From: Matthieu Crapet <mcrapet@gmail.com> >> > >> >> > >> In early days Technologic Systems fixed the 0x163 value in redboot >> > >> instead of 0x2a1, this patch allow to overwrite it. >> > >> >> > >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> >> > >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> >> > > >> > > As others have already pointed out, this is a pure hack and not >> > > suitable for mainline. >> > > >> > > The bootloader for systems that needs this really should be updated. >> > > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based >> > > system and doesn't even have a platform init in mainline. >> > >> > I see your point, but what if the bootloader can't be updated? Does >> > that mean that people using these boards will have to bother with >> > applying patches on mainline kernel for ever? >> > Can't we find a way to address this issue, I'm pretty sure this is not >> > the only board that need this kind of asm hack. >> >> All you need to do is to wrap the kernel binary image with >> a small shim that corrects the Machine ID in r1. devio can >> do that, as can (I think) printf(1). >> >> No need to replace the bootloader or hack the kernel. > > devio 'wl 0xe59f1000,4' 'wl 0xe28ff004,4' 'wl $MACH,4' >> id.bin > cat id.bin zImage > zImage.crippled Thank you for the tip, i will have a look at this. Regards, Chris > > Like this (I used this on Toradex board where those morons fixed machine id too). >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 3/4] EP93XX: Add more register definition 2009-10-04 1:14 [RFC][PATCH v1.0] Update and enhance TS-7XXX support Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud @ 2009-10-04 1:14 ` Christian Gagneraud 2009-10-04 19:33 ` Ryan Mallon 2009-10-04 23:09 ` H Hartley Sweeten 2009-10-04 1:14 ` [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem Christian Gagneraud 3 siblings, 2 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-04 1:14 UTC (permalink / raw) To: linux-arm-kernel Add register definition for GPIO A,B,C and D data and data direction, Security, Chip ID, ... Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> --- arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h index c5216fc..a5f721e 100644 --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h @@ -111,28 +111,42 @@ #define EP93XX_I2S_BASE EP93XX_APB_IOMEM(0x00020000) #define EP93XX_SECURITY_BASE EP93XX_APB_IOMEM(0x00030000) +#define EP93XX_SECURITY_REG(x) (EP93XX_SECURITY_BASE + (x)) +#define EP93XX_SECURITY_UNIQID EP93XX_SECURITY_REG(0x2440) #define EP93XX_GPIO_BASE EP93XX_APB_IOMEM(0x00040000) #define EP93XX_GPIO_REG(x) (EP93XX_GPIO_BASE + (x)) +#define EP93XX_GPIO_A_DATA EP93XX_GPIO_REG(0x00) +#define EP93XX_GPIO_B_DATA EP93XX_GPIO_REG(0x04) +#define EP93XX_GPIO_C_DATA EP93XX_GPIO_REG(0x08) +#define EP93XX_GPIO_D_DATA EP93XX_GPIO_REG(0x0C) +#define EP93XX_GPIO_A_DIR EP93XX_GPIO_REG(0x10) +#define EP93XX_GPIO_B_DIR EP93XX_GPIO_REG(0x14) +#define EP93XX_GPIO_C_DIR EP93XX_GPIO_REG(0x18) +#define EP93XX_GPIO_D_DIR EP93XX_GPIO_REG(0x1C) #define EP93XX_GPIO_F_INT_TYPE1 EP93XX_GPIO_REG(0x4c) #define EP93XX_GPIO_F_INT_TYPE2 EP93XX_GPIO_REG(0x50) #define EP93XX_GPIO_F_INT_ACK EP93XX_GPIO_REG(0x54) #define EP93XX_GPIO_F_INT_ENABLE EP93XX_GPIO_REG(0x58) #define EP93XX_GPIO_F_INT_STATUS EP93XX_GPIO_REG(0x5c) +#define EP93XX_GPIO_F_INT_DEBOUNCE EP93XX_GPIO_REG(0x64) #define EP93XX_GPIO_A_INT_TYPE1 EP93XX_GPIO_REG(0x90) #define EP93XX_GPIO_A_INT_TYPE2 EP93XX_GPIO_REG(0x94) #define EP93XX_GPIO_A_INT_ACK EP93XX_GPIO_REG(0x98) #define EP93XX_GPIO_A_INT_ENABLE EP93XX_GPIO_REG(0x9c) +#define EP93XX_GPIO_A_INT_DEBOUNCE EP93XX_GPIO_REG(0xa8) #define EP93XX_GPIO_A_INT_STATUS EP93XX_GPIO_REG(0xa0) #define EP93XX_GPIO_B_INT_TYPE1 EP93XX_GPIO_REG(0xac) #define EP93XX_GPIO_B_INT_TYPE2 EP93XX_GPIO_REG(0xb0) #define EP93XX_GPIO_B_INT_ACK EP93XX_GPIO_REG(0xb4) #define EP93XX_GPIO_B_INT_ENABLE EP93XX_GPIO_REG(0xb8) #define EP93XX_GPIO_B_INT_STATUS EP93XX_GPIO_REG(0xbc) +#define EP93XX_GPIO_B_INT_DEBOUNCE EP93XX_GPIO_REG(0xc4) #define EP93XX_GPIO_EEDRIVE EP93XX_GPIO_REG(0xc8) #define EP93XX_AAC_BASE EP93XX_APB_IOMEM(0x00080000) +#define EP93XX_SPI_PHYS_BASE EP93XX_APB_PHYS(0x000a0000) #define EP93XX_SPI_BASE EP93XX_APB_IOMEM(0x000a0000) #define EP93XX_IRDA_BASE EP93XX_APB_IOMEM(0x000b0000) @@ -221,6 +235,7 @@ #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV (1<<16) #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN (1<<15) #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV (1<<0) +#define EP93XX_SYSCON_CHIPID EP93XX_SYSCON_REG(0x94) #define EP93XX_SYSCON_SWLOCK EP93XX_SYSCON_REG(0xc0) #define EP93XX_WATCHDOG_BASE EP93XX_APB_IOMEM(0x00140000) ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v1.0 3/4] EP93XX: Add more register definition 2009-10-04 1:14 ` [PATCH v1.0 3/4] EP93XX: Add more register definition Christian Gagneraud @ 2009-10-04 19:33 ` Ryan Mallon 2009-10-04 23:09 ` H Hartley Sweeten 1 sibling, 0 replies; 28+ messages in thread From: Ryan Mallon @ 2009-10-04 19:33 UTC (permalink / raw) To: linux-arm-kernel Christian Gagneraud wrote: > Add register definition for GPIO A,B,C and D data and data direction, > Security, Chip ID, ... > > Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > --- > > arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 15 +++++++++++++++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h > index c5216fc..a5f721e 100644 > --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h > +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h > @@ -111,28 +111,42 @@ > #define EP93XX_I2S_BASE EP93XX_APB_IOMEM(0x00020000) > > #define EP93XX_SECURITY_BASE EP93XX_APB_IOMEM(0x00030000) > +#define EP93XX_SECURITY_REG(x) (EP93XX_SECURITY_BASE + (x)) > +#define EP93XX_SECURITY_UNIQID EP93XX_SECURITY_REG(0x2440) > > #define EP93XX_GPIO_BASE EP93XX_APB_IOMEM(0x00040000) > #define EP93XX_GPIO_REG(x) (EP93XX_GPIO_BASE + (x)) > +#define EP93XX_GPIO_A_DATA EP93XX_GPIO_REG(0x00) > +#define EP93XX_GPIO_B_DATA EP93XX_GPIO_REG(0x04) > +#define EP93XX_GPIO_C_DATA EP93XX_GPIO_REG(0x08) > +#define EP93XX_GPIO_D_DATA EP93XX_GPIO_REG(0x0C) > +#define EP93XX_GPIO_A_DIR EP93XX_GPIO_REG(0x10) > +#define EP93XX_GPIO_B_DIR EP93XX_GPIO_REG(0x14) > +#define EP93XX_GPIO_C_DIR EP93XX_GPIO_REG(0x18) > +#define EP93XX_GPIO_D_DIR EP93XX_GPIO_REG(0x1C) Are these being used for something? EP93xx already has full gpiolib support, so there should be no need to define these registers. ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon 5 Amuri Park, 404 Barbadoes St ryan at bluewatersys.com PO Box 13 889, Christchurch 8013 http://www.bluewatersys.com New Zealand Phone: +64 3 3779127 Freecall: Australia 1800 148 751 Fax: +64 3 3779135 USA 1800 261 2934 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 3/4] EP93XX: Add more register definition 2009-10-04 1:14 ` [PATCH v1.0 3/4] EP93XX: Add more register definition Christian Gagneraud 2009-10-04 19:33 ` Ryan Mallon @ 2009-10-04 23:09 ` H Hartley Sweeten 2009-10-05 12:06 ` Christian Gagneraud 1 sibling, 1 reply; 28+ messages in thread From: H Hartley Sweeten @ 2009-10-04 23:09 UTC (permalink / raw) To: linux-arm-kernel On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: > Add register definition for GPIO A,B,C and D data and data direction, > Security, Chip ID, ... > > Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > --- > > arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 15 +++++++++++++++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h > index c5216fc..a5f721e 100644 > --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h > +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h > @@ -111,28 +111,42 @@ > #define EP93XX_I2S_BASE EP93XX_APB_IOMEM(0x00020000) > > #define EP93XX_SECURITY_BASE EP93XX_APB_IOMEM(0x00030000) > +#define EP93XX_SECURITY_REG(x) (EP93XX_SECURITY_BASE + (x)) > +#define EP93XX_SECURITY_UNIQID EP93XX_SECURITY_REG(0x2440) > > #define EP93XX_GPIO_BASE EP93XX_APB_IOMEM(0x00040000) > #define EP93XX_GPIO_REG(x) (EP93XX_GPIO_BASE + (x)) > +#define EP93XX_GPIO_A_DATA EP93XX_GPIO_REG(0x00) > +#define EP93XX_GPIO_B_DATA EP93XX_GPIO_REG(0x04) > +#define EP93XX_GPIO_C_DATA EP93XX_GPIO_REG(0x08) > +#define EP93XX_GPIO_D_DATA EP93XX_GPIO_REG(0x0C) > +#define EP93XX_GPIO_A_DIR EP93XX_GPIO_REG(0x10) > +#define EP93XX_GPIO_B_DIR EP93XX_GPIO_REG(0x14) > +#define EP93XX_GPIO_C_DIR EP93XX_GPIO_REG(0x18) > +#define EP93XX_GPIO_D_DIR EP93XX_GPIO_REG(0x1C) > #define EP93XX_GPIO_F_INT_TYPE1 EP93XX_GPIO_REG(0x4c) > #define EP93XX_GPIO_F_INT_TYPE2 EP93XX_GPIO_REG(0x50) > #define EP93XX_GPIO_F_INT_ACK EP93XX_GPIO_REG(0x54) > #define EP93XX_GPIO_F_INT_ENABLE EP93XX_GPIO_REG(0x58) > #define EP93XX_GPIO_F_INT_STATUS EP93XX_GPIO_REG(0x5c) > +#define EP93XX_GPIO_F_INT_DEBOUNCE EP93XX_GPIO_REG(0x64) > #define EP93XX_GPIO_A_INT_TYPE1 EP93XX_GPIO_REG(0x90) > #define EP93XX_GPIO_A_INT_TYPE2 EP93XX_GPIO_REG(0x94) > #define EP93XX_GPIO_A_INT_ACK EP93XX_GPIO_REG(0x98) > #define EP93XX_GPIO_A_INT_ENABLE EP93XX_GPIO_REG(0x9c) > +#define EP93XX_GPIO_A_INT_DEBOUNCE EP93XX_GPIO_REG(0xa8) > #define EP93XX_GPIO_A_INT_STATUS EP93XX_GPIO_REG(0xa0) > #define EP93XX_GPIO_B_INT_TYPE1 EP93XX_GPIO_REG(0xac) > #define EP93XX_GPIO_B_INT_TYPE2 EP93XX_GPIO_REG(0xb0) > #define EP93XX_GPIO_B_INT_ACK EP93XX_GPIO_REG(0xb4) > #define EP93XX_GPIO_B_INT_ENABLE EP93XX_GPIO_REG(0xb8) > #define EP93XX_GPIO_B_INT_STATUS EP93XX_GPIO_REG(0xbc) > +#define EP93XX_GPIO_B_INT_DEBOUNCE EP93XX_GPIO_REG(0xc4) > #define EP93XX_GPIO_EEDRIVE EP93XX_GPIO_REG(0xc8) The ep93xx has been converted to full gpiolib support. There is no need for the GPIO register defines. Also, it's a bad idea to have them since anything using these will be "breaking" the gpiolib API. If you need to use the gpio debounce the ep93xx core already has support for this. Please see ep93xx_gpio_int_debounce() in arch/arm/mach-ep93xx/core.c. On a side note. What tree did you base this patch on? The EP93XX_GPIO_EEDRIVE is not currently in mainline. > #define EP93XX_AAC_BASE EP93XX_APB_IOMEM(0x00080000) > > +#define EP93XX_SPI_PHYS_BASE EP93XX_APB_PHYS(0x000a0000) > #define EP93XX_SPI_BASE EP93XX_APB_IOMEM(0x000a0000) > > #define EP93XX_IRDA_BASE EP93XX_APB_IOMEM(0x000b0000) > @@ -221,6 +235,7 @@ > #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV (1<<16) > #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN (1<<15) > #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV (1<<0) > +#define EP93XX_SYSCON_CHIPID EP93XX_SYSCON_REG(0x94) > #define EP93XX_SYSCON_SWLOCK EP93XX_SYSCON_REG(0xc0) > > #define EP93XX_WATCHDOG_BASE EP93XX_APB_IOMEM(0x00140000) NAK. Regards, Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 3/4] EP93XX: Add more register definition 2009-10-04 23:09 ` H Hartley Sweeten @ 2009-10-05 12:06 ` Christian Gagneraud 2009-10-05 16:51 ` H Hartley Sweeten 0 siblings, 1 reply; 28+ messages in thread From: Christian Gagneraud @ 2009-10-05 12:06 UTC (permalink / raw) To: linux-arm-kernel H Hartley Sweeten wrote: > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote: >> Add register definition for GPIO A,B,C and D data and data direction, >> Security, Chip ID, ... >> >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> >> --- >> >> arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 15 +++++++++++++++ >> 1 files changed, 15 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h >> index c5216fc..a5f721e 100644 >> --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h >> +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h >> @@ -111,28 +111,42 @@ >> #define EP93XX_I2S_BASE EP93XX_APB_IOMEM(0x00020000) >> >> #define EP93XX_SECURITY_BASE EP93XX_APB_IOMEM(0x00030000) >> +#define EP93XX_SECURITY_REG(x) (EP93XX_SECURITY_BASE + (x)) >> +#define EP93XX_SECURITY_UNIQID EP93XX_SECURITY_REG(0x2440) >> >> #define EP93XX_GPIO_BASE EP93XX_APB_IOMEM(0x00040000) >> #define EP93XX_GPIO_REG(x) (EP93XX_GPIO_BASE + (x)) >> +#define EP93XX_GPIO_A_DATA EP93XX_GPIO_REG(0x00) >> +#define EP93XX_GPIO_B_DATA EP93XX_GPIO_REG(0x04) >> +#define EP93XX_GPIO_C_DATA EP93XX_GPIO_REG(0x08) >> +#define EP93XX_GPIO_D_DATA EP93XX_GPIO_REG(0x0C) >> +#define EP93XX_GPIO_A_DIR EP93XX_GPIO_REG(0x10) >> +#define EP93XX_GPIO_B_DIR EP93XX_GPIO_REG(0x14) >> +#define EP93XX_GPIO_C_DIR EP93XX_GPIO_REG(0x18) >> +#define EP93XX_GPIO_D_DIR EP93XX_GPIO_REG(0x1C) >> #define EP93XX_GPIO_F_INT_TYPE1 EP93XX_GPIO_REG(0x4c) >> #define EP93XX_GPIO_F_INT_TYPE2 EP93XX_GPIO_REG(0x50) >> #define EP93XX_GPIO_F_INT_ACK EP93XX_GPIO_REG(0x54) >> #define EP93XX_GPIO_F_INT_ENABLE EP93XX_GPIO_REG(0x58) >> #define EP93XX_GPIO_F_INT_STATUS EP93XX_GPIO_REG(0x5c) >> +#define EP93XX_GPIO_F_INT_DEBOUNCE EP93XX_GPIO_REG(0x64) >> #define EP93XX_GPIO_A_INT_TYPE1 EP93XX_GPIO_REG(0x90) >> #define EP93XX_GPIO_A_INT_TYPE2 EP93XX_GPIO_REG(0x94) >> #define EP93XX_GPIO_A_INT_ACK EP93XX_GPIO_REG(0x98) >> #define EP93XX_GPIO_A_INT_ENABLE EP93XX_GPIO_REG(0x9c) >> +#define EP93XX_GPIO_A_INT_DEBOUNCE EP93XX_GPIO_REG(0xa8) >> #define EP93XX_GPIO_A_INT_STATUS EP93XX_GPIO_REG(0xa0) >> #define EP93XX_GPIO_B_INT_TYPE1 EP93XX_GPIO_REG(0xac) >> #define EP93XX_GPIO_B_INT_TYPE2 EP93XX_GPIO_REG(0xb0) >> #define EP93XX_GPIO_B_INT_ACK EP93XX_GPIO_REG(0xb4) >> #define EP93XX_GPIO_B_INT_ENABLE EP93XX_GPIO_REG(0xb8) >> #define EP93XX_GPIO_B_INT_STATUS EP93XX_GPIO_REG(0xbc) >> +#define EP93XX_GPIO_B_INT_DEBOUNCE EP93XX_GPIO_REG(0xc4) >> #define EP93XX_GPIO_EEDRIVE EP93XX_GPIO_REG(0xc8) > > The ep93xx has been converted to full gpiolib support. There > is no need for the GPIO register defines. Also, it's a bad > idea to have them since anything using these will be "breaking" > the gpiolib API. > > If you need to use the gpio debounce the ep93xx core already has > support for this. Please see ep93xx_gpio_int_debounce() in > arch/arm/mach-ep93xx/core.c. This was needed for a GPIO based keypad. I will have a look on how to convert it to use GPIO lib. > > On a side note. What tree did you base this patch on? The > EP93XX_GPIO_EEDRIVE is not currently in mainline. Linus tree + a couple of pending patches from this ML. > >> #define EP93XX_AAC_BASE EP93XX_APB_IOMEM(0x00080000) >> >> +#define EP93XX_SPI_PHYS_BASE EP93XX_APB_PHYS(0x000a0000) >> #define EP93XX_SPI_BASE EP93XX_APB_IOMEM(0x000a0000) >> >> #define EP93XX_IRDA_BASE EP93XX_APB_IOMEM(0x000b0000) >> @@ -221,6 +235,7 @@ >> #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV (1<<16) >> #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN (1<<15) >> #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV (1<<0) >> +#define EP93XX_SYSCON_CHIPID EP93XX_SYSCON_REG(0x94) >> #define EP93XX_SYSCON_SWLOCK EP93XX_SYSCON_REG(0xc0) >> >> #define EP93XX_WATCHDOG_BASE EP93XX_APB_IOMEM(0x00140000) > > NAK. OK for GPIO and SPI, but what about the SECURITY and SYSCON_CHIPID stuff? The idea behind that is to extend in some way board/cpu specific information. For example the TS-7XXX boards comes with some options, there is currently a patch that add a /proc entry to display cpu and board information (CPU version, CPLD/FPGA firmware version, state of configuration jumpers, HW options installed, ...) Regards, Chris > > Regards, > Hartley > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 3/4] EP93XX: Add more register definition 2009-10-05 12:06 ` Christian Gagneraud @ 2009-10-05 16:51 ` H Hartley Sweeten 2009-10-05 18:30 ` Christian Gagneraud 0 siblings, 1 reply; 28+ messages in thread From: H Hartley Sweeten @ 2009-10-05 16:51 UTC (permalink / raw) To: linux-arm-kernel On Monday, October 05, 2009 5:06 AM, Christian Gagneraud wrote: >> The ep93xx has been converted to full gpiolib support. There >> is no need for the GPIO register defines. Also, it's a bad >> idea to have them since anything using these will be "breaking" >> the gpiolib API. >> >> If you need to use the gpio debounce the ep93xx core already has >> support for this. Please see ep93xx_gpio_int_debounce() in >> arch/arm/mach-ep93xx/core.c. > > This was needed for a GPIO based keypad. I will have a look on how to > convert it to use GPIO lib. If you are referring to Matthieu Crapet's 0017-ts72xx_dio_keypad.patch, that patch appears to have already been converted over to use gpiolib. Regardless, the in tree matrix_keypad.c driver will probably work instead of introducing another GPIO based keypad driver. >> On a side note. What tree did you base this patch on? The >> EP93XX_GPIO_EEDRIVE is not currently in mainline. > > Linus tree + a couple of pending patches from this ML. Bad form. Pending patches could always be dropped at some point. You should only base your patches on published trees'. >>> #define EP93XX_AAC_BASE EP93XX_APB_IOMEM(0x00080000) >>> >>> +#define EP93XX_SPI_PHYS_BASE EP93XX_APB_PHYS(0x000a0000) >>> #define EP93XX_SPI_BASE EP93XX_APB_IOMEM(0x000a0000) >>> >>> #define EP93XX_IRDA_BASE EP93XX_APB_IOMEM(0x000b0000) >>> @@ -221,6 +235,7 @@ >>> #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV (1<<16) >>> #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN (1<<15) >>> #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV (1<<0) >>> +#define EP93XX_SYSCON_CHIPID EP93XX_SYSCON_REG(0x94) >>> #define EP93XX_SYSCON_SWLOCK EP93XX_SYSCON_REG(0xc0) >>> >>> #define EP93XX_WATCHDOG_BASE EP93XX_APB_IOMEM(0x00140000) >> >> NAK. > > OK for GPIO and SPI, but what about the SECURITY and SYSCON_CHIPID > stuff? The idea behind that is to extend in some way board/cpu > specific information. > For example the TS-7XXX boards comes with some options, there is > currently a patch that add a /proc entry to display cpu and board > information (CPU version, CPLD/FPGA firmware version, state of > configuration jumpers, HW options installed, ...) I think you are referring to Matthieu's 0006-ep93xx_cpuinfo.patch. This is IMHO a hack. I have another approach for this that I proposed to Russell a while ago. He had some concern's about breaking userspace tools at that time. I am planning on resubmitting my patch shortly in order to get more opinions. Please hold off on this for a bit. Regards, Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 3/4] EP93XX: Add more register definition 2009-10-05 16:51 ` H Hartley Sweeten @ 2009-10-05 18:30 ` Christian Gagneraud 0 siblings, 0 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-05 18:30 UTC (permalink / raw) To: linux-arm-kernel H Hartley Sweeten wrote: > On Monday, October 05, 2009 5:06 AM, Christian Gagneraud wrote: >>> The ep93xx has been converted to full gpiolib support. There >>> is no need for the GPIO register defines. Also, it's a bad >>> idea to have them since anything using these will be "breaking" >>> the gpiolib API. >>> >>> If you need to use the gpio debounce the ep93xx core already has >>> support for this. Please see ep93xx_gpio_int_debounce() in >>> arch/arm/mach-ep93xx/core.c. >> This was needed for a GPIO based keypad. I will have a look on how to >> convert it to use GPIO lib. > > If you are referring to Matthieu Crapet's 0017-ts72xx_dio_keypad.patch, > that patch appears to have already been converted over to use gpiolib. > > Regardless, the in tree matrix_keypad.c driver will probably work > instead of introducing another GPIO based keypad driver. > >>> On a side note. What tree did you base this patch on? The >>> EP93XX_GPIO_EEDRIVE is not currently in mainline. >> Linus tree + a couple of pending patches from this ML. > > Bad form. Pending patches could always be dropped at some point. You > should only base your patches on published trees'. > >>>> #define EP93XX_AAC_BASE EP93XX_APB_IOMEM(0x00080000) >>>> >>>> +#define EP93XX_SPI_PHYS_BASE EP93XX_APB_PHYS(0x000a0000) >>>> #define EP93XX_SPI_BASE EP93XX_APB_IOMEM(0x000a0000) >>>> >>>> #define EP93XX_IRDA_BASE EP93XX_APB_IOMEM(0x000b0000) >>>> @@ -221,6 +235,7 @@ >>>> #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV (1<<16) >>>> #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN (1<<15) >>>> #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV (1<<0) >>>> +#define EP93XX_SYSCON_CHIPID EP93XX_SYSCON_REG(0x94) >>>> #define EP93XX_SYSCON_SWLOCK EP93XX_SYSCON_REG(0xc0) >>>> >>>> #define EP93XX_WATCHDOG_BASE EP93XX_APB_IOMEM(0x00140000) >>> NAK. >> OK for GPIO and SPI, but what about the SECURITY and SYSCON_CHIPID >> stuff? The idea behind that is to extend in some way board/cpu >> specific information. >> For example the TS-7XXX boards comes with some options, there is >> currently a patch that add a /proc entry to display cpu and board >> information (CPU version, CPLD/FPGA firmware version, state of >> configuration jumpers, HW options installed, ...) > > I think you are referring to Matthieu's 0006-ep93xx_cpuinfo.patch. > This is IMHO a hack. I have another approach for this that I proposed Yes, this is a hack, and that's why I'm here, I would like to see most of these ideas pushed to mainline, and I know that almost all these patches won't be accepted, they need rework, heavy rework for some. > to Russell a while ago. He had some concern's about breaking userspace > tools at that time. I am planning on resubmitting my patch shortly > in order to get more opinions. That's true it could break some user space tools, so why not another /proc entry like /proc/machineinfo or /proc/boardinfo, .... (without separator, to mimic /proc/cpuinfo) In that respect, it will gives more freedom to display whatever revelant information machine maintainers can think of. The approach you have in your "arm: add /proc/cpuinfo extension for ep93xx" patch sounds good to me. Regards, Chris > > Please hold off on this for a bit. > > Regards, > Hartley > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-04 1:14 [RFC][PATCH v1.0] Update and enhance TS-7XXX support Christian Gagneraud ` (2 preceding siblings ...) 2009-10-04 1:14 ` [PATCH v1.0 3/4] EP93XX: Add more register definition Christian Gagneraud @ 2009-10-04 1:14 ` Christian Gagneraud 2009-10-05 12:21 ` Christian Gagneraud 3 siblings, 1 reply; 28+ messages in thread From: Christian Gagneraud @ 2009-10-04 1:14 UTC (permalink / raw) To: linux-arm-kernel Tested on TS7260 with 64MB SDRAM (8*8MB). (Other boards will be tested soon-ish). Special thanks to Matthieu Crappet, Charlie M. I'm not sure what's the impact for other machine based on EP93XX, it's likely that SECTION_SIZE_BITS and MAX_PHYSMEM_BITS needs to be define with default values that suits everyone PS: Has to be apply on top of this patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/001706.html Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> --- arch/arm/Kconfig | 1 + arch/arm/include/asm/memory.h | 2 ++ arch/arm/mach-ep93xx/include/mach/memory.h | 30 ++++++++++++++++++++++++++++ 3 files changed, 33 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1c4119c..0f1d52f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -288,6 +288,7 @@ config ARCH_EP93XX select CPU_ARM920T select ARM_AMBA select ARM_VIC + select ARCH_SPARSEMEM_ENABLE select GENERIC_GPIO select HAVE_CLK select COMMON_CLKDEV diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h index cefedf0..6be9d9b 100644 --- a/arch/arm/include/asm/memory.h +++ b/arch/arm/include/asm/memory.h @@ -125,8 +125,10 @@ * private definitions which should NOT be used outside memory.h * files. Use virt_to_phys/phys_to_virt/__pa/__va instead. */ +#ifndef __phys_to_virt #define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET) #define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET) +#endif /* * Convert a physical address to a Page Frame Number and back diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h index 554064e..4cb3329 100644 --- a/arch/arm/mach-ep93xx/include/mach/memory.h +++ b/arch/arm/mach-ep93xx/include/mach/memory.h @@ -19,4 +19,34 @@ #error "Kconfig bug: No EP93xx PHYS_OFFSET set" #endif +#ifdef CONFIG_MACH_TS72XX +/* + * Non-linear mapping like so: + * phys => virt + * 0x00000000 => 0xc0000000 + * 0x01000000 => 0xc1000000 + * 0x04000000 => 0xc4000000 + * 0x05000000 => 0xc5000000 + * 0xe0000000 => 0xc8000000 + * 0xe1000000 => 0xc9000000 + * 0xe4000000 => 0xcc000000 + * 0xe5000000 => 0xcd000000 + * + * As suggested here: http://marc.info/?l=linux-arm&m=122754446724900&w=2 + * + * Note that static inline functions won't work here because + * arch/arm/include/asm/memory.h uses "#ifndef __virt_to_phys" to check whether to + * use generic functions or not. + */ +#define __phys_to_virt(p) \ + (((p) & 0x07ffffff) | (((p) & 0xe0000000) ? 0x08000000 : 0) | PAGE_OFFSET) + +#define __virt_to_phys(v) \ + (((v) & 0x07ffffff) | (((v) & 0x08000000) ? 0xe0000000 : 0 )) + +#define SECTION_SIZE_BITS 24 +#define MAX_PHYSMEM_BITS 32 + +#endif /* CONFIG_ARCH_TS72XX */ + #endif ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-04 1:14 ` [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem Christian Gagneraud @ 2009-10-05 12:21 ` Christian Gagneraud 2009-10-05 17:06 ` H Hartley Sweeten 0 siblings, 1 reply; 28+ messages in thread From: Christian Gagneraud @ 2009-10-05 12:21 UTC (permalink / raw) To: linux-arm-kernel Hi, What people think about enabling sparsemem on EP93XX? I know this patch as it is will break all but this board. Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that will suit all the supported boards? Regards, Chris Christian Gagneraud wrote: > Tested on TS7260 with 64MB SDRAM (8*8MB). (Other boards will be tested > soon-ish). Special thanks to Matthieu Crappet, Charlie M. > > I'm not sure what's the impact for other machine based on EP93XX, it's likely > that SECTION_SIZE_BITS and MAX_PHYSMEM_BITS needs to be define with default > values that suits everyone > > PS: Has to be apply on top of this patch: > http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/001706.html > > Signed-off-by: Matthieu Crapet <mcrapet@gmail.com> > Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie> > --- > > arch/arm/Kconfig | 1 + > arch/arm/include/asm/memory.h | 2 ++ > arch/arm/mach-ep93xx/include/mach/memory.h | 30 ++++++++++++++++++++++++++++ > 3 files changed, 33 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 1c4119c..0f1d52f 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -288,6 +288,7 @@ config ARCH_EP93XX > select CPU_ARM920T > select ARM_AMBA > select ARM_VIC > + select ARCH_SPARSEMEM_ENABLE > select GENERIC_GPIO > select HAVE_CLK > select COMMON_CLKDEV > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h > index cefedf0..6be9d9b 100644 > --- a/arch/arm/include/asm/memory.h > +++ b/arch/arm/include/asm/memory.h > @@ -125,8 +125,10 @@ > * private definitions which should NOT be used outside memory.h > * files. Use virt_to_phys/phys_to_virt/__pa/__va instead. > */ > +#ifndef __phys_to_virt > #define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET) > #define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET) > +#endif > > /* > * Convert a physical address to a Page Frame Number and back > diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h > index 554064e..4cb3329 100644 > --- a/arch/arm/mach-ep93xx/include/mach/memory.h > +++ b/arch/arm/mach-ep93xx/include/mach/memory.h > @@ -19,4 +19,34 @@ > #error "Kconfig bug: No EP93xx PHYS_OFFSET set" > #endif > > +#ifdef CONFIG_MACH_TS72XX > +/* > + * Non-linear mapping like so: > + * phys => virt > + * 0x00000000 => 0xc0000000 > + * 0x01000000 => 0xc1000000 > + * 0x04000000 => 0xc4000000 > + * 0x05000000 => 0xc5000000 > + * 0xe0000000 => 0xc8000000 > + * 0xe1000000 => 0xc9000000 > + * 0xe4000000 => 0xcc000000 > + * 0xe5000000 => 0xcd000000 > + * > + * As suggested here: http://marc.info/?l=linux-arm&m=122754446724900&w=2 > + * > + * Note that static inline functions won't work here because > + * arch/arm/include/asm/memory.h uses "#ifndef __virt_to_phys" to check whether to > + * use generic functions or not. > + */ > +#define __phys_to_virt(p) \ > + (((p) & 0x07ffffff) | (((p) & 0xe0000000) ? 0x08000000 : 0) | PAGE_OFFSET) > + > +#define __virt_to_phys(v) \ > + (((v) & 0x07ffffff) | (((v) & 0x08000000) ? 0xe0000000 : 0 )) > + > +#define SECTION_SIZE_BITS 24 > +#define MAX_PHYSMEM_BITS 32 > + > +#endif /* CONFIG_ARCH_TS72XX */ > + > #endif > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-05 12:21 ` Christian Gagneraud @ 2009-10-05 17:06 ` H Hartley Sweeten 2009-10-05 18:16 ` Christian Gagneraud 0 siblings, 1 reply; 28+ messages in thread From: H Hartley Sweeten @ 2009-10-05 17:06 UTC (permalink / raw) To: linux-arm-kernel On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote: > Hi, > > What people think about enabling sparsemem on EP93XX? I know this > patch as it is will break all but this board. > > Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that > will suit all the supported boards? With sparsemem enabled what is your memory detected during boot? For instance on my ep9307 based system with flatmem I get: Memory: 32MB 32MB = 64MB total Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem) And cat /proc/iomem shows: c0000000-c1ffffff : System RAM c0027000-c0385fff : Kernel text c03a0000-c03df88f : Kernel data c4000000-c5ffffff : System RAM So the kernel finds two 32MB chunks which is what the bootloader passed in the ATAGS. And the addresses match what was passed. What is your intended result by switching to sparsemem? I have also messed with sparsemem and I get the same results as above with it enabled. I don't see any real reason to switch to sparsemem. The _only_ reason I can see is if a system has more than 8 banks of memory. I think that is the current limit for flatmem support in the kernel. There are only two configuration I know of that can cause this on the ep93xx when only on chip select is used: 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 0 -> 16 banks 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 0 -> 16 banks Both of these configuration can be "fixed" by having the bootloader set the SROMLL bit = 1. 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 1 -> 8 banks 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 1 -> 1 bank Please refer to the following document for more information: http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf Regards, Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-05 17:06 ` H Hartley Sweeten @ 2009-10-05 18:16 ` Christian Gagneraud 2009-10-05 18:52 ` H Hartley Sweeten 0 siblings, 1 reply; 28+ messages in thread From: Christian Gagneraud @ 2009-10-05 18:16 UTC (permalink / raw) To: linux-arm-kernel H Hartley Sweeten wrote: > On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote: >> Hi, >> >> What people think about enabling sparsemem on EP93XX? I know this >> patch as it is will break all but this board. >> >> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that >> will suit all the supported boards? > > With sparsemem enabled what is your memory detected during boot? For > instance on my ep9307 based system with flatmem I get: > > Memory: 32MB 32MB = 64MB total > Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem) ^^^^^ Are you missing 16MB? Here is what i get with sparsemem: Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem) > And cat /proc/iomem shows: > > c0000000-c1ffffff : System RAM > c0027000-c0385fff : Kernel text > c03a0000-c03df88f : Kernel data > c4000000-c5ffffff : System RAM 00000000-007fffff : System RAM 00020000-00276fff : Kernel text 00278000-002c1923 : Kernel data 01000000-017fffff : System RAM 04000000-047fffff : System RAM 05000000-057fffff : System RAM 80010000-8001ffff : ep93xx-eth 80010000-8001ffff : ep93xx-eth 80020000-80020fff : ep93xx-ohci 808c0000-808c0fff : apb:uart1 808c0000-808c003f : uart-pl010 808d0000-808d0fff : apb:uart2 808d0000-808d003f : uart-pl010 808e0000-808e0fff : apb:uart3 808e0000-808e003f : uart-pl010 80920000-8092010b : ep93xx-rtc e0000000-e07fffff : System RAM e1000000-e17fffff : System RAM e4000000-e47fffff : System RAM e5000000-e57fffff : System RAM For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that shows at 0x00000000, for boards shipped with 64MB there's another 32MB chip on SD_CS2 which pop up at 0xe0000000 That's for the models that offer 32 or 64MB, but TS have other models that offer 64 or 128MB, these boards are designed the same way: 1 64MB chip on SD_CS3 and optional a second 64MB chip on SD_CS2. I was told that in that case 16 banks needed to be define (and btw it couldn't be handled , I didn't check it yet. Before sparsemem, we had to use discontigmem (and patch it),now with parsemem there's no needs for such a thing anymore, the only needed bits are 4 #define. > > So the kernel finds two 32MB chunks which is what the bootloader passed > in the ATAGS. And the addresses match what was passed. > > What is your intended result by switching to sparsemem? > > I have also messed with sparsemem and I get the same results as above > with it enabled. I don't see any real reason to switch to sparsemem. > > The _only_ reason I can see is if a system has more than 8 banks of > memory. I think that is the current limit for flatmem support in the > kernel. There are only two configuration I know of that can cause this > on the ep93xx when only on chip select is used: > > 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 0 -> 16 banks > 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 0 -> 16 banks > > Both of these configuration can be "fixed" by having the bootloader set > the SROMLL bit = 1. > > 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 1 -> 8 banks > 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 1 -> 1 bank > > Please refer to the following document for more information: > > http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf Interesting, thank you. Regards, Chris > > Regards, > Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-05 18:16 ` Christian Gagneraud @ 2009-10-05 18:52 ` H Hartley Sweeten 2009-10-06 21:21 ` Christian Gagneraud 0 siblings, 1 reply; 28+ messages in thread From: H Hartley Sweeten @ 2009-10-05 18:52 UTC (permalink / raw) To: linux-arm-kernel On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote: > H Hartley Sweeten wrote: >> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote: >>> Hi, >>> >>> What people think about enabling sparsemem on EP93XX? I know this >>> patch as it is will break all but this board. >>> >>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that >>> will suit all the supported boards? >> >> With sparsemem enabled what is your memory detected during boot? For >> instance on my ep9307 based system with flatmem I get: >> >> Memory: 32MB 32MB = 64MB total >> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem) > ^^^^^ > Are you missing 16MB? No. My rootfs is in /dev/ram and uses the remaining space. > Here is what i get with sparsemem: > > Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total > > Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem) > > 00000000-007fffff : System RAM > 00020000-00276fff : Kernel text > 00278000-002c1923 : Kernel data > 01000000-017fffff : System RAM > 04000000-047fffff : System RAM > 05000000-057fffff : System RAM > e0000000-e07fffff : System RAM > e1000000-e17fffff : System RAM > e4000000-e47fffff : System RAM > e5000000-e57fffff : System RAM > > For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that > shows at 0x00000000, for boards shipped with 64MB there's another 32MB > chip on SD_CS2 which pop up at 0xe0000000 OK. That makes sense. I was under the impression that the 64MB board was using a single chip select. > That's for the models that offer 32 or 64MB, but TS have other models > that offer 64 or 128MB, these boards are designed the same way: 1 64MB > chip on SD_CS3 and optional a second 64MB chip on SD_CS2. > I was told that in that case 16 banks needed to be define (and btw it > couldn't be handled , I didn't check it yet. The single chip 64MB board would work fine but it would use 8 banks. The 128MB board would be a problem with flatmem because of the 16 banks. In order to support this NR_BANKS would have to be increased in arch/arm/include/asm/setup.h. > Before sparsemem, we had to use discontigmem (and patch it),now with > parsemem there's no needs for such a thing anymore, the only needed > bits are 4 #define. Sparsemem is probably a good solution for the multiple chip selects. But we need to make sure that any solution used works for all ep93xx variants. The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async) boot, there are 5 possible base addresses for them. Then, depending on the bus width and the density of memory used, the node mapping for each bank can vary greatly. Even worse, node mapping changes depending on the SROMLL bit. The document referenced below has all the information needed but at this point I don't know of a good solution. > http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf Maybe Russell can help (Cced). Regards, Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-05 18:52 ` H Hartley Sweeten @ 2009-10-06 21:21 ` Christian Gagneraud 2009-10-06 21:26 ` Christian Gagneraud 0 siblings, 1 reply; 28+ messages in thread From: Christian Gagneraud @ 2009-10-06 21:21 UTC (permalink / raw) To: linux-arm-kernel H Hartley Sweeten wrote: > On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote: >> H Hartley Sweeten wrote: >>> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote: >>>> Hi, >>>> >>>> What people think about enabling sparsemem on EP93XX? I know this >>>> patch as it is will break all but this board. >>>> >>>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that >>>> will suit all the supported boards? >>> With sparsemem enabled what is your memory detected during boot? For >>> instance on my ep9307 based system with flatmem I get: >>> >>> Memory: 32MB 32MB = 64MB total >>> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem) >> ^^^^^ >> Are you missing 16MB? > > No. My rootfs is in /dev/ram and uses the remaining space. > >> Here is what i get with sparsemem: >> >> Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total >> >> Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem) >> >> 00000000-007fffff : System RAM >> 00020000-00276fff : Kernel text >> 00278000-002c1923 : Kernel data >> 01000000-017fffff : System RAM >> 04000000-047fffff : System RAM >> 05000000-057fffff : System RAM >> e0000000-e07fffff : System RAM >> e1000000-e17fffff : System RAM >> e4000000-e47fffff : System RAM >> e5000000-e57fffff : System RAM >> >> For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that >> shows at 0x00000000, for boards shipped with 64MB there's another 32MB >> chip on SD_CS2 which pop up at 0xe0000000 > > OK. That makes sense. I was under the impression that the 64MB board > was using a single chip select. > >> That's for the models that offer 32 or 64MB, but TS have other models >> that offer 64 or 128MB, these boards are designed the same way: 1 64MB >> chip on SD_CS3 and optional a second 64MB chip on SD_CS2. >> I was told that in that case 16 banks needed to be define (and btw it >> couldn't be handled , I didn't check it yet. > > The single chip 64MB board would work fine but it would use 8 banks. The > 128MB board would be a problem with flatmem because of the 16 banks. In > order to support this NR_BANKS would have to be increased in > arch/arm/include/asm/setup.h. > >> Before sparsemem, we had to use discontigmem (and patch it),now with >> parsemem there's no needs for such a thing anymore, the only needed >> bits are 4 #define. > > Sparsemem is probably a good solution for the multiple chip selects. But > we need to make sure that any solution used works for all ep93xx variants. > > The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async) > boot, there are 5 possible base addresses for them. Then, depending on > the bus width and the density of memory used, the node mapping for each > bank can vary greatly. Even worse, node mapping changes depending on the > SROMLL bit. The document referenced below has all the information needed > but at this point I don't know of a good solution. > >> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf Actually, in the EP93XX User's Manual, the table 13-11 on pages 3-12 to 13-16 gives all the possibilities. When SROMLL=0, SECTION_SIZE_BITS=24 suits all the cases (segments are always spaced by a multiple of 16MB: 0xNM00.0000 with N=0,C,D,E,F depending of the chip select, and M=1,2,..,F). Now for SROMLL=1, I see at least 4 exceptions: - 64MBit/32bit/11x8x4banks => 4 segments of 2MB spaced by 4MB: - 0xN000-0xN01F - 0xN040-... - 0xN080-... - 0xN0C0-... 23 >= SECTION_SIZE_BITS >= 22 - 128MBit/32bit/12x9x4banks => 1 segment of 32 MB - 0xN000-0xN1FF SECTION_SIZE_BITS >= 25 - 256Mbit/32bit/13x9x4banks => 2 segments of 32 MB spaced by 64MB: - 0xN000-0xN1FF - 0xN400-... 26 >= SECTION_SIZE_BITS >=25 - 512Mbit/32bit/13x10x4 => 1 segment of 128 MB - 0xN000-0xN7FF SECTION_SIZE_BITS>=27 (Am I right Russel?) So on 12 possibilities, there's only 4 exceptions. And finally for the virt<->phys: There's 4 chip select, one of them can pop-up at two different addresses. The biggest SDRAM segment being 128MB, we have the following possible address ranges: 0x0000-0x07FF 0xC000-0xC7FF 0xD000-0xD7FF 0xE000-0xE7FF 0xF000-0xF7FF So why not a mapping like this one: 0xC000 => PAGE_OFFSET + 0x0000 (1100.0XXX => XX00.0XXX) 0xD000 => PAGE_OFFSET + 0x0800 (1101.0XXX => XX00.1XXX) 0xE000 => PAGE_OFFSET + 0x1000 (1110.0XXX => XX01.0XXX) 0xF000 => PAGE_OFFSET + 0x1800 (1111.0XXX => XX01.1XXX) 0x0000 => PAGE_OFFSET + 0x2000 (0000.0XXX => XX10.0XXX) Which should be done with: ((pa&0x80000000) ? (pa&0x07FFFFFF)|((pa&0x30000000)>>1) : (pa|0x20000000)) | PAGE_OFFSET and for virt_to_phys something like: (va&0x07FFFFFFF)| ((va&0x20000000) ? ((va&0x18000000)<<1)|0xC0000000 : 0x00000000) (NB: this macro is PHYS_OFFSET agnostic and allow the use of multiple chips select) A simpler possibility would be to activate sparsemem only for ts72xx and stuff memory.h with: #if defined(CONFIG_SPARSEMEM) #if defined(CONFIG_MACH_TS72XX) ... #else #error ... #endif #endif What do you think? Regards, Chris > > Maybe Russell can help (Cced). > > Regards, > Hartley ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem 2009-10-06 21:21 ` Christian Gagneraud @ 2009-10-06 21:26 ` Christian Gagneraud 0 siblings, 0 replies; 28+ messages in thread From: Christian Gagneraud @ 2009-10-06 21:26 UTC (permalink / raw) To: linux-arm-kernel Christian Gagneraud wrote: > H Hartley Sweeten wrote: >> On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote: >>> H Hartley Sweeten wrote: >>>> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote: >>>>> Hi, >>>>> >>>>> What people think about enabling sparsemem on EP93XX? I know this >>>>> patch as it is will break all but this board. >>>>> >>>>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that >>>>> will suit all the supported boards? >>>> With sparsemem enabled what is your memory detected during boot? For >>>> instance on my ep9307 based system with flatmem I get: >>>> >>>> Memory: 32MB 32MB = 64MB total >>>> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K >>>> highmem) >>> ^^^^^ >>> Are you missing 16MB? >> >> No. My rootfs is in /dev/ram and uses the remaining space. >> >>> Here is what i get with sparsemem: >>> >>> Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total >>> Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem) >>> >>> 00000000-007fffff : System RAM 00020000-00276fff : Kernel text >>> 00278000-002c1923 : Kernel data 01000000-017fffff : System RAM >>> 04000000-047fffff : System RAM 05000000-057fffff : System RAM >>> e0000000-e07fffff : System RAM e1000000-e17fffff : System RAM >>> e4000000-e47fffff : System RAM e5000000-e57fffff : System RAM >>> >>> For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that >>> shows at 0x00000000, for boards shipped with 64MB there's another >>> 32MB chip on SD_CS2 which pop up at 0xe0000000 >> >> OK. That makes sense. I was under the impression that the 64MB board >> was using a single chip select. >> >>> That's for the models that offer 32 or 64MB, but TS have other models >>> that offer 64 or 128MB, these boards are designed the same way: 1 >>> 64MB chip on SD_CS3 and optional a second 64MB chip on SD_CS2. >>> I was told that in that case 16 banks needed to be define (and btw it >>> couldn't be handled , I didn't check it yet. >> >> The single chip 64MB board would work fine but it would use 8 banks. The >> 128MB board would be a problem with flatmem because of the 16 banks. In >> order to support this NR_BANKS would have to be increased in >> arch/arm/include/asm/setup.h. >> >>> Before sparsemem, we had to use discontigmem (and patch it),now with >>> parsemem there's no needs for such a thing anymore, the only needed >>> bits are 4 #define. >> >> Sparsemem is probably a good solution for the multiple chip selects. But >> we need to make sure that any solution used works for all ep93xx >> variants. >> >> The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async) >> boot, there are 5 possible base addresses for them. Then, depending on >> the bus width and the density of memory used, the node mapping for each >> bank can vary greatly. Even worse, node mapping changes depending on the >> SROMLL bit. The document referenced below has all the information needed >> but at this point I don't know of a good solution. >> >>> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf > > Actually, in the EP93XX User's Manual, the table 13-11 on pages 3-12 to > 13-16 gives all the possibilities. It is exactly the same table actually, sorry for the noise. Regards, Chris. > > When SROMLL=0, SECTION_SIZE_BITS=24 suits all the cases (segments are > always spaced by a multiple of 16MB: 0xNM00.0000 with N=0,C,D,E,F > depending of the chip select, and M=1,2,..,F). > > Now for SROMLL=1, I see at least 4 exceptions: > - 64MBit/32bit/11x8x4banks => 4 segments of 2MB spaced by 4MB: > - 0xN000-0xN01F > - 0xN040-... > - 0xN080-... > - 0xN0C0-... > > 23 >= SECTION_SIZE_BITS >= 22 > > - 128MBit/32bit/12x9x4banks => 1 segment of 32 MB > - 0xN000-0xN1FF > > SECTION_SIZE_BITS >= 25 > > - 256Mbit/32bit/13x9x4banks => 2 segments of 32 MB spaced by 64MB: > - 0xN000-0xN1FF > - 0xN400-... > > 26 >= SECTION_SIZE_BITS >=25 > > - 512Mbit/32bit/13x10x4 => 1 segment of 128 MB > - 0xN000-0xN7FF > > SECTION_SIZE_BITS>=27 > > (Am I right Russel?) > > So on 12 possibilities, there's only 4 exceptions. > > And finally for the virt<->phys: > > There's 4 chip select, one of them can pop-up at two different > addresses. The biggest SDRAM segment being 128MB, we > have the following possible address ranges: > 0x0000-0x07FF > 0xC000-0xC7FF > 0xD000-0xD7FF > 0xE000-0xE7FF > 0xF000-0xF7FF > > So why not a mapping like this one: > 0xC000 => PAGE_OFFSET + 0x0000 (1100.0XXX => XX00.0XXX) > 0xD000 => PAGE_OFFSET + 0x0800 (1101.0XXX => XX00.1XXX) > 0xE000 => PAGE_OFFSET + 0x1000 (1110.0XXX => XX01.0XXX) > 0xF000 => PAGE_OFFSET + 0x1800 (1111.0XXX => XX01.1XXX) > 0x0000 => PAGE_OFFSET + 0x2000 (0000.0XXX => XX10.0XXX) > > Which should be done with: > ((pa&0x80000000) ? (pa&0x07FFFFFF)|((pa&0x30000000)>>1) : > (pa|0x20000000)) | PAGE_OFFSET > > and for virt_to_phys something like: > (va&0x07FFFFFFF)| ((va&0x20000000) ? ((va&0x18000000)<<1)|0xC0000000 : > 0x00000000) > (NB: this macro is PHYS_OFFSET agnostic and allow the use of multiple > chips select) > > A simpler possibility would be to activate sparsemem only for ts72xx and > stuff memory.h with: > > #if defined(CONFIG_SPARSEMEM) > #if defined(CONFIG_MACH_TS72XX) > ... > #else > #error ... > #endif > #endif > > > What do you think? > > Regards, > Chris > > >> >> Maybe Russell can help (Cced). >> >> Regards, >> Hartley > > ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2009-10-06 21:26 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-10-04 1:14 [RFC][PATCH v1.0] Update and enhance TS-7XXX support Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud 2009-10-04 11:05 ` Matthieu Crapet 2009-10-04 11:13 ` Alexander Clouter 2009-10-04 18:34 ` Bill Gatliff 2009-10-04 18:35 ` Bill Gatliff 2009-10-04 11:21 ` Russell King - ARM Linux 2009-10-04 11:55 ` Christian Gagneraud 2009-10-04 23:03 ` H Hartley Sweeten 2009-10-05 12:17 ` Christian Gagneraud 2009-10-05 14:10 ` Alexander Clouter 2009-10-05 15:15 ` Mikael Pettersson 2009-10-05 16:01 ` Marek Vasut 2009-10-05 18:34 ` Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 3/4] EP93XX: Add more register definition Christian Gagneraud 2009-10-04 19:33 ` Ryan Mallon 2009-10-04 23:09 ` H Hartley Sweeten 2009-10-05 12:06 ` Christian Gagneraud 2009-10-05 16:51 ` H Hartley Sweeten 2009-10-05 18:30 ` Christian Gagneraud 2009-10-04 1:14 ` [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem Christian Gagneraud 2009-10-05 12:21 ` Christian Gagneraud 2009-10-05 17:06 ` H Hartley Sweeten 2009-10-05 18:16 ` Christian Gagneraud 2009-10-05 18:52 ` H Hartley Sweeten 2009-10-06 21:21 ` Christian Gagneraud 2009-10-06 21:26 ` Christian Gagneraud
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).