Here are a couple mach-ep93xx patches that I have been holding on to.
Some of these have been previously posted.
The first patch is needed for 128 MiB version of the TS-7300 board.
That board uses multiple chip selects for the SDRAM and does not boot
with the previous flatmem setup. With the switch, all the other ep93xx
boards I have still work properly.
The second patch has been rebased due to the chip select change in
the spi-ep93xx driver which has been merged.
Patch 3 is just a cosmetic change.
Patch 4 was originally from Florian Fainelli's github ts72xx branch.
It has been updated to the new spi-ep93xx chip select method.
H Hartley Sweeten (4):
ARM: ep93xx: switch to SPARSEMEM
ARM: ep93xx: simone: let the mmc_spi driver handle the card detect
ARM: ep93xx: tidy up TS-72xx Watchdog resources
ARM: ep93xx: Add lm70 HWMON sensor to TS-72xx boards
arch/arm/Kconfig | 2 +-
arch/arm/mach-ep93xx/simone.c | 54 +++----------------------------------------
arch/arm/mach-ep93xx/ts72xx.c | 47 +++++++++++++++++++++++++++----------
arch/arm/mach-ep93xx/ts72xx.h | 3 ---
4 files changed, 39 insertions(+), 67 deletions(-)
--
2.10.0
The EP93xx has four chip selects that can be used for the SDRAM memory.
These chip selects are decoded to specify an address domain:
SDCS3 0x00000000-0x0fffffff with Boot Option ASDO=1
SDCS0 0xc0000000-0xcfffffff
SDCS1 0xd0000000-0xdfffffff
SDCS2 0xe0000000-x0efffffff
SDCS3 0xf0000000-0xffffffff with Boot Option ASDO=0
Because of the row/column/bank architecture of SDRAM, the mapping of
these memories into the processor's memory space is discontiguous.
Most ep93xx systems only use one of the chip selects. For these systems,
ARCH_HAS_HOLES_MEMORYMODEL has worked fine to handle the discontiguous
memory.
But, some of the TS-72xx boards use multiple chip selects. The TS-7300 in
particular uses SDCS3 (with ASDO=1) and SDCS2. On that system with
ARCH_HAS_HOLES_MEMORYMODEL the SDCS2 memory does not get handled correctly
and results in the system not booting.
Change the EP93xx to ARCH_SPARSEMEM_ENABLE. This handles the discontiguous
memory for all configurations.
This has been tested on the following ep93xx platforms:
EDB9307A with 64 MiB on SDCS0
Vision EP9307 with 64 MiB on SDCS0
TS-7300 with 64 MiB on SDCS3 (with ASDO=1) and 64 MiB on SDCS2
sim.one with 64 MiB on SDCS0
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
Cc: Russell King <linux@armlinux.org.uk>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This board uses a GPIO for the MMC card detect. Let the mmc_spi
driver handle it instead of the platform code.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
---
arch/arm/mach-ep93xx/simone.c | 54 +++----------------------------------------
1 file changed, 3 insertions(+), 51 deletions(-)
The ts-72xx watchdog uses two byte sized registers. Tidy up the resource
declaration so that the proper information is shown in /proc/iomem.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
arch/arm/mach-ep93xx/ts72xx.c | 20 +++++++++-----------
arch/arm/mach-ep93xx/ts72xx.h | 3 ---
2 files changed, 9 insertions(+), 14 deletions(-)
Register the TI TMP122 (lm70) temperature sensor driver for the TS-72xx
boards.
Originaly from Florian Fainelli. Updated to the new spi-ep93xx chip select
method.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mach-ep93xx/ts72xx.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
The EP93xx has four chip selects that can be used for the SDRAM memory.
These chip selects are decoded to specify an address domain:
SDCS3 0x00000000-0x0fffffff with Boot Option ASDO=1
SDCS0 0xc0000000-0xcfffffff
SDCS1 0xd0000000-0xdfffffff
SDCS2 0xe0000000-x0efffffff
SDCS3 0xf0000000-0xffffffff with Boot Option ASDO=0
Because of the row/column/bank architecture of SDRAM, the mapping of
these memories into the processor's memory space is discontiguous.
Most ep93xx systems only use one of the chip selects. For these systems,
ARCH_HAS_HOLES_MEMORYMODEL has worked fine to handle the discontiguous
memory.
But, some of the TS-72xx boards use multiple chip selects. The TS-7300 in
particular uses SDCS3 (with ASDO=1) and SDCS2. On that system with
ARCH_HAS_HOLES_MEMORYMODEL the SDCS2 memory does not get handled correctly
and results in the system not booting.
Change the EP93xx to ARCH_SPARSEMEM_ENABLE. This handles the discontiguous
memory for all configurations.
This has been tested on the following ep93xx platforms:
EDB9307A with 64 MiB on SDCS0
Vision EP9307 with 64 MiB on SDCS0
TS-7300 with 64 MiB on SDCS3 (with ASDO=1) and 64 MiB on SDCS2
sim.one with 64 MiB on SDCS0
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
Cc: Russell King <linux@armlinux.org.uk>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
On a TS-3700 with 32MiB of SDRAM, thanks!
--
Florian
This board uses a GPIO for the MMC card detect. Let the mmc_spi
driver handle it instead of the platform code.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
The ts-72xx watchdog uses two byte sized registers. Tidy up the resource
declaration so that the proper information is shown in /proc/iomem.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Register the TI TMP122 (lm70) temperature sensor driver for the TS-72xx
boards.
Originaly from Florian Fainelli. Updated to the new spi-ep93xx chip select
method.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Hi Hartley,
Le 02/21/17 ? 10:15, H Hartley Sweeten a ?crit :
Here are a couple mach-ep93xx patches that I have been holding on to.
Some of these have been previously posted.
The first patch is needed for 128 MiB version of the TS-7300 board.
That board uses multiple chip selects for the SDRAM and does not boot
with the previous flatmem setup. With the switch, all the other ep93xx
boards I have still work properly.
The second patch has been rebased due to the chip select change in
the spi-ep93xx driver which has been merged.
Patch 3 is just a cosmetic change.
Patch 4 was originally from Florian Fainelli's github ts72xx branch.
It has been updated to the new spi-ep93xx chip select method.
Patch 4 does no longer apply cleanly because of this commit:
264a4e1c6241fddc5980b3429e133621b3fe01fe ("ARM: EP93xx: Register ethoc
on TS-7300 boards"), do you mind resubmitting so this can be included?
Thanks!
H Hartley Sweeten (4):
ARM: ep93xx: switch to SPARSEMEM
ARM: ep93xx: simone: let the mmc_spi driver handle the card detect
ARM: ep93xx: tidy up TS-72xx Watchdog resources
ARM: ep93xx: Add lm70 HWMON sensor to TS-72xx boards
arch/arm/Kconfig | 2 +-
arch/arm/mach-ep93xx/simone.c | 54 +++----------------------------------------
arch/arm/mach-ep93xx/ts72xx.c | 47 +++++++++++++++++++++++++++----------
arch/arm/mach-ep93xx/ts72xx.h | 3 ---
4 files changed, 39 insertions(+), 67 deletions(-)
The EP93xx has four chip selects that can be used for the SDRAM memory.
These chip selects are decoded to specify an address domain:
SDCS3 0x00000000-0x0fffffff with Boot Option ASDO=1
SDCS0 0xc0000000-0xcfffffff
SDCS1 0xd0000000-0xdfffffff
SDCS2 0xe0000000-x0efffffff
SDCS3 0xf0000000-0xffffffff with Boot Option ASDO=0
Because of the row/column/bank architecture of SDRAM, the mapping of
these memories into the processor's memory space is discontiguous.
Most ep93xx systems only use one of the chip selects. For these systems,
ARCH_HAS_HOLES_MEMORYMODEL has worked fine to handle the discontiguous
memory.
But, some of the TS-72xx boards use multiple chip selects. The TS-7300 in
particular uses SDCS3 (with ASDO=1) and SDCS2. On that system with
ARCH_HAS_HOLES_MEMORYMODEL the SDCS2 memory does not get handled correctly
and results in the system not booting.
Change the EP93xx to ARCH_SPARSEMEM_ENABLE. This handles the discontiguous
memory for all configurations.
This has been tested on the following ep93xx platforms:
EDB9307A with 64 MiB on SDCS0
Vision EP9307 with 64 MiB on SDCS0
TS-7300 with 64 MiB on SDCS3 (with ASDO=1) and 64 MiB on SDCS2
sim.one with 64 MiB on SDCS0
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
Cc: Russell King <linux@armlinux.org.uk>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
On a TS-3700 with 32MiB of SDRAM, thanks!
OK this is weird, this patch applied against v4.11 works fine on a 32MB
board configuration, but applied against v4.12-rc2 I now get the following:
Uncompressing Linux... done, booting the kernel.
Warning: Neither atags nor dtb found
as if r2 was lost somehow.
I will start a bisection to figure out if/when it started to break.
Russell do you have an idea?
--
Florian
Hello Florian,
On 26/05/17 18:13, Florian Fainelli wrote:
quoted
quoted
The EP93xx has four chip selects that can be used for the SDRAM memory.
These chip selects are decoded to specify an address domain:
SDCS3 0x00000000-0x0fffffff with Boot Option ASDO=1
SDCS0 0xc0000000-0xcfffffff
SDCS1 0xd0000000-0xdfffffff
SDCS2 0xe0000000-x0efffffff
SDCS3 0xf0000000-0xffffffff with Boot Option ASDO=0
Because of the row/column/bank architecture of SDRAM, the mapping of
these memories into the processor's memory space is discontiguous.
Most ep93xx systems only use one of the chip selects. For these systems,
ARCH_HAS_HOLES_MEMORYMODEL has worked fine to handle the discontiguous
memory.
But, some of the TS-72xx boards use multiple chip selects. The TS-7300 in
particular uses SDCS3 (with ASDO=1) and SDCS2. On that system with
ARCH_HAS_HOLES_MEMORYMODEL the SDCS2 memory does not get handled correctly
and results in the system not booting.
Change the EP93xx to ARCH_SPARSEMEM_ENABLE. This handles the discontiguous
memory for all configurations.
This has been tested on the following ep93xx platforms:
EDB9307A with 64 MiB on SDCS0
Vision EP9307 with 64 MiB on SDCS0
TS-7300 with 64 MiB on SDCS3 (with ASDO=1) and 64 MiB on SDCS2
sim.one with 64 MiB on SDCS0
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
Cc: Russell King <linux@armlinux.org.uk>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
On a TS-3700 with 32MiB of SDRAM, thanks!
OK this is weird, this patch applied against v4.11 works fine on a 32MB
board configuration, but applied against v4.12-rc2 I now get the following:
Uncompressing Linux... done, booting the kernel.
Warning: Neither atags nor dtb found
as if r2 was lost somehow.
I will start a bisection to figure out if/when it started to break.
Russell do you have an idea?
I've applied the patch to 4.12-rc2 as well (to be more precise, 1b8f2ffc of Linus's tree),
and it boots fine on EDB9302 (32MiB one chip on SDCS3). I even ran "memtester" fine, one
iteration.
So, from my PoV
Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
--
Regards,
Alexander.
Hello Florian,
On 26/05/17 18:13, Florian Fainelli wrote:
quoted
quoted
quoted
The EP93xx has four chip selects that can be used for the SDRAM memory.
These chip selects are decoded to specify an address domain:
SDCS3 0x00000000-0x0fffffff with Boot Option ASDO=1
SDCS0 0xc0000000-0xcfffffff
SDCS1 0xd0000000-0xdfffffff
SDCS2 0xe0000000-x0efffffff
SDCS3 0xf0000000-0xffffffff with Boot Option ASDO=0
Because of the row/column/bank architecture of SDRAM, the mapping of
these memories into the processor's memory space is discontiguous.
Most ep93xx systems only use one of the chip selects. For these systems,
ARCH_HAS_HOLES_MEMORYMODEL has worked fine to handle the discontiguous
memory.
But, some of the TS-72xx boards use multiple chip selects. The TS-7300 in
particular uses SDCS3 (with ASDO=1) and SDCS2. On that system with
ARCH_HAS_HOLES_MEMORYMODEL the SDCS2 memory does not get handled correctly
and results in the system not booting.
Change the EP93xx to ARCH_SPARSEMEM_ENABLE. This handles the discontiguous
memory for all configurations.
This has been tested on the following ep93xx platforms:
EDB9307A with 64 MiB on SDCS0
Vision EP9307 with 64 MiB on SDCS0
TS-7300 with 64 MiB on SDCS3 (with ASDO=1) and 64 MiB on SDCS2
sim.one with 64 MiB on SDCS0
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: Linus Walleij <redacted>
Cc: Russell King <linux@armlinux.org.uk>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
On a TS-3700 with 32MiB of SDRAM, thanks!
OK this is weird, this patch applied against v4.11 works fine on a 32MB
board configuration, but applied against v4.12-rc2 I now get the following:
Uncompressing Linux... done, booting the kernel.
Warning: Neither atags nor dtb found
as if r2 was lost somehow.
I will start a bisection to figure out if/when it started to break.
Russell do you have an idea?
I've applied the patch to 4.12-rc2 as well (to be more precise, 1b8f2ffc of Linus's tree),
and it boots fine on EDB9302 (32MiB one chip on SDCS3). I even ran "memtester" fine, one
iteration.
I need to debug this further because it does not make sense to me why
this patch on 4.12-rc1 works but on on 4.1-2-rc2 other than just having
a bit more bloat one image vs. another.
Thanks!
So, from my PoV
Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
--
Regards,
Alexander.
On Friday, May 26, 2017 2:50 PM, Florian Fainelli wrote:
On 05/26/2017 02:28 PM, Alexander Sverdlin wrote:
quoted
I've applied the patch to 4.12-rc2 as well (to be more precise, 1b8f2ffc of Linus's tree),
and it boots fine on EDB9302 (32MiB one chip on SDCS3). I even ran "memtester" fine, one
iteration.
I need to debug this further because it does not make sense to me why
this patch on 4.12-rc1 works but on on 4.1-2-rc2 other than just having
a bit more bloat one image vs. another.
The bloat might be the problem.
In my earlier testing with the TS-7300 I found that if my uncompressed image/rootfs was
larger than then SDRAM segment size the system would not boot. I think I sent an email
to you regarding this when I was first trying to get the TS-7300 to boot a newer kernel.
Hartley
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-05-26 22:39:21
On Fri, May 26, 2017 at 09:13:36AM -0700, Florian Fainelli wrote:
OK this is weird, this patch applied against v4.11 works fine on a 32MB
board configuration, but applied against v4.12-rc2 I now get the following:
Uncompressing Linux... done, booting the kernel.
Warning: Neither atags nor dtb found
as if r2 was lost somehow.
I will start a bisection to figure out if/when it started to break.
Russell do you have an idea?
I've seen it on other platforms where the dtb is placed too close to
the kernel image, so when the decompressor relocates itself, it ends
up overwriting the dtb.
Remember that the bigger the decompressed kernel image, the higher
the decompressor relocates itself in memory.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.