[PATCH v3 0/7] rpi5: initial support

[PATCH v3 0/7] rpi5: initial support

[Ivan T. Ivanov]

Hi,

These patches are adding basic support for RPi5.
They are based on v2 series from Dmitry Malkin[1].

With them I am able to _start_ current openSUSE
Tumbleweed without modification. They are still
a lot of things to be added to the upstream Linux
before it runs flawlessly on this device, but at
least in U-Booot SD controller used for uSD card
and Frameboffer and HDMI0 devices are working fine
now. It seems that PCIe controller is working fine
too, but I have not tested it too much.

Serial console and reset are also functional.

Hopefully this will help others add missing pieces
more easily.

Happy hacking!

Regards,
Ivan

[1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1R+L24WBgpo-iP1yo7A@mail.gmail.com/

Dmitry Malkin (2):
  rpi5: add initial memory map for bcm2712
  rpi5: Use devicetree as alternative way to read IO base addresses

Ivan T. Ivanov (5):
  rpi5: Use devicetree to retrieve board revision
  bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
  mmc: bcmstb: Add support for bcm2712 SD controller
  configs: rpi_arm64: enable SDHCI BCMSTB driver
  pci: pcie-brcmstb: Add bcm2712 PCIe controller support

 arch/arm/mach-bcm283x/include/mach/base.h  |   5 +-
 arch/arm/mach-bcm283x/include/mach/mbox.h  |   3 +-
 arch/arm/mach-bcm283x/include/mach/sdhci.h |   3 +-
 arch/arm/mach-bcm283x/include/mach/timer.h |   3 +-
 arch/arm/mach-bcm283x/include/mach/wdog.h  |   3 +-
 arch/arm/mach-bcm283x/init.c               |  81 ++++++++--
 board/raspberrypi/rpi/rpi.c                |  22 ++-
 configs/rpi_arm64_defconfig                |   1 +
 drivers/mmc/bcmstb_sdhci.c                 | 173 ++++++++++++++++++++-
 drivers/pci/pcie_brcmstb.c                 |  23 ++-
 drivers/video/bcm2835.c                    |  10 +-
 11 files changed, 296 insertions(+), 31 deletions(-)

-- 
2.35.3

[PATCH v3 1/7] rpi5: add initial memory map for bcm2712

[Ivan T. Ivanov]

From: Dmitry Malkin <dmitry@bedrocksystems.com>

includes:
* 1GB of RAM (from 4GB or 8GB total)
* VPU memory interface
* AXI ranges (main peripherals)

Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 arch/arm/mach-bcm283x/init.c | 38 +++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 7265faf6ce..af23b9711a 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -19,7 +19,7 @@
 #ifdef CONFIG_ARM64
 #include <asm/armv8/mmu.h>
 
-#define MEM_MAP_MAX_ENTRIES (4)
+#define MEM_MAP_MAX_ENTRIES (5)
 
 static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = {
 	{
@@ -68,6 +68,41 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
 	}
 };
 
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
+	{
+		.virt = 0x00000000UL,
+		.phys = 0x00000000UL,
+		.size = 0x3f800000UL,
+		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+			 PTE_BLOCK_INNER_SHARE
+	}, {
+		.virt = 0x3f800000UL,
+		.phys = 0x3f800000UL,
+		.size = 0x00800000UL,
+		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+			 PTE_BLOCK_NON_SHARE |
+			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
+	}, {
+		/* Beginning of AXI bus where uSD controller lives */
+		.virt = 0x1000000000UL,
+		.phys = 0x1000000000UL,
+		.size = 0x0002000000UL,
+		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+			 PTE_BLOCK_NON_SHARE |
+			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
+	}, {
+		.virt = 0x107c000000UL,
+		.phys = 0x107c000000UL,
+		.size = 0x0004000000UL,
+		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+			 PTE_BLOCK_NON_SHARE |
+			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
+	}, {
+		/* List terminator */
+		0,
+	}
+};
+
 struct mm_region *mem_map = bcm283x_mem_map;
 
 /*
@@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = {
 	{ .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map},
 	{ .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map},
 	{ .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map},
+	{ .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map},
 	{ },
 };
 
-- 
2.35.3

[PATCH v3 2/7] rpi5: Use devicetree as alternative way to read IO base addresses

[Ivan T. Ivanov]

From: Dmitry Malkin <dmitry@bedrocksystems.com>

MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.
Find them via devicetree blob passed by bootloader.

Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 arch/arm/mach-bcm283x/include/mach/base.h  |  5 ++-
 arch/arm/mach-bcm283x/include/mach/mbox.h  |  3 +-
 arch/arm/mach-bcm283x/include/mach/sdhci.h |  3 +-
 arch/arm/mach-bcm283x/include/mach/timer.h |  3 +-
 arch/arm/mach-bcm283x/include/mach/wdog.h  |  3 +-
 arch/arm/mach-bcm283x/init.c               | 43 ++++++++++++++++++----
 6 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-bcm283x/include/mach/base.h b/arch/arm/mach-bcm283x/include/mach/base.h
index 4ccaf69693..6de99e7ea1 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -6,7 +6,10 @@
 #ifndef _BCM283x_BASE_H_
 #define _BCM283x_BASE_H_
 
-extern unsigned long rpi_bcm283x_base;
+extern unsigned long rpi_mbox_base;
+extern unsigned long rpi_timer_base;
+extern unsigned long rpi_sdhci_base;
+extern unsigned long rpi_wdog_base;
 
 #ifdef CONFIG_ARMV7_LPAE
 #ifdef CONFIG_TARGET_RPI_4_32B
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 490664f878..35d4e2f075 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -38,8 +38,7 @@
 
 /* Raw mailbox HW */
 
-#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-				 rpi_bcm283x_base + 0x0000b880; })
+#define BCM2835_MBOX_PHYSADDR	rpi_mbox_base
 
 struct bcm2835_mbox_regs {
 	u32 read;
diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h b/arch/arm/mach-bcm283x/include/mach/sdhci.h
index 7323690687..e837c679c4 100644
--- a/arch/arm/mach-bcm283x/include/mach/sdhci.h
+++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h
@@ -8,8 +8,7 @@
 
 #include <asm/arch/base.h>
 
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-				  rpi_bcm283x_base + 0x00300000; })
+#define BCM2835_SDHCI_PHYSADDR	rpi_sdhci_base
 
 int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
 
diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h b/arch/arm/mach-bcm283x/include/mach/timer.h
index 5567dbd7f3..60500a256d 100644
--- a/arch/arm/mach-bcm283x/include/mach/timer.h
+++ b/arch/arm/mach-bcm283x/include/mach/timer.h
@@ -11,8 +11,7 @@
 #include <linux/bug.h>
 #endif
 
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-				  rpi_bcm283x_base + 0x00003000; })
+#define BCM2835_TIMER_PHYSADDR	rpi_timer_base
 
 #define BCM2835_TIMER_CS_M3	(1 << 3)
 #define BCM2835_TIMER_CS_M2	(1 << 2)
diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h b/arch/arm/mach-bcm283x/include/mach/wdog.h
index 9942666720..b950560674 100644
--- a/arch/arm/mach-bcm283x/include/mach/wdog.h
+++ b/arch/arm/mach-bcm283x/include/mach/wdog.h
@@ -8,8 +8,7 @@
 
 #include <asm/arch/base.h>
 
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-				 rpi_bcm283x_base + 0x00100000; })
+#define BCM2835_WDOG_PHYSADDR	rpi_wdog_base
 
 struct bcm2835_wdog_regs {
 	u32 unknown0[7];
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index af23b9711a..1c5c748484 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -151,7 +151,11 @@ static void rpi_update_mem_map(void)
 static void rpi_update_mem_map(void) {}
 #endif
 
-unsigned long rpi_bcm283x_base = 0x3f000000;
+/* Default bcm283x devices addresses */
+unsigned long rpi_mbox_base  = 0x3f00b880;
+unsigned long rpi_sdhci_base = 0x3f300000;
+unsigned long rpi_wdog_base  = 0x3f100000;
+unsigned long rpi_timer_base = 0x3f003000;
 
 int arch_cpu_init(void)
 {
@@ -162,22 +166,45 @@ int arch_cpu_init(void)
 
 int mach_cpu_init(void)
 {
-	int ret, soc_offset;
+	int ret, soc, offset;
 	u64 io_base, size;
 
 	rpi_update_mem_map();
 
 	/* Get IO base from device tree */
-	soc_offset = fdt_path_offset(gd->fdt_blob, "/soc");
-	if (soc_offset < 0)
-		return soc_offset;
+	soc = fdt_path_offset(gd->fdt_blob, "/soc");
+	if (soc < 0)
+		return soc;
 
-	ret = fdt_read_range((void *)gd->fdt_blob, soc_offset, 0, NULL,
-				&io_base, &size);
+	ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL,
+			     &io_base, &size);
 	if (ret)
 		return ret;
 
-	rpi_bcm283x_base = io_base;
+	rpi_mbox_base  = io_base + 0x00b880;
+	rpi_sdhci_base = io_base + 0x300000;
+	rpi_wdog_base  = io_base + 0x100000;
+	rpi_timer_base = io_base + 0x003000;
+
+	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+					       "brcm,bcm2835-mbox");
+	if (offset > soc)
+		rpi_mbox_base = fdt_get_base_address(gd->fdt_blob, offset);
+
+	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+					       "brcm,bcm2835-sdhci");
+	if (offset > soc)
+		rpi_sdhci_base = fdt_get_base_address(gd->fdt_blob, offset);
+
+	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+					       "brcm,bcm2835-system-timer");
+	if (offset > soc)
+		rpi_timer_base = fdt_get_base_address(gd->fdt_blob, offset);
+
+	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+					       "brcm,bcm2712-pm");
+	if (offset > soc)
+		rpi_wdog_base = fdt_get_base_address(gd->fdt_blob, offset);
 
 	return 0;
 }
-- 
2.35.3

[PATCH v3 3/7] rpi5: Use devicetree to retrieve board revision

[Ivan T. Ivanov]

Firmware on RPi5 return error on board revision query
through firmware interface, but on the other hand it fills
"linux,revision" in "system" node, so use it to detect board
revision.

	system {
		linux,revision = <0xc04170>;
		linux,serial = <0x6cf44e80 0x3c533ede>;
	};

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 board/raspberrypi/rpi/rpi.c | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index cd823ad746..2851ebc985 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -171,6 +171,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
 		DTB_DIR "bcm2711-rpi-cm4.dtb",
 		true,
 	},
+	[0x17] = {
+		"5 Model B",
+		DTB_DIR "bcm2712-rpi-5-b.dtb",
+		true,
+	},
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
@@ -429,15 +434,27 @@ static void get_board_revision(void)
 	int ret;
 	const struct rpi_model *models;
 	uint32_t models_count;
+	ofnode node;
 
 	BCM2835_MBOX_INIT_HDR(msg);
 	BCM2835_MBOX_INIT_TAG(&msg->get_board_rev, GET_BOARD_REV);
 
 	ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr);
 	if (ret) {
-		printf("bcm2835: Could not query board revision\n");
 		/* Ignore error; not critical */
-		return;
+		node = ofnode_path("/system");
+		if (!ofnode_valid(node)) {
+			printf("bcm2835: Could not find /system node\n");
+			return;
+		}
+
+		ret = ofnode_read_u32(node, "linux,revision", &revision);
+		if (ret) {
+			printf("bcm2835: Could not find linux,revision\n");
+			return;
+		}
+	} else {
+		revision = msg->get_board_rev.body.resp.rev;
 	}
 
 	/*
@@ -451,7 +468,6 @@ static void get_board_revision(void)
 	 * http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=98367&start=250
 	 * http://www.raspberrypi.org/forums/viewtopic.php?f=31&t=20594
 	 */
-	revision = msg->get_board_rev.body.resp.rev;
 	if (revision & 0x800000) {
 		rev_scheme = 1;
 		rev_type = (revision >> 4) & 0xff;
-- 
2.35.3

[PATCH v3 4/7] bcm2835: brcm, bcm2708-fb device is using r5g6b5 format

[Ivan T. Ivanov]

brcm,bcm2708-fb device provided by firmware on RPi5 uses
16 bits per pixel. Update driver to properly handle this.

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 drivers/video/bcm2835.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 14942526f1..245c958b6e 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -43,7 +43,7 @@ static int bcm2835_video_probe(struct udevice *dev)
 
 	uc_priv->xsize = w;
 	uc_priv->ysize = h;
-	uc_priv->bpix = VIDEO_BPP32;
+	uc_priv->bpix = dev_get_driver_data(dev);
 	plat->base = fb_base;
 	plat->size = fb_size;
 
@@ -51,11 +51,11 @@ static int bcm2835_video_probe(struct udevice *dev)
 }
 
 static const struct udevice_id bcm2835_video_ids[] = {
-	{ .compatible = "brcm,bcm2835-hdmi" },
-	{ .compatible = "brcm,bcm2711-hdmi0" },
-	{ .compatible = "brcm,bcm2708-fb" },
+	{ .compatible = "brcm,bcm2835-hdmi",  .data = VIDEO_BPP32},
+	{ .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
+	{ .compatible = "brcm,bcm2708-fb",    .data = VIDEO_BPP16 },
 #if !IS_ENABLED(CONFIG_VIDEO_DT_SIMPLEFB)
-	{ .compatible = "simple-framebuffer" },
+	{ .compatible = "simple-framebuffer", .data = VIDEO_BPP32},
 #endif
 	{ }
 };
-- 
2.35.3

[PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller

[Ivan T. Ivanov]

Borrow SD quirks from vendor Linux driver.

"BCM2712 unfortunately carries with it a perennial bug with the SD
controller register interface present on previous chips (2711/2709/2708).
Accesses must be dword-sized and a read-modify-write cycle to the 32-bit
registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
BCM2712 does not seem to need the extreme delay between each write as on
previous chips, just the serialisation of writes to these registers in a
single 32-bit operation."

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 drivers/mmc/bcmstb_sdhci.c | 173 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 172 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/bcmstb_sdhci.c b/drivers/mmc/bcmstb_sdhci.c
index dc96818cff..21489e66c0 100644
--- a/drivers/mmc/bcmstb_sdhci.c
+++ b/drivers/mmc/bcmstb_sdhci.c
@@ -38,6 +38,16 @@
  */
 #define BCMSTB_SDHCI_MINIMUM_CLOCK_FREQUENCY	400000
 
+#define SDIO_CFG_CTRL				0x0
+#define  SDIO_CFG_CTRL_SDCD_N_TEST_EN		BIT(31)
+#define  SDIO_CFG_CTRL_SDCD_N_TEST_LEV		BIT(30)
+
+#define SDIO_CFG_SD_PIN_SEL			0x44
+#define  SDIO_CFG_SD_PIN_SEL_MASK		0x3
+#define  SDIO_CFG_SD_PIN_SEL_CARD		BIT(1)
+
+#define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
+
 /*
  * This driver has only been tested with eMMC devices; SD devices may
  * not work.
@@ -47,6 +57,53 @@ struct sdhci_bcmstb_plat {
 	struct mmc mmc;
 };
 
+struct sdhci_bcmstb_host {
+	struct sdhci_host host;
+	u32 shadow_cmd;
+	u32 shadow_blk;
+	bool is_cmd_shadowed;
+	bool is_blk_shadowed;
+};
+
+struct sdhci_brcmstb_dev_priv {
+	int (*init)(struct udevice *dev);
+	struct sdhci_ops *ops;
+};
+
+static inline struct sdhci_bcmstb_host *to_bcmstb_host(struct sdhci_host *host)
+{
+	return container_of(host, struct sdhci_bcmstb_host, host);
+}
+
+static int sdhci_brcmstb_init_2712(struct udevice *dev)
+{
+	struct sdhci_host *host = dev_get_priv(dev);
+	void *cfg_regs;
+	u32 reg;
+
+	/* Map in the non-standard CFG registers */
+	cfg_regs = dev_remap_addr_name(dev, "cfg");
+	if (!cfg_regs)
+		return -ENOENT;
+
+	if ((host->mmc->host_caps & MMC_CAP_NONREMOVABLE) ||
+	    (host->mmc->host_caps & MMC_CAP_NEEDS_POLL)) {
+		/* Force presence */
+		reg = readl(cfg_regs + SDIO_CFG_CTRL);
+		reg &= ~SDIO_CFG_CTRL_SDCD_N_TEST_LEV;
+		reg |= SDIO_CFG_CTRL_SDCD_N_TEST_EN;
+		writel(reg, cfg_regs + SDIO_CFG_CTRL);
+	} else {
+		/* Enable card detection line */
+		reg = readl(cfg_regs + SDIO_CFG_SD_PIN_SEL);
+		reg &= ~SDIO_CFG_SD_PIN_SEL_MASK;
+		reg |= SDIO_CFG_SD_PIN_SEL_CARD;
+		writel(reg, cfg_regs + SDIO_CFG_SD_PIN_SEL);
+	}
+
+	return 0;
+}
+
 static int sdhci_bcmstb_bind(struct udevice *dev)
 {
 	struct sdhci_bcmstb_plat *plat = dev_get_plat(dev);
@@ -58,10 +115,14 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
 {
 	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
 	struct sdhci_bcmstb_plat *plat = dev_get_plat(dev);
-	struct sdhci_host *host = dev_get_priv(dev);
+	struct sdhci_bcmstb_host *bcmstb = dev_get_priv(dev);
+	struct sdhci_host *host = &bcmstb->host;
+	struct sdhci_brcmstb_dev_priv *dev_priv;
 	fdt_addr_t base;
 	int ret;
 
+	dev_priv = (struct sdhci_brcmstb_dev_priv *)dev_get_driver_data(dev);
+
 	base = dev_read_addr(dev);
 	if (base == FDT_ADDR_T_NONE)
 		return -EINVAL;
@@ -75,6 +136,10 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
 
 	host->mmc = &plat->mmc;
 	host->mmc->dev = dev;
+
+	if (dev_priv && dev_priv->ops)
+		host->ops = dev_priv->ops;
+
 	ret = sdhci_setup_cfg(&plat->cfg, host,
 			      BCMSTB_SDHCI_MAXIMUM_CLOCK_FREQUENCY,
 			      BCMSTB_SDHCI_MINIMUM_CLOCK_FREQUENCY);
@@ -84,10 +149,116 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
 	upriv->mmc = &plat->mmc;
 	host->mmc->priv = host;
 
+	if (dev_priv && dev_priv->init) {
+		ret = dev_priv->init(dev);
+		if (ret)
+			return ret;
+	}
+
 	return sdhci_probe(dev);
 }
 
+static u16 sdhci_brcmstb_32bits_readw(struct sdhci_host *host, int reg)
+{
+	struct sdhci_bcmstb_host *bcmstb = to_bcmstb_host(host);
+	u16 word;
+	u32 val;
+
+	if (reg == SDHCI_TRANSFER_MODE && bcmstb->is_cmd_shadowed) {
+		/* Get the saved transfer mode */
+		val = bcmstb->shadow_cmd;
+	} else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+		   bcmstb->is_blk_shadowed) {
+		/* Get the saved block info */
+		val = bcmstb->shadow_blk;
+	} else {
+		val = readl(host->ioaddr + (reg & ~3));
+	}
+
+	word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
+	return word;
+}
+
+static u8 sdhci_brcmstb_32bits_readb(struct sdhci_host *host, int reg)
+{
+	u32 val = readl(host->ioaddr + (reg & ~3));
+	u8 byte = val >> REG_OFFSET_IN_BITS(reg) & 0xff;
+	return byte;
+}
+
+/*
+ * BCM2712 unfortunately carries with it a perennial bug with the SD
+ * controller register interface present on previous chips (2711/2709/2708).
+ * Accesses must be dword-sized and a read-modify-write cycle to the
+ * 32-bit registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
+ * BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
+ * BCM2712 does not seem to need the extreme delay between each write as
+ * on previous chips, just the serialisation of writes to these registers
+ * in a single 32-bit operation.
+ */
+static void sdhci_brcmstb_32bits_writew(struct sdhci_host *host, u16 val, int reg)
+{
+	struct sdhci_bcmstb_host *bcmstb = to_bcmstb_host(host);
+	u32 word_shift = REG_OFFSET_IN_BITS(reg);
+	u32 mask = 0xffff << word_shift;
+	u32 oldval, newval;
+
+	if (reg == SDHCI_COMMAND) {
+		/* Write the block now as we are issuing a command */
+		if (bcmstb->is_blk_shadowed) {
+			writel(bcmstb->shadow_blk, host->ioaddr + SDHCI_BLOCK_SIZE);
+			bcmstb->is_blk_shadowed = false;
+		}
+		oldval = bcmstb->shadow_cmd;
+		bcmstb->is_cmd_shadowed = false;
+	} else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+		   bcmstb->is_blk_shadowed) {
+		/* Block size and count are stored in shadow reg */
+		oldval = bcmstb->shadow_blk;
+	} else {
+		/* Read reg, all other registers are not shadowed */
+		oldval = readl(host->ioaddr + (reg & ~3));
+	}
+	newval = (oldval & ~mask) | (val << word_shift);
+
+	if (reg == SDHCI_TRANSFER_MODE) {
+		/* Save the transfer mode until the command is issued */
+		bcmstb->shadow_cmd = newval;
+		bcmstb->is_cmd_shadowed = true;
+	} else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
+		/* Save the block info until the command is issued */
+		bcmstb->shadow_blk = newval;
+		bcmstb->is_blk_shadowed = true;
+	} else {
+		/* Command or other regular 32-bit write */
+		writel(newval, host->ioaddr + (reg & ~3));
+	}
+}
+
+static void sdhci_brcmstb_32bits_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+	u32 oldval = readl(host->ioaddr + (reg & ~3));
+	u32 byte_shift = REG_OFFSET_IN_BITS(reg);
+	u32 mask = 0xff << byte_shift;
+	u32 newval = (oldval & ~mask) | (val << byte_shift);
+
+	writel(newval, host->ioaddr + (reg & ~3));
+}
+
+static struct sdhci_ops sdhci_brcmstb_ops_2712 = {
+	.read_b    = sdhci_brcmstb_32bits_readb,
+	.read_w    = sdhci_brcmstb_32bits_readw,
+	.write_w   = sdhci_brcmstb_32bits_writew,
+	.write_b   = sdhci_brcmstb_32bits_writeb,
+};
+
+static const struct sdhci_brcmstb_dev_priv match_priv_2712 = {
+	.init = sdhci_brcmstb_init_2712,
+	.ops = &sdhci_brcmstb_ops_2712,
+};
+
 static const struct udevice_id sdhci_bcmstb_match[] = {
+	{ .compatible = "brcm,bcm2712-sdhci", .data = (ulong)&match_priv_2712 },
 	{ .compatible = "brcm,bcm7425-sdhci" },
 	{ .compatible = "brcm,sdhci-brcmstb" },
 	{ }
-- 
2.35.3

[PATCH v3 6/7] configs: rpi_arm64: enable SDHCI BCMSTB driver

[Ivan T. Ivanov]

RPi5 have "brcm,bcm2712-sdhci" controller which is
handled by "sdhci-bcmstb" driver, so enable it.

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 configs/rpi_arm64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index f9dade18f6..1107fd11de 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -33,6 +33,7 @@ CONFIG_BCM2835_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_BCM2835=y
+CONFIG_MMC_SDHCI_BCMSTB=y
 CONFIG_BCMGENET=y
 CONFIG_PCI_BRCMSTB=y
 CONFIG_PINCTRL=y
-- 
2.35.3

[PATCH v3 7/7] pci: pcie-brcmstb: Add bcm2712 PCIe controller support

[Ivan T. Ivanov]

PCIe controller have minor register map difference compared
to bcm2711 variant. Handle this using device specific register
offset.

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 drivers/pci/pcie_brcmstb.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c
index cd45f0bee9..d63e715b2e 100644
--- a/drivers/pci/pcie_brcmstb.c
+++ b/drivers/pci/pcie_brcmstb.c
@@ -90,7 +90,6 @@
 #define PCIE_MEM_WIN0_LIMIT_HI(win)	\
 	 PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI + ((win) * 8)
 
-#define PCIE_MISC_HARD_PCIE_HARD_DEBUG			0x4204
 #define  PCIE_HARD_DEBUG_SERDES_IDDQ_MASK		0x08000000
 
 #define PCIE_MSI_INTR2_CLR				0x4508
@@ -131,6 +130,10 @@
 #define SSC_STATUS_PLL_LOCK_MASK			0x800
 #define SSC_STATUS_PLL_LOCK_SHIFT			11
 
+struct pcie_cfg_data {
+	unsigned long hard_debug_offs;
+};
+
 /**
  * struct brcm_pcie - the PCIe controller state
  * @base: Base address of memory mapped IO registers of the controller
@@ -141,6 +144,7 @@
 struct brcm_pcie {
 	void __iomem		*base;
 
+	struct pcie_cfg_data	*cfg;
 	int			gen;
 	bool			ssc;
 };
@@ -458,7 +462,7 @@ static int brcm_pcie_probe(struct udevice *dev)
 	/* Take the bridge out of reset */
 	clrbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_INIT_MASK);
 
-	clrbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
+	clrbits_le32(base + pcie->cfg->hard_debug_offs,
 		     PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
 
 	/* Wait for SerDes to be stable */
@@ -599,7 +603,7 @@ static int brcm_pcie_remove(struct udevice *dev)
 	setbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_PERST_MASK);
 
 	/* Turn off SerDes */
-	setbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
+	setbits_le32(base + pcie->cfg->hard_debug_offs,
 		     PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
 
 	/* Shutdown bridge */
@@ -620,6 +624,8 @@ static int brcm_pcie_of_to_plat(struct udevice *dev)
 	if (!pcie->base)
 		return -EINVAL;
 
+	pcie->cfg = (struct pcie_cfg_data *)dev_get_driver_data(dev);
+
 	pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc");
 
 	ret = ofnode_read_u32(dn, "max-link-speed", &max_link_speed);
@@ -636,8 +642,17 @@ static const struct dm_pci_ops brcm_pcie_ops = {
 	.write_config	= brcm_pcie_write_config,
 };
 
+static const struct pcie_cfg_data bcm2711_cfg = {
+	.hard_debug_offs	= 0x4204
+};
+
+static const struct pcie_cfg_data bcm2712_cfg = {
+	.hard_debug_offs	= 0x4304
+};
+
 static const struct udevice_id brcm_pcie_ids[] = {
-	{ .compatible = "brcm,bcm2711-pcie" },
+	{ .compatible = "brcm,bcm2711-pcie", .data = (ulong)&bcm2711_cfg },
+	{ .compatible = "brcm,bcm2712-pcie", .data = (ulong)&bcm2712_cfg },
 	{ }
 };
 
-- 
2.35.3

Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712

[Stefan Wahren]

Hi Ivan,

Am 18.12.23 um 22:03 schrieb Ivan T. Ivanov:
> From: Dmitry Malkin <dmitry@bedrocksystems.com>
>
> includes:
> * 1GB of RAM (from 4GB or 8GB total)
> * VPU memory interface
> * AXI ranges (main peripherals)
my experience with U-Boot is little, but i do my best to give you some
feedback.
>
> Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
> ---
>   arch/arm/mach-bcm283x/init.c | 38 +++++++++++++++++++++++++++++++++++-
>   1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 7265faf6ce..af23b9711a 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -19,7 +19,7 @@
>   #ifdef CONFIG_ARM64
>   #include <asm/armv8/mmu.h>
>
> -#define MEM_MAP_MAX_ENTRIES (4)
> +#define MEM_MAP_MAX_ENTRIES (5)
>
>   static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = {
>   	{
> @@ -68,6 +68,41 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
>   	}
>   };
>
> +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
> +	{
in comparison to mach-imx/imx9/soc.c most of the memory maps doesn't
have a describing comment.
> +		.virt = 0x00000000UL,
> +		.phys = 0x00000000UL,
> +		.size = 0x3f800000UL,
> +		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> +			 PTE_BLOCK_INNER_SHARE
> +	}, {
> +		.virt = 0x3f800000UL,
> +		.phys = 0x3f800000UL,
> +		.size = 0x00800000UL,
> +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +			 PTE_BLOCK_NON_SHARE |
> +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +	}, {
> +		/* Beginning of AXI bus where uSD controller lives */
> +		.virt = 0x1000000000UL,
> +		.phys = 0x1000000000UL,
> +		.size = 0x0002000000UL,
> +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +			 PTE_BLOCK_NON_SHARE |
> +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +	}, {
> +		.virt = 0x107c000000UL,
> +		.phys = 0x107c000000UL,
> +		.size = 0x0004000000UL,
> +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +			 PTE_BLOCK_NON_SHARE |
> +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +	}, {
> +		/* List terminator */
> +		0,
> +	}
> +};
> +
>   struct mm_region *mem_map = bcm283x_mem_map;
>
>   /*
> @@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = {
>   	{ .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map},
>   	{ .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map},
>   	{ .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map},
> +	{ .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map},
>   	{ },
>   };
>
Looking at the complete file, i saw the function print_cpuinfo().
Personally i think it's wrong to print BCM283x in case of a RPI 4 or 5.

Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format

[Stefan Wahren]

Hi Ivan,

Am 18.12.23 um 22:03 schrieb Ivan T. Ivanov:
> brcm,bcm2708-fb device provided by firmware on RPi5 uses
> 16 bits per pixel. Update driver to properly handle this.
>
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
> ---
>   drivers/video/bcm2835.c | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
> index 14942526f1..245c958b6e 100644
> --- a/drivers/video/bcm2835.c
> +++ b/drivers/video/bcm2835.c
> @@ -43,7 +43,7 @@ static int bcm2835_video_probe(struct udevice *dev)
>
>   	uc_priv->xsize = w;
>   	uc_priv->ysize = h;
> -	uc_priv->bpix = VIDEO_BPP32;
> +	uc_priv->bpix = dev_get_driver_data(dev);
>   	plat->base = fb_base;
>   	plat->size = fb_size;
>
> @@ -51,11 +51,11 @@ static int bcm2835_video_probe(struct udevice *dev)
>   }
>
>   static const struct udevice_id bcm2835_video_ids[] = {
> -	{ .compatible = "brcm,bcm2835-hdmi" },
> -	{ .compatible = "brcm,bcm2711-hdmi0" },
> -	{ .compatible = "brcm,bcm2708-fb" },
> +	{ .compatible = "brcm,bcm2835-hdmi",  .data = VIDEO_BPP32},
> +	{ .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
> +	{ .compatible = "brcm,bcm2708-fb",    .data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for
brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
the other boards. I would expect some brcm,bcm2712 compatible at least
this needs an explanation in the commit message.
>   #if !IS_ENABLED(CONFIG_VIDEO_DT_SIMPLEFB)
> -	{ .compatible = "simple-framebuffer" },
> +	{ .compatible = "simple-framebuffer", .data = VIDEO_BPP32},
>   #endif
>   	{ }
>   };

Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712

[Ivan T. Ivanov]

On 12-18 23:25, Stefan Wahren wrote:
> > 
> > +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
> > +	{
> in comparison to mach-imx/imx9/soc.c most of the memory maps doesn't
> have a describing comment.

Yep, I have thinking to add more comments, but decided to not modify too
much patch from Dmitry. On the other side there is not much excitement
stuff here.

> > +		.virt = 0x00000000UL,
> > +		.phys = 0x00000000UL,
> > +		.size = 0x3f800000UL,
> > +		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> > +			 PTE_BLOCK_INNER_SHARE
> > +	}, {
> > +		.virt = 0x3f800000UL,
> > +		.phys = 0x3f800000UL,
> > +		.size = 0x00800000UL,
> > +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +			 PTE_BLOCK_NON_SHARE |
> > +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > +	}, {
> > +		/* Beginning of AXI bus where uSD controller lives */
> > +		.virt = 0x1000000000UL,
> > +		.phys = 0x1000000000UL,
> > +		.size = 0x0002000000UL,
> > +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +			 PTE_BLOCK_NON_SHARE |
> > +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > +	}, {
> > +		.virt = 0x107c000000UL,
> > +		.phys = 0x107c000000UL,
> > +		.size = 0x0004000000UL,
> > +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +			 PTE_BLOCK_NON_SHARE |
> > +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > +	}, {
> > +		/* List terminator */
> > +		0,
> > +	}
> > +};
> > +
> >   struct mm_region *mem_map = bcm283x_mem_map;
> > 
> >   /*
> > @@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = {
> >   	{ .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map},
> >   	{ .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map},
> >   	{ .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map},
> > +	{ .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map},
> >   	{ },
> >   };
> > 
> Looking at the complete file, i saw the function print_cpuinfo().
> Personally i think it's wrong to print BCM283x in case of a RPI 4 or 5.

CONFIG_DISPLAY_CPUINFO is not set for RPi's, but I suppose this could be nice
aesthetic enhancement.

Thanks,
Ivan

Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format

[Ivan T. Ivanov]

On 12-18 23:32, Stefan Wahren wrote:
> > 
> >   static const struct udevice_id bcm2835_video_ids[] = {
> > -	{ .compatible = "brcm,bcm2835-hdmi" },
> > -	{ .compatible = "brcm,bcm2711-hdmi0" },
> > -	{ .compatible = "brcm,bcm2708-fb" },
> > +	{ .compatible = "brcm,bcm2835-hdmi",  .data = VIDEO_BPP32},
> > +	{ .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
> > +	{ .compatible = "brcm,bcm2708-fb",    .data = VIDEO_BPP16 },
> this change looks wrong to me. Before we used VIDEO_BPP32 for
> brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
> the other boards. I would expect some brcm,bcm2712 compatible at least
> this needs an explanation in the commit message.
> 

If you are confident that this semi device was working before with
BPP32 I will try to find better way to handle this. Do you remember
which RPi version was this?

Thanks,
Ivan

Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format

[Stefan Wahren]

Hi Ivan,

Am 19.12.23 um 09:51 schrieb Ivan T. Ivanov:
> On 12-18 23:32, Stefan Wahren wrote:
>>>    static const struct udevice_id bcm2835_video_ids[] = {
>>> -	{ .compatible = "brcm,bcm2835-hdmi" },
>>> -	{ .compatible = "brcm,bcm2711-hdmi0" },
>>> -	{ .compatible = "brcm,bcm2708-fb" },
>>> +	{ .compatible = "brcm,bcm2835-hdmi",  .data = VIDEO_BPP32},
>>> +	{ .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
>>> +	{ .compatible = "brcm,bcm2708-fb",    .data = VIDEO_BPP16 },
>> this change looks wrong to me. Before we used VIDEO_BPP32 for
>> brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
>> the other boards. I would expect some brcm,bcm2712 compatible at least
>> this needs an explanation in the commit message.
>>
> If you are confident that this semi device was working before with
> BPP32 I will try to find better way to handle this. Do you remember
> which RPi version was this?
as said before i'm don't have much experience with U-Boot, so i'm not
confident. But downgrading the bpp value for an existing setting only to
make RPi 5 work, isn't a good approach. It's a hack.

A quick search for the compatible revealed this [1], so it looks like a
fallback which applies to all Raspberry Pi boards with a firmware
provided DTB.

In case all of them uses 16 bit, i'm fine with this change but then the
commit log should mention this. I think these are points which needs to
be discussed with the Raspberry Pi guys.

Best regards

[1] - https://lists.denx.de/pipermail/u-boot/2018-July/333476.html
>
> Thanks,
> Ivan
>

Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712

[Simon Glass]

Hi Ivan,

On Mon, 18 Dec 2023 at 14:04, Ivan T. Ivanov <iivanov@suse.de> wrote:
>
> From: Dmitry Malkin <dmitry@bedrocksystems.com>
>
> includes:
> * 1GB of RAM (from 4GB or 8GB total)
> * VPU memory interface
> * AXI ranges (main peripherals)
>
> Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
> ---
>  arch/arm/mach-bcm283x/init.c | 38 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 7265faf6ce..af23b9711a 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -19,7 +19,7 @@
>  #ifdef CONFIG_ARM64
>  #include <asm/armv8/mmu.h>
>
> -#define MEM_MAP_MAX_ENTRIES (4)
> +#define MEM_MAP_MAX_ENTRIES (5)
>
>  static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = {
>         {
> @@ -68,6 +68,41 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
>         }
>  };
>
> +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {

Would it be possible to read these from the devicetree?

> +       {
> +               .virt = 0x00000000UL,
> +               .phys = 0x00000000UL,
> +               .size = 0x3f800000UL,
> +               .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> +                        PTE_BLOCK_INNER_SHARE
> +       }, {

Regards,
Simon

Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712

[Ivan T. Ivanov]

On 12-19 21:45, Simon Glass wrote:
> >
> > +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
> 
> Would it be possible to read these from the devicetree?

If there is a devicetree passed, yes, it will be possible.
I have not done this just because I can't test all possible
combinations on older platforms. But for IO regions I am
not sure how feasible this is.

> 
> > +       {
> > +               .virt = 0x00000000UL,
> > +               .phys = 0x00000000UL,
> > +               .size = 0x3f800000UL,
> > +               .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> > +                        PTE_BLOCK_INNER_SHARE
> > +       }, {
> 

Regards,
Ivan

Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format

[Matthias Brugger]

On 19/12/2023 09:51, Ivan T. Ivanov wrote:
> On 12-18 23:32, Stefan Wahren wrote:
>>>
>>>    static const struct udevice_id bcm2835_video_ids[] = {
>>> -	{ .compatible = "brcm,bcm2835-hdmi" },
>>> -	{ .compatible = "brcm,bcm2711-hdmi0" },
>>> -	{ .compatible = "brcm,bcm2708-fb" },
>>> +	{ .compatible = "brcm,bcm2835-hdmi",  .data = VIDEO_BPP32},
>>> +	{ .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
>>> +	{ .compatible = "brcm,bcm2708-fb",    .data = VIDEO_BPP16 },
>> this change looks wrong to me. Before we used VIDEO_BPP32 for
>> brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
>> the other boards. I would expect some brcm,bcm2712 compatible at least
>> this needs an explanation in the commit message.
>>
> 
> If you are confident that this semi device was working before with
> BPP32 I will try to find better way to handle this. Do you remember
> which RPi version was this?
> 

I think that was RPi1 maybe RPi2 Zero W as well.

Regards,
Matthias

Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712

[Ivan T . Ivanov]

Hi,

On 12-18 23:03, Ivan T. Ivanov wrote:
>  
> +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
> +	{
> +		.virt = 0x00000000UL,
> +		.phys = 0x00000000UL,
> +		.size = 0x3f800000UL,

Something that I realized just now. This memory map is valid only if
HDMI cable is plugged in. Otherwise size of this section is 0x3fc00000.
This is how it is populated by the embedded  bootloaader.

Which I am reading as: bootloader do not expose video framebuffer if
HDMI cable is not plugged in at boot time.

With current map, board hang at boot if HDMI is not plugged in.

If I make first region with size 0x3Fc00000 and remove below
dedicated framebuffer region, device boots with and without
HDMI cable plugged in.

> +		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> +			 PTE_BLOCK_INNER_SHARE
> +	}, {
> +		.virt = 0x3f800000UL,
> +		.phys = 0x3f800000UL,
> +		.size = 0x00800000UL,
> +		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +			 PTE_BLOCK_NON_SHARE |
> +			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +	}, {

Sorry that I missed it the first time.

Regards,
Ivan

Re: [PATCH v3 0/7] rpi5: initial support

[Stefan Agner]

Hi Ivan,

On 2023-12-18 22:03, Ivan T. Ivanov wrote:
> Hi,
> 
> These patches are adding basic support for RPi5.
> They are based on v2 series from Dmitry Malkin[1].
> 
> With them I am able to _start_ current openSUSE
> Tumbleweed without modification. They are still
> a lot of things to be added to the upstream Linux
> before it runs flawlessly on this device, but at
> least in U-Booot SD controller used for uSD card
> and Frameboffer and HDMI0 devices are working fine
> now. It seems that PCIe controller is working fine
> too, but I have not tested it too much.

Thank you very much for this work!

> 
> Serial console and reset are also functional.

I've applied the patchset to v2024.01-rc5 and built the
rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin
to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten
anything on the serial console on pin 8/10 of the Raspberry Pi pin
header. Is there anything specific needed to get the console going?

--
Stefan

> 
> Hopefully this will help others add missing pieces
> more easily.
> 
> Happy hacking!
> 
> Regards,
> Ivan
> 
> [1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1R+L24WBgpo-iP1yo7A@mail.gmail.com/
> 
> Dmitry Malkin (2):
>   rpi5: add initial memory map for bcm2712
>   rpi5: Use devicetree as alternative way to read IO base addresses
> 
> Ivan T. Ivanov (5):
>   rpi5: Use devicetree to retrieve board revision
>   bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
>   mmc: bcmstb: Add support for bcm2712 SD controller
>   configs: rpi_arm64: enable SDHCI BCMSTB driver
>   pci: pcie-brcmstb: Add bcm2712 PCIe controller support
> 
>  arch/arm/mach-bcm283x/include/mach/base.h  |   5 +-
>  arch/arm/mach-bcm283x/include/mach/mbox.h  |   3 +-
>  arch/arm/mach-bcm283x/include/mach/sdhci.h |   3 +-
>  arch/arm/mach-bcm283x/include/mach/timer.h |   3 +-
>  arch/arm/mach-bcm283x/include/mach/wdog.h  |   3 +-
>  arch/arm/mach-bcm283x/init.c               |  81 ++++++++--
>  board/raspberrypi/rpi/rpi.c                |  22 ++-
>  configs/rpi_arm64_defconfig                |   1 +
>  drivers/mmc/bcmstb_sdhci.c                 | 173 ++++++++++++++++++++-
>  drivers/pci/pcie_brcmstb.c                 |  23 ++-
>  drivers/video/bcm2835.c                    |  10 +-
>  11 files changed, 296 insertions(+), 31 deletions(-)

Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format

[Ivan T. Ivanov]

On 12-20 09:51, Matthias Brugger wrote:
> > > > 
> > > >    static const struct udevice_id bcm2835_video_ids[] = {
> > > > -	{ .compatible = "brcm,bcm2835-hdmi" },
> > > > -	{ .compatible = "brcm,bcm2711-hdmi0" },
> > > > -	{ .compatible = "brcm,bcm2708-fb" },
> > > > +	{ .compatible = "brcm,bcm2835-hdmi",  .data = VIDEO_BPP32},
> > > > +	{ .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
> > > > +	{ .compatible = "brcm,bcm2708-fb",    .data = VIDEO_BPP16 },
> > > this change looks wrong to me. Before we used VIDEO_BPP32 for
> > > brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
> > > the other boards. I would expect some brcm,bcm2712 compatible at least
> > > this needs an explanation in the commit message.
> > > 

I think I found better and reliable way to find the right value.

    bpp = pitch / width

Which are queried from firmware.

Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1, RPi2 Zero W, RPi5b v1.0.

> 
> I think that was RPi1 maybe RPi2 Zero W as well.
> 

For the record: RPi2 Zero W exposes "brcm,bcm2835-hdmi" device.

Regards,
Ivan

Re: [PATCH v3 0/7] rpi5: initial support

[Matthias Brugger]

On 21/12/2023 14:42, Stefan Agner wrote:
> Hi Ivan,
> 
> On 2023-12-18 22:03, Ivan T. Ivanov wrote:
>> Hi,
>>
>> These patches are adding basic support for RPi5.
>> They are based on v2 series from Dmitry Malkin[1].
>>
>> With them I am able to _start_ current openSUSE
>> Tumbleweed without modification. They are still
>> a lot of things to be added to the upstream Linux
>> before it runs flawlessly on this device, but at
>> least in U-Booot SD controller used for uSD card
>> and Frameboffer and HDMI0 devices are working fine
>> now. It seems that PCIe controller is working fine
>> too, but I have not tested it too much.
> 
> Thank you very much for this work!
> 
>>
>> Serial console and reset are also functional.
> 
> I've applied the patchset to v2024.01-rc5 and built the
> rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin
> to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten
> anything on the serial console on pin 8/10 of the Raspberry Pi pin
> header. Is there anything specific needed to get the console going?
> 

Welcome to the club! :)

The RPi5 uses a rather non-standard port for debug console:
https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html#uart-connector

Up to now I wasn't able to get serial console on the normal pins 8/10.

Regards
Matthias

> --
> Stefan
> 
>>
>> Hopefully this will help others add missing pieces
>> more easily.
>>
>> Happy hacking!
>>
>> Regards,
>> Ivan
>>
>> [1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1R+L24WBgpo-iP1yo7A@mail.gmail.com/
>>
>> Dmitry Malkin (2):
>>    rpi5: add initial memory map for bcm2712
>>    rpi5: Use devicetree as alternative way to read IO base addresses
>>
>> Ivan T. Ivanov (5):
>>    rpi5: Use devicetree to retrieve board revision
>>    bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
>>    mmc: bcmstb: Add support for bcm2712 SD controller
>>    configs: rpi_arm64: enable SDHCI BCMSTB driver
>>    pci: pcie-brcmstb: Add bcm2712 PCIe controller support
>>
>>   arch/arm/mach-bcm283x/include/mach/base.h  |   5 +-
>>   arch/arm/mach-bcm283x/include/mach/mbox.h  |   3 +-
>>   arch/arm/mach-bcm283x/include/mach/sdhci.h |   3 +-
>>   arch/arm/mach-bcm283x/include/mach/timer.h |   3 +-
>>   arch/arm/mach-bcm283x/include/mach/wdog.h  |   3 +-
>>   arch/arm/mach-bcm283x/init.c               |  81 ++++++++--
>>   board/raspberrypi/rpi/rpi.c                |  22 ++-
>>   configs/rpi_arm64_defconfig                |   1 +
>>   drivers/mmc/bcmstb_sdhci.c                 | 173 ++++++++++++++++++++-
>>   drivers/pci/pcie_brcmstb.c                 |  23 ++-
>>   drivers/video/bcm2835.c                    |  10 +-
>>   11 files changed, 296 insertions(+), 31 deletions(-)

Re: [PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]



On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:
> Borrow SD quirks from vendor Linux driver.
> 
> "BCM2712 unfortunately carries with it a perennial bug with the SD
> controller register interface present on previous chips (2711/2709/2708).
> Accesses must be dword-sized and a read-modify-write cycle to the 32-bit
> registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
> BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
> BCM2712 does not seem to need the extreme delay between each write as on
> previous chips, just the serialisation of writes to these registers in a
> single 32-bit operation."
> 
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>

This is diverging from the Linux sdhci-brcmstb.c driver where no such 
quirk needs to be carried out, rather the logic for such quirks has been 
present in sdhci-iproc.c...
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]

Re: [PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller

[Stefan Wahren]

Hi,

Am 21.12.23 um 16:13 schrieb Florian Fainelli:
>
>
> On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:
>> Borrow SD quirks from vendor Linux driver.
>>
>> "BCM2712 unfortunately carries with it a perennial bug with the SD
>> controller register interface present on previous chips
>> (2711/2709/2708).
>> Accesses must be dword-sized and a read-modify-write cycle to the 32-bit
>> registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
>> BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
>> BCM2712 does not seem to need the extreme delay between each write as on
>> previous chips, just the serialisation of writes to these registers in a
>> single 32-bit operation."
>>
>> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
>
> This is diverging from the Linux sdhci-brcmstb.c driver where no such
> quirk needs to be carried out, rather the logic for such quirks has
> been present in sdhci-iproc.c...

it seems this patch based the downstream kernel changes [1]. I would
suggest to use an existing driver which already handle this bug
(iproc_sdhci or bcm2835_sdhci).

Does the Rpi 5 still works, if the compatible "brcm,bcm2712-sdhci" is
added to mmc/iproc_sdhci.c?

[1] -
https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9

Re: [PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller

[Ivan T. Ivanov]

On 12-21 16:39, Stefan Wahren wrote:
> To: Florian Fainelli <florian.fainelli@broadcom.com>,  "Ivan T. Ivanov"
> > 
> > On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:
> > > Borrow SD quirks from vendor Linux driver.
> > > 
> > > "BCM2712 unfortunately carries with it a perennial bug with the SD
> > > controller register interface present on previous chips
> > > (2711/2709/2708).
> > > Accesses must be dword-sized and a read-modify-write cycle to the 32-bit
> > > registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
> > > BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
> > > BCM2712 does not seem to need the extreme delay between each write as on
> > > previous chips, just the serialisation of writes to these registers in a
> > > single 32-bit operation."
> > > 
> > > Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
> > 
> > This is diverging from the Linux sdhci-brcmstb.c driver where no such
> > quirk needs to be carried out, rather the logic for such quirks has
> > been present in sdhci-iproc.c...
> 
> it seems this patch based the downstream kernel changes [1].

Yep.

> I would
> suggest to use an existing driver which already handle this bug
> (iproc_sdhci or bcm2835_sdhci).
> 
> Does the Rpi 5 still works, if the compatible "brcm,bcm2712-sdhci" is
> added to mmc/iproc_sdhci.c?

No, it is not working :-)

Even after I added shadow variables usage in iproc_readw, which do not
have it.

Even after I used hard coded values for "clock-freq-min-max", which are
missing in RPi5 device tree.

Even after I added 2712 specific "cfg" space initialization procedure
from the brcnstb driver.

On the other hand they are some tuning procedures in iproc driver
which I am not sure that are relevant for 2712 controller.

And the diff stat is getting bigger that equivalent for brcmstb driver.

To me it is  a bit easier to add 2712 support to brcmstb driver,
because it will be easier to follow any vendor Linux driver changes.

It looks like hardware engineers are just making the same mistake
when integrating 2712 SDHCI controller as for IPROC controller.

Regards,
Ivan

> 
> [1] -
> https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9

Re: [PATCH v3 2/7] rpi5: Use devicetree as alternative way to read IO base addresses

[Matthias Brugger]

On 18/12/2023 22:03, Ivan T. Ivanov wrote:
> From: Dmitry Malkin <dmitry@bedrocksystems.com>
> 
> MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.
> Find them via devicetree blob passed by bootloader.
> 
> Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>

Reviewed-by: Matthias Brugger <mbrugger@suse.com>

> ---
>   arch/arm/mach-bcm283x/include/mach/base.h  |  5 ++-
>   arch/arm/mach-bcm283x/include/mach/mbox.h  |  3 +-
>   arch/arm/mach-bcm283x/include/mach/sdhci.h |  3 +-
>   arch/arm/mach-bcm283x/include/mach/timer.h |  3 +-
>   arch/arm/mach-bcm283x/include/mach/wdog.h  |  3 +-
>   arch/arm/mach-bcm283x/init.c               | 43 ++++++++++++++++++----
>   6 files changed, 43 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h b/arch/arm/mach-bcm283x/include/mach/base.h
> index 4ccaf69693..6de99e7ea1 100644
> --- a/arch/arm/mach-bcm283x/include/mach/base.h
> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> @@ -6,7 +6,10 @@
>   #ifndef _BCM283x_BASE_H_
>   #define _BCM283x_BASE_H_
>   
> -extern unsigned long rpi_bcm283x_base;
> +extern unsigned long rpi_mbox_base;
> +extern unsigned long rpi_timer_base;
> +extern unsigned long rpi_sdhci_base;
> +extern unsigned long rpi_wdog_base;
>   
>   #ifdef CONFIG_ARMV7_LPAE
>   #ifdef CONFIG_TARGET_RPI_4_32B
> diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h b/arch/arm/mach-bcm283x/include/mach/mbox.h
> index 490664f878..35d4e2f075 100644
> --- a/arch/arm/mach-bcm283x/include/mach/mbox.h
> +++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
> @@ -38,8 +38,7 @@
>   
>   /* Raw mailbox HW */
>   
> -#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
> -				 rpi_bcm283x_base + 0x0000b880; })
> +#define BCM2835_MBOX_PHYSADDR	rpi_mbox_base
>   
>   struct bcm2835_mbox_regs {
>   	u32 read;
> diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h b/arch/arm/mach-bcm283x/include/mach/sdhci.h
> index 7323690687..e837c679c4 100644
> --- a/arch/arm/mach-bcm283x/include/mach/sdhci.h
> +++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h
> @@ -8,8 +8,7 @@
>   
>   #include <asm/arch/base.h>
>   
> -#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
> -				  rpi_bcm283x_base + 0x00300000; })
> +#define BCM2835_SDHCI_PHYSADDR	rpi_sdhci_base
>   
>   int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
>   
> diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h b/arch/arm/mach-bcm283x/include/mach/timer.h
> index 5567dbd7f3..60500a256d 100644
> --- a/arch/arm/mach-bcm283x/include/mach/timer.h
> +++ b/arch/arm/mach-bcm283x/include/mach/timer.h
> @@ -11,8 +11,7 @@
>   #include <linux/bug.h>
>   #endif
>   
> -#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
> -				  rpi_bcm283x_base + 0x00003000; })
> +#define BCM2835_TIMER_PHYSADDR	rpi_timer_base
>   
>   #define BCM2835_TIMER_CS_M3	(1 << 3)
>   #define BCM2835_TIMER_CS_M2	(1 << 2)
> diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h b/arch/arm/mach-bcm283x/include/mach/wdog.h
> index 9942666720..b950560674 100644
> --- a/arch/arm/mach-bcm283x/include/mach/wdog.h
> +++ b/arch/arm/mach-bcm283x/include/mach/wdog.h
> @@ -8,8 +8,7 @@
>   
>   #include <asm/arch/base.h>
>   
> -#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
> -				 rpi_bcm283x_base + 0x00100000; })
> +#define BCM2835_WDOG_PHYSADDR	rpi_wdog_base
>   
>   struct bcm2835_wdog_regs {
>   	u32 unknown0[7];
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index af23b9711a..1c5c748484 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -151,7 +151,11 @@ static void rpi_update_mem_map(void)
>   static void rpi_update_mem_map(void) {}
>   #endif
>   
> -unsigned long rpi_bcm283x_base = 0x3f000000;
> +/* Default bcm283x devices addresses */
> +unsigned long rpi_mbox_base  = 0x3f00b880;
> +unsigned long rpi_sdhci_base = 0x3f300000;
> +unsigned long rpi_wdog_base  = 0x3f100000;
> +unsigned long rpi_timer_base = 0x3f003000;
>   
>   int arch_cpu_init(void)
>   {
> @@ -162,22 +166,45 @@ int arch_cpu_init(void)
>   
>   int mach_cpu_init(void)
>   {
> -	int ret, soc_offset;
> +	int ret, soc, offset;
>   	u64 io_base, size;
>   
>   	rpi_update_mem_map();
>   
>   	/* Get IO base from device tree */
> -	soc_offset = fdt_path_offset(gd->fdt_blob, "/soc");
> -	if (soc_offset < 0)
> -		return soc_offset;
> +	soc = fdt_path_offset(gd->fdt_blob, "/soc");
> +	if (soc < 0)
> +		return soc;
>   
> -	ret = fdt_read_range((void *)gd->fdt_blob, soc_offset, 0, NULL,
> -				&io_base, &size);
> +	ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL,
> +			     &io_base, &size);
>   	if (ret)
>   		return ret;
>   
> -	rpi_bcm283x_base = io_base;
> +	rpi_mbox_base  = io_base + 0x00b880;
> +	rpi_sdhci_base = io_base + 0x300000;
> +	rpi_wdog_base  = io_base + 0x100000;
> +	rpi_timer_base = io_base + 0x003000;
> +
> +	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
> +					       "brcm,bcm2835-mbox");
> +	if (offset > soc)
> +		rpi_mbox_base = fdt_get_base_address(gd->fdt_blob, offset);
> +
> +	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
> +					       "brcm,bcm2835-sdhci");
> +	if (offset > soc)
> +		rpi_sdhci_base = fdt_get_base_address(gd->fdt_blob, offset);
> +
> +	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
> +					       "brcm,bcm2835-system-timer");
> +	if (offset > soc)
> +		rpi_timer_base = fdt_get_base_address(gd->fdt_blob, offset);
> +
> +	offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
> +					       "brcm,bcm2712-pm");
> +	if (offset > soc)
> +		rpi_wdog_base = fdt_get_base_address(gd->fdt_blob, offset);
>   
>   	return 0;
>   }

Re: [PATCH v3 3/7] rpi5: Use devicetree to retrieve board revision

[Matthias Brugger]

On 18/12/2023 22:03, Ivan T. Ivanov wrote:
> Firmware on RPi5 return error on board revision query
> through firmware interface, but on the other hand it fills
> "linux,revision" in "system" node, so use it to detect board
> revision.
> 
> 	system {
> 		linux,revision = <0xc04170>;
> 		linux,serial = <0x6cf44e80 0x3c533ede>;
> 	};
> 
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>

Reviewed-by: Matthias Brugger <mbrugger@suse.com>

> ---
>   board/raspberrypi/rpi/rpi.c | 22 +++++++++++++++++++---
>   1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index cd823ad746..2851ebc985 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -171,6 +171,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
>   		DTB_DIR "bcm2711-rpi-cm4.dtb",
>   		true,
>   	},
> +	[0x17] = {
> +		"5 Model B",
> +		DTB_DIR "bcm2712-rpi-5-b.dtb",
> +		true,
> +	},
>   };
>   
>   static const struct rpi_model rpi_models_old_scheme[] = {
> @@ -429,15 +434,27 @@ static void get_board_revision(void)
>   	int ret;
>   	const struct rpi_model *models;
>   	uint32_t models_count;
> +	ofnode node;
>   
>   	BCM2835_MBOX_INIT_HDR(msg);
>   	BCM2835_MBOX_INIT_TAG(&msg->get_board_rev, GET_BOARD_REV);
>   
>   	ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr);
>   	if (ret) {
> -		printf("bcm2835: Could not query board revision\n");
>   		/* Ignore error; not critical */
> -		return;
> +		node = ofnode_path("/system");
> +		if (!ofnode_valid(node)) {
> +			printf("bcm2835: Could not find /system node\n");
> +			return;
> +		}
> +
> +		ret = ofnode_read_u32(node, "linux,revision", &revision);
> +		if (ret) {
> +			printf("bcm2835: Could not find linux,revision\n");
> +			return;
> +		}
> +	} else {
> +		revision = msg->get_board_rev.body.resp.rev;
>   	}
>   
>   	/*
> @@ -451,7 +468,6 @@ static void get_board_revision(void)
>   	 * http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=98367&start=250
>   	 * http://www.raspberrypi.org/forums/viewtopic.php?f=31&t=20594
>   	 */
> -	revision = msg->get_board_rev.body.resp.rev;
>   	if (revision & 0x800000) {
>   		rev_scheme = 1;
>   		rev_type = (revision >> 4) & 0xff;

Re: [PATCH v3 7/7] pci: pcie-brcmstb: Add bcm2712 PCIe controller support

[Matthias Brugger]

On 18/12/2023 22:03, Ivan T. Ivanov wrote:
> PCIe controller have minor register map difference compared
> to bcm2711 variant. Handle this using device specific register
> offset.
> 
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>

Reviewed-by: Matthias Brugger <mbrugger@suse.com>

> ---
>   drivers/pci/pcie_brcmstb.c | 23 +++++++++++++++++++----
>   1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c
> index cd45f0bee9..d63e715b2e 100644
> --- a/drivers/pci/pcie_brcmstb.c
> +++ b/drivers/pci/pcie_brcmstb.c
> @@ -90,7 +90,6 @@
>   #define PCIE_MEM_WIN0_LIMIT_HI(win)	\
>   	 PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI + ((win) * 8)
>   
> -#define PCIE_MISC_HARD_PCIE_HARD_DEBUG			0x4204
>   #define  PCIE_HARD_DEBUG_SERDES_IDDQ_MASK		0x08000000
>   
>   #define PCIE_MSI_INTR2_CLR				0x4508
> @@ -131,6 +130,10 @@
>   #define SSC_STATUS_PLL_LOCK_MASK			0x800
>   #define SSC_STATUS_PLL_LOCK_SHIFT			11
>   
> +struct pcie_cfg_data {
> +	unsigned long hard_debug_offs;
> +};
> +
>   /**
>    * struct brcm_pcie - the PCIe controller state
>    * @base: Base address of memory mapped IO registers of the controller
> @@ -141,6 +144,7 @@
>   struct brcm_pcie {
>   	void __iomem		*base;
>   
> +	struct pcie_cfg_data	*cfg;
>   	int			gen;
>   	bool			ssc;
>   };
> @@ -458,7 +462,7 @@ static int brcm_pcie_probe(struct udevice *dev)
>   	/* Take the bridge out of reset */
>   	clrbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_INIT_MASK);
>   
> -	clrbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
> +	clrbits_le32(base + pcie->cfg->hard_debug_offs,
>   		     PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
>   
>   	/* Wait for SerDes to be stable */
> @@ -599,7 +603,7 @@ static int brcm_pcie_remove(struct udevice *dev)
>   	setbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_PERST_MASK);
>   
>   	/* Turn off SerDes */
> -	setbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
> +	setbits_le32(base + pcie->cfg->hard_debug_offs,
>   		     PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
>   
>   	/* Shutdown bridge */
> @@ -620,6 +624,8 @@ static int brcm_pcie_of_to_plat(struct udevice *dev)
>   	if (!pcie->base)
>   		return -EINVAL;
>   
> +	pcie->cfg = (struct pcie_cfg_data *)dev_get_driver_data(dev);
> +
>   	pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc");
>   
>   	ret = ofnode_read_u32(dn, "max-link-speed", &max_link_speed);
> @@ -636,8 +642,17 @@ static const struct dm_pci_ops brcm_pcie_ops = {
>   	.write_config	= brcm_pcie_write_config,
>   };
>   
> +static const struct pcie_cfg_data bcm2711_cfg = {
> +	.hard_debug_offs	= 0x4204
> +};
> +
> +static const struct pcie_cfg_data bcm2712_cfg = {
> +	.hard_debug_offs	= 0x4304
> +};
> +
>   static const struct udevice_id brcm_pcie_ids[] = {
> -	{ .compatible = "brcm,bcm2711-pcie" },
> +	{ .compatible = "brcm,bcm2711-pcie", .data = (ulong)&bcm2711_cfg },
> +	{ .compatible = "brcm,bcm2712-pcie", .data = (ulong)&bcm2712_cfg },
>   	{ }
>   };
>   

Re: [PATCH v3 0/7] rpi5: initial support

[Marc Zyngier]

Hi Ivan,

On 2023-12-18 21:03, Ivan T. Ivanov wrote:
> Hi,
> 
> These patches are adding basic support for RPi5.
> They are based on v2 series from Dmitry Malkin[1].
> 
> With them I am able to _start_ current openSUSE
> Tumbleweed without modification. They are still
> a lot of things to be added to the upstream Linux
> before it runs flawlessly on this device, but at
> least in U-Booot SD controller used for uSD card
> and Frameboffer and HDMI0 devices are working fine
> now. It seems that PCIe controller is working fine
> too, but I have not tested it too much.
> 
> Serial console and reset are also functional.
> 
> Hopefully this will help others add missing pieces
> more easily.

So I've given this a go, and the basics (serial) worked
out of the box (thanks for that!) after performing the
memory-map change you described in your reply to patch 1.

However, I don't get anything on the PCIe front:

U-Boot> pci enum
PCIe BRCM: link down
PCIe BRCM: link down

despite having an nvme device connected and enabled
(the RPi kernel finds it).

I'm guessing I must be missing something. How did you
test PCIe?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 0/7] rpi5: initial support

[Ivan T. Ivanov]

On 12-22 12:19, Marc Zyngier wrote:
> 
> Hi Ivan,
> 
> On 2023-12-18 21:03, Ivan T. Ivanov wrote:
> > Hi,
> > 
> > These patches are adding basic support for RPi5.
> > They are based on v2 series from Dmitry Malkin[1].
> > 
> > With them I am able to _start_ current openSUSE
> > Tumbleweed without modification. They are still
> > a lot of things to be added to the upstream Linux
> > before it runs flawlessly on this device, but at
> > least in U-Booot SD controller used for uSD card
> > and Frameboffer and HDMI0 devices are working fine
> > now. It seems that PCIe controller is working fine
> > too, but I have not tested it too much.
> > 
> > Serial console and reset are also functional.
> > 
> > Hopefully this will help others add missing pieces
> > more easily.
> 
> So I've given this a go, and the basics (serial) worked
> out of the box (thanks for that!) after performing the
> memory-map change you described in your reply to patch 1.
> 
> However, I don't get anything on the PCIe front:
> 
> U-Boot> pci enum
> PCIe BRCM: link down
> PCIe BRCM: link down
> 
> despite having an nvme device connected and enabled
> (the RPi kernel finds it).
> 
> I'm guessing I must be missing something. How did you
> test PCIe?
> 

No, you are not missing anything. I have not tested it
for real. That is why I said "it seems". Sorry.

Yesterday I started looking more closely at what's missing
and unfortunately a lot more changes are needed.

Regards,
Ivan

Re: [PATCH v3 0/7] rpi5: initial support

[Marc Zyngier]

On 2023-12-22 12:33, Ivan T. Ivanov wrote:
> On 12-22 12:19, Marc Zyngier wrote:
>> 
>> Hi Ivan,
>> 
>> On 2023-12-18 21:03, Ivan T. Ivanov wrote:
>> > Hi,
>> >
>> > These patches are adding basic support for RPi5.
>> > They are based on v2 series from Dmitry Malkin[1].
>> >
>> > With them I am able to _start_ current openSUSE
>> > Tumbleweed without modification. They are still
>> > a lot of things to be added to the upstream Linux
>> > before it runs flawlessly on this device, but at
>> > least in U-Booot SD controller used for uSD card
>> > and Frameboffer and HDMI0 devices are working fine
>> > now. It seems that PCIe controller is working fine
>> > too, but I have not tested it too much.
>> >
>> > Serial console and reset are also functional.
>> >
>> > Hopefully this will help others add missing pieces
>> > more easily.
>> 
>> So I've given this a go, and the basics (serial) worked
>> out of the box (thanks for that!) after performing the
>> memory-map change you described in your reply to patch 1.
>> 
>> However, I don't get anything on the PCIe front:
>> 
>> U-Boot> pci enum
>> PCIe BRCM: link down
>> PCIe BRCM: link down
>> 
>> despite having an nvme device connected and enabled
>> (the RPi kernel finds it).
>> 
>> I'm guessing I must be missing something. How did you
>> test PCIe?
>> 
> 
> No, you are not missing anything. I have not tested it
> for real. That is why I said "it seems". Sorry.
> 
> Yesterday I started looking more closely at what's missing
> and unfortunately a lot more changes are needed.

Ah, fair enough. I was slightly surprised that it appeared
to be working out of the box, which would have been a first
on the ARM side...

Happy to test whatever patches you come up with!

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...