[PATCH 0/8] QEMU virt machine support via mach-vexpress

[PATCH 0/8] QEMU virt machine support via mach-vexpress

[Rouven Czerwinski]

Instead of using ARCH_QEMU, this variant uses ARCH_VEXPRESS to base its
support for the QEMU virt machine on. Contains a cleanup and conversion
of the vexpress boards to board drivers and an implementation of
zero_page_access and faulting for ARM32.

Rouven Czerwinski (8):
  ARM: MMU: add zero_page_{access,faulting}
  mtd: cfi_flash: allow 0x0 mapping
  amba: add *_amba_driver helper macros
  ARM: vexpress: remove unused KConfig file
  ARM: vexpress: convert to board driver
  ARM: vexpress: move Options to ARCH_VEXPRESS
  ARM: qemu: add support for qemu virt platform
  ARM: vexpress: enable VIRT board, MMU and cmds

 arch/arm/Kconfig                    |  6 ++-
 arch/arm/boards/Makefile            |  1 +
 arch/arm/boards/qemu-virt/Makefile  |  1 +
 arch/arm/boards/qemu-virt/board.c   | 36 +++++++++++++++
 arch/arm/boards/vexpress/Kconfig    |  8 ----
 arch/arm/boards/vexpress/init.c     | 69 +++++++++++++++++------------
 arch/arm/configs/vexpress_defconfig |  5 +++
 arch/arm/cpu/Kconfig                |  1 -
 arch/arm/cpu/mmu.c                  | 13 ++++++
 arch/arm/mach-vexpress/Kconfig      | 12 ++---
 drivers/clocksource/amba-sp804.c    |  2 +-
 drivers/mci/mmci.c                  |  7 +--
 drivers/mtd/nor/cfi_flash.c         |  6 +++
 drivers/mtd/nor/cfi_flash.h         | 18 ++++++++
 drivers/serial/amba-pl011.c         |  8 +---
 include/linux/amba/bus.h            |  7 +++
 include/zero_page.h                 | 14 ------
 lib/Kconfig                         |  3 --
 18 files changed, 139 insertions(+), 78 deletions(-)
 create mode 100644 arch/arm/boards/qemu-virt/Makefile
 create mode 100644 arch/arm/boards/qemu-virt/board.c
 delete mode 100644 arch/arm/boards/vexpress/Kconfig

-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 1/8] ARM: MMU: add zero_page_{access,faulting}

[Rouven Czerwinski]

On the qemu virt machine, the cfi flash is mapped at 0x0.
Therefore implement zero_page_{access,faulting} to allow usage of the
cfi_flash driver on this machine.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 arch/arm/cpu/Kconfig |  1 -
 arch/arm/cpu/mmu.c   | 13 +++++++++++++
 include/zero_page.h  | 14 --------------
 lib/Kconfig          |  3 ---
 4 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/arch/arm/cpu/Kconfig b/arch/arm/cpu/Kconfig
index ca3bd98962..f9f52a6252 100644
--- a/arch/arm/cpu/Kconfig
+++ b/arch/arm/cpu/Kconfig
@@ -89,7 +89,6 @@ config CPU_V8
 	select ARM_EXCEPTIONS
 	select GENERIC_FIND_NEXT_BIT
 	select ARCH_HAS_STACK_DUMP
-	select ARCH_HAS_ZERO_PAGE
 
 config CPU_XSC3
         bool
diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c
index 6af228505d..bfb8eab5f5 100644
--- a/arch/arm/cpu/mmu.c
+++ b/arch/arm/cpu/mmu.c
@@ -17,6 +17,7 @@
 #include <memory.h>
 #include <asm/system_info.h>
 #include <asm/sections.h>
+#include <zero_page.h>
 
 #include "mmu.h"
 
@@ -354,6 +355,18 @@ static void create_zero_page(void)
 	}
 }
 
+void zero_page_access(void)
+{
+	arm_create_pte(0x0, pte_flags_cached);
+}
+
+void zero_page_faulting(void)
+{
+	u32 *zero;
+	zero = arm_create_pte(0x0, pte_flags_uncached);
+	zero[0] = 0;
+}
+
 /*
  * Map vectors and zero page
  */
diff --git a/include/zero_page.h b/include/zero_page.h
index ad6861f240..b0efb814db 100644
--- a/include/zero_page.h
+++ b/include/zero_page.h
@@ -4,8 +4,6 @@
 
 #include <common.h>
 
-#if defined CONFIG_ARCH_HAS_ZERO_PAGE
-
 /*
  * zero_page_faulting - fault when accessing the zero page
  */
@@ -20,18 +18,6 @@ void zero_page_faulting(void);
  */
 void zero_page_access(void);
 
-#else
-
-static inline void zero_page_faulting(void)
-{
-}
-
-static inline void zero_page_access(void)
-{
-}
-
-#endif
-
 static inline bool zero_page_contains(unsigned long addr)
 {
 	return addr < PAGE_SIZE;
diff --git a/lib/Kconfig b/lib/Kconfig
index e5831ecdb9..887f50ff00 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -182,9 +182,6 @@ config ARCH_HAS_STACK_DUMP
 config ARCH_HAS_DATA_ABORT_MASK
 	bool
 
-config ARCH_HAS_ZERO_PAGE
-	bool
-
 config HAVE_EFFICIENT_UNALIGNED_ACCESS
 	bool
 
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Rouven Czerwinski]

Annotate the different read and write functions with
zero_page_{access/faulting}. This allows the cfi_flash driver to be used
on the QEMU virt machine with an enabled MMU.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 drivers/mtd/nor/cfi_flash.c |  6 ++++++
 drivers/mtd/nor/cfi_flash.h | 18 ++++++++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/mtd/nor/cfi_flash.c b/drivers/mtd/nor/cfi_flash.c
index 225b03ec3d..2fcbd13e46 100644
--- a/drivers/mtd/nor/cfi_flash.c
+++ b/drivers/mtd/nor/cfi_flash.c
@@ -896,8 +896,10 @@ static int cfi_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
 {
 	struct flash_info *info = container_of(mtd, struct flash_info, mtd);
 
+	zero_page_access();
 	memcpy(buf, info->base + from, len);
 	*retlen = len;
+	zero_page_faulting();
 
 	return 0;
 }
@@ -908,7 +910,9 @@ static int cfi_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
 	struct flash_info *info = container_of(mtd, struct flash_info, mtd);
 	int ret;
 
+	zero_page_access();
 	ret = write_buff(info, buf, (unsigned long)info->base + to, len);
+	zero_page_faulting();
 	*retlen = len;
 
         return ret;
@@ -919,7 +923,9 @@ static int cfi_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
 	struct flash_info *info = container_of(mtd, struct flash_info, mtd);
 	int ret;
 
+	zero_page_access();
 	ret = cfi_erase(info, instr->len, instr->addr);
+	zero_page_faulting();
 	if (ret)
 		return -EIO;
 
diff --git a/drivers/mtd/nor/cfi_flash.h b/drivers/mtd/nor/cfi_flash.h
index cea6a8712c..99359a325e 100644
--- a/drivers/mtd/nor/cfi_flash.h
+++ b/drivers/mtd/nor/cfi_flash.h
@@ -22,6 +22,8 @@
 #include <io.h>
 #include <linux/mtd/mtd.h>
 
+#include <zero_page.h>
+
 typedef unsigned long flash_sect_t;
 
 #if   defined(CONFIG_DRIVER_CFI_BANK_WIDTH_8)
@@ -255,43 +257,59 @@ void flash_make_cmd(struct flash_info *info, u32 cmd, cfiword_t *cmdbuf);
 
 static inline void flash_write8(u8 value, void *addr)
 {
+	zero_page_access();
 	__raw_writeb(value, addr);
+	zero_page_faulting();
 }
 
 static inline void flash_write16(u16 value, void *addr)
 {
+	zero_page_access();
 	__raw_writew(value, addr);
+	zero_page_faulting();
 }
 
 static inline void flash_write32(u32 value, void *addr)
 {
+	zero_page_access();
 	__raw_writel(value, addr);
+	zero_page_faulting();
 }
 
 static inline void flash_write64(u64 value, void *addr)
 {
+	zero_page_access();
 	memcpy((void *)addr, &value, 8);
+	zero_page_faulting();
 }
 
 static inline u8 flash_read8(void *addr)
 {
+	zero_page_access();
 	return __raw_readb(addr);
+	zero_page_faulting();
 }
 
 static inline u16 flash_read16(void *addr)
 {
+	zero_page_access();
 	return __raw_readw(addr);
+	zero_page_faulting();
 }
 
 static inline u32 flash_read32(void *addr)
 {
+	zero_page_access();
 	return __raw_readl(addr);
+	zero_page_faulting();
 }
 
 static inline u64 flash_read64(void *addr)
 {
+	zero_page_access();
 	/* No architectures currently implement readq() */
 	return *(volatile u64 *)addr;
+	zero_page_faulting();
 }
 
 /*
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 3/8] amba: add *_amba_driver helper macros

[Rouven Czerwinski]

Reuse the flexible register_driver_macro() to add
{device,coredevice,console}_amba_driver to get rid of the init
boilerplate code used within the amba drivers.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 drivers/clocksource/amba-sp804.c | 2 +-
 drivers/mci/mmci.c               | 7 +------
 drivers/serial/amba-pl011.c      | 8 +-------
 include/linux/amba/bus.h         | 7 +++++++
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/clocksource/amba-sp804.c b/drivers/clocksource/amba-sp804.c
index 8ed5ae4be0..0c0ecaa83a 100644
--- a/drivers/clocksource/amba-sp804.c
+++ b/drivers/clocksource/amba-sp804.c
@@ -85,4 +85,4 @@ struct amba_driver sp804_driver = {
 	.id_table	= sp804_ids,
 };
 
-coredevice_platform_driver(sp804_driver);
+coredevice_amba_driver(sp804_driver);
diff --git a/drivers/mci/mmci.c b/drivers/mci/mmci.c
index f45557d4f7..53f25dff96 100644
--- a/drivers/mci/mmci.c
+++ b/drivers/mci/mmci.c
@@ -709,9 +709,4 @@ static struct amba_driver mmci_driver = {
 	.id_table	= mmci_ids,
 };
 
-static int mmci_init(void)
-{
-	amba_driver_register(&mmci_driver);
-	return 0;
-}
-device_initcall(mmci_init);
+device_amba_driver(mmci_driver);
diff --git a/drivers/serial/amba-pl011.c b/drivers/serial/amba-pl011.c
index 865ecdddb2..9261d20f2a 100644
--- a/drivers/serial/amba-pl011.c
+++ b/drivers/serial/amba-pl011.c
@@ -237,10 +237,4 @@ struct amba_driver pl011_driver = {
 	.id_table	= pl011_ids,
 };
 
-static int pl011_init(void)
-{
-	amba_driver_register(&pl011_driver);
-	return 0;
-}
-
-console_initcall(pl011_init);
+console_amba_driver(pl011_driver);
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 7b3e603322..390220a3de 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -60,6 +60,13 @@ extern struct bus_type amba_bustype;
 
 #define to_amba_device(d)	container_of(d, struct amba_device, dev)
 
+#define device_amba_driver(drv)	\
+	register_driver_macro(device,amba,drv)
+#define coredevice_amba_driver(drv)	\
+	register_driver_macro(coredevice,amba,drv)
+#define console_amba_driver(drv)	\
+	register_driver_macro(console,amba,drv)
+
 int amba_driver_register(struct amba_driver *);
 void amba_driver_unregister(struct amba_driver *);
 struct amba_device *amba_device_alloc(const char *, int id, resource_size_t, size_t);
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 4/8] ARM: vexpress: remove unused KConfig file

[Rouven Czerwinski]

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 arch/arm/boards/vexpress/Kconfig | 8 --------
 1 file changed, 8 deletions(-)
 delete mode 100644 arch/arm/boards/vexpress/Kconfig

diff --git a/arch/arm/boards/vexpress/Kconfig b/arch/arm/boards/vexpress/Kconfig
deleted file mode 100644
index 94cba3ba81..0000000000
--- a/arch/arm/boards/vexpress/Kconfig
+++ /dev/null
@@ -1,8 +0,0 @@
-
-if MACH_VERSATILEPB
-
-config ARCH_TEXT_BASE
-	hex
-	default 0x01000000
-
-endif
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 5/8] ARM: vexpress: convert to board driver

[Rouven Czerwinski]

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 arch/arm/boards/vexpress/init.c | 69 +++++++++++++++++++--------------
 1 file changed, 40 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boards/vexpress/init.c b/arch/arm/boards/vexpress/init.c
index 946385393f..6ba23bbb62 100644
--- a/arch/arm/boards/vexpress/init.c
+++ b/arch/arm/boards/vexpress/init.c
@@ -19,9 +19,33 @@
 
 #define V2M_SYS_FLASH	0x03c
 
-static int vexpress_core_init(void)
+static int of_fixup_virtio_mmio(struct device_node *root, void *unused)
+{
+	struct device_node *barebox_root, *np, *parent;
+
+	barebox_root = of_get_root_node();
+	if (root == barebox_root)
+		return 0;
+
+	for_each_compatible_node_from(np, barebox_root, NULL, "virtio,mmio") {
+		if (of_get_parent(np) == barebox_root)
+			parent = root;
+		else
+			parent = of_find_node_by_path_from(root,
+							   of_get_parent(np)->full_name);
+		if (!parent)
+			return -EINVAL;
+
+		of_copy_node(parent, np);
+	}
+
+	return 0;
+}
+
+static int vexpress_probe(struct device_d *dev)
 {
 	char *hostname = "vexpress-unknown";
+	int ret = 0;
 
 	if (amba_is_arm_sp804(IOMEM(0x10011000))) {
 		vexpress_a9_legacy_init();
@@ -42,35 +66,22 @@ static int vexpress_core_init(void)
 
 	barebox_set_hostname(hostname);
 
-	return 0;
-}
-postcore_initcall(vexpress_core_init);
-
-static int of_fixup_virtio_mmio(struct device_node *root, void *unused)
-{
-	struct device_node *barebox_root, *np, *parent;
-
-	barebox_root = of_get_root_node();
-	if (root == barebox_root)
-		return 0;
+	ret = of_register_fixup(of_fixup_virtio_mmio, NULL);
 
-	for_each_compatible_node_from(np, barebox_root, NULL, "virtio,mmio") {
-		if (of_get_parent(np) == barebox_root)
-			parent = root;
-		else
-			parent = of_find_node_by_path_from(root,
-							   of_get_parent(np)->full_name);
-		if (!parent)
-			return -EINVAL;
+	return ret;
+}
 
-		of_copy_node(parent, np);
-	}
+static const struct of_device_id vexpress_of_match[] = {
+	{ .compatible = "arm,vexpress,v2p-ca9" },
+	{ .compatible = "arm,vexpress,v2p-ca15" },
+	{ .compatible = "arm,vexpress" },
+	{ /* Sentinel */},
+};
 
-	return 0;
-}
+static struct driver_d vexpress_board_driver = {
+	.name = "board-vexpress",
+	.probe = vexpress_probe,
+	.of_compatible = vexpress_of_match,
+};
 
-static int of_register_virtio_mmio_fixup(void)
-{
-	return of_register_fixup(of_fixup_virtio_mmio, NULL);
-}
-late_initcall(of_register_virtio_mmio_fixup);
+postcore_platform_driver(vexpress_board_driver);
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 6/8] ARM: vexpress: move Options to ARCH_VEXPRESS

[Rouven Czerwinski]

In preparation for the qemu virt image, move the KConfig options from
MACH_VEXPRESS to ARCH_VEXPRESS. Also remove the choice, since we allow
multiple boards to be selected with HAVE_PBL_MULTI_IMAGES.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 arch/arm/Kconfig               | 4 ++++
 arch/arm/mach-vexpress/Kconfig | 8 --------
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ea6d459dfe..91da0e4ff3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -223,6 +223,10 @@ config ARCH_VEXPRESS
 	select AMBA_SP804
 	select CLKDEV_LOOKUP
 	select COMMON_CLK
+	select OFTREE
+	select OFDEVICE
+	select RELOCATABLE
+	select HAVE_PBL_MULTI_IMAGES
 
 config ARCH_TEGRA
 	bool "NVIDIA Tegra"
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index aaa535f073..4058177b3a 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -4,17 +4,9 @@ config ARCH_TEXT_BASE
 	hex
 	default 0x0
 
-choice
-	prompt "ARM Board type"
-
 config MACH_VEXPRESS
 	bool "ARM Vexpress"
-	select RELOCATABLE
-	select HAVE_PBL_MULTI_IMAGES
-	select OFTREE
-	select OFDEVICE
 	select COMMON_CLK_OF_PROVIDER
 
-endchoice
 
 endif
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 7/8] ARM: qemu: add support for qemu virt platform

[Rouven Czerwinski]

Necessary support to boot barebox on ARM qemu virt platforms.
No internal device tree, since it is passed by qemu. Therefore it
employs the generic 2nd stage image as the low level code and only adds
a virt specific board driver.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 arch/arm/Kconfig                   |  2 +-
 arch/arm/boards/Makefile           |  1 +
 arch/arm/boards/qemu-virt/Makefile |  1 +
 arch/arm/boards/qemu-virt/board.c  | 36 ++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Kconfig     |  4 ++++
 5 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boards/qemu-virt/Makefile
 create mode 100644 arch/arm/boards/qemu-virt/board.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 91da0e4ff3..5342de54c1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -216,7 +216,7 @@ config ARCH_VERSATILE
 	select HAS_DEBUG_LL
 
 config ARCH_VEXPRESS
-	bool "ARM Vexpres boards"
+	bool "ARM Vexpress & virt boards"
 	select HAS_DEBUG_LL
 	select CPU_V7
 	select ARM_AMBA
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index a02d80d2da..81c228efd6 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_MACH_ZYLONITE)			+= zylonite/
 obj-$(CONFIG_MACH_VARISCITE_MX6)		+= variscite-mx6/
 obj-$(CONFIG_MACH_VSCOM_BALTOS)			+= vscom-baltos/
 obj-$(CONFIG_MACH_QEMU_VIRT64)			+= qemu-virt64/
+obj-$(CONFIG_MACH_VIRT)				+= qemu-virt/
 obj-$(CONFIG_MACH_WARP7)			+= element14-warp7/
 obj-$(CONFIG_MACH_WEBASTO_CCBV2)		+= webasto-ccbv2/
 obj-$(CONFIG_MACH_VF610_TWR)			+= freescale-vf610-twr/
diff --git a/arch/arm/boards/qemu-virt/Makefile b/arch/arm/boards/qemu-virt/Makefile
new file mode 100644
index 0000000000..dcfc2937d3
--- /dev/null
+++ b/arch/arm/boards/qemu-virt/Makefile
@@ -0,0 +1 @@
+obj-y += board.o
diff --git a/arch/arm/boards/qemu-virt/board.c b/arch/arm/boards/qemu-virt/board.c
new file mode 100644
index 0000000000..3aeea1a017
--- /dev/null
+++ b/arch/arm/boards/qemu-virt/board.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Pengutronix e.K.
+ *
+ */
+#include <common.h>
+#include <init.h>
+#include <asm/system_info.h>
+
+static int virt_probe(struct device_d *dev)
+{
+	char *hostname = "virt";
+
+	if (cpu_is_cortex_a7())
+		hostname = "virt-a7";
+	else if (cpu_is_cortex_a15())
+		hostname = "virt-a15";
+
+	barebox_set_model("ARM QEMU virt");
+	barebox_set_hostname(hostname);
+
+	return 0;
+}
+
+static const struct of_device_id virt_of_match[] = {
+	{ .compatible = "linux,dummy-virt" },
+	{ /* Sentinel */},
+};
+
+static struct driver_d virt_board_driver = {
+	.name = "board-qemu-virt",
+	.probe = virt_probe,
+	.of_compatible = virt_of_match,
+};
+
+postcore_platform_driver(virt_board_driver);
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 4058177b3a..7677a1411b 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -8,5 +8,9 @@ config MACH_VEXPRESS
 	bool "ARM Vexpress"
 	select COMMON_CLK_OF_PROVIDER
 
+config MACH_VIRT
+	bool "QEMU virt"
+	select ARM_PSCI_CLIENT
+	select BOARD_ARM_GENERIC_DT
 
 endif
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 8/8] ARM: vexpress: enable VIRT board, MMU and cmds

[Rouven Czerwinski]

Enable the new qemu virt board, the MMU, ofdiff and mmuinfo.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
 arch/arm/configs/vexpress_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
index caa9f512d6..b8dc2686da 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -1,4 +1,6 @@
 CONFIG_ARCH_VEXPRESS=y
+CONFIG_MACH_VEXPRESS=y
+CONFIG_MACH_VIRT=y
 CONFIG_AEABI=y
 CONFIG_ARM_OPTIMZED_STRING_FUNCTIONS=y
 CONFIG_MALLOC_SIZE=0x0
@@ -36,6 +38,7 @@ CONFIG_CMD_EDIT=y
 CONFIG_CMD_LOGIN=y
 CONFIG_CMD_MENU=y
 CONFIG_CMD_MENU_MANAGEMENT=y
+CONFIG_CMD_ARM_MMUINFO=y
 CONFIG_CMD_PASSWD=y
 CONFIG_CMD_READLINE=y
 CONFIG_CMD_TIMEOUT=y
@@ -44,6 +47,7 @@ CONFIG_CMD_CRC_CMP=y
 CONFIG_CMD_CLK=y
 CONFIG_CMD_DETECT=y
 CONFIG_CMD_OFTREE=y
+CONFIG_CMD_OF_DIFF=y
 CONFIG_NET=y
 CONFIG_NET_NFS=y
 CONFIG_NET_NETCONSOLE=y
@@ -52,6 +56,7 @@ CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_DRIVER_NET_SMC91111=y
 # CONFIG_SPI is not set
 CONFIG_MTD=y
+CONFIG_MMU=y
 CONFIG_MTD_CONCAT=y
 CONFIG_DRIVER_CFI=y
 CONFIG_MCI=y
-- 
2.28.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Lucas Stach]

Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> Annotate the different read and write functions with
> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> on the QEMU virt machine with an enabled MMU.

I don't like this zero-page access allow in a driver at all. If you
have some free address space somewhere, you could also solve this issue
by remapping the IO resource to somewhere else in the address space,
deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
if you need some inspiration.

Regards,
Lucas

> Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
> ---
>  drivers/mtd/nor/cfi_flash.c |  6 ++++++
>  drivers/mtd/nor/cfi_flash.h | 18 ++++++++++++++++++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/mtd/nor/cfi_flash.c b/drivers/mtd/nor/cfi_flash.c
> index 225b03ec3d..2fcbd13e46 100644
> --- a/drivers/mtd/nor/cfi_flash.c
> +++ b/drivers/mtd/nor/cfi_flash.c
> @@ -896,8 +896,10 @@ static int cfi_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
>  {
>  	struct flash_info *info = container_of(mtd, struct flash_info, mtd);
>  
> +	zero_page_access();
>  	memcpy(buf, info->base + from, len);
>  	*retlen = len;
> +	zero_page_faulting();
>  
>  	return 0;
>  }
> @@ -908,7 +910,9 @@ static int cfi_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
>  	struct flash_info *info = container_of(mtd, struct flash_info, mtd);
>  	int ret;
>  
> +	zero_page_access();
>  	ret = write_buff(info, buf, (unsigned long)info->base + to, len);
> +	zero_page_faulting();
>  	*retlen = len;
>  
>          return ret;
> @@ -919,7 +923,9 @@ static int cfi_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
>  	struct flash_info *info = container_of(mtd, struct flash_info, mtd);
>  	int ret;
>  
> +	zero_page_access();
>  	ret = cfi_erase(info, instr->len, instr->addr);
> +	zero_page_faulting();
>  	if (ret)
>  		return -EIO;
>  
> diff --git a/drivers/mtd/nor/cfi_flash.h b/drivers/mtd/nor/cfi_flash.h
> index cea6a8712c..99359a325e 100644
> --- a/drivers/mtd/nor/cfi_flash.h
> +++ b/drivers/mtd/nor/cfi_flash.h
> @@ -22,6 +22,8 @@
>  #include <io.h>
>  #include <linux/mtd/mtd.h>
>  
> +#include <zero_page.h>
> +
>  typedef unsigned long flash_sect_t;
>  
>  #if   defined(CONFIG_DRIVER_CFI_BANK_WIDTH_8)
> @@ -255,43 +257,59 @@ void flash_make_cmd(struct flash_info *info, u32 cmd, cfiword_t *cmdbuf);
>  
>  static inline void flash_write8(u8 value, void *addr)
>  {
> +	zero_page_access();
>  	__raw_writeb(value, addr);
> +	zero_page_faulting();
>  }
>  
>  static inline void flash_write16(u16 value, void *addr)
>  {
> +	zero_page_access();
>  	__raw_writew(value, addr);
> +	zero_page_faulting();
>  }
>  
>  static inline void flash_write32(u32 value, void *addr)
>  {
> +	zero_page_access();
>  	__raw_writel(value, addr);
> +	zero_page_faulting();
>  }
>  
>  static inline void flash_write64(u64 value, void *addr)
>  {
> +	zero_page_access();
>  	memcpy((void *)addr, &value, 8);
> +	zero_page_faulting();
>  }
>  
>  static inline u8 flash_read8(void *addr)
>  {
> +	zero_page_access();
>  	return __raw_readb(addr);
> +	zero_page_faulting();
>  }
>  
>  static inline u16 flash_read16(void *addr)
>  {
> +	zero_page_access();
>  	return __raw_readw(addr);
> +	zero_page_faulting();
>  }
>  
>  static inline u32 flash_read32(void *addr)
>  {
> +	zero_page_access();
>  	return __raw_readl(addr);
> +	zero_page_faulting();
>  }
>  
>  static inline u64 flash_read64(void *addr)
>  {
> +	zero_page_access();
>  	/* No architectures currently implement readq() */
>  	return *(volatile u64 *)addr;
> +	zero_page_faulting();
>  }
>  
>  /*


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Rouven Czerwinski]

On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> > Annotate the different read and write functions with
> > zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> > on the QEMU virt machine with an enabled MMU.
> 
> I don't like this zero-page access allow in a driver at all. If you
> have some free address space somewhere, you could also solve this issue
> by remapping the IO resource to somewhere else in the address space,
> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> if you need some inspiration.

I totally agree, remapping the IO region sounds like a much better
choice.

Regards,
Rouven



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Sascha Hauer]

On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> > > Annotate the different read and write functions with
> > > zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> > > on the QEMU virt machine with an enabled MMU.
> > 
> > I don't like this zero-page access allow in a driver at all. If you
> > have some free address space somewhere, you could also solve this issue
> > by remapping the IO resource to somewhere else in the address space,
> > deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> > if you need some inspiration.
> 
> I totally agree, remapping the IO region sounds like a much better
> choice.

But where should it be mapped to? Just 4k upwards and hope that the area
just above the cfi flash isn't occupied by something else?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Sascha Hauer]

On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
> > On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> > > > Annotate the different read and write functions with
> > > > zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> > > > on the QEMU virt machine with an enabled MMU.
> > > 
> > > I don't like this zero-page access allow in a driver at all. If you
> > > have some free address space somewhere, you could also solve this issue
> > > by remapping the IO resource to somewhere else in the address space,
> > > deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> > > if you need some inspiration.
> > 
> > I totally agree, remapping the IO region sounds like a much better
> > choice.
> 
> But where should it be mapped to? Just 4k upwards and hope that the area
> just above the cfi flash isn't occupied by something else?

Ok, here's the plan:

In a board specific initcall map the memory to wherever it's convenient,
modify the address of the CFI flash in the device node and add a big
comment that there's nothing to see here.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Ahmad Fatoum]

Hi,

On 11/10/20 10:15 AM, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
>> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
>>> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
>>>> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
>>>>> Annotate the different read and write functions with
>>>>> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
>>>>> on the QEMU virt machine with an enabled MMU.
>>>>
>>>> I don't like this zero-page access allow in a driver at all. If you
>>>> have some free address space somewhere, you could also solve this issue
>>>> by remapping the IO resource to somewhere else in the address space,
>>>> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
>>>> if you need some inspiration.
>>>
>>> I totally agree, remapping the IO region sounds like a much better
>>> choice.
>>
>> But where should it be mapped to? Just 4k upwards and hope that the area
>> just above the cfi flash isn't occupied by something else?
> 
> Ok, here's the plan:
> 
> In a board specific initcall map the memory to wherever it's convenient,
> modify the address of the CFI flash in the device node and add a big
> comment that there's nothing to see here.

The device tree specification defines a "virtual-reg property [that] specifies
an effective address that maps to the first physical address specified in
the reg property of the device node.  This property enables boot programs to
provide client programs with virtual-to-physical mappings that have been set up".

So, how about a tad more generic approach:

- barebox device tree extends cfi-flash node with virtual-reg of appropriate
  location
- Define a of_iomap() function that
  - MMU off => does normal request_iomem_region when MMU is off
  - MMU on  => remaps reg to virtual-reg and does request_iomem_region

Advantages:
  - No extra board code
  - Reusable for others as well
  - No device tree patching necessary

I am not familiar with the PowerPC support in barebox, but if we keep the MMU
on, then the use of virtual-reg is correct and if we turn it off, it doesn't
hurt to have it, so we should be within spec.

Let me know what you think.
Cheers,
Ahmad

> 
> Sascha
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Ahmad Fatoum]

On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> Hi,
> 
> On 11/10/20 10:15 AM, Sascha Hauer wrote:
>> On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
>>> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
>>>> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
>>>>> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
>>>>>> Annotate the different read and write functions with
>>>>>> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
>>>>>> on the QEMU virt machine with an enabled MMU.
>>>>>
>>>>> I don't like this zero-page access allow in a driver at all. If you
>>>>> have some free address space somewhere, you could also solve this issue
>>>>> by remapping the IO resource to somewhere else in the address space,
>>>>> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
>>>>> if you need some inspiration.
>>>>
>>>> I totally agree, remapping the IO region sounds like a much better
>>>> choice.
>>>
>>> But where should it be mapped to? Just 4k upwards and hope that the area
>>> just above the cfi flash isn't occupied by something else?
>>
>> Ok, here's the plan:
>>
>> In a board specific initcall map the memory to wherever it's convenient,
>> modify the address of the CFI flash in the device node and add a big
>> comment that there's nothing to see here.
> 
> The device tree specification defines a "virtual-reg property [that] specifies
> an effective address that maps to the first physical address specified in
> the reg property of the device node.  This property enables boot programs to
> provide client programs with virtual-to-physical mappings that have been set up".
> 
> So, how about a tad more generic approach:
> 
> - barebox device tree extends cfi-flash node with virtual-reg of appropriate
>   location
> - Define a of_iomap() function that

Or rather a  more generic name, like dev_ioremap?.(In that case
!CONFIG_OF is the same as MMU off).

>   - MMU off => does normal request_iomem_region when MMU is off
>   - MMU on  => remaps reg to virtual-reg and does request_iomem_region
> 
> Advantages:
>   - No extra board code
>   - Reusable for others as well
>   - No device tree patching necessary
> 
> I am not familiar with the PowerPC support in barebox, but if we keep the MMU
> on, then the use of virtual-reg is correct and if we turn it off, it doesn't
> hurt to have it, so we should be within spec.
> 
> Let me know what you think.
> Cheers,
> Ahmad
> 
>>
>> Sascha
>>
>>
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Sascha Hauer]

On Tue, Nov 10, 2020 at 10:43:30AM +0100, Ahmad Fatoum wrote:
> On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> > Hi,
> > 
> > On 11/10/20 10:15 AM, Sascha Hauer wrote:
> >> On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> >>> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
> >>>> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> >>>>> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> >>>>>> Annotate the different read and write functions with
> >>>>>> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> >>>>>> on the QEMU virt machine with an enabled MMU.
> >>>>>
> >>>>> I don't like this zero-page access allow in a driver at all. If you
> >>>>> have some free address space somewhere, you could also solve this issue
> >>>>> by remapping the IO resource to somewhere else in the address space,
> >>>>> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> >>>>> if you need some inspiration.
> >>>>
> >>>> I totally agree, remapping the IO region sounds like a much better
> >>>> choice.
> >>>
> >>> But where should it be mapped to? Just 4k upwards and hope that the area
> >>> just above the cfi flash isn't occupied by something else?
> >>
> >> Ok, here's the plan:
> >>
> >> In a board specific initcall map the memory to wherever it's convenient,
> >> modify the address of the CFI flash in the device node and add a big
> >> comment that there's nothing to see here.
> > 
> > The device tree specification defines a "virtual-reg property [that] specifies
> > an effective address that maps to the first physical address specified in
> > the reg property of the device node.  This property enables boot programs to
> > provide client programs with virtual-to-physical mappings that have been set up".
> > 
> > So, how about a tad more generic approach:
> > 
> > - barebox device tree extends cfi-flash node with virtual-reg of appropriate
> >   location
> > - Define a of_iomap() function that
> 
> Or rather a  more generic name, like dev_ioremap?.(In that case
> !CONFIG_OF is the same as MMU off).

I wouldn't use ioremap as name when the function has a different
semantics, but other than that: Sounds good. Make it so!

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping

[Rouven Czerwinski]

On Thu, 2020-11-12 at 11:06 +0100, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 10:43:30AM +0100, Ahmad Fatoum wrote:
> > On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> > > Hi,
> > > 
> > > On 11/10/20 10:15 AM, Sascha Hauer wrote:
> > > > On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> > > > > On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski
> > > > > wrote:
> > > > > > On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > > > > > > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven
> > > > > > > Czerwinski:
> > > > > > > > Annotate the different read and write functions with
> > > > > > > > zero_page_{access/faulting}. This allows the cfi_flash
> > > > > > > > driver to be used
> > > > > > > > on the QEMU virt machine with an enabled MMU.
> > > > > > > 
> > > > > > > I don't like this zero-page access allow in a driver at
> > > > > > > all. If you
> > > > > > > have some free address space somewhere, you could also
> > > > > > > solve this issue
> > > > > > > by remapping the IO resource to somewhere else in the
> > > > > > > address space,
> > > > > > > deviating from the 1:1 mapping. The Tegra PCIe host
> > > > > > > driver does this,
> > > > > > > if you need some inspiration.
> > > > > > 
> > > > > > I totally agree, remapping the IO region sounds like a much
> > > > > > better
> > > > > > choice.
> > > > > 
> > > > > But where should it be mapped to? Just 4k upwards and hope
> > > > > that the area
> > > > > just above the cfi flash isn't occupied by something else?
> > > > 
> > > > Ok, here's the plan:
> > > > 
> > > > In a board specific initcall map the memory to wherever it's
> > > > convenient,
> > > > modify the address of the CFI flash in the device node and add
> > > > a big
> > > > comment that there's nothing to see here.
> > > 
> > > The device tree specification defines a "virtual-reg property
> > > [that] specifies
> > > an effective address that maps to the first physical address
> > > specified in
> > > the reg property of the device node.  This property enables boot
> > > programs to
> > > provide client programs with virtual-to-physical mappings that
> > > have been set up".
> > > 
> > > So, how about a tad more generic approach:
> > > 
> > > - barebox device tree extends cfi-flash node with virtual-reg of
> > > appropriate
> > >   location
> > > - Define a of_iomap() function that
> > 
> > Or rather a  more generic name, like dev_ioremap?.(In that case
> > !CONFIG_OF is the same as MMU off).
> 
> I wouldn't use ioremap as name when the function has a different
> semantics, but other than that: Sounds good. Make it so!

This only works if you have available IOMEM big enough somewhere, which
is not the case on the qemu ARM virt platform. While I agree that
having MMU enabled is great for testing, maybe we can just add !MMU as
a dependency for the virt board.

Regards,
Rouven


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 0/8] QEMU virt machine support via mach-vexpress

[Sascha Hauer]

On Mon, Nov 09, 2020 at 02:44:22PM +0100, Rouven Czerwinski wrote:
> Instead of using ARCH_QEMU, this variant uses ARCH_VEXPRESS to base its
> support for the QEMU virt machine on. Contains a cleanup and conversion
> of the vexpress boards to board drivers and an implementation of
> zero_page_access and faulting for ARM32.
> 
> Rouven Czerwinski (8):
>   ARM: MMU: add zero_page_{access,faulting}
>   mtd: cfi_flash: allow 0x0 mapping
>   amba: add *_amba_driver helper macros
>   ARM: vexpress: remove unused KConfig file
>   ARM: vexpress: convert to board driver
>   ARM: vexpress: move Options to ARCH_VEXPRESS
>   ARM: qemu: add support for qemu virt platform
>   ARM: vexpress: enable VIRT board, MMU and cmds

Until the flash-at-zero problem is solved: Applied 3-7.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox