* Tony Lindgren <tony@xxxxxxxxxxx> [171110 03:28]:
> * Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> [171110 00:10]:
> > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote:
> > > Hmm OK. Does your first patch above now have the initcall issue too?
> > > It boots if I make that also subsys_initcall and then I get:
> >
> > > [ 2.078094] vmalloc_pool_init: DMA: get vmalloc area: d0010000
> >
> > Yes, first patch has the initcall issue and it's intentional in order
> > to check the theory. I checked following log for this.
> >
> > - Boot failure
> > SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
> > SRAM_ADDR: omap_map_sram: V: 0xd0050000 - 0xd0057000
> >
> > - Boot success
> > SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
> > SRAM_ADDR: omap_map_sram: V: 0xd0008000 - 0xd000f000
> >
> > When failure, virtual address for sram is higher than normal one due
> > to vmalloc area allocation in __dma_alloc_remap(). If it is deferred,
> > virtual address is the same with success case and then the system work.
> >
> > So, my next theory is that there is n900 specific assumption that sram
> > should have that address. Could you check if any working tree for n900
> > which doesn't have my CMA series work or not with adding
> > "arm/dma: vmalloc area allocation"?
>
> Oh I see, sorry I was not following you earlier. So you mean that
> by adding the vmalloc_pool_init() initcall the va mapping for SRAM
> changes.
>
> And yes, save_secure_ram_context seems to be doing some sketchy
> virt to phys calculation with sram_phy_addr_mask. Here's a small
> patch to fix that for your CMA series, maybe you can merge it
> with your series to avoid breaking booting for git bisect.
>
> Then I'll follow up on cleaning up save_secure_ram_context later.
Here's a better version, the static mapping did not get used.. It
just moved the area so it happened to work. It needs to be set
up as MT_MEMORY_RWX_NONCACHED instead.
Regards,
Tony
8< -------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@xxxxxxxxxxx>
Date: Thu, 9 Nov 2017 17:05:34 -0800
Subject: [PATCH] ARM: OMAP2+: Add static SRAM mapping for
save_secure_ram_context
With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>, it
was noticed that n900 stopped booting. After investigating it turned
out that n900 save_secure_ram_context does some whacky virtual to
physical address translation for the SRAM data address.
Let's fix this for CMA changes by adding a static mapping for SRAM
on omap3. Then we can follow up with a patch to clean up the address
translation in save_secure_ram_context later on.
Debugged-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
---
arch/arm/mach-omap2/io.c | 6 ++++++
arch/arm/mach-omap2/iomap.h | 4 ++++
2 files changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -139,6 +139,12 @@ static struct map_desc omap243x_io_desc[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
static struct map_desc omap34xx_io_desc[] __initdata = {
+ {
+ .virtual = OMAP34XX_SRAM_VIRT,
+ .pfn = __phys_to_pfn(OMAP34XX_SRAM_PHYS),
+ .length = OMAP34XX_SRAM_SIZE,
+ .type = MT_MEMORY_RWX_NONCACHED
+ },
{
.virtual = L3_34XX_VIRT,
.pfn = __phys_to_pfn(L3_34XX_PHYS),
diff --git a/arch/arm/mach-omap2/iomap.h b/arch/arm/mach-omap2/iomap.h
--- a/arch/arm/mach-omap2/iomap.h
+++ b/arch/arm/mach-omap2/iomap.h
@@ -123,6 +123,10 @@
* VPOM3430 was not working for Int controller
*/
+#define OMAP34XX_SRAM_PHYS 0x40200000
+#define OMAP34XX_SRAM_VIRT 0xd0010000
+#define OMAP34XX_SRAM_SIZE 0x10000
+
#define L4_PER_34XX_PHYS L4_PER_34XX_BASE
/* 0x49000000 --> 0xfb000000 */
#define L4_PER_34XX_VIRT (L4_PER_34XX_PHYS + OMAP2_L4_IO_OFFSET)
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
