generic early_ioremap support

PATCH Superseded Mark Salter 6 participants 19 messages Feb 12, 2014 – Mar 4, 2014

Subsystems (9)

Memory management Documentation Arm (32-bit) x86 +5 more subsystems

lore

Share & tools

lore

Mark Salter

author

2014-02-12 20:56 UTC #0 lore raw

v4 cover generic early_ioremap support

This patch series takes the common bits from the x86 early ioremap implementation and creates a generic implementation which may be used by other architectures. The early ioremap interfaces are intended for situations where boot code needs to make temporary virtual mappings before the normal ioremap interfaces are available. Typically, this means before paging_init() has run.

These patches are layered on top of generic fixmap patches which were pulled into 3.14-rc with the exception of the arm patch:

https://lkml.org/lkml/2013/11/25/477

The arm fixmap patch is currently in the akpm tree and has been part of linux-next for a while.

This is version 4 of the patch series. These patches (and underlying fixmap patches) may be found at:

git://github.com/mosalter/linux.git (early-ioremap-v4 branch)

Changes from version 3:

* Removed dependency on MMU. In the case of no-MMU, the early remap functions return the address passed in. This helps simplify use of early_ioremap functions on architectures such as ARM which have optional MMU support.

* Added L_PTE_XN to arm page flags so mappings are non-executable.

* Include linux/io.h rather than asm/io.h in arm setup.c

* Moved early_ioremap_init() before setup_machine_fdt() in arm

    setup_arch().

* Fixed mispelling in config EARLY_IOREMAP help text.

Changes from version 2:

* Added some Acks

* Incorporated a patch from Dave Young to change the signature of early_memremap() (dropping __iomem from returned pointer) which is the first patch in a larger series:

https://lkml.org/lkml/2013/12/22/69

This allows the change of just the x86 function signature to be bisected.

Changes from version 1:

* Moved the generic code into linux/mm instead of linux/lib

* Have early_memremap() return normal pointer instead of __iomem This is in response to sparse warning cleanups being made in an unrelated patch series:

https://lkml.org/lkml/2013/12/22/69

* Added arm64 patch to call init_mem_pgprot() earlier so that the pgprot macros are valid in time for early_ioremap use

* Added validity checking for early_ioremap pgd, pud, and pmd in arm64

Dave Young (1):
x86/mm: sparse warning fix for early_memremap

Mark Salter (5):
mm: create generic early_ioremap() support
x86: use generic early_ioremap
arm: add early_ioremap support
arm64: initialize pgprot info earlier in boot
arm64: add early_ioremap support

 Documentation/arm64/memory.txt      |   4 +-
 arch/arm/Kconfig                    |  10 ++
 arch/arm/include/asm/Kbuild         |   1 +
 arch/arm/include/asm/fixmap.h       |  20 +++
 arch/arm/include/asm/io.h           |   1 +
 arch/arm/kernel/setup.c             |   2 +
 arch/arm/mm/Makefile                |   4 +
 arch/arm/mm/early_ioremap.c         |  93 +++++++++++++
 arch/arm/mm/mmu.c                   |   2 +
 arch/arm64/Kconfig                  |   1 +
 arch/arm64/include/asm/Kbuild       |   1 +
 arch/arm64/include/asm/fixmap.h     |  67 +++++++++
 arch/arm64/include/asm/io.h         |   1 +
 arch/arm64/include/asm/memory.h     |   2 +-
 arch/arm64/include/asm/mmu.h        |   1 +
 arch/arm64/kernel/early_printk.c    |   8 +-
 arch/arm64/kernel/head.S            |   9 +-
 arch/arm64/kernel/setup.c           |   4 +
 arch/arm64/mm/ioremap.c             |  85 +++++++++++
 arch/arm64/mm/mmu.c                 |  44 +-----
 arch/x86/Kconfig                    |   1 +
 arch/x86/include/asm/Kbuild         |   1 +
 arch/x86/include/asm/fixmap.h       |   6 +
 arch/x86/include/asm/io.h           |  14 +-
 arch/x86/mm/ioremap.c               | 224 +----------------------------
 arch/x86/mm/pgtable_32.c            |   2 +-
 include/asm-generic/early_ioremap.h |  42 ++++++
 mm/Kconfig                          |   3 +
 mm/Makefile                         |   1 +
 mm/early_ioremap.c                  | 271 ++++++++++++++++++++++++++++++++++++
 30 files changed, 636 insertions(+), 289 deletions(-)
 create mode 100644 arch/arm/mm/early_ioremap.c
 create mode 100644 arch/arm64/include/asm/fixmap.h
 create mode 100644 include/asm-generic/early_ioremap.h
 create mode 100644 mm/early_ioremap.c

Signature · 1 line

1.8.5.3

Mark Salter

author

2014-02-12 20:56 UTC #1 lore raw

PATCH v4 1/6 x86/mm: sparse warning fix for early_memremap

From: Dave Young <[email protected]>

There's a lot of sparse warnings for code like below:
void *a = early_memremap(phys_addr, size);

early_memremap intend to map kernel memory with ioremap facility, the return pointer should be a kernel ram pointer instead of iomem one.

For making the function clearer and supressing sparse warnings this patch do below two things:
1. cast to (__force void *) for the return value of early_memremap
2. add early_memunmap function and pass (__force void __iomem *) to iounmap

Quoted 4 lines

From Boris:
Ingo told me yesterday, it makes sense too. I'd guess we can try it. FWIW, all callers of early_memremap use the memory they get remapped as normal memory so we should be safe.

Signed-off-by Dave Young <[email protected]>

Signed-off-by Mark Salter <[email protected]>

---
 arch/x86/include/asm/io.h |  3 ++-
 arch/x86/mm/ioremap.c     | 10 +++++++---
 2 files changed, 9 insertions(+), 4 deletions(-)

arch/x86/include/asm/io.h +2 -1

index 34f69cb..1db414f 100644
@@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
 extern void early_ioremap_reset(void);
 extern void __iomem *early_ioremap(resource_size_t phys_addr,
 				   unsigned long size);
-extern void __iomem *early_memremap(resource_size_t phys_addr,
+extern void *early_memremap(resource_size_t phys_addr,
 				    unsigned long size);
 extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
 extern void fixup_early_ioremap(void);
 extern bool is_early_ioremap_ptep(pte_t *ptep);

arch/x86/mm/ioremap.c +7 -3

index 799580c..bbb4504 100644
@@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
 }
 
 /* Remap memory */
-void __init __iomem *
-early_memremap(resource_size_t phys_addr, unsigned long size)
+void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
 {
-	return __early_ioremap(phys_addr, size, PAGE_KERNEL);
+	return (__force void *)__early_ioremap(phys_addr, size, PAGE_KERNEL);
 }
 
 void __init early_iounmap(void __iomem *addr, unsigned long size)

@@ -620,3 +619,8 @@ void __init early_iounmap(void __iomem *addr, unsigned long size)
 	}
 	prev_map[slot] = NULL;
 }
+
+void __init early_memunmap(void *addr, unsigned long size)
+{
+	early_iounmap((__force void __iomem *)addr, size);
+}

Signature · 1 line

1.8.5.3

Mark Salter

author

2014-02-12 20:56 UTC #2 lore raw

PATCH v4 2/6 mm: create generic early_ioremap() support

In reply to Mark Salter

This patch creates a generic implementation of early_ioremap() support based on the existing x86 implementation. early_ioremp() is useful for early boot code which needs to temporarily map I/O or memory regions before normal mapping functions such as ioremap() are available.

Some architectures have optional MMU. In the no-MMU case, the remap functions simply return the passed in physical address and the unmap functions do nothing.

Signed-off-by Mark Salter <[email protected]>

Acked-by Catalin Marinas <[email protected]>

---
 include/asm-generic/early_ioremap.h |  42 ++++++
 mm/Kconfig                          |   3 +
 mm/Makefile                         |   1 +
 mm/early_ioremap.c                  | 271 ++++++++++++++++++++++++++++++++++++
 4 files changed, 317 insertions(+)
 create mode 100644 include/asm-generic/early_ioremap.h
 create mode 100644 mm/early_ioremap.c

include/asm-generic/early_ioremap.h new file +42 -0

new file mode 100644
index 0000000..a5de55c
@@ -0,0 +1,42 @@
+#ifndef _ASM_EARLY_IOREMAP_H_
+#define _ASM_EARLY_IOREMAP_H_
+
+#include <linux/types.h>
+
+/*
+ * early_ioremap() and early_iounmap() are for temporary early boot-time
+ * mappings, before the real ioremap() is functional.
+ */
+extern void __iomem *early_ioremap(resource_size_t phys_addr,
+				   unsigned long size);
+extern void *early_memremap(resource_size_t phys_addr,
+			    unsigned long size);
+extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
+
+/*
+ * Weak function called by early_ioremap_reset(). It does nothing, but
+ * architectures may provide their own version to do any needed cleanups.
+ */
+extern void early_ioremap_shutdown(void);
+
+#if defined(CONFIG_GENERIC_EARLY_IOREMAP) && defined(CONFIG_MMU)
+/* Arch-specific initialization */
+extern void early_ioremap_init(void);
+
+/* Generic initialization called by architecture code */
+extern void early_ioremap_setup(void);
+
+/*
+ * Called as last step in paging_init() so library can act
+ * accordingly for subsequent map/unmap requests.
+ */
+extern void early_ioremap_reset(void);
+
+#else
+static inline void early_ioremap_init(void) { }
+static inline void early_ioremap_setup(void) { }
+static inline void early_ioremap_reset(void) { }
+#endif
+
+#endif /* _ASM_EARLY_IOREMAP_H_ */

mm/Kconfig +3 -0

index 2d9f150..bf846a2 100644
@@ -577,3 +577,6 @@ config PGTABLE_MAPPING
 
 	  You can check speed with zsmalloc benchmark[1].
 	  [1] https://github.com/spartacus06/zsmalloc
+
+config GENERIC_EARLY_IOREMAP
+	bool

mm/Makefile +1 -0

index 310c90a..9d9c587 100644
@@ -61,3 +61,4 @@ obj-$(CONFIG_CLEANCACHE) += cleancache.o
 obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
 obj-$(CONFIG_ZBUD)	+= zbud.o
 obj-$(CONFIG_ZSMALLOC)	+= zsmalloc.o
+obj-$(CONFIG_GENERIC_EARLY_IOREMAP) += early_ioremap.o

mm/early_ioremap.c new file +271 -0

271 lines not on this page · raw message

Signature · 1 line

1.8.5.3

Mark Salter

author

2014-02-12 20:57 UTC #3 lore raw

PATCH v4 3/6 x86: use generic early_ioremap

In reply to Mark Salter

Move x86 over to the generic early ioremap implementation.

Signed-off-by Mark Salter <[email protected]>

---
 arch/x86/Kconfig              |   1 +
 arch/x86/include/asm/Kbuild   |   1 +
 arch/x86/include/asm/fixmap.h |   6 ++
 arch/x86/include/asm/io.h     |  15 +--
 arch/x86/mm/ioremap.c         | 228 +-----------------------------------------
 arch/x86/mm/pgtable_32.c      |   2 +-
 6 files changed, 13 insertions(+), 240 deletions(-)

arch/x86/Kconfig +1 -0

index 0af5250..fb479bc 100644
@@ -127,6 +127,7 @@ config X86
 	select HAVE_DEBUG_STACKOVERFLOW
 	select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
 	select HAVE_CC_STACKPROTECTOR
+	select GENERIC_EARLY_IOREMAP
 
 config INSTRUCTION_DECODER
 	def_bool y

arch/x86/include/asm/Kbuild +1 -0

index 7f66985..203f5f9 100644
@@ -5,3 +5,4 @@ genhdr-y += unistd_64.h
 genhdr-y += unistd_x32.h
 
 generic-y += clkdev.h
+generic-y += early_ioremap.h

arch/x86/include/asm/fixmap.h +6 -0

index 7252cd3..e5f236d 100644
@@ -177,5 +177,11 @@ static inline void __set_fixmap(enum fixed_addresses idx,
 
 #include <asm-generic/fixmap.h>
 
+#define __late_set_fixmap(idx, phys, flags) __set_fixmap(idx, phys, flags)
+#define __late_clear_fixmap(idx) __set_fixmap(idx, 0, __pgprot(0))
+
+void __early_set_fixmap(enum fixed_addresses idx,
+			phys_addr_t phys, pgprot_t flags);
+
 #endif /* !__ASSEMBLY__ */
 #endif /* _ASM_X86_FIXMAP_H */

arch/x86/include/asm/io.h +1 ~~-14~~

index 1db414f..aae7010 100644
@@ -39,6 +39,7 @@
 #include <linux/string.h>
 #include <linux/compiler.h>
 #include <asm/page.h>
+#include <asm/early_ioremap.h>
 
 #define build_mmio_read(name, size, type, reg, barrier) \
 static inline type name(const volatile void __iomem *addr) \

@@ -316,20 +317,6 @@ extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
 				unsigned long prot_val);
 extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
 
-/*
- * early_ioremap() and early_iounmap() are for temporary early boot-time
- * mappings, before the real ioremap() is functional.
- * A boot-time mapping is currently limited to at most 16 pages.
- */
-extern void early_ioremap_init(void);
-extern void early_ioremap_reset(void);
-extern void __iomem *early_ioremap(resource_size_t phys_addr,
-				   unsigned long size);
-extern void *early_memremap(resource_size_t phys_addr,
-				    unsigned long size);
-extern void early_iounmap(void __iomem *addr, unsigned long size);
-extern void early_memunmap(void *addr, unsigned long size);
-extern void fixup_early_ioremap(void);
 extern bool is_early_ioremap_ptep(pte_t *ptep);
 
 #ifdef CONFIG_XEN

arch/x86/mm/ioremap.c +3 ~~-225~~

253 lines not on this page · raw message

arch/x86/mm/pgtable_32.c +1 -1

index a69bcb8..4dd8cf6 100644
@@ -127,7 +127,7 @@ static int __init parse_reservetop(char *arg)
 
 	address = memparse(arg, &arg);
 	reserve_top_address(address);
-	fixup_early_ioremap();
+	early_ioremap_init();
 	return 0;
 }
 early_param("reservetop", parse_reservetop);

Signature · 1 line

1.8.5.3

Mark Salter

author

2014-02-12 20:56 UTC #4 lore raw

PATCH v4 4/6 arm: add early_ioremap support

In reply to Mark Salter

This patch uses the generic early_ioremap code to implement early_ioremap for ARM. The ARM-specific bits come mostly from an earlier patch from Leif Lindholm <[email protected]> here:

https://lkml.org/lkml/2013/10/3/279

Signed-off-by Mark Salter <[email protected]>

Tested-by Leif Lindholm <[email protected]>

Acked-by Catalin Marinas <[email protected]>

---
 arch/arm/Kconfig              | 10 +++++
 arch/arm/include/asm/Kbuild   |  1 +
 arch/arm/include/asm/fixmap.h | 20 ++++++++++
 arch/arm/include/asm/io.h     |  1 +
 arch/arm/kernel/setup.c       |  2 +
 arch/arm/mm/Makefile          |  4 ++
 arch/arm/mm/early_ioremap.c   | 93 +++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mm/mmu.c             |  2 +
 8 files changed, 133 insertions(+)
 create mode 100644 arch/arm/mm/early_ioremap.c

arch/arm/Kconfig +10 -0

index e254198..7a35ef6 100644
@@ -1874,6 +1874,16 @@ config UACCESS_WITH_MEMCPY
 	  However, if the CPU data cache is using a write-allocate mode,
 	  this option is unlikely to provide any performance gain.
 
+config EARLY_IOREMAP
+	bool "Provide early_ioremap() support for kernel initialization"
+	select GENERIC_EARLY_IOREMAP
+	help
+	  Provide a mechanism for kernel initialisation code to temporarily
+	  map, in a highmem-agnostic way, memory pages in before ioremap()
+	  and friends are available (before paging_init() has run). It uses
+	  the same virtual memory range as kmap so all early mappings must
+	  be unmapped before paging_init() is called.
+
 config SECCOMP
 	bool
 	prompt "Enable seccomp to safely compute untrusted bytecode"

arch/arm/include/asm/Kbuild +1 -0

index 3278afe..6fcfd7d 100644
@@ -4,6 +4,7 @@ generic-y += auxvec.h
 generic-y += bitsperlong.h
 generic-y += cputime.h
 generic-y += current.h
+generic-y += early_ioremap.h
 generic-y += emergency-restart.h
 generic-y += errno.h
 generic-y += exec.h

arch/arm/include/asm/fixmap.h +20 -0

index 68ea615..ff8fa3e 100644
@@ -21,8 +21,28 @@ enum fixed_addresses {
 	FIX_KMAP_BEGIN,
 	FIX_KMAP_END = (FIXADDR_TOP - FIXADDR_START) >> PAGE_SHIFT,
 	__end_of_fixed_addresses
+/*
+ * 224 temporary boot-time mappings, used by early_ioremap(),
+ * before ioremap() is functional.
+ *
+ * (P)re-using the FIXADDR region, which is used for highmem
+ * later on, and statically aligned to 1MB.
+ */
+#define NR_FIX_BTMAPS		32
+#define FIX_BTMAPS_SLOTS	7
+#define TOTAL_FIX_BTMAPS	(NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END		FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN		(FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1)
 };
 
+#define FIXMAP_PAGE_COMMON (L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN)
+
+#define FIXMAP_PAGE_NORMAL (FIXMAP_PAGE_COMMON | L_PTE_MT_WRITEBACK)
+#define FIXMAP_PAGE_IO	   (FIXMAP_PAGE_COMMON | L_PTE_MT_DEV_NONSHARED)
+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+			       phys_addr_t phys, pgprot_t flags);
+
 #include <asm-generic/fixmap.h>
 
 #endif

arch/arm/include/asm/io.h +1 -0

index 8aa4cca..637e0cd 100644
@@ -28,6 +28,7 @@
 #include <asm/byteorder.h>
 #include <asm/memory.h>
 #include <asm-generic/pci_iomap.h>
+#include <asm/early_ioremap.h>
 #include <xen/xen.h>
 
 /*

arch/arm/kernel/setup.c +2 -0

index b0df976..9c8b751 100644
@@ -30,6 +30,7 @@
 #include <linux/bug.h>
 #include <linux/compiler.h>
 #include <linux/sort.h>
+#include <linux/io.h>
 
 #include <asm/unified.h>
 #include <asm/cp15.h>

@@ -880,6 +881,7 @@ void __init setup_arch(char **cmdline_p)
 	const struct machine_desc *mdesc;
 
 	setup_processor();
+	early_ioremap_init();
 	mdesc = setup_machine_fdt(__atags_pointer);
 	if (!mdesc)
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);

arch/arm/mm/Makefile +4 -0

index 7f39ce2..501af98 100644
@@ -12,6 +12,10 @@ ifneq ($(CONFIG_MMU),y)
 obj-y				+= nommu.o
 endif
 
+ifeq ($(CONFIG_MMU),y)
+obj-$(CONFIG_EARLY_IOREMAP)	+= early_ioremap.o
+endif
+
 obj-$(CONFIG_ARM_PTDUMP)	+= dump.o
 obj-$(CONFIG_MODULES)		+= proc-syms.o

arch/arm/mm/early_ioremap.c new file +93 -0

93 lines not on this page · raw message

arch/arm/mm/mmu.c +2 -0

index 4f08c13..5067294 100644
@@ -35,6 +35,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/pci.h>
+#include <asm/early_ioremap.h>
 
 #include "mm.h"
 #include "tcm.h"

@@ -1489,6 +1490,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 {
 	void *zero_page;
 
+	early_ioremap_reset();
 	build_mem_type_table();
 	prepare_page_table();
 	map_lowmem();

Signature · 1 line

1.8.5.3

Rob Herring

2014-02-26 05:48 UTC #5 lore raw

Re: [PATCH v4 4/6] arm: add early_ioremap support

Quoted 4 lines · Mark Salter

This patch uses the generic early_ioremap code to implement early_ioremap for ARM. The ARM-specific bits come mostly from an earlier patch from Leif Lindholm <[email protected]> here:

This doesn't actually work for me. The PTE flags are not correct and accesses to a device fault. See below.

Quoted 61 lines

https://lkml.org/lkml/2013/10/3/279

Signed-off-by Mark Salter <[email protected]>

Tested-by Leif Lindholm <[email protected]>

Acked-by Catalin Marinas <[email protected]>

---
 arch/arm/Kconfig              | 10 +++++
 arch/arm/include/asm/Kbuild   |  1 +
 arch/arm/include/asm/fixmap.h | 20 ++++++++++
 arch/arm/include/asm/io.h     |  1 +
 arch/arm/kernel/setup.c       |  2 +
 arch/arm/mm/Makefile          |  4 ++
 arch/arm/mm/early_ioremap.c   | 93 +++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mm/mmu.c             |  2 +
 8 files changed, 133 insertions(+)
 create mode 100644 arch/arm/mm/early_ioremap.c

arch/arm/Kconfig +10 -0

index e254198..7a35ef6 100644
@@ -1874,6 +1874,16 @@ config UACCESS_WITH_MEMCPY
          However, if the CPU data cache is using a write-allocate mode,
          this option is unlikely to provide any performance gain.
 
+config EARLY_IOREMAP
+       bool "Provide early_ioremap() support for kernel initialization"
+       select GENERIC_EARLY_IOREMAP
+       help
+         Provide a mechanism for kernel initialisation code to temporarily
+         map, in a highmem-agnostic way, memory pages in before ioremap()
+         and friends are available (before paging_init() has run). It uses
+         the same virtual memory range as kmap so all early mappings must
+         be unmapped before paging_init() is called.
+
 config SECCOMP
        bool
        prompt "Enable seccomp to safely compute untrusted bytecode"

arch/arm/include/asm/Kbuild +1 -0

index 3278afe..6fcfd7d 100644
@@ -4,6 +4,7 @@ generic-y += auxvec.h
 generic-y += bitsperlong.h
 generic-y += cputime.h
 generic-y += current.h
+generic-y += early_ioremap.h
 generic-y += emergency-restart.h
 generic-y += errno.h
 generic-y += exec.h

arch/arm/include/asm/fixmap.h +2 -0

index 68ea615..ff8fa3e 100644
@@ -21,8 +21,28 @@ enum fixed_addresses {
        FIX_KMAP_BEGIN,
        FIX_KMAP_END = (FIXADDR_TOP - FIXADDR_START) >> PAGE_SHIFT,
        __end_of_fixed_addresses
+/*
+ * 224 temporary boot-time mappings, used by early_ioremap(),

arch/arm/include/asm/fixmap.h enum fixed_addresses { · line 35

Quoted 10 lines

arch/arm/include/asm/fixmap.h +10 -0

+ * before ioremap() is functional.
+ *
+ * (P)re-using the FIXADDR region, which is used for highmem
+ * later on, and statically aligned to 1MB.
+ */
+#define NR_FIX_BTMAPS          32
+#define FIX_BTMAPS_SLOTS       7
+#define TOTAL_FIX_BTMAPS       (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END          FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN                (FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1)

Why the different logic from arm64? Specifically, it doesn't make adding a permanent mapping simple.

arch/arm/include/asm/fixmap.h enum fixed_addresses { · line 41

Quoted 6 lines

arch/arm/include/asm/fixmap.h +4 -0

 };
 
+#define FIXMAP_PAGE_COMMON (L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN)
+
+#define FIXMAP_PAGE_NORMAL (FIXMAP_PAGE_COMMON | L_PTE_MT_WRITEBACK)
+#define FIXMAP_PAGE_IO    (FIXMAP_PAGE_COMMON | L_PTE_MT_DEV_NONSHARED)

This should be L_PTE_MT_DEV_SHARED and also needs L_PTE_DIRTY and L_PTE_SHARED as we want this to match MT_DEVICE.

These should also be wrapped with __pgprot().

Quoted 60 lines

arch/arm/include/asm/fixmap.h +4 -0

+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+                              phys_addr_t phys, pgprot_t flags);
+
 #include <asm-generic/fixmap.h>
 
 #endif

arch/arm/include/asm/io.h +1 -0

index 8aa4cca..637e0cd 100644
@@ -28,6 +28,7 @@
 #include <asm/byteorder.h>
 #include <asm/memory.h>
 #include <asm-generic/pci_iomap.h>
+#include <asm/early_ioremap.h>
 #include <xen/xen.h>
 
 /*

arch/arm/kernel/setup.c +2 -0

index b0df976..9c8b751 100644
@@ -30,6 +30,7 @@
 #include <linux/bug.h>
 #include <linux/compiler.h>
 #include <linux/sort.h>
+#include <linux/io.h>
 
 #include <asm/unified.h>
 #include <asm/cp15.h>

@@ -880,6 +881,7 @@ void __init setup_arch(char **cmdline_p)
        const struct machine_desc *mdesc;
 
        setup_processor();
+       early_ioremap_init();
        mdesc = setup_machine_fdt(__atags_pointer);
        if (!mdesc)
                mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);

arch/arm/mm/Makefile +4 -0

index 7f39ce2..501af98 100644
@@ -12,6 +12,10 @@ ifneq ($(CONFIG_MMU),y)
 obj-y                          += nommu.o
 endif
 
+ifeq ($(CONFIG_MMU),y)
+obj-$(CONFIG_EARLY_IOREMAP)    += early_ioremap.o
+endif
+
 obj-$(CONFIG_ARM_PTDUMP)       += dump.o
 obj-$(CONFIG_MODULES)          += proc-syms.o

arch/arm/mm/early_ioremap.c new file +0 -0

new file mode 100644
index 0000000..c3e2bf2

arch/arm/mm/early_ioremap.c line 10

Quoted 10 lines

arch/arm/mm/early_ioremap.c new file +10 -0

@@ -0,0 +1,93 @@
+/*
+ * early_ioremap() support for ARM
+ *
+ * Based on existing support in arch/x86/mm/ioremap.c
+ *
+ * Restrictions: currently only functional before paging_init()
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>

io.h doesn't appear to be needed.

Quoted 59 lines

arch/arm/mm/early_ioremap.c new file +59 -0

+
+#include <asm/fixmap.h>
+#include <asm/pgalloc.h>
+#include <asm/pgtable.h>
+#include <asm/tlbflush.h>
+
+#include <asm/mach/map.h>
+
+static pte_t bm_pte[PTRS_PER_PTE] __aligned(PTE_HWTABLE_SIZE) __initdata;
+
+static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
+{
+       unsigned int index = pgd_index(addr);
+       pgd_t *pgd = cpu_get_pgd() + index;
+       pud_t *pud = pud_offset(pgd, addr);
+       pmd_t *pmd = pmd_offset(pud, addr);
+
+       return pmd;
+}
+
+static inline pte_t * __init early_ioremap_pte(unsigned long addr)
+{
+       return &bm_pte[pte_index(addr)];
+}
+
+void __init early_ioremap_init(void)
+{
+       pmd_t *pmd;
+
+       pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
+
+       pmd_populate_kernel(NULL, pmd, bm_pte);
+
+       /*
+        * Make sure we don't span multiple pmds.
+        */
+       BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
+                    != (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
+
+       if (pmd != early_ioremap_pmd(fix_to_virt(FIX_BTMAP_END))) {
+               WARN_ON(1);
+               pr_warn("pmd %p != %p\n",
+                       pmd, early_ioremap_pmd(fix_to_virt(FIX_BTMAP_END)));
+               pr_warn("fix_to_virt(FIX_BTMAP_BEGIN): %08lx\n",
+                       fix_to_virt(FIX_BTMAP_BEGIN));
+               pr_warn("fix_to_virt(FIX_BTMAP_END):   %08lx\n",
+                       fix_to_virt(FIX_BTMAP_END));
+               pr_warn("FIX_BTMAP_END:       %d\n", FIX_BTMAP_END);
+               pr_warn("FIX_BTMAP_BEGIN:     %d\n", FIX_BTMAP_BEGIN);
+       }
+
+       early_ioremap_setup();
+}
+
+void __init __early_set_fixmap(enum fixed_addresses idx,
+                              phys_addr_t phys, pgprot_t flags)
+{
+       unsigned long addr = __fix_to_virt(idx);
+       pte_t *pte;

arch/arm/mm/early_ioremap.c line 79

Quoted 10 lines

arch/arm/mm/early_ioremap.c new file +10 -0

+       u64 desc;
+
+       if (idx > FIX_KMAP_END) {
+               BUG();
+               return;
+       }
+       pte = early_ioremap_pte(addr);
+
+       if (pgprot_val(flags))
+               set_pte_at(NULL, 0xfff00000, pte,

Couldn't you use addr here instead of 0xfff00000? It's not really used other than a check against TASK_SIZE.

arch/arm/mm/early_ioremap.c line 80

Quoted 1 line

arch/arm/mm/early_ioremap.c new file +1 -0
+                          pfn_pte(phys >> PAGE_SHIFT, flags));

phys_to_pfn(phys)

arch/arm/mm/early_ioremap.c line 92

Quoted 12 lines

arch/arm/mm/early_ioremap.c new file +12 -0

+       else
+               pte_clear(NULL, addr, pte);
+       flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+       desc = *pte;
+}
+
+void __init
+early_ioremap_shutdown(void)
+{
+       pmd_t *pmd;
+       pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
+       pmd_clear(pmd);

This is redundant with the clearing done in devicemaps_init. Not a big deal but this is probably something we don't want with permanent mappings. I'm still trying to figure out how to do those. Leaving this page table in place doesn't seem to work, so I think we'll have to copy mappings to the new page tables.

Rob

Leif Lindholm

2014-02-26 09:37 UTC #6 lore raw

Re: [PATCH v4 4/6] arm: add early_ioremap support

Hi Rob,

Thanks for having a look.
Since I'm at least partially responsible for the below, I'll respond before Mark wakes up.

Quoted 8 lines · Rob Herring

Quoted 4 lines · Mark Salter
This patch uses the generic early_ioremap code to implement early_ioremap for ARM. The ARM-specific bits come mostly from an earlier patch from Leif Lindholm <[email protected]> here:
This doesn't actually work for me. The PTE flags are not correct and accesses to a device fault. See below.

Do they fault before paging_init()?
If not, see below.

Quoted 26 lines

https://lkml.org/lkml/2013/10/3/279

Signed-off-by Mark Salter <[email protected]>

Tested-by Leif Lindholm <[email protected]>

Acked-by Catalin Marinas <[email protected]>

---
 arch/arm/Kconfig              | 10 +++++
 arch/arm/include/asm/Kbuild   |  1 +
 arch/arm/include/asm/fixmap.h | 20 ++++++++++
 arch/arm/include/asm/io.h     |  1 +
 arch/arm/kernel/setup.c       |  2 +
 arch/arm/mm/Makefile          |  4 ++
 arch/arm/mm/early_ioremap.c   | 93 +++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mm/mmu.c             |  2 +
 8 files changed, 133 insertions(+)
 create mode 100644 arch/arm/mm/early_ioremap.c

arch/arm/Kconfig +0 -0

index e254198..7a35ef6 100644
@@ -1874,6 +1874,16 @@ config UACCESS_WITH_MEMCPY
          However, if the CPU data cache is using a write-allocate mode,
          this option is unlikely to provide any performance gain.

Quoted 10 lines

arch/arm/Kconfig config UACCESS_WITH_MEMCPY · line 1886

Quoted 10 lines

arch/arm/Kconfig +10 -0

+config EARLY_IOREMAP
+       bool "Provide early_ioremap() support for kernel initialization"
+       select GENERIC_EARLY_IOREMAP
+       help
+         Provide a mechanism for kernel initialisation code to temporarily
+         map, in a highmem-agnostic way, memory pages in before ioremap()
+         and friends are available (before paging_init() has run). It uses
+         the same virtual memory range as kmap so all early mappings must
+         be unmapped before paging_init() is called.
+

Quoted 30 lines

arch/arm/Kconfig +0 -0

 config SECCOMP
        bool
        prompt "Enable seccomp to safely compute untrusted bytecode"

arch/arm/include/asm/Kbuild +1 -0

index 3278afe..6fcfd7d 100644
@@ -4,6 +4,7 @@ generic-y += auxvec.h
 generic-y += bitsperlong.h
 generic-y += cputime.h
 generic-y += current.h
+generic-y += early_ioremap.h
 generic-y += emergency-restart.h
 generic-y += errno.h
 generic-y += exec.h

arch/arm/include/asm/fixmap.h +7 -0

index 68ea615..ff8fa3e 100644
@@ -21,8 +21,28 @@ enum fixed_addresses {
        FIX_KMAP_BEGIN,
        FIX_KMAP_END = (FIXADDR_TOP - FIXADDR_START) >> PAGE_SHIFT,
        __end_of_fixed_addresses
+/*
+ * 224 temporary boot-time mappings, used by early_ioremap(),
+ * before ioremap() is functional.
+ *
+ * (P)re-using the FIXADDR region, which is used for highmem
+ * later on, and statically aligned to 1MB.
+ */

Quoted 8 lines

arch/arm/include/asm/fixmap.h enum fixed_addresses { · line 35
Quoted 5 lines
arch/arm/include/asm/fixmap.h +5 -0
+#define NR_FIX_BTMAPS          32
+#define FIX_BTMAPS_SLOTS       7
+#define TOTAL_FIX_BTMAPS       (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END          FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN                (FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1)
Why the different logic from arm64? Specifically, it doesn't make adding a permanent mapping simple.

Making a permanent mapping using this would require either:
- Not using the fixmap region.
- Rewriting arm kmap.

Quoted 11 lines

arch/arm/include/asm/fixmap.h enum fixed_addresses { · line 41
Quoted 6 lines
arch/arm/include/asm/fixmap.h +4 -0
 };
 
+#define FIXMAP_PAGE_COMMON (L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN)
+
+#define FIXMAP_PAGE_NORMAL (FIXMAP_PAGE_COMMON | L_PTE_MT_WRITEBACK)
+#define FIXMAP_PAGE_IO    (FIXMAP_PAGE_COMMON | L_PTE_MT_DEV_NONSHARED)
This should be L_PTE_MT_DEV_SHARED and also needs L_PTE_DIRTY and L_PTE_SHARED as we want this to match MT_DEVICE.
These should also be wrapped with __pgprot().

Ok.

Quoted 64 lines

arch/arm/include/asm/fixmap.h +4 -0

+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+                              phys_addr_t phys, pgprot_t flags);
+
 #include <asm-generic/fixmap.h>
 
 #endif

arch/arm/include/asm/io.h +1 -0

index 8aa4cca..637e0cd 100644
@@ -28,6 +28,7 @@
 #include <asm/byteorder.h>
 #include <asm/memory.h>
 #include <asm-generic/pci_iomap.h>
+#include <asm/early_ioremap.h>
 #include <xen/xen.h>
 
 /*

arch/arm/kernel/setup.c +2 -0

index b0df976..9c8b751 100644
@@ -30,6 +30,7 @@
 #include <linux/bug.h>
 #include <linux/compiler.h>
 #include <linux/sort.h>
+#include <linux/io.h>
 
 #include <asm/unified.h>
 #include <asm/cp15.h>

@@ -880,6 +881,7 @@ void __init setup_arch(char **cmdline_p)
        const struct machine_desc *mdesc;
 
        setup_processor();
+       early_ioremap_init();
        mdesc = setup_machine_fdt(__atags_pointer);
        if (!mdesc)
                mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);

arch/arm/mm/Makefile +4 -0

index 7f39ce2..501af98 100644
@@ -12,6 +12,10 @@ ifneq ($(CONFIG_MMU),y)
 obj-y                          += nommu.o
 endif
 
+ifeq ($(CONFIG_MMU),y)
+obj-$(CONFIG_EARLY_IOREMAP)    += early_ioremap.o
+endif
+
 obj-$(CONFIG_ARM_PTDUMP)       += dump.o
 obj-$(CONFIG_MODULES)          += proc-syms.o

arch/arm/mm/early_ioremap.c new file +4 -0

new file mode 100644
index 0000000..c3e2bf2
@@ -0,0 +1,93 @@
+/*
+ * early_ioremap() support for ARM
+ *
+ * Based on existing support in arch/x86/mm/ioremap.c

Quoted 8 lines

arch/arm/mm/early_ioremap.c line 10
Quoted 6 lines
arch/arm/mm/early_ioremap.c new file +6 -0
+ *
+ * Restrictions: currently only functional before paging_init()
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
io.h doesn't appear to be needed.

No, not in this version.

Quoted 64 lines

arch/arm/mm/early_ioremap.c new file +64 -0

+
+#include <asm/fixmap.h>
+#include <asm/pgalloc.h>
+#include <asm/pgtable.h>
+#include <asm/tlbflush.h>
+
+#include <asm/mach/map.h>
+
+static pte_t bm_pte[PTRS_PER_PTE] __aligned(PTE_HWTABLE_SIZE) __initdata;
+
+static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
+{
+       unsigned int index = pgd_index(addr);
+       pgd_t *pgd = cpu_get_pgd() + index;
+       pud_t *pud = pud_offset(pgd, addr);
+       pmd_t *pmd = pmd_offset(pud, addr);
+
+       return pmd;
+}
+
+static inline pte_t * __init early_ioremap_pte(unsigned long addr)
+{
+       return &bm_pte[pte_index(addr)];
+}
+
+void __init early_ioremap_init(void)
+{
+       pmd_t *pmd;
+
+       pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
+
+       pmd_populate_kernel(NULL, pmd, bm_pte);
+
+       /*
+        * Make sure we don't span multiple pmds.
+        */
+       BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
+                    != (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
+
+       if (pmd != early_ioremap_pmd(fix_to_virt(FIX_BTMAP_END))) {
+               WARN_ON(1);
+               pr_warn("pmd %p != %p\n",
+                       pmd, early_ioremap_pmd(fix_to_virt(FIX_BTMAP_END)));
+               pr_warn("fix_to_virt(FIX_BTMAP_BEGIN): %08lx\n",
+                       fix_to_virt(FIX_BTMAP_BEGIN));
+               pr_warn("fix_to_virt(FIX_BTMAP_END):   %08lx\n",
+                       fix_to_virt(FIX_BTMAP_END));
+               pr_warn("FIX_BTMAP_END:       %d\n", FIX_BTMAP_END);
+               pr_warn("FIX_BTMAP_BEGIN:     %d\n", FIX_BTMAP_BEGIN);
+       }
+
+       early_ioremap_setup();
+}
+
+void __init __early_set_fixmap(enum fixed_addresses idx,
+                              phys_addr_t phys, pgprot_t flags)
+{
+       unsigned long addr = __fix_to_virt(idx);
+       pte_t *pte;
+       u64 desc;
+
+       if (idx > FIX_KMAP_END) {
+               BUG();
+               return;

Quoted 8 lines

arch/arm/mm/early_ioremap.c line 79
Quoted 5 lines
arch/arm/mm/early_ioremap.c new file +5 -0
+       }
+       pte = early_ioremap_pte(addr);
+
+       if (pgprot_val(flags))
+               set_pte_at(NULL, 0xfff00000, pte,
Couldn't you use addr here instead of 0xfff00000? It's not really used other than a check against TASK_SIZE.

Sure.

Quoted 3 lines

arch/arm/mm/early_ioremap.c line 80
Quoted 1 line
arch/arm/mm/early_ioremap.c new file +1 -0
+                          pfn_pte(phys >> PAGE_SHIFT, flags));
phys_to_pfn(phys)

Stolen like that from x86 :)
Sure.

Quoted 10 lines

arch/arm/mm/early_ioremap.c new file +10 -0

+       else
+               pte_clear(NULL, addr, pte);
+       flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+       desc = *pte;
+}
+
+void __init
+early_ioremap_shutdown(void)
+{
+       pmd_t *pmd;

Quoted 8 lines

arch/arm/mm/early_ioremap.c line 92
Quoted 2 lines
arch/arm/mm/early_ioremap.c new file +2 -0
+       pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
+       pmd_clear(pmd);
This is redundant with the clearing done in devicemaps_init. Not a big deal but this is probably something we don't want with permanent mappings. I'm still trying to figure out how to do those. Leaving this page table in place doesn't seem to work, so I think we'll have to copy mappings to the new page tables.

As described in the Kconfig option, and more explicitly in the documentation included with my last submission (last summer), these mappings don't stick around.

/
Leif

Mark Salter

author

2014-02-26 14:59 UTC #7 lore raw

Re: [PATCH v4 4/6] arm: add early_ioremap support

In reply to Rob Herring

Quoted 9 lines · Rob Herring

arch/arm/include/asm/fixmap.h enum fixed_addresses {
Quoted 5 lines
arch/arm/include/asm/fixmap.h +5 -0
+#define NR_FIX_BTMAPS          32
+#define FIX_BTMAPS_SLOTS       7
+#define TOTAL_FIX_BTMAPS       (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END          FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN                (FIX_BTMAP_END +
TOTAL_FIX_BTMAPS - 1)
Why the different logic from arm64? Specifically, it doesn't make adding a permanent mapping simple.

I looked at adding support for permanent mappings but it was going to take more time than I had. Also on ARM, we have to deal with kmap's needs as well. Working that out was going to take more time than I had. I think getting the patch in now to support early_ioremap is the way to go. Adding support for permanent mappings can be done later with the early console support for which it is needed.

Rob Herring

2014-02-26 15:56 UTC #8 lore raw

Re: [PATCH v4 4/6] arm: add early_ioremap support

Quoted 11 lines · Mark Salter

Quoted 9 lines · Rob Herring
arch/arm/include/asm/fixmap.h enum fixed_addresses {
Quoted 5 lines
arch/arm/include/asm/fixmap.h +5 -0
+#define NR_FIX_BTMAPS          32
+#define FIX_BTMAPS_SLOTS       7
+#define TOTAL_FIX_BTMAPS       (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END          FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN                (FIX_BTMAP_END +
TOTAL_FIX_BTMAPS - 1)
Why the different logic from arm64? Specifically, it doesn't make adding a permanent mapping simple.

Quoted 6 lines

I looked at adding support for permanent mappings but it was going to take more time than I had. Also on ARM, we have to deal with kmap's needs as well. Working that out was going to take more time than I had. I think getting the patch in now to support early_ioremap is the way to go. Adding support for permanent mappings can be done later with the early console support for which it is needed.

I'm not saying that you should add permanent mappings, but just align the definitions across arches more. So make arm look something like this:

enum fixed_addresses {
__end_of_permanent_fixed_addresses,

/*
* Temporary boot-time mappings, used by early_ioremap(),
* before ioremap() is functional.
*/

#define NR_FIX_BTMAPS          32
#define FIX_BTMAPS_SLOTS       7
#define TOTAL_FIX_BTMAPS       (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)

FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
FIX_BTMAP_BEGIN = FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1, __end_of_fixed_addresses
FIX_KMAP_BEGIN = FIX_BTMAP_END,
FIX_KMAP_END = FIX_BTMAP_BEGIN,
};

These could then go into the generic header:

#define FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)

Rob

Mark Salter

author

2014-02-12 20:56 UTC #9 lore raw

PATCH v4 5/6 arm64: initialize pgprot info earlier in boot

In reply to Mark Salter

Presently, paging_init() calls init_mem_pgprot() to initialize pgprot values used by macros such as PAGE_KERNEL, PAGE_KERNEL_EXEC, etc. The new fixmap and early_ioremap support also needs to use these macros before paging_init() is called. This patch moves the init_mem_pgprot() call out of paging_init() and into setup_arch() so that pgprot_default gets initialized in time for fixmap and early_ioremap.

Signed-off-by Mark Salter <[email protected]>

---
 arch/arm64/include/asm/mmu.h | 1 +
 arch/arm64/kernel/setup.c    | 2 ++
 arch/arm64/mm/mmu.c          | 3 +--
 3 files changed, 4 insertions(+), 2 deletions(-)

arch/arm64/include/asm/mmu.h +1 -0

index 2494fc0..f600d40 100644
@@ -27,5 +27,6 @@ typedef struct {
 extern void paging_init(void);
 extern void setup_mm_for_reboot(void);
 extern void __iomem *early_io_map(phys_addr_t phys, unsigned long virt);
+extern void init_mem_pgprot(void);
 
 #endif

arch/arm64/kernel/setup.c +2 -0

index c8e9eff..1c66cfb 100644
@@ -327,6 +327,8 @@ void __init setup_arch(char **cmdline_p)
 
 	*cmdline_p = boot_command_line;
 
+	init_mem_pgprot();
+
 	parse_early_param();
 
 	arm64_memblock_init();

arch/arm64/mm/mmu.c +1 -2

index f8dc7e8..ba259a0 100644
@@ -125,7 +125,7 @@ early_param("cachepolicy", early_cachepolicy);
 /*
  * Adjust the PMD section entries according to the CPU in use.
  */
-static void __init init_mem_pgprot(void)
+void __init init_mem_pgprot(void)
 {
 	pteval_t default_pgprot;
 	int i;

@@ -357,7 +357,6 @@ void __init paging_init(void)
 {
 	void *zero_page;
 
-	init_mem_pgprot();
 	map_mem();
 
 	/*

Signature · 1 line

1.8.5.3

Mark Salter

author

2014-02-12 20:56 UTC #10 lore raw

PATCH v4 6/6 arm64: add early_ioremap support

In reply to Mark Salter

Add support for early IO or memory mappings which are needed before the normal ioremap() is usable. This also adds fixmap support for permanent fixed mappings such as that used by the earlyprintk device register region.

Signed-off-by Mark Salter <[email protected]>

---
 Documentation/arm64/memory.txt   |  4 +-
 arch/arm64/Kconfig               |  1 +
 arch/arm64/include/asm/Kbuild    |  1 +
 arch/arm64/include/asm/fixmap.h  | 67 +++++++++++++++++++++++++++++++
 arch/arm64/include/asm/io.h      |  1 +
 arch/arm64/include/asm/memory.h  |  2 +-
 arch/arm64/kernel/early_printk.c |  8 +++-
 arch/arm64/kernel/head.S         |  9 ++---
 arch/arm64/kernel/setup.c        |  2 +
 arch/arm64/mm/ioremap.c          | 85 ++++++++++++++++++++++++++++++++++++++++
 arch/arm64/mm/mmu.c              | 41 -------------------
 11 files changed, 169 insertions(+), 52 deletions(-)
 create mode 100644 arch/arm64/include/asm/fixmap.h

Documentation/arm64/memory.txt +2 -2

index 5e054bf..953c81e 100644
@@ -35,7 +35,7 @@ ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap
 
 ffffffbe00000000	ffffffbffbbfffff	  ~8GB		[guard, future vmmemap]
 
-ffffffbffbc00000	ffffffbffbdfffff	   2MB		earlyprintk device
+ffffffbffbc00000	ffffffbffbdfffff	   2MB		fixed mappings
 
 ffffffbffbe00000	ffffffbffbe0ffff	  64KB		PCI I/O space

@@ -60,7 +60,7 @@ fffffdfc00000000	fffffdfdffffffff	   8GB		vmemmap
 
 fffffdfe00000000	fffffdfffbbfffff	  ~8GB		[guard, future vmmemap]
 
-fffffdfffbc00000	fffffdfffbdfffff	   2MB		earlyprintk device
+fffffdfffbc00000	fffffdfffbdfffff	   2MB		fixed mappings
 
 fffffdfffbe00000	fffffdfffbe0ffff	  64KB		PCI I/O space

arch/arm64/Kconfig +1 -0

index 27bbcfc..da4304a 100644
@@ -16,6 +16,7 @@ config ARM64
 	select DCACHE_WORD_ACCESS
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+	select GENERIC_EARLY_IOREMAP
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW

arch/arm64/include/asm/Kbuild +1 -0

index 71c53ec..27e3c6b 100644
@@ -10,6 +10,7 @@ generic-y += delay.h
 generic-y += div64.h
 generic-y += dma.h
 generic-y += emergency-restart.h
+generic-y += early_ioremap.h
 generic-y += errno.h
 generic-y += ftrace.h
 generic-y += hw_irq.h

arch/arm64/include/asm/fixmap.h new file +67 -0

67 lines not on this page · raw message

arch/arm64/include/asm/io.h +1 -0

index 4cc813e..8fb2152 100644
@@ -27,6 +27,7 @@
 #include <asm/byteorder.h>
 #include <asm/barrier.h>
 #include <asm/pgtable.h>
+#include <asm/early_ioremap.h>
 
 #include <xen/xen.h>

arch/arm64/include/asm/memory.h +1 -1

index 9dc5dc3..e94f945 100644
@@ -49,7 +49,7 @@
 #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
 #define MODULES_END		(PAGE_OFFSET)
 #define MODULES_VADDR		(MODULES_END - SZ_64M)
-#define EARLYCON_IOBASE		(MODULES_VADDR - SZ_4M)
+#define FIXADDR_TOP		(MODULES_VADDR - SZ_2M - PAGE_SIZE)
 #define TASK_SIZE_64		(UL(1) << VA_BITS)
 
 #ifdef CONFIG_COMPAT

arch/arm64/kernel/early_printk.c +6 -2

index fbb6e18..850d9a4 100644
@@ -26,6 +26,8 @@
 #include <linux/amba/serial.h>
 #include <linux/serial_reg.h>
 
+#include <asm/fixmap.h>
+
 static void __iomem *early_base;
 static void (*printch)(char ch);

@@ -141,8 +143,10 @@ static int __init setup_early_printk(char *buf)
 	}
 	/* no options parsing yet */
 
-	if (paddr)
-		early_base = early_io_map(paddr, EARLYCON_IOBASE);
+	if (paddr) {
+		set_fixmap_io(FIX_EARLYCON, paddr);
+		early_base = (void __iomem *)fix_to_virt(FIX_EARLYCON);
+	}
 
 	printch = match->printch;
 	early_console = &early_console_dev;

arch/arm64/kernel/head.S +3 -6

index 0b281ff..c86bfdf 100644
@@ -412,7 +412,7 @@ ENDPROC(__calc_phys_offset)
  *   - identity mapping to enable the MMU (low address, TTBR0)
  *   - first few MB of the kernel linear mapping to jump to once the MMU has
  *     been enabled, including the FDT blob (TTBR1)
- *   - UART mapping if CONFIG_EARLY_PRINTK is enabled (TTBR1)
+ *   - pgd entry for fixed mappings (TTBR1)
  */
 __create_page_tables:
 	pgtbl	x25, x26, x24			// idmap_pg_dir and swapper_pg_dir addresses

@@ -465,15 +465,12 @@ __create_page_tables:
 	sub	x6, x6, #1			// inclusive range
 	create_block_map x0, x7, x3, x5, x6
 1:
-#ifdef CONFIG_EARLY_PRINTK
 	/*
-	 * Create the pgd entry for the UART mapping. The full mapping is done
-	 * later based earlyprintk kernel parameter.
+	 * Create the pgd entry for the fixed mappings.
 	 */
-	ldr	x5, =EARLYCON_IOBASE		// UART virtual address
+	ldr	x5, =FIXADDR_TOP		// Fixed mapping virtual address
 	add	x0, x26, #2 * PAGE_SIZE		// section table address
 	create_pgd_entry x26, x0, x5, x6, x7
-#endif
 	ret
 ENDPROC(__create_page_tables)
 	.ltorg

arch/arm64/kernel/setup.c +2 -0

index 1c66cfb..4d2ac74 100644
@@ -42,6 +42,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 
+#include <asm/fixmap.h>
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/cputable.h>

@@ -328,6 +329,7 @@ void __init setup_arch(char **cmdline_p)
 	*cmdline_p = boot_command_line;
 
 	init_mem_pgprot();
+	early_ioremap_init();
 
 	parse_early_param();

arch/arm64/mm/ioremap.c +85 -0

94 lines not on this page · raw message

arch/arm64/mm/mmu.c +0 ~~-41~~

47 lines not on this page · raw message

Signature · 1 line

1.8.5.3

Mark Salter

author

2014-02-25 14:10 UTC #11 lore raw

In reply to Mark Salter

Quoted 12 lines · Mark Salter

This patch series takes the common bits from the x86 early ioremap implementation and creates a generic implementation which may be used by other architectures. The early ioremap interfaces are intended for situations where boot code needs to make temporary virtual mappings before the normal ioremap interfaces are available. Typically, this means before paging_init() has run.
These patches are layered on top of generic fixmap patches which were pulled into 3.14-rc with the exception of the arm patch:
https://lkml.org/lkml/2013/11/25/477

Quoted 7 lines

The arm fixmap patch is currently in the akpm tree and has been part of linux-next for a while.
This is version 4 of the patch series. These patches (and underlying fixmap patches) may be found at:
git://github.com/mosalter/linux.git (early-ioremap-v4 branch)

There have been no comments on this patch series over the past two weeks. I'd like to get it into linux-next for some wider testing and eventually into 3.15. Is there something I can do to help it along?

Will Deacon

2014-02-25 18:30 UTC #12 lore raw

Quoted 19 lines · Mark Salter

Quoted 18 lines · Mark Salter
This patch series takes the common bits from the x86 early ioremap implementation and creates a generic implementation which may be used by other architectures. The early ioremap interfaces are intended for situations where boot code needs to make temporary virtual mappings before the normal ioremap interfaces are available. Typically, this means before paging_init() has run.
These patches are layered on top of generic fixmap patches which were pulled into 3.14-rc with the exception of the arm patch:
https://lkml.org/lkml/2013/11/25/477
The arm fixmap patch is currently in the akpm tree and has been part of linux-next for a while.
This is version 4 of the patch series. These patches (and underlying fixmap patches) may be found at:

Quoted 6 lines

Quoted 1 line
git://github.com/mosalter/linux.git (early-ioremap-v4 branch)
There have been no comments on this patch series over the past two weeks. I'd like to get it into linux-next for some wider testing and eventually into 3.15. Is there something I can do to help it along?

I'd suggest spitting the core part out from the arch-specific parts. That way, the core part can merged independently and architectures can move over as they see fit. It also signals (at least to me) that, "hey, I should probably review this" whilst my current stance is "there's a whole load of stuff under mm/ that needs to be acked first".

If you put the whole thing into next, you just run the risk of conflicts with all the arch trees.

Will

Mark Salter

author

2014-02-25 18:45 UTC #13 lore raw

Quoted 8 lines · Will Deacon

I'd suggest spitting the core part out from the arch-specific parts. That way, the core part can merged independently and architectures can move over as they see fit. It also signals (at least to me) that, "hey, I should probably review this" whilst my current stance is "there's a whole load of stuff under mm/ that needs to be acked first".
If you put the whole thing into next, you just run the risk of conflicts with all the arch trees.

I've been thinking of breaking out the common bits and x86 bits and just going with that for now. There's no point in just doing the common bits because it won't get tested without at least one architecture using it.

H. Peter Anvin

reviewer Acked-by

2014-02-25 19:42 UTC #14 lore raw

Quoted 7 lines · Mark Salter

Quoted 6 lines · Will Deacon
I'd suggest spitting the core part out from the arch-specific parts. That way, the core part can merged independently and architectures can move over as they see fit. It also signals (at least to me) that, "hey, I should probably review this" whilst my current stance is "there's a whole load of stuff under mm/ that needs to be acked first".

Quoted 7 lines

Quoted 2 lines
If you put the whole thing into next, you just run the risk of conflicts with all the arch trees.
I've been thinking of breaking out the common bits and x86 bits and just going with that for now. There's no point in just doing the common bits because it won't get tested without at least one architecture using it.

If you think it makes sense we could take the common bits + x86 and put them through the -tip tree. The other option would be to put the whole thread in linux-next with Acks.

As far as x86 is concerned it looks like it is mostly just code movement, so I'm happy giving my:

Acked-by H. Peter Anvin <[email protected]>

Catalin Marinas

maintainer Acked-by

2014-02-25 23:04 UTC #15 lore raw

Quoted 11 lines · H. Peter Anvin

Quoted 10 lines · Mark Salter
Quoted 8 lines · Will Deacon
I'd suggest spitting the core part out from the arch-specific parts. That way, the core part can merged independently and architectures can move over as they see fit. It also signals (at least to me) that, "hey, I should probably review this" whilst my current stance is "there's a whole load of stuff under mm/ that needs to be acked first".
If you put the whole thing into next, you just run the risk of conflicts with all the arch trees.

Quoted 7 lines

Quoted 4 lines
I've been thinking of breaking out the common bits and x86 bits and just going with that for now. There's no point in just doing the common bits because it won't get tested without at least one architecture using it.
If you think it makes sense we could take the common bits + x86 and put them through the -tip tree.

I?m ok with the arm64 patches to go through -tip with my ack on all patches:

Acked-by Catalin Marinas <[email protected]>

Quoted 7 lines

The other option would be to put the whole
thread in linux-next with Acks.
As far as x86 is concerned it looks like it is mostly just code movement, so I'm happy giving my:
Acked-by H. Peter Anvin <[email protected]>

Thanks. Either way works for me.

I think the series still need an ack from rmk at least on the arm patch (4/6).

Catalin

H. Peter Anvin

reviewer

2014-02-25 23:05 UTC #16 lore raw

Quoted 4 lines · Catalin Marinas

I think the series still need an ack from rmk at least on the arm patch (4/6).

OK. Russell?

-hpa

Mark Salter

author

2014-03-03 22:29 UTC #17 lore raw

In reply to H. Peter Anvin

Quoted 16 lines · H. Peter Anvin

Quoted 7 lines · Mark Salter
Quoted 6 lines · Will Deacon
I'd suggest spitting the core part out from the arch-specific parts. That way, the core part can merged independently and architectures can move over as they see fit. It also signals (at least to me) that, "hey, I should probably review this" whilst my current stance is "there's a whole load of stuff under mm/ that needs to be acked first".
Quoted 7 lines
Quoted 2 lines
If you put the whole thing into next, you just run the risk of conflicts with all the arch trees.
I've been thinking of breaking out the common bits and x86 bits and just going with that for now. There's no point in just doing the common bits because it won't get tested without at least one architecture using it.

Quoted 9 lines

If you think it makes sense we could take the common bits + x86 and put them through the -tip tree. The other option would be to put the whole thread in linux-next with Acks.
As far as x86 is concerned it looks like it is mostly just code movement, so I'm happy giving my:
Acked-by H. Peter Anvin <[email protected]>

I going to send out a v5 with the arm bits dropped and Ack-bys added. There is still some work left there, so I think I'll redo the arm bits separately after once the common bits are in the kernel.

Peter, is your Acked-by only for "[3/6] x86: use generic early_ioremap"? Or did you intend "[1/6] x86/mm: sparse warning fix for early_memremap" and/or "[2/6] mm: create generic early_ioremap() support" also?

H. Peter Anvin

reviewer

2014-03-04 01:30 UTC #18 lore raw

All three .

Quoted 45 lines · Mark Salter

Quoted 3 lines · H. Peter Anvin
Quoted 2 lines · Mark Salter
Quoted 1 line · Will Deacon
I'd suggest spitting the core part out from the arch-specific
parts. That
Quoted 1 line
Quoted 1 line
Quoted 1 line
way, the core part can merged independently and architectures can
move over
Quoted 1 line
Quoted 1 line
Quoted 1 line
as they see fit. It also signals (at least to me) that, "hey, I
should
Quoted 1 line
Quoted 1 line
Quoted 1 line
probably review this" whilst my current stance is "there's a whole
load of
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
stuff under mm/ that needs to be acked first".
If you put the whole thing into next, you just run the risk of
conflicts
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
with all the arch trees.
I've been thinking of breaking out the common bits and x86 bits and
just
Quoted 1 line
Quoted 1 line
going with that for now. There's no point in just doing the common
bits
Quoted 1 line
Quoted 1 line
because it won't get tested without at least one architecture using
it.
Quoted 3 lines
Quoted 1 line
If you think it makes sense we could take the common bits + x86 and
put
Quoted 1 line
them through the -tip tree. The other option would be to put the
whole
Quoted 7 lines
thread in linux-next with Acks.
As far as x86 is concerned it looks like it is mostly just code movement, so I'm happy giving my:
Acked-by H. Peter Anvin <[email protected]>
I going to send out a v5 with the arm bits dropped and Ack-bys added. There is still some work left there, so I think I'll redo the arm bits separately after once the common bits are in the kernel.
Peter, is your Acked-by only for "[3/6] x86: use generic early_ioremap"?
Or did you intend "[1/6] x86/mm: sparse warning fix for early_memremap" and/or "[2/6] mm: create generic early_ioremap() support" also?

Signature · 1 line

Sent from my mobile phone.  Please pardon brevity and lack of formatting.