From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH] arm: Allow mounting root on omaps with CPU_V6 and CPU_V7
Date: Fri, 19 Feb 2010 10:03:32 -0800 [thread overview]
Message-ID: <20100219180331.GC21755@atomide.com> (raw)
In-Reply-To: <20100219083556.GB19649@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
* Russell King - ARM Linux <linux@arm.linux.org.uk> [100219 00:33]:
> On Thu, Feb 18, 2010 at 04:27:48PM -0800, Tony Lindgren wrote:
> > @@ -779,5 +779,5 @@ config CACHE_XSC3L2
> >
> > config ARM_L1_CACHE_SHIFT
> > int
> > - default 6 if ARCH_OMAP3 || ARCH_S5PC1XX
> > + default 6 if (ARCH_OMAP3 || ARCH_S5PC1XX) && !ARCH_OMAP2
> > default 5
>
> This one is definitely wrong. Setting the L1 cache line size larger
> than it actually is should be safe; setting it smaller is definitely
> unsafe.
OK dropped that part, updated patch below. Maybe the VFPv3
code can be fixed to boot on earlier hardware too.
So I guess ARM_L1_CACHE_SHIFT should be only used for alignment, and
not for for cache operations?
If so, then what have in arch/arm/plat-omap/iommu.c seems buggy:
static void flush_iopgd_range(u32 *first, u32 *last)
{
/* FIXME: L2 cache should be taken care of if it exists */
do {
asm("mcr p15, 0, %0, c7, c10, 1 @ flush_pgd"
: : "r" (first));
first += L1_CACHE_BYTES / sizeof(*first);
} while (first <= last);
}
It seems that this code should use the real cache line size instead to
avoid every other line not to flush if ARM_L1_CACHE_SHIFT is set larger
than it is.
Regards,
Tony
[-- Attachment #2: v6-v7-mount-root-v2.patch --]
[-- Type: text/x-diff, Size: 1374 bytes --]
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 18 Feb 2010 16:28:26 -0800
Subject: [PATCH] arm: Allow mounting root on omaps with CPU_V6 and CPU_V7
To mount root, we need to disable VFPv3 and HAS_TLS_REG.
Otherwise we'll get something like this for CPUv3:
Freeing init memory: 184K
Internal error: Oops - undefined instruction: 0 [#1]
last sysfs file:
Modules linked in:
CPU: 0 Not tainted (2.6.33-rc8-07824-gf2e1d91-dirty #36)
PC is at no_old_VFP_process+0x8/0x3c
LR is at __und_usr_unknown+0x0/0x14
...
Or the system just hangs if HAS_TLS_REG is set.
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 184a6bd..7b93898 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1498,7 +1498,7 @@ config VFP
config VFPv3
bool
depends on VFP
- default y if CPU_V7
+ default y if CPU_V7 && !ARCH_OMAP2
config NEON
bool "Advanced SIMD (NEON) Extension support"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 4c2e90d..65f5ebd 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -718,7 +718,7 @@ config TLS_REG_EMUL
config HAS_TLS_REG
bool
depends on !TLS_REG_EMUL
- default y if SMP || CPU_32v7
+ default y if (SMP || CPU_32v7) && !ARCH_OMAP2
help
This selects support for the CP15 thread register.
It is defined to be available on some ARMv6 processors (including
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: Allow mounting root on omaps with CPU_V6 and CPU_V7
Date: Fri, 19 Feb 2010 10:03:32 -0800 [thread overview]
Message-ID: <20100219180331.GC21755@atomide.com> (raw)
In-Reply-To: <20100219083556.GB19649@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [100219 00:33]:
> On Thu, Feb 18, 2010 at 04:27:48PM -0800, Tony Lindgren wrote:
> > @@ -779,5 +779,5 @@ config CACHE_XSC3L2
> >
> > config ARM_L1_CACHE_SHIFT
> > int
> > - default 6 if ARCH_OMAP3 || ARCH_S5PC1XX
> > + default 6 if (ARCH_OMAP3 || ARCH_S5PC1XX) && !ARCH_OMAP2
> > default 5
>
> This one is definitely wrong. Setting the L1 cache line size larger
> than it actually is should be safe; setting it smaller is definitely
> unsafe.
OK dropped that part, updated patch below. Maybe the VFPv3
code can be fixed to boot on earlier hardware too.
So I guess ARM_L1_CACHE_SHIFT should be only used for alignment, and
not for for cache operations?
If so, then what have in arch/arm/plat-omap/iommu.c seems buggy:
static void flush_iopgd_range(u32 *first, u32 *last)
{
/* FIXME: L2 cache should be taken care of if it exists */
do {
asm("mcr p15, 0, %0, c7, c10, 1 @ flush_pgd"
: : "r" (first));
first += L1_CACHE_BYTES / sizeof(*first);
} while (first <= last);
}
It seems that this code should use the real cache line size instead to
avoid every other line not to flush if ARM_L1_CACHE_SHIFT is set larger
than it is.
Regards,
Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v6-v7-mount-root-v2.patch
Type: text/x-diff
Size: 1374 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100219/fb979dbd/attachment.bin>
next prev parent reply other threads:[~2010-02-19 18:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 0:27 [PATCH] arm: Allow mounting root on omaps with CPU_V6 and CPU_V7 Tony Lindgren
2010-02-19 0:27 ` Tony Lindgren
2010-02-19 8:35 ` Russell King - ARM Linux
2010-02-19 8:35 ` Russell King - ARM Linux
2010-02-19 18:03 ` Tony Lindgren [this message]
2010-02-19 18:03 ` Tony Lindgren
2010-02-19 19:25 ` Russell King - ARM Linux
2010-02-19 19:25 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100219180331.GC21755@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.