[PATCH v4 0/6] rpi5: initial support

[PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

These patches are slight update for patches posted earlier here[1].
They are adding basic support for RPi5 and are based on v2 series
from Dmitry Malkin[2].

What changed:

* Initial memory map now includes whole first 1GB of DRAM. At runtime,
  the firmware will adjust this size depending on whether an HDMI cable
  is plugged in or not. If there is HDMI monitor connected it will reserve
  framebufer memory region and will add simple-framebuffer device into
  devicetree.

* Dynamically calculate bits per pixel in video driver. This works
  on all prevous RPi's models that I have.

* I am dropping PCIe patch for now. I made some progress on porting changes
  from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
  tricky. They are many devices behind PCIe, but more or less all of them
  requires missing either "reset-controller" or "clock-controller" or
  "pin-controller" drivers. I was able to probe "cdns,macb" device, but
  access to ethernet PHY over MDIO bus is stucking. Then I ported
  "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
  missing clock. And on top of that machine that I used for developing this
  crashed and I lost my PCIe changes :-|. Anyway.

These patches allows me to boot current openSUSE Tumbleweed without
modification. I can see serial console log and boot process on HDMI
connected monitor.

I think these patches should be enough for start. Please consider for
inclusion.

Thanks,
Ivan

[1] https://lore.kernel.org/all/20231218210341.30073-1-iivanov@suse.de/
[2] 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 (4):
  rpi5: Use devicetree to retrieve board revision
  bcm2835: Dynamically calculate bytes per pixel parameter
  mmc: bcmstb: Add support for bcm2712 SD controller
  configs: rpi_arm64: enable SDHCI BCMSTB driver

 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               |  74 ++++++++-
 board/raspberrypi/rpi/rpi.c                |  22 ++-
 configs/rpi_arm64_defconfig                |   1 +
 drivers/mmc/bcmstb_sdhci.c                 | 173 ++++++++++++++++++++-
 drivers/video/bcm2835.c                    |  18 ++-
 10 files changed, 282 insertions(+), 23 deletions(-)

-- 
2.35.3

[PATCH v4 1/6] rpi5: add initial memory map for bcm2712

[Ivan T. Ivanov]

From: Dmitry Malkin <dmitry@bedrocksystems.com>

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

When HDMI cable is plugged in at boot time firmware will
insert "simple-framebuffer" device into devicetree and will
shrink first memory region to 0x3f800000UL. Board setup then
will properly reserve frameboofer region.

When no HDMI cable is plugged in size of the region will be
0x3fc00000UL.

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

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 7265faf6ce..f1a0c8588d 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -68,6 +68,36 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
 	}
 };
 
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
+	{
+		/* First 1GB of DRAM */
+		.virt = 0x00000000UL,
+		.phys = 0x00000000UL,
+		.size = 0x40000000UL,
+		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+			 PTE_BLOCK_INNER_SHARE
+	}, {
+		/* 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
+	}, {
+		/* SoC bus */
+		.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 +108,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

Re: [PATCH v4 1/6] rpi5: add initial memory map for bcm2712

[Florian Fainelli]

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

On 1/10/24 04:29, Ivan T. Ivanov wrote:
> From: Dmitry Malkin <dmitry@bedrocksystems.com>
> 
> This includes:
> * 1GB of RAM (from 4GB or 8GB total)
> * AXI ranges (main peripherals)
> 
> When HDMI cable is plugged in at boot time firmware will
> insert "simple-framebuffer" device into devicetree and will
> shrink first memory region to 0x3f800000UL. Board setup then
> will properly reserve frameboofer region.

s/frameboofer/framebuffer/

> 
> When no HDMI cable is plugged in size of the region will be
> 0x3fc00000UL.

s/in size/in the size/
-- 
Florian


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

[PATCH v4 2/6] 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>
Reviewed-by: Matthias Brugger <mbrugger@suse.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 f1a0c8588d..016bc1eb41 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -146,7 +146,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)
 {
@@ -157,22 +161,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

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

[Florian Fainelli]

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

On 1/10/24 04:29, Ivan T. Ivanov wrote:
> From: Dmitry Malkin <dmitry@bedrocksystems.com>
> 
> MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.

s/has a/have a /

> Find them via devicetree blob passed by bootloader.
> 
> Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
> Reviewed-by: Matthias Brugger <mbrugger@suse.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;

Maybe suffix those variables with _phys_base to denote they are physical 
addresses, even if you seem to use a 1:1 mapping between virtual and 
physical, knowing which type of address we are dealing with right away 
is clearer.
-- 
Florian


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

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

[Ivan T. Ivanov]

On 01-10 10:00, Florian Fainelli wrote:
> On 1/10/24 04:29, Ivan T. Ivanov wrote:
> > From: Dmitry Malkin <dmitry@bedrocksystems.com>
> > 
> > MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.
> 
> s/has a/have a /
> 

Thanks!

> > Find them via devicetree blob passed by bootloader.
> > 
> > Signed-off-by: Dmitry Malkin <dmitry@bedrocksystems.com>
> > Reviewed-by: Matthias Brugger <mbrugger@suse.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;
> 
> Maybe suffix those variables with _phys_base to denote they are physical
> addresses, even if you seem to use a 1:1 mapping between virtual and
> physical, knowing which type of address we are dealing with right away is
> clearer.

I am not an expert on U-Boot, but I think mapping is always 1:1, so
explicit naming it that way looks redundant. As you can see even initial
naming don't specify it. But if you insist I could change it.

Regards,
Ivan

[PATCH v4 3/6] 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>;
	};

Reviewed-by: Matthias Brugger <mbrugger@suse.com>
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 v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter

[Ivan T. Ivanov]

brcm,bcm2708-fb device provided by firmware on RPi5 uses
16 bits per pixel, so lets calculate framebuffer bytes
per pixel dynamically based on queried information.

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

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

diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 14942526f1..63efa762db 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -16,7 +16,7 @@ static int bcm2835_video_probe(struct udevice *dev)
 	struct video_uc_plat *plat = dev_get_uclass_plat(dev);
 	struct video_priv *uc_priv = dev_get_uclass_priv(dev);
 	int ret;
-	int w, h, pitch;
+	int w, h, pitch, bpp;
 	ulong fb_base, fb_size, fb_start, fb_end;
 
 	debug("bcm2835: Query resolution...\n");
@@ -41,9 +41,23 @@ static int bcm2835_video_probe(struct udevice *dev)
 					DCACHE_WRITEBACK);
 	video_set_flush_dcache(dev, true);
 
+	bpp = pitch / w;
+	switch (bpp) {
+	case 2:
+		uc_priv->bpix = VIDEO_BPP16;
+		break;
+	case 4:
+		uc_priv->bpix = VIDEO_BPP32;
+		break;
+	default:
+		printf("bcm2835: unexpected bpp %d, pitch %d, width %d\n",
+		       bpp, pitch, w);
+		uc_priv->bpix = VIDEO_BPP32;
+		break;
+	}
+
 	uc_priv->xsize = w;
 	uc_priv->ysize = h;
-	uc_priv->bpix = VIDEO_BPP32;
 	plat->base = fb_base;
 	plat->size = fb_size;
 
-- 
2.35.3

Re: [PATCH v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter

[Matthias Brugger]

On 10/01/2024 13:29, Ivan T. Ivanov wrote:
> brcm,bcm2708-fb device provided by firmware on RPi5 uses
> 16 bits per pixel, so lets calculate framebuffer bytes
> per pixel dynamically based on queried information.
> 
> Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1,
> RPi2 Zero W, RPi5b v1.0.
> 
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>

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

> ---
>   drivers/video/bcm2835.c | 18 ++++++++++++++++--
>   1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
> index 14942526f1..63efa762db 100644
> --- a/drivers/video/bcm2835.c
> +++ b/drivers/video/bcm2835.c
> @@ -16,7 +16,7 @@ static int bcm2835_video_probe(struct udevice *dev)
>   	struct video_uc_plat *plat = dev_get_uclass_plat(dev);
>   	struct video_priv *uc_priv = dev_get_uclass_priv(dev);
>   	int ret;
> -	int w, h, pitch;
> +	int w, h, pitch, bpp;
>   	ulong fb_base, fb_size, fb_start, fb_end;
>   
>   	debug("bcm2835: Query resolution...\n");
> @@ -41,9 +41,23 @@ static int bcm2835_video_probe(struct udevice *dev)
>   					DCACHE_WRITEBACK);
>   	video_set_flush_dcache(dev, true);
>   
> +	bpp = pitch / w;
> +	switch (bpp) {
> +	case 2:
> +		uc_priv->bpix = VIDEO_BPP16;
> +		break;
> +	case 4:
> +		uc_priv->bpix = VIDEO_BPP32;
> +		break;
> +	default:
> +		printf("bcm2835: unexpected bpp %d, pitch %d, width %d\n",
> +		       bpp, pitch, w);
> +		uc_priv->bpix = VIDEO_BPP32;
> +		break;
> +	}
> +
>   	uc_priv->xsize = w;
>   	uc_priv->ysize = h;
> -	uc_priv->bpix = VIDEO_BPP32;
>   	plat->base = fb_base;
>   	plat->size = fb_size;
>   

[PATCH v4 5/6] 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

Re: [PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller

[Stefan Wahren]

Hi Ivan,

Am 10.01.24 um 13:29 schrieb 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>
did you noticed this commit/pull request?

https://github.com/raspberrypi/linux/pull/5842/commits/3c9d840dc933cfb13a77fd3c03356ee4adacc30b

Re: Re: [PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller

[Ivan T. Ivanov]

On 01-11 23:07, Stefan Wahren wrote:
> 
> Hi Ivan,
> 
> Am 10.01.24 um 13:29 schrieb 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>
> did you noticed this commit/pull request?
> 
> https://github.com/raspberrypi/linux/pull/5842/commits/3c9d840dc933cfb13a77fd3c03356ee4adacc30b

Doh, no. Let me check.

Thanks!
Ivan

Re: Re: Re: [PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller

[Ivan T. Ivanov]

Hi,

> On 01-12 09:44, Ivan T. Ivanov wrote:
> On 01-11 23:07, Stefan Wahren wrote:
> > 
> > Hi Ivan,
> > 
> > Am 10.01.24 um 13:29 schrieb 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>
> > did you noticed this commit/pull request?
> > 
> > https://github.com/raspberrypi/linux/pull/5842/commits/3c9d840dc933cfb13a77fd3c03356ee4adacc30b
> 
> Doh, no. Let me check.

And indeed, no special accessors are needed. I am preparing new version
and will send it shortly.

Thanks,
Ivan

[PATCH v4 6/6] 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 08bb30b1d7..11ede9435d 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

Re: [PATCH v4 0/6] rpi5: initial support

[Matthias Brugger]

On 10/01/2024 13:29, Ivan T. Ivanov wrote:
> Hi,
> 
> These patches are slight update for patches posted earlier here[1].
> They are adding basic support for RPi5 and are based on v2 series
> from Dmitry Malkin[2].
> 
> What changed:
> 
> * Initial memory map now includes whole first 1GB of DRAM. At runtime,
>    the firmware will adjust this size depending on whether an HDMI cable
>    is plugged in or not. If there is HDMI monitor connected it will reserve
>    framebufer memory region and will add simple-framebuffer device into
>    devicetree.
> 
> * Dynamically calculate bits per pixel in video driver. This works
>    on all prevous RPi's models that I have.
> 
> * I am dropping PCIe patch for now. I made some progress on porting changes
>    from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
>    tricky. They are many devices behind PCIe, but more or less all of them
>    requires missing either "reset-controller" or "clock-controller" or
>    "pin-controller" drivers. I was able to probe "cdns,macb" device, but
>    access to ethernet PHY over MDIO bus is stucking. Then I ported
>    "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
>    missing clock. And on top of that machine that I used for developing this
>    crashed and I lost my PCIe changes :-|. Anyway.
> 
> These patches allows me to boot current openSUSE Tumbleweed without
> modification. I can see serial console log and boot process on HDMI
> connected monitor.
> 
> I think these patches should be enough for start. Please consider for
> inclusion.
> 
> Thanks,
> Ivan
> 
> [1] https://lore.kernel.org/all/20231218210341.30073-1-iivanov@suse.de/
> [2] 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 (4):
>    rpi5: Use devicetree to retrieve board revision
>    bcm2835: Dynamically calculate bytes per pixel parameter
>    mmc: bcmstb: Add support for bcm2712 SD controller
>    configs: rpi_arm64: enable SDHCI BCMSTB driver
> 

In the meantime I was able to test this series. So here my:
Tested-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               |  74 ++++++++-
>   board/raspberrypi/rpi/rpi.c                |  22 ++-
>   configs/rpi_arm64_defconfig                |   1 +
>   drivers/mmc/bcmstb_sdhci.c                 | 173 ++++++++++++++++++++-
>   drivers/video/bcm2835.c                    |  18 ++-
>   10 files changed, 282 insertions(+), 23 deletions(-)
> 

Re: [PATCH v4 0/6] rpi5: initial support

[Stefan Agner]

Hi Ivan,

I am looking into enabling NVMe boot support using U-Boot on Raspberry
Pi 5. Which brings me to some questions wrt PCIe support (see below).

On 2024-01-10 13:29, Ivan T. Ivanov wrote:
> Hi,
> 
> These patches are slight update for patches posted earlier here[1].
> They are adding basic support for RPi5 and are based on v2 series
> from Dmitry Malkin[2].
> 
> What changed:
> 
> * Initial memory map now includes whole first 1GB of DRAM. At runtime,
>   the firmware will adjust this size depending on whether an HDMI cable
>   is plugged in or not. If there is HDMI monitor connected it will reserve
>   framebufer memory region and will add simple-framebuffer device into
>   devicetree.
> 
> * Dynamically calculate bits per pixel in video driver. This works
>   on all prevous RPi's models that I have.
> 
> * I am dropping PCIe patch for now. I made some progress on porting changes
>   from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
>   tricky. They are many devices behind PCIe, but more or less all of them
>   requires missing either "reset-controller" or "clock-controller" or
>   "pin-controller" drivers. I was able to probe "cdns,macb" device, but
>   access to ethernet PHY over MDIO bus is stucking. Then I ported
>   "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
>   missing clock. And on top of that machine that I used for developing this
>   crashed and I lost my PCIe changes :-|. Anyway.

Have you tried using a M.2 HAT? This likely won't require much in terms
of enabling the device.

You write that you made some progress, is that compared to v3? Do you
mind sharing the latest version of your patches?

Best regards,
Stefan

> 
> These patches allows me to boot current openSUSE Tumbleweed without
> modification. I can see serial console log and boot process on HDMI
> connected monitor.
> 
> I think these patches should be enough for start. Please consider for
> inclusion.
> 
> Thanks,
> Ivan
> 
> [1] https://lore.kernel.org/all/20231218210341.30073-1-iivanov@suse.de/
> [2] 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 (4):
>   rpi5: Use devicetree to retrieve board revision
>   bcm2835: Dynamically calculate bytes per pixel parameter
>   mmc: bcmstb: Add support for bcm2712 SD controller
>   configs: rpi_arm64: enable SDHCI BCMSTB driver
> 
>  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               |  74 ++++++++-
>  board/raspberrypi/rpi/rpi.c                |  22 ++-
>  configs/rpi_arm64_defconfig                |   1 +
>  drivers/mmc/bcmstb_sdhci.c                 | 173 ++++++++++++++++++++-
>  drivers/video/bcm2835.c                    |  18 ++-
>  10 files changed, 282 insertions(+), 23 deletions(-)

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi Stefan,

> On 19 Sep 2024, at 12:36, Stefan Agner <stefan@agner.ch> wrote:
> 
> Hi Ivan,
> 
> I am looking into enabling NVMe boot support using U-Boot on Raspberry
> Pi 5. Which brings me to some questions wrt PCIe support (see below).
> 
> On 2024-01-10 13:29, Ivan T. Ivanov wrote:
>> 


>> * I am dropping PCIe patch for now. I made some progress on porting changes
>>  from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
>>  tricky. They are many devices behind PCIe, but more or less all of them
>>  requires missing either "reset-controller" or "clock-controller" or
>>  "pin-controller" drivers. I was able to probe "cdns,macb" device, but
>>  access to ethernet PHY over MDIO bus is stucking. Then I ported
>>  "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
>>  missing clock. And on top of that machine that I used for developing this
>>  crashed and I lost my PCIe changes :-|. Anyway.
> 
> Have you tried using a M.2 HAT? This likely won't require much in terms
> of enabling the device.
> 
> You write that you made some progress, is that compared to v3? Do you
> mind sharing the latest version of your patches?


No further progress on PCIe for U-Boot from my side was made, sorry.

Stan is working on adding support for 2712 PCIe in Linux [1]. Perhaps
once this is complete we can work on adding U-Boot support for the same,
unless someone don’t beat us, of course. 

Regards,
Ivan

Re: [PATCH v4 0/6] rpi5: initial support

[Stefan Agner]

Hi Ivan,

Thanks for the quick response!

On 2024-09-19 11:52, Ivan T. Ivanov wrote:
> Hi Stefan,
> 
>> On 19 Sep 2024, at 12:36, Stefan Agner <stefan@agner.ch> wrote:
>> 
>> Hi Ivan,
>> 
>> I am looking into enabling NVMe boot support using U-Boot on Raspberry
>> Pi 5. Which brings me to some questions wrt PCIe support (see below).
>> 
>> On 2024-01-10 13:29, Ivan T. Ivanov wrote:
>>> 
> 
> 
>>> * I am dropping PCIe patch for now. I made some progress on porting changes
>>>  from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
>>>  tricky. They are many devices behind PCIe, but more or less all of them
>>>  requires missing either "reset-controller" or "clock-controller" or
>>>  "pin-controller" drivers. I was able to probe "cdns,macb" device, but
>>>  access to ethernet PHY over MDIO bus is stucking. Then I ported
>>>  "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
>>>  missing clock. And on top of that machine that I used for developing this
>>>  crashed and I lost my PCIe changes :-|. Anyway.
>> 
>> Have you tried using a M.2 HAT? This likely won't require much in terms
>> of enabling the device.
>> 
>> You write that you made some progress, is that compared to v3? Do you
>> mind sharing the latest version of your patches?
> 
> 
> No further progress on PCIe for U-Boot from my side was made, sorry.
> 

So v3 the patch you've shared in v3 is your latest state? I was
wondering since you wrote in this v4 patch set "I made some progress on
porting changes
 from vendor Linux tree to U-Boot."...


> Stan is working on adding support for 2712 PCIe in Linux [1]. Perhaps
> once this is complete we can work on adding U-Boot support for the same,
> unless someone don’t beat us, of course. 

Hm, it seems the link did not make it. I guess you meant to link this
patch set [1]

--
Stefan

[1]
https://lore.kernel.org/lkml/20240910151845.17308-1-svarbanov@suse.de/T/

> 
> Regards,
> Ivan

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

On 09-19 16:01, Stefan Agner wrote:
> Hi Ivan,
> 
> Thanks for the quick response!
> 
> On 2024-09-19 11:52, Ivan T. Ivanov wrote:
> > Hi Stefan,
> > 
> >> On 19 Sep 2024, at 12:36, Stefan Agner <stefan@agner.ch> wrote:
> >> 
> >> Hi Ivan,
> >> 
> >> I am looking into enabling NVMe boot support using U-Boot on Raspberry
> >> Pi 5. Which brings me to some questions wrt PCIe support (see below).
> >> 
> >> On 2024-01-10 13:29, Ivan T. Ivanov wrote:
> >>> 
> > 
> > 
> >>> * I am dropping PCIe patch for now. I made some progress on porting changes
> >>>  from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
> >>>  tricky. They are many devices behind PCIe, but more or less all of them
> >>>  requires missing either "reset-controller" or "clock-controller" or
> >>>  "pin-controller" drivers. I was able to probe "cdns,macb" device, but
> >>>  access to ethernet PHY over MDIO bus is stucking. Then I ported
> >>>  "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
> >>>  missing clock. And on top of that machine that I used for developing this
> >>>  crashed and I lost my PCIe changes :-|. Anyway.
> >> 
> >> Have you tried using a M.2 HAT? This likely won't require much in terms
> >> of enabling the device.
> >> 
> >> You write that you made some progress, is that compared to v3? Do you
> >> mind sharing the latest version of your patches?
> > 
> > 
> > No further progress on PCIe for U-Boot from my side was made, sorry.
> > 
> 
> So v3 the patch you've shared in v3 is your latest state? I was
> wondering since you wrote in this v4 patch set "I made some progress on
> porting changes
>  from vendor Linux tree to U-Boot."...

And then " .. And on top of that machine that I used for developing this
crashed and I lost my PCIe changes ... ". Reading the whole paragraph
now I agree it is not completely clear what happened.

> 
> 
> > Stan is working on adding support for 2712 PCIe in Linux [1]. Perhaps
> > once this is complete we can work on adding U-Boot support for the same,
> > unless someone don’t beat us, of course. 
> 
> Hm, it seems the link did not make it. I guess you meant to link this
> patch set [1]
> 
> --
> Stefan
> 
> [1]
> https://lore.kernel.org/lkml/20240910151845.17308-1-svarbanov@suse.de/T/

Yes.

Regards,
Ivan

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi Ivan,

first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.

Best regards,

Jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

On 01-12 14:10, Jens Maus wrote:
> 
> Hi Ivan,
> 
> first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
> 

Yes, I am using rpi_arm64_defconfig for building the U-Boot.
And as I wrote in the cover letter I am using openSUSE Tumbleweed
image[1], [2]. Once you copy image to uSD card mount EFI uSD
partition and copy new u-boot.bin over existing one. That
it is. Just make sure you clearly sync, unmount the card.
You can find config.txt file in the EFI partition.

Regards,
Ivan

[1] https://en.opensuse.org/HCL:Raspberry_Pi4
[2] http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-XFCE-raspberrypi.aarch64.raw.xz

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 17.01.2024 um 16:07 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
> On 01-12 14:10, Jens Maus wrote:
>> 
>> Hi Ivan,
>> 
>> first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
>> 
> 
> Yes, I am using rpi_arm64_defconfig for building the U-Boot.
> And as I wrote in the cover letter I am using openSUSE Tumbleweed
> image[1], [2]. Once you copy image to uSD card mount EFI uSD
> partition and copy new u-boot.bin over existing one. That
> it is. Just make sure you clearly sync, unmount the card.
> You can find config.txt file in the EFI partition.

That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?

Best Regards,

Jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

> On 17 Jan 2024, at 17:13, Jens Maus <mail@jens-maus.de> wrote:
> 
> Hi,
> 
>> Am 17.01.2024 um 16:07 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>> 
>> On 01-12 14:10, Jens Maus wrote:
>>> 
>>> Hi Ivan,
>>> 
>>> first of all, thanks for the updated rpi5 patchset. However, I am unable to reproduce that it is actually working as you suggest. Could you please quickly elaborate on your test environment and the test config.txt for the RaspberryPi5? Here I have compiled U-Boot 2024.01 with your patches applied and using the „rpi_arm64_defconfig“, put the u-boot.bin file on the sd card and then added „kernel=u-boot.bin“ to the config.txt file. The environment I am using is a buildroot-based system which boots nicely with the default RaspberryPi boot loader and a RaspberryPi5. However, as soon as I replace the „kernel=Image“ line with „kernel=u-boot.bin“ the system stalls and there is no HDMI output (nor any console output) with the u-boot 2024.01 version and your patches applied.
>>> 
>> 
>> Yes, I am using rpi_arm64_defconfig for building the U-Boot.
>> And as I wrote in the cover letter I am using openSUSE Tumbleweed
>> image[1], [2]. Once you copy image to uSD card mount EFI uSD
>> partition and copy new u-boot.bin over existing one. That
>> it is. Just make sure you clearly sync, unmount the card.
>> You can find config.txt file in the EFI partition.
> 
> That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?

Unfortunately on RPi5 they moved UART debug port to
separate connector [1], [2]. 

Let me update my Tumbleweed image and check again.

Just to reiterate that if not properly syncing
content to uSD card could have strange side effects. 

Regards,
Ivan

[1] https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html
[2] https://www.youtube.com/watch?v=kP2S3JUH-qk

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 17.01.2024 um 16:23 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
>> That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?
> 
> Unfortunately on RPi5 they moved UART debug port to
> separate connector [1], [2].

I know. In fact, I already have such a rpi debug probe [1] at my desk. Nevertheless, haven’t tried to fire up the rpi5 with your u-boot.bin to see if anything sensible comes up at that special UART debug port which could explain the stalling and no HDMI output I saw here last time I checked.

> Let me update my Tumbleweed image and check again.

Thx. Can you perhaps also elaborate on your build environment for that particular u-boot.bin build? Or perhaps put a binary of it somewhere so that I could check if it works with your u-boot.bin build.

> Just to reiterate that if not properly syncing
> content to uSD card could have strange side effects. 

I am aware of these kind of issues. But in fact, I am quite sure I synced all content properly to the microSD card.

Best Regards,

Jens

[1] https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

> On 17 Jan 2024, at 17:30, Jens Maus <mail@jens-maus.de> wrote:
> 
> Hi,
> 
>> Am 17.01.2024 um 16:23 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>> 
>>> That’s in fact exactly what I was also trying in addition to get u-boot running with your patches in my own buildroot-based environment. So I was also exactly using this Tumbleweed rpi4 image and simply replaced the u-boot.bin file with my own build version which I built with your patches applied and using the rpi_arm64_defconfig as the build config. However, there is still no output on any of the HDMI ports. Haven’t tried to see if there is any serial output on the special UART debug port of the rpi5. Should there be any output at all?
>> 
>> Unfortunately on RPi5 they moved UART debug port to
>> separate connector [1], [2].
> 
> I know. In fact, I already have such a rpi debug probe [1] at my desk. Nevertheless, haven’t tried to fire up the rpi5 with your u-boot.bin to see if anything sensible comes up at that special UART debug port which could explain the stalling and no HDMI output I saw here last time I checked.
> 
>> Let me update my Tumbleweed image and check again.
> 
> Thx. Can you perhaps also elaborate on your build environment for that particular u-boot.bin build? Or perhaps put a binary of it somewhere so that I could check if it works with your u-boot.bin build.

I have aarch64 based machine at hand running openSUSE,
thus I am building U-boot “natively”, no cross-compiling.

$ make rpi_arm64_defconfig
$ make

I just dumped latest Tumbleweed[1] to uSD card and copied
u-boot.bin to EFI. I can see the HDMI output.

One thing which I forgot to mention is that once I see
Grub2 prompt I change console parameter from ttyS0 to ttyAMA0
and usually add “ignore_loglevel earlycon”.

Regards,
Ivan

[1] b66d5fa70e5cab998bc6000737015746c636e4b622397b407225b9de73f4a9be  openSUSE-Tumbleweed-ARM-XFCE-raspberrypi.aarch64.raw.xz

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 17.01.2024 um 17:45 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
> I have aarch64 based machine at hand running openSUSE,
> thus I am building U-boot “natively”, no cross-compiling.
> 
> $ make rpi_arm64_defconfig
> $ make

> I just dumped latest Tumbleweed[1] to uSD card and copied
> u-boot.bin to EFI. I can see the HDMI output.

I actually just did that. Installed a fresh Tumbleweed on a microSD card, booted it up with a rpi4 and after installing all necessary build tools I applied your patches to u-boot 2024.01 sources, and then executed these two commands to let it compile a u-boot.bin file which I then put in /boot/efi to replace the u-boot.bin which is/was already there. Then I pulled the SD card and moved it over to the RaspberryPi5 in trying to get it booted up. However, again no HDMI output at all and unfortunately also the serial output on the debug probe does not show U-boot popping up at all. Interestingly, using the patched u-boot.bin with a RaspberryPi4 still works and it boots up perfectly fine, but not with the RaspberryPi5 I have here. 

Any idea why this might be the case here while you report that the above mentioned procedure works for you? In fact, the RaspberryPi5 I have here is a 8GB model and with the rpi-eeprom version from 2024/01/05 [1] in case this might be relevant.

Best Regards,

Jens

[1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

> On 18 Jan 2024, at 1:06, Jens Maus <mail@jens-maus.de> wrote:
> 
> Hi,
> 
>> Am 17.01.2024 um 17:45 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>> 
>> I have aarch64 based machine at hand running openSUSE,
>> thus I am building U-boot “natively”, no cross-compiling.
>> 
>> $ make rpi_arm64_defconfig
>> $ make
> 
>> I just dumped latest Tumbleweed[1] to uSD card and copied
>> u-boot.bin to EFI. I can see the HDMI output.
> 
> I actually just did that. Installed a fresh Tumbleweed on a microSD card, booted it up with a rpi4 and after installing all necessary build tools I applied your patches to u-boot 2024.01 sources, and then executed these two commands to let it compile a u-boot.bin file which I then put in /boot/efi to replace the u-boot.bin which is/was already there. Then I pulled the SD card and moved it over to the RaspberryPi5 in trying to get it booted up. However, again no HDMI output at all and unfortunately also the serial output on the debug probe does not show U-boot popping up at all. Interestingly, using the patched u-boot.bin with a RaspberryPi4 still works and it boots up perfectly fine, but not with the RaspberryPi5 I have here. 
> 
> Any idea why this might be the case here while you report that the above mentioned procedure works for you? In fact, the RaspberryPi5 I have here is a 8GB model and with the rpi-eeprom version from 2024/01/05 [1] in case this might be relevant.

EEPROM version on mine device is older[1], but I suspect that size of
the RAM is what make a difference, mine have only 4GB of RAM.

I am afraid you will have to connect that UART debug cable and share
what is the memory map on your device :-)

Regards,
Ivan

[1] RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 18.01.2024 um 09:33 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
>> I actually just did that. Installed a fresh Tumbleweed on a microSD card, booted it up with a rpi4 and after installing all necessary build tools I applied your patches to u-boot 2024.01 sources, and then executed these two commands to let it compile a u-boot.bin file which I then put in /boot/efi to replace the u-boot.bin which is/was already there. Then I pulled the SD card and moved it over to the RaspberryPi5 in trying to get it booted up. However, again no HDMI output at all and unfortunately also the serial output on the debug probe does not show U-boot popping up at all. Interestingly, using the patched u-boot.bin with a RaspberryPi4 still works and it boots up perfectly fine, but not with the RaspberryPi5 I have here. 
>> 
>> Any idea why this might be the case here while you report that the above mentioned procedure works for you? In fact, the RaspberryPi5 I have here is a 8GB model and with the rpi-eeprom version from 2024/01/05 [1] in case this might be relevant.
> 
> EEPROM version on mine device is older[1], but I suspect that size of
> the RAM is what make a difference, mine have only 4GB of RAM.

This can be also of course the reason why it works for you while it doesn’t for me.

> I am afraid you will have to connect that UART debug cable and share
> what is the memory map on your device :-)

No problem. Here is the output of the RPI bootloader boot up until the system stalls:

— cut here — 
RPi: BOOTSYS release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 boardrev d04170 stc 923866
AON_RESET: 00000003 PM_RSTS 00001000
RP1_BOOT chip ID: 0x20001927
PM_RSTS: 0x00001000
part 00000000 reset_info 00000000
PMIC reset-event 00000000 rtc 00000000 alarm 00000000 enabled 0
uSD voltage 3.3V
Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 4267
DDR 4267 1 0 64 152
RP1_BOOT chip ID: 0x20001927

RP1_BOOT chip ID: 0x20001927
RP1_BOOT: fw size 25968
PCI2 init
PCI2 reset
PCIe scan 00001de4:00000001
RP1_CHIP_INFO 20001927

RPi: BOOTLOADER release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 boardrev d04170 stc 3892985
AON_RESET: 00000003 PM_RSTS 00001000
M.2 PCIe HAT not detected.
usb_pd_init status 3
USB_PD CONFIG 0 41
Boot mode: SD (01) order f4
SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
OCR c0ff8000 [291]
CID: 00035344534536344780519441cb0123
CSD: 400e00325b590001dbd37f800a404000
SD: bus-width: 4 spec: 2 SCR: 0x02458443 0x00000000
SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
MBR: 0x00002000,  131072 type: 0x0c
MBR: 0x00022000, 1024000 type: 0x82
MBR: 0x0011c000,123572224 type: 0x83
MBR: 0x00000000,       0 type: 0x00
USB-PD: src-cap PDO object1 0x0a0191f4
Current 5000 mA
Voltage 5000 mV
USB-PD: src-cap PDO object2 0x0002d12c
Current 3000 mA
Voltage 9000 mV
USB-PD: src-cap PDO object3 0x0003c0e1
Current 2250 mA
Voltage 12000 mV
USB-PD: src-cap PDO object4 0x0004b0b4
Current 1800 mA
Voltage 15000 mV
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' '  V       ^ ' clusters 32695 (4)
rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
FAT16 clusters 32695
[sdcard] autoboot.txt not found
Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' '  V       ^ ' clusters 32695 (4)
rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
FAT16 clusters 32695
Read config.txt bytes     3046 hnd 0x123c
Read ubootconfig.txt bytes       35 hnd 0x468
[sdcard] extraconfig.txt not found
[sdcard] pieeprom.upd not found
usb_max_current_enable default 0 max-current 5000
Read bcm2712-rpi-5-b.dtb bytes    79357 hnd 0x139f
dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712

NOTICE:  BL31: v2.6(release):v2.6-239-g2a9ede0bd
NOTICE:  BL31: Built : 14:26:57, Jun 22 2023
— cut here — 

Best Regards,

Jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

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

On 01-18 18:18, Jens Maus wrote:
> 
> > I am afraid you will have to connect that UART debug cable and share
> > what is the memory map on your device :-)
> 
> No problem.

Thanks, but could you apply attached patch and send me
the logs when there is HDMI monitor connected to the board
and one when cable is unplugged.

Regards,
Ivan



[-- Attachment #2: 0001-fdtdec-hack-Show-DRAM-size-parameters.patch --]
[-- Type: text/x-patch, Size: 815 bytes --]

From f9e039d3febbb046fe06f72731e7ba558927aa55 Mon Sep 17 00:00:00 2001
From: "Ivan T. Ivanov" <iivanov@suse.de>
Date: Fri, 19 Jan 2024 07:22:39 +0200
Subject: [PATCH] fdtdec: hack: Show DRAM size parameters

---
 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index b2c59ab381..84cbd82cdb 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1107,7 +1107,7 @@ int fdtdec_setup_memory_banksize(void)
 		gd->bd->bi_dram[bank].size =
 			(phys_size_t)(res.end - res.start + 1);
 
-		debug("%s: DRAM Bank #%d: start = 0x%llx, size = 0x%llx\n",
+		printf("%s: DRAM Bank #%d: start = 0x%llx, size = 0x%llx\n",
 		      __func__, bank,
 		      (unsigned long long)gd->bd->bi_dram[bank].start,
 		      (unsigned long long)gd->bd->bi_dram[bank].size);
-- 
2.35.3

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 19.01.2024 um 06:29 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
> On 01-18 18:18, Jens Maus wrote:
>> 
>>> I am afraid you will have to connect that UART debug cable and share
>>> what is the memory map on your device :-)
>> 
>> No problem.
> 
> Thanks, but could you apply attached patch and send me
> the logs when there is HDMI monitor connected to the board
> and one when cable is unplugged.

I applied that patch, but unfortunately no U-Boot specific output on the special debug UART of the rpi5 at all. As I have shown in my earlier email, the output ends with the „NOTICE: BL31…“ messages and there is no single line coming from U-boot at all. Also tried to add „#define DEBUG“ to the fdtdec.c file and added CONFIG_LOG=y as well as raising the maximum debug level to 9 to the U-boot build. This for some reason this does not end up in any additional U-boot debug line output on the RPi debug probe connected to the special UART of the rpi5. I even tried to connect the debug probe to the UART pins of the GPIO but also there no U-Boot debug output at all, I am afraid.

So where should that U-Boot debug output actually appear with your u-boot.bin patched version?

Best Regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Stefan Wahren]

Hi,

Am 19.01.24 um 08:21 schrieb Jens Maus:
> Hi,
>
>> Am 19.01.2024 um 06:29 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>>
>> On 01-18 18:18, Jens Maus wrote:
>>>> I am afraid you will have to connect that UART debug cable and share
>>>> what is the memory map on your device :-)
>>> No problem.
>> Thanks, but could you apply attached patch and send me
>> the logs when there is HDMI monitor connected to the board
>> and one when cable is unplugged.
> I applied that patch, but unfortunately no U-Boot specific output on the special debug UART of the rpi5 at all. As I have shown in my earlier email, the output ends with the „NOTICE: BL31…“ messages and there is no single line coming from U-boot at all. Also tried to add „#define DEBUG“ to the fdtdec.c file and added CONFIG_LOG=y as well as raising the maximum debug level to 9 to the U-boot build. This for some reason this does not end up in any additional U-boot debug line output on the RPi debug probe connected to the special UART of the rpi5. I even tried to connect the debug probe to the UART pins of the GPIO but also there no U-Boot debug output at all, I am afraid.
i don't know the reason for this issue, but here are some thoughts:

According to this issue [1] the 4 GB and the 8 GB variant uses
completely different RAM ICs. Not sure this is relevant here or a red
herring, because i would assume the VideoCore firmware would care about
this.

Another idea could be to dump the runtime DT of both variants via sysfs
(using official RPi OS) and compare them with each other. In the past
there was a lot DT firmware hackery for the Raspberry Pi 4.

Regards

[1] - https://github.com/raspberrypi/firmware/issues/1854
>
> So where should that U-Boot debug output actually appear with your u-boot.bin patched version?
>
> Best Regards,
> jens

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 19.01.2024 um 10:20 schrieb Stefan Wahren <wahrenst@gmx.net>:
> 
> Another idea could be to dump the runtime DT of both variants via sysfs
> (using official RPi OS) and compare them with each other. In the past
> there was a lot DT firmware hackery for the Raspberry Pi 4.

Good idea indeed. I just did that and executed "dtc -I fs /sys/firmware/devicetree/base“ in a quick RaspberryPiOS installation.

See [1] for the corresponding output. Hopefully Ivan can do the same so that we can see if there are any differences that might explain why his u-boot patches are working for him while they does not for me.

Best Regards,
Jens

[1] https://gist.github.com/jens-maus/497e03cf1305ffe8a07e3196c27d6ebd
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

+ u-boot@lists.denx.de

I am not sure how I drop the list in my last email, sorry.

On 01-19 12:56, Jens Maus wrote:
> Hi Ivan,
> 
> > Am 19.01.2024 um 12:22 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> > 
> > On 01-19 11:49, Jens Maus wrote:
> >>> Am 19.01.2024 um 10:20 schrieb Stefan Wahren <wahrenst@gmx.net>:
> >>> 
> >>> Another idea could be to dump the runtime DT of both variants via sysfs
> >>> (using official RPi OS) and compare them with each other. In the past
> >>> there was a lot DT firmware hackery for the Raspberry Pi 4.
> >> 
> >> Good idea indeed. I just did that and executed "dtc -I fs /sys/firmware/devicetree/base“ in a quick RaspberryPiOS installation.
> >> 
> >> See [1] for the corresponding output. Hopefully Ivan can do the same so that we can see if there are any differences that might
> >> explain why his u-boot patches are working for him while they does not for me.
> >> 
> >> Best Regards,
> >> Jens
> >> 
> >> [1] https://gist.github.com/jens-maus/497e03cf1305ffe8a07e3196c27d6ebd
> > 
> > Thanks! Unfortunately at least first 2 memory banks looks the same as in 4GB version:
> > 
> > memory@0 {
> >    device_type = "memory";
> >    reg = <0x00 0x00 0x3f800000 0x00 0x40000000 0xc0000000>;
> > };
> > 
> > Jens, could you please, disconnect HDMI cable and capture devicetree
> > file again.
> 
> Sure. Here the diff against the other device tree at gist:
> 
> — cut here —
> --- device-tree	2024-01-19 11:33:41.831797039 +0100
> +++ device-tree2	2024-01-19 12:53:11.333845039 +0100
> @@ -2,7 +2,7 @@
>  
>  / {
>  	#address-cells = <0x02>;
> -	memreserve = <0x3f800000 0x800000>;
> +	memreserve = <0x3fc00000 0x400000>;
>  	model = "Raspberry Pi 5 Model B Rev 1.0";
>  	serial-number = "6b206ca09127ae99";
>  	#size-cells = <0x01>;
> @@ -41,7 +41,7 @@
>  
>  	memory@0 {
>  		device_type = "memory";
> -		reg = <0x00 0x00 0x3f800000 0x00 0x40000000 0xc0000000 0x01 0x00 0x80000000 0x01 0x80000000 0x80000000>;
> +		reg = <0x00 0x00 0x3fc00000 0x00 0x40000000 0xc0000000 0x01 0x00 0x80000000 0x01 0x80000000 0x80000000>;
>  	};
>  

Same here, expect that they are more memory banks, of course.
It is really strange that you don't seen even single message
from the U-Boot..

Hm... Ivan

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

> Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
> Same here, expect that they are more memory banks, of course.
> It is really strange that you don't seen even single message
> from the U-Boot..

Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?

Perhaps it is really dependent on the eeprom version? Can you perhaps try to bump your eeprom version to the latest version to see if this might be the culprit?

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

On 01-19 14:54, Jens Maus wrote:
> 
> > Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> > 
> > Same here, expect that they are more memory banks, of course.
> > It is really strange that you don't seen even single message
> > from the U-Boot..
> 
> Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?

Yes, there is even small submarine on the top right side of the screen
while U-Boot is running.

> 
> Perhaps it is really dependent on the eeprom version? Can you perhaps try to bump your eeprom version to the latest version to see if this might be the culprit?
> 

Yes, will do this.

Regards,
Ivan

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

> Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
> On 01-19 14:54, Jens Maus wrote:
>> 
>>> Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>>> 
>>> Same here, expect that they are more memory banks, of course.
>>> It is really strange that you don't seen even single message
>>> from the U-Boot..
>> 
>> Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?
> 
> Yes, there is even small submarine on the top right side of the screen
> while U-Boot is running.

On the HDMI port, right? But what about the serial UART output? Is there anything U-Boot outputs right after the rpi boot loader is done? Here not. And as said, the same u-boot.bin boots up perfectly with a rpi4 and I can see the U-Boot submarine logo on the HDMI.

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

> On 19 Jan 2024, at 16:08, Jens Maus <mail@jens-maus.de> wrote:
> 
> 
>> Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>> 
>> On 01-19 14:54, Jens Maus wrote:
>>> 
>>>> Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>>>> 
>>>> Same here, expect that they are more memory banks, of course.
>>>> It is really strange that you don't seen even single message
>>>> from the U-Boot..
>>> 
>>> Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see any debug output on the serial debug probe connection to the rpi5?
>> 
>> Yes, there is even small submarine on the top right side of the screen
>> while U-Boot is running.
> 
> On the HDMI port, right? But what about the serial UART output? 

Yes, I can see serial output from U-Boot. I am using one of these
simple USB<->UART cables. You can see serial output when you boot
with RPiOS, when you use "Raspberry Pi Debug Probe”, right?

Ivan

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

> Am 19.01.2024 um 15:24 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
>> On 19 Jan 2024, at 16:08, Jens Maus <mail@jens-maus.de> wrote:
>> 
>> On the HDMI port, right? But what about the serial UART output? 
> 
> Yes, I can see serial output from U-Boot. I am using one of these
> simple USB<->UART cables. You can see serial output when you boot
> with RPiOS, when you use "Raspberry Pi Debug Probe”, right?

Yes, when booting up RPiOS I can first see the same serial debug output regarding the rpi boot loader until the same „NOTICE: BL31: …“ lines. Then RPiOS comes up and in the end I get an interactive serial console login "raspberrypi login:“ prompt on the RaspberryPi Debug Probe connection to that special UART port on the rpi5 pcb.

So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

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

On 01-19 17:12, Jens Maus wrote:
> >> 
> >> On the HDMI port, right? But what about the serial UART output? 
> > 
> > Yes, I can see serial output from U-Boot. I am using one of these
> > simple USB<->UART cables. You can see serial output when you boot
> > with RPiOS, when you use "Raspberry Pi Debug Probe”, right?
> 
> Yes, when booting up RPiOS I can first see the same serial debug output regarding the rpi boot loader until the same „NOTICE: BL31: …“ lines. Then RPiOS comes up and in the end I get an interactive serial console login "raspberrypi login:“ prompt on the RaspberryPi Debug Probe connection to that special UART port on the rpi5 pcb.
> 

Yeah, I don't know why I asked even though I saw those messages in your log.

> So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
> 

Yes :-) See attached log file.

Regards,
Ivan


[-- Attachment #2: RPi-u-boot.log --]
[-- Type: text/plain, Size: 3139 bytes --]

RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede boardrev c04170 stc 815886
AON_RESET: 00000003 PM_RSTS 00001000
RP1_BOOT chip ID: 0x20001927
PM_RSTS: 0x00001000
part 00000000 reset_info 00000000
PMIC reset-event 00000000 rtc 00000000 alarm 00000000 enabled 0
uSD voltage 3.3V
Initialising SDRAM 'Samsung' 16Gb x2 total-size: 32 Gbit 4267
DDR 4267 1 0 32 152
RP1_BOOT chip ID: 0x20001927

RP1_BOOT chip ID: 0x20001927
RP1_BOOT: fw size 25968
PCI2 init
PCI2 reset
PCIe scan 00001de4:00000001
RP1_CHIP_INFO 20001927

RPi: BOOTLOADER release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede boardrev c04170 stc 3726990
AON_RESET: 00000003 PM_RSTS 00001000
usb_pd_init status 1
Boot mode: SD (01) order f4
SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
OCR c0ff8000 [118]
CID: 00035344534e33324780fa570bda0169
CSD: 400e00325b590000edb07f800a400000
SD: bus-width: 4 spec: 2 SCR: 0x02358483 0x00000000
SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
MBR: 0x00002000,  131072 type: 0x0c
MBR: 0x00022000, 1024000 type: 0x82
MBR: 0x0011c000,10321887 type: 0x83
MBR: 0x00000000,       0 type: 0x00
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' '  V       ^ ' clusters 32695 (4)
rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
FAT16 clusters 32695
[sdcard] autoboot.txt not found
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' '  V       ^ ' clusters 32695 (4)
rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
FAT16 clusters 32695
Read config.txt bytes     3046 hnd 0x123c
Read ubootconfig.txt bytes       35 hnd 0x468
[sdcard] extraconfig.txt not found
[sdcard] pieeprom.upd not found
usb_max_current_enable default 0 max-current 900
Read bcm2712-rpi-5-b.dtb bytes    79357 hnd 0x139f
dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
PM_RSTS 00001000
Selecting USB low current limit

NOTICE:  BL31: v2.6(release):v2.6-239-g2a9ede0bd
NOTICE:  BL31: Built : 14:26:57, Jun 22 2023


U-Boot 2024.01-00778-ga7376eff69-dirty (Jan 19 2024 - 07:17:48 +0200)

DRAM:  fdtdec_setup_memory_banksize: DRAM Bank #0: start = 0x0, size = 0x3fc00000
fdtdec_setup_memory_banksize: DRAM Bank #1: start = 0x40000000, size = 0xc0000000
1020 MiB (effective 4 GiB)
mbox: Header response code invalid
RPI 5 Model B (0xc04170)
Core:  22 devices, 12 uclasses, devicetree: board
MMC:   mmc@fff000: 0, mmc@1100000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
mbox: Header response code invalid
bcm2835: Could not query MAC address
Net:   No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot:  0
U-Boot>

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

> Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
>> So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
>> 
> 
> Yes :-) See attached log file.

Really strange that in your case U-Boot seems to come up nicely and outputs something on the debug UART. Here definitely not. And the only difference in the rpi boot loader log outputs I could spot between yours and mine is:

— cut here —
--- uboot2.log	2024-01-19 17:36:18.099674743 +0100
+++ uboot1.log	2024-01-19 17:33:06.794258533 +0100
@@ -1,13 +1,13 @@
-RPi: BOOTSYS release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40
-BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 boardrev d04170 stc 930201
+RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
+BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede boardrev c04170 stc 815886
 AON_RESET: 00000003 PM_RSTS 00001000
 RP1_BOOT chip ID: 0x20001927
 PM_RSTS: 0x00001000
 part 00000000 reset_info 00000000
 PMIC reset-event 00000000 rtc 00000000 alarm 00000000 enabled 0
 uSD voltage 3.3V
-Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 4267
-DDR 4267 1 0 64 152
+Initialising SDRAM 'Samsung' 16Gb x2 total-size: 32 Gbit 4267
+DDR 4267 1 0 32 152
 RP1_BOOT chip ID: 0x20001927
 
 RP1_BOOT chip ID: 0x20001927
@@ -17,18 +17,17 @@
 PCIe scan 00001de4:00000001
 RP1_CHIP_INFO 20001927
 
-RPi: BOOTLOADER release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40
-BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 boardrev d04170 stc 3949421
+RPi: BOOTLOADER release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
+BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede boardrev c04170 stc 3726990
 AON_RESET: 00000003 PM_RSTS 00001000
-M.2 PCIe HAT not detected.
 usb_pd_init status 1
 Boot mode: SD (01) order f4
 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
-OCR c0ff8000 [310]
-CID: 00035344534536344780519441cb0123
-CSD: 400e00325b590001dbd37f800a404000
-SD: bus-width: 4 spec: 2 SCR: 0x02458443 0x00000000
+OCR c0ff8000 [118]
+CID: 00035344534e33324780fa570bda0169
+CSD: 400e00325b590000edb07f800a400000
+SD: bus-width: 4 spec: 2 SCR: 0x02358483 0x00000000
 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
 MBR: 0x00002000,  131072 type: 0x0c
 MBR: 0x00022000, 1024000 type: 0x82
@@ -39,7 +38,6 @@
 rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
 FAT16 clusters 32695
 [sdcard] autoboot.txt not found
-Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0
 Trying partition: 0
 type: 16 lba: 8192 'mkfs.fat' '  V       ^ ' clusters 32695 (4)
 rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
@@ -52,6 +50,7 @@
 Read bcm2712-rpi-5-b.dtb bytes    79357 hnd 0x139f
 dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
+PM_RSTS 00001000
 Selecting USB low current limit
 
 NOTICE:  BL31: v2.6(release):v2.6-239-g2a9ede0bd
— cut here —

So lets see if after you updated to a more recent rpi eeprom U-boot is still able to boot…

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 19.01.2024 um 17:53 schrieb Jens Maus <mail@jens-maus.de>:
> 
>> Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>> 
>>> So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
>>> 
>> 
>> Yes :-) See attached log file.
> 
> Really strange that in your case U-Boot seems to come up nicely and outputs something on the debug UART. Here definitely not. And the only difference in the rpi boot loader log outputs I could spot between yours and mine is:

Replying to myself after having analysed this a bit further this evening...

> […]
> 
> So lets see if after you updated to a more recent rpi eeprom U-boot is still able to boot…

I actually do have some good and bad news:

1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.

2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.

So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.

So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.

Best regards,
jens

[1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Stefan Wahren]

Hi Jens,

Am 19.01.24 um 22:26 schrieb Jens Maus:
> Hi,
>
>> Am 19.01.2024 um 17:53 schrieb Jens Maus <mail@jens-maus.de>:
>>
>>> Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>>>
>>>> So you say with your own u-boot.bin you see serial U-Boot output after that „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART on the GPIO header?
>>>>
>>> Yes :-) See attached log file.
>> Really strange that in your case U-Boot seems to come up nicely and outputs something on the debug UART. Here definitely not. And the only difference in the rpi boot loader log outputs I could spot between yours and mine is:
> Replying to myself after having analysed this a bit further this evening...
>
>> […]
>>
>> So lets see if after you updated to a more recent rpi eeprom U-boot is still able to boot…
> I actually do have some good and bad news:
>
> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
>
> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
>
> So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
>
> So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
thanks for your work, but i think you are wasting your time. The
rpi-eeprom release 2024/01/15 seems to be broken [1]

:-(

[1] - https://github.com/raspberrypi/rpi-eeprom/issues/523

>
> Best regards,
> jens
>
> [1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst@gmx.net>:
> 
> Am 19.01.24 um 22:26 schrieb Jens Maus:
>> I actually do have some good and bad news:
>> 
>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
>> 
>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
>> 
>> So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
>> 
>> So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
> thanks for your work, but i think you are wasting your time. The
> rpi-eeprom release 2024/01/15 seems to be broken [1]
> 
> :-(

Thanks for that info. However, I also tested older eeprom versions to identify when the issue that u-boot cannot boot a rpi5 started to appear. And I am afraid, it already starts with version 2023-11-20 right after the 2023-10-30 which currently seems to work fine with Ivan’s patches. Looking at the release notes of rpi-eeprom [1] one can see the following entries:

— cut here —
2023-11-20: Auto-detect support for PCIe expansion HAT (default + latest)

    • Add autodetect support for PCIe expansion HATs
    • Add PCIE_PROBE=1 to the EEPROM config for custom PCIe exapansion designs that do not support the upcoming HAT spec. This gives similar behaviour to CM4 where PCIe x1 is enumerated to discover NVMe devices.
    • Fix loading of multiple initramfs images that are not 32-bit aligned sizes raspberrypi/firmware#1843
    • Kernel load performance improvement - remove a memcpy
— cut here — 

So as I stated earlier, one probable catch for the u-boot patches here might be the mentioned PCIe changes with the rpi-eeprom 2023-11-20 version. Or it might be related to the „kernel load performance improvements“ mentioned?!?

For now I am of course using the 2023-10-30 rpi-eeprom version and so far it works flawlessly with Ivan’s u-boot patches. Still I hope Ivan or someone else can have a closer look why with the 2023-11-20 version of rpi-eeprom u-boot immediately stops working at all.

best regards,
jens

[1] https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-notes.md
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Stefan Wahren]

Hi,

Am 20.01.24 um 10:48 schrieb Jens Maus:
> Hi,
>
>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst@gmx.net>:
>>
>> Am 19.01.24 um 22:26 schrieb Jens Maus:
>>> I actually do have some good and bad news:
>>>
>>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
>>>
>>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
>>>
>>> So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
>>>
>>> So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
>> thanks for your work, but i think you are wasting your time. The
>> rpi-eeprom release 2024/01/15 seems to be broken [1]
>>
>> :-(
> Thanks for that info. However, I also tested older eeprom versions to identify when the issue that u-boot cannot boot a rpi5 started to appear. And I am afraid, it already starts with version 2023-11-20 right after the 2023-10-30 which currently seems to work fine with Ivan’s patches. Looking at the release notes of rpi-eeprom [1] one can see the following entries:
sorry, i got it wrong. I thought only 2024-01-15 is affected.
Unfortunately i'm not a U-Boot developer and i also don't have a RPi 5.
So i only can give some (hopefully) smart advices :-)

One idea would be to enable early debug in U-Boot (no idea how to
achieve this). I assume U-Boot crashes before it's able to print the
first line, but it's hard to believe it crashes at the very first
instruction of U-Boot. So with some luck we should be able to narrow
done the cause.

Another point would be to open an Github issue on rpi-eeprom and ask
them for advice, why 2023-11-20 stops to work in our case. Sure they
don't want to support U-Boot, but they are also interested in Linux
Mainline support.

Best regards
>
> — cut here —
> 2023-11-20: Auto-detect support for PCIe expansion HAT (default + latest)
>
>      • Add autodetect support for PCIe expansion HATs
>      • Add PCIE_PROBE=1 to the EEPROM config for custom PCIe exapansion designs that do not support the upcoming HAT spec. This gives similar behaviour to CM4 where PCIe x1 is enumerated to discover NVMe devices.
>      • Fix loading of multiple initramfs images that are not 32-bit aligned sizes raspberrypi/firmware#1843
>      • Kernel load performance improvement - remove a memcpy
> — cut here —
>
> So as I stated earlier, one probable catch for the u-boot patches here might be the mentioned PCIe changes with the rpi-eeprom 2023-11-20 version. Or it might be related to the „kernel load performance improvements“ mentioned?!?
>
> For now I am of course using the 2023-10-30 rpi-eeprom version and so far it works flawlessly with Ivan’s u-boot patches. Still I hope Ivan or someone else can have a closer look why with the 2023-11-20 version of rpi-eeprom u-boot immediately stops working at all.
>
> best regards,
> jens
>
> [1] https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-notes.md

Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

> On 20 Jan 2024, at 12:50, Stefan Wahren <wahrenst@gmx.net> wrote:
> 
> Hi,
> 
> Am 20.01.24 um 10:48 schrieb Jens Maus:
>> Hi,
>> 
>>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst@gmx.net>:
>>> 
>>> Am 19.01.24 um 22:26 schrieb Jens Maus:
>>>> I actually do have some good and bad news:
>>>> 
>>>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
>>>> 
>>>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
>>>> 
> 
> One idea would be to enable early debug in U-Boot (no idea how to
> achieve this). I assume U-Boot crashes before it's able to print the
> first line, but it's hard to believe it crashes at the very first
> instruction of U-Boot. So with some luck we should be able to narrow
> done the cause.

I was able to enable early debug UART in U-Boot and I will try to
find what is happening, once I get some free cycles.

Regards,
Ivan

Re: Re: [PATCH v4 0/6] rpi5: initial support

[Ivan T. Ivanov]

Hi,

On 01-22 13:57, Ivan T. Ivanov wrote:
> > Am 20.01.24 um 10:48 schrieb Jens Maus:
> >> Hi,
> >> 
> >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst@gmx.net>:
> >>> 
> >>> Am 19.01.24 um 22:26 schrieb Jens Maus:
> >>>> I actually do have some good and bad news:
> >>>> 
> >>>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
> >>>> 
> >>>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
> >>>> 
> > 
> > One idea would be to enable early debug in U-Boot (no idea how to
> > achieve this). I assume U-Boot crashes before it's able to print the
> > first line, but it's hard to believe it crashes at the very first
> > instruction of U-Boot. So with some luck we should be able to narrow
> > done the cause.
> 
> I was able to enable early debug UART in U-Boot and I will try to
> find what is happening, once I get some free cycles.

Ok, this was relatively easy to find :-)

New versions of EEPROM firmware change “kernel”/U-Boot load address 
from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is
hardcoded to 0x80000 code run through the fields. 

Hopefully simple patch like bellow make it work fine in older and
newer EEPROM firmware versions.

Regards,
Ivan  

diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 11ede9435d..ce64f9554f 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_BCM283X=y
 CONFIG_TEXT_BASE=0x00080000
+CONFIG_POSITION_INDEPENDENT=y

Re: [PATCH v4 0/6] rpi5: initial support

[Mark Kettenis]

> Date: Mon, 22 Jan 2024 16:16:34 +0200
> From: "Ivan T. Ivanov" <iivanov@suse.de>
> 
> Hi,
> 
> On 01-22 13:57, Ivan T. Ivanov wrote:
> > > Am 20.01.24 um 10:48 schrieb Jens Maus:
> > >> Hi,
> > >> 
> > >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst@gmx.net>:
> > >>> 
> > >>> Am 19.01.24 um 22:26 schrieb Jens Maus:
> > >>>> I actually do have some good and bad news:
> > >>>> 
> > >>>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
> > >>>> 
> > >>>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
> > >>>> 
> > > 
> > > One idea would be to enable early debug in U-Boot (no idea how to
> > > achieve this). I assume U-Boot crashes before it's able to print the
> > > first line, but it's hard to believe it crashes at the very first
> > > instruction of U-Boot. So with some luck we should be able to narrow
> > > done the cause.
> > 
> > I was able to enable early debug UART in U-Boot and I will try to
> > find what is happening, once I get some free cycles.
> 
> Ok, this was relatively easy to find :-)
> 
> New versions of EEPROM firmware change “kernel”/U-Boot load address 
> from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is
> hardcoded to 0x80000 code run through the fields. 
> 
> Hopefully simple patch like bellow make it work fine in older and
> newer EEPROM firmware versions.
> 
> Regards,
> Ivan  
> 
> diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> index 11ede9435d..ce64f9554f 100644
> --- a/configs/rpi_arm64_defconfig
> +++ b/configs/rpi_arm64_defconfig
> @@ -1,6 +1,7 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_BCM283X=y
>  CONFIG_TEXT_BASE=0x00080000
> +CONFIG_POSITION_INDEPENDENT=y

Not sure if it really matters, but for the Apple M1 config I set
CONFIG_TEXT_BASE to 0x00000000 (zero).

Re: [PATCH v4 0/6] rpi5: initial support

[Tom Rini]

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

On Mon, Jan 22, 2024 at 03:30:00PM +0100, Mark Kettenis wrote:
> > Date: Mon, 22 Jan 2024 16:16:34 +0200
> > From: "Ivan T. Ivanov" <iivanov@suse.de>
> > 
> > Hi,
> > 
> > On 01-22 13:57, Ivan T. Ivanov wrote:
> > > > Am 20.01.24 um 10:48 schrieb Jens Maus:
> > > >> Hi,
> > > >> 
> > > >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst@gmx.net>:
> > > >>> 
> > > >>> Am 19.01.24 um 22:26 schrieb Jens Maus:
> > > >>>> I actually do have some good and bad news:
> > > >>>> 
> > > >>>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
> > > >>>> 
> > > >>>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
> > > >>>> 
> > > > 
> > > > One idea would be to enable early debug in U-Boot (no idea how to
> > > > achieve this). I assume U-Boot crashes before it's able to print the
> > > > first line, but it's hard to believe it crashes at the very first
> > > > instruction of U-Boot. So with some luck we should be able to narrow
> > > > done the cause.
> > > 
> > > I was able to enable early debug UART in U-Boot and I will try to
> > > find what is happening, once I get some free cycles.
> > 
> > Ok, this was relatively easy to find :-)
> > 
> > New versions of EEPROM firmware change “kernel”/U-Boot load address 
> > from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is
> > hardcoded to 0x80000 code run through the fields. 
> > 
> > Hopefully simple patch like bellow make it work fine in older and
> > newer EEPROM firmware versions.
> > 
> > Regards,
> > Ivan  
> > 
> > diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> > index 11ede9435d..ce64f9554f 100644
> > --- a/configs/rpi_arm64_defconfig
> > +++ b/configs/rpi_arm64_defconfig
> > @@ -1,6 +1,7 @@
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_BCM283X=y
> >  CONFIG_TEXT_BASE=0x00080000
> > +CONFIG_POSITION_INDEPENDENT=y
> 
> Not sure if it really matters, but for the Apple M1 config I set
> CONFIG_TEXT_BASE to 0x00000000 (zero).

It shouldn't matter. 0x0 is the default for TEXT_BASE in this case, but
also a number of platforms set it to something else seemingly valid,
but could I suspect still drop the setting as it should not matter at
run time.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v4 0/6] rpi5: initial support

[Jens Maus]

Hi,

> Am 22.01.2024 um 15:16 schrieb Ivan T. Ivanov <iivanov@suse.de>:
> 
> On 01-22 13:57, Ivan T. Ivanov wrote:
>> I was able to enable early debug UART in U-Boot and I will try to
>> find what is happening, once I get some free cycles.
> 
> Ok, this was relatively easy to find :-)
> 
> New versions of EEPROM firmware change “kernel”/U-Boot load address 
> from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is
> hardcoded to 0x80000 code run through the fields. 
> 
> Hopefully simple patch like bellow make it work fine in older and
> newer EEPROM firmware versions.

Thanks for this tiny but important fix on your patchset. In fact, I was able to verify that now with your latest v5 patchset for the initial rpi5 support even newer/latest rpi-eeprom versions work as expected and u-boot is chain loaded by the rpi boot loader.

So thanks again for that fix and I am looking forward to seeing your patchset integrated and hopefully also maintained in future so that USB boot and GPIO support will be added in the near future.

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

Re: [PATCH v4 0/6] rpi5: initial support

[Stefan Wahren]

Hi Jens,

Am 23.01.24 um 12:11 schrieb Jens Maus:
> Hi,
>
>> Am 22.01.2024 um 15:16 schrieb Ivan T. Ivanov <iivanov@suse.de>:
>>
>> On 01-22 13:57, Ivan T. Ivanov wrote:
>>> I was able to enable early debug UART in U-Boot and I will try to
>>> find what is happening, once I get some free cycles.
>> Ok, this was relatively easy to find :-)
>>
>> New versions of EEPROM firmware change “kernel”/U-Boot load address
>> from 0x80000 to 0x200000. And because on RPi’s CONFIG_TEXT_BASE is
>> hardcoded to 0x80000 code run through the fields.
>>
>> Hopefully simple patch like bellow make it work fine in older and
>> newer EEPROM firmware versions.
> Thanks for this tiny but important fix on your patchset. In fact, I was able to verify that now with your latest v5 patchset for the initial rpi5 support even newer/latest rpi-eeprom versions work as expected and u-boot is chain loaded by the rpi boot loader.
thank you for testing. Could you please give your Tested-by to v5 or at
least parts of them?
>
> So thanks again for that fix and I am looking forward to seeing your patchset integrated and hopefully also maintained in future so that USB boot and GPIO support will be added in the near future.
>
> regards,
> jens