[PATCH v3 0/7] rpi5: initial support
Hi,
These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much.
Serial console and reset are also functional.
Hopefully this will help others add missing pieces more easily.
Happy hacking!
Regards, Ivan
[1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1R+L24WBgpo-iP1y...
Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses
Ivan T. Ivanov (5): rpi5: Use devicetree to retrieve board revision bcm2835: brcm,bcm2708-fb device is using r5g6b5 format mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver pci: pcie-brcmstb: Add bcm2712 PCIe controller support
arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 81 ++++++++-- board/raspberrypi/rpi/rpi.c | 22 ++- configs/rpi_arm64_defconfig | 1 + drivers/mmc/bcmstb_sdhci.c | 173 ++++++++++++++++++++- drivers/pci/pcie_brcmstb.c | 23 ++- drivers/video/bcm2835.c | 10 +- 11 files changed, 296 insertions(+), 31 deletions(-)
From: Dmitry Malkin dmitry@bedrocksystems.com
includes: * 1GB of RAM (from 4GB or 8GB total) * VPU memory interface * AXI ranges (main peripherals)
Signed-off-by: Dmitry Malkin dmitry@bedrocksystems.com Signed-off-by: Ivan T. Ivanov iivanov@suse.de --- arch/arm/mach-bcm283x/init.c | 38 +++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c index 7265faf6ce..af23b9711a 100644 --- a/arch/arm/mach-bcm283x/init.c +++ b/arch/arm/mach-bcm283x/init.c @@ -19,7 +19,7 @@ #ifdef CONFIG_ARM64 #include <asm/armv8/mmu.h>
-#define MEM_MAP_MAX_ENTRIES (4) +#define MEM_MAP_MAX_ENTRIES (5)
static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = { { @@ -68,6 +68,41 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = { } };
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = { + { + .virt = 0x00000000UL, + .phys = 0x00000000UL, + .size = 0x3f800000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | + PTE_BLOCK_INNER_SHARE + }, { + .virt = 0x3f800000UL, + .phys = 0x3f800000UL, + .size = 0x00800000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | + PTE_BLOCK_NON_SHARE | + PTE_BLOCK_PXN | PTE_BLOCK_UXN + }, { + /* Beginning of AXI bus where uSD controller lives */ + .virt = 0x1000000000UL, + .phys = 0x1000000000UL, + .size = 0x0002000000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | + PTE_BLOCK_NON_SHARE | + PTE_BLOCK_PXN | PTE_BLOCK_UXN + }, { + .virt = 0x107c000000UL, + .phys = 0x107c000000UL, + .size = 0x0004000000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | + PTE_BLOCK_NON_SHARE | + PTE_BLOCK_PXN | PTE_BLOCK_UXN + }, { + /* List terminator */ + 0, + } +}; + struct mm_region *mem_map = bcm283x_mem_map;
/* @@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = { { .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map}, { .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map}, { .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map}, + { .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map}, { }, };
Hi Ivan,
Am 18.12.23 um 22:03 schrieb Ivan T. Ivanov:
From: Dmitry Malkin dmitry@bedrocksystems.com
includes:
- 1GB of RAM (from 4GB or 8GB total)
- VPU memory interface
- AXI ranges (main peripherals)
my experience with U-Boot is little, but i do my best to give you some feedback.
Signed-off-by: Dmitry Malkin dmitry@bedrocksystems.com Signed-off-by: Ivan T. Ivanov iivanov@suse.de
arch/arm/mach-bcm283x/init.c | 38 +++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c index 7265faf6ce..af23b9711a 100644 --- a/arch/arm/mach-bcm283x/init.c +++ b/arch/arm/mach-bcm283x/init.c @@ -19,7 +19,7 @@ #ifdef CONFIG_ARM64 #include <asm/armv8/mmu.h>
-#define MEM_MAP_MAX_ENTRIES (4) +#define MEM_MAP_MAX_ENTRIES (5)
static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = { { @@ -68,6 +68,41 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = { } };
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
- {
in comparison to mach-imx/imx9/soc.c most of the memory maps doesn't have a describing comment.
.virt = 0x00000000UL,.phys = 0x00000000UL,.size = 0x3f800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |PTE_BLOCK_INNER_SHARE- }, {
.virt = 0x3f800000UL,.phys = 0x3f800000UL,.size = 0x00800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
/* Beginning of AXI bus where uSD controller lives */.virt = 0x1000000000UL,.phys = 0x1000000000UL,.size = 0x0002000000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
.virt = 0x107c000000UL,.phys = 0x107c000000UL,.size = 0x0004000000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
/* List terminator */0,- }
+};
struct mm_region *mem_map = bcm283x_mem_map;
/*
@@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = { { .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map}, { .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map}, { .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map},
- { .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map}, { }, };
Looking at the complete file, i saw the function print_cpuinfo(). Personally i think it's wrong to print BCM283x in case of a RPI 4 or 5.
On 12-18 23:25, Stefan Wahren wrote:
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
- {
in comparison to mach-imx/imx9/soc.c most of the memory maps doesn't have a describing comment.
Yep, I have thinking to add more comments, but decided to not modify too much patch from Dmitry. On the other side there is not much excitement stuff here.
.virt = 0x00000000UL,.phys = 0x00000000UL,.size = 0x3f800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |PTE_BLOCK_INNER_SHARE- }, {
.virt = 0x3f800000UL,.phys = 0x3f800000UL,.size = 0x00800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
/* Beginning of AXI bus where uSD controller lives */.virt = 0x1000000000UL,.phys = 0x1000000000UL,.size = 0x0002000000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
.virt = 0x107c000000UL,.phys = 0x107c000000UL,.size = 0x0004000000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
/* List terminator */0,- }
+};
struct mm_region *mem_map = bcm283x_mem_map;
/*
@@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = { { .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map}, { .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map}, { .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map},
- { .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map}, { }, };
Looking at the complete file, i saw the function print_cpuinfo(). Personally i think it's wrong to print BCM283x in case of a RPI 4 or 5.
CONFIG_DISPLAY_CPUINFO is not set for RPi's, but I suppose this could be nice aesthetic enhancement.
Thanks, Ivan
Hi Ivan,
On Mon, 18 Dec 2023 at 14:04, Ivan T. Ivanov iivanov@suse.de wrote:
From: Dmitry Malkin dmitry@bedrocksystems.com
includes:
- 1GB of RAM (from 4GB or 8GB total)
- VPU memory interface
- AXI ranges (main peripherals)
Signed-off-by: Dmitry Malkin dmitry@bedrocksystems.com Signed-off-by: Ivan T. Ivanov iivanov@suse.de
arch/arm/mach-bcm283x/init.c | 38 +++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c index 7265faf6ce..af23b9711a 100644 --- a/arch/arm/mach-bcm283x/init.c +++ b/arch/arm/mach-bcm283x/init.c @@ -19,7 +19,7 @@ #ifdef CONFIG_ARM64 #include <asm/armv8/mmu.h>
-#define MEM_MAP_MAX_ENTRIES (4) +#define MEM_MAP_MAX_ENTRIES (5)
static struct mm_region bcm283x_mem_map[MEM_MAP_MAX_ENTRIES] = { { @@ -68,6 +68,41 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = { } };
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
Would it be possible to read these from the devicetree?
{.virt = 0x00000000UL,.phys = 0x00000000UL,.size = 0x3f800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |PTE_BLOCK_INNER_SHARE}, {
Regards, Simon
On 12-19 21:45, Simon Glass wrote:
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
Would it be possible to read these from the devicetree?
If there is a devicetree passed, yes, it will be possible. I have not done this just because I can't test all possible combinations on older platforms. But for IO regions I am not sure how feasible this is.
{.virt = 0x00000000UL,.phys = 0x00000000UL,.size = 0x3f800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |PTE_BLOCK_INNER_SHARE}, {
Regards, Ivan
Hi,
On 12-18 23:03, Ivan T. Ivanov wrote:
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
- {
.virt = 0x00000000UL,.phys = 0x00000000UL,.size = 0x3f800000UL,
Something that I realized just now. This memory map is valid only if HDMI cable is plugged in. Otherwise size of this section is 0x3fc00000. This is how it is populated by the embedded bootloaader.
Which I am reading as: bootloader do not expose video framebuffer if HDMI cable is not plugged in at boot time.
With current map, board hang at boot if HDMI is not plugged in.
If I make first region with size 0x3Fc00000 and remove below dedicated framebuffer region, device boots with and without HDMI cable plugged in.
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |PTE_BLOCK_INNER_SHARE- }, {
.virt = 0x3f800000UL,.phys = 0x3f800000UL,.size = 0x00800000UL,.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |PTE_BLOCK_NON_SHARE |PTE_BLOCK_PXN | PTE_BLOCK_UXN- }, {
Sorry that I missed it the first time.
Regards, Ivan
From: Dmitry Malkin dmitry@bedrocksystems.com
MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets. Find them via devicetree blob passed by bootloader.
Signed-off-by: Dmitry Malkin dmitry@bedrocksystems.com Signed-off-by: Ivan T. Ivanov iivanov@suse.de --- arch/arm/mach-bcm283x/include/mach/base.h | 5 ++- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 43 ++++++++++++++++++---- 6 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h b/arch/arm/mach-bcm283x/include/mach/base.h index 4ccaf69693..6de99e7ea1 100644 --- a/arch/arm/mach-bcm283x/include/mach/base.h +++ b/arch/arm/mach-bcm283x/include/mach/base.h @@ -6,7 +6,10 @@ #ifndef _BCM283x_BASE_H_ #define _BCM283x_BASE_H_
-extern unsigned long rpi_bcm283x_base; +extern unsigned long rpi_mbox_base; +extern unsigned long rpi_timer_base; +extern unsigned long rpi_sdhci_base; +extern unsigned long rpi_wdog_base;
#ifdef CONFIG_ARMV7_LPAE #ifdef CONFIG_TARGET_RPI_4_32B diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h b/arch/arm/mach-bcm283x/include/mach/mbox.h index 490664f878..35d4e2f075 100644 --- a/arch/arm/mach-bcm283x/include/mach/mbox.h +++ b/arch/arm/mach-bcm283x/include/mach/mbox.h @@ -38,8 +38,7 @@
/* Raw mailbox HW */
-#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \ - rpi_bcm283x_base + 0x0000b880; }) +#define BCM2835_MBOX_PHYSADDR rpi_mbox_base
struct bcm2835_mbox_regs { u32 read; diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h b/arch/arm/mach-bcm283x/include/mach/sdhci.h index 7323690687..e837c679c4 100644 --- a/arch/arm/mach-bcm283x/include/mach/sdhci.h +++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h @@ -8,8 +8,7 @@
#include <asm/arch/base.h>
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \ - rpi_bcm283x_base + 0x00300000; }) +#define BCM2835_SDHCI_PHYSADDR rpi_sdhci_base
int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h b/arch/arm/mach-bcm283x/include/mach/timer.h index 5567dbd7f3..60500a256d 100644 --- a/arch/arm/mach-bcm283x/include/mach/timer.h +++ b/arch/arm/mach-bcm283x/include/mach/timer.h @@ -11,8 +11,7 @@ #include <linux/bug.h> #endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \ - rpi_bcm283x_base + 0x00003000; }) +#define BCM2835_TIMER_PHYSADDR rpi_timer_base
#define BCM2835_TIMER_CS_M3 (1 << 3) #define BCM2835_TIMER_CS_M2 (1 << 2) diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h b/arch/arm/mach-bcm283x/include/mach/wdog.h index 9942666720..b950560674 100644 --- a/arch/arm/mach-bcm283x/include/mach/wdog.h +++ b/arch/arm/mach-bcm283x/include/mach/wdog.h @@ -8,8 +8,7 @@
#include <asm/arch/base.h>
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \ - rpi_bcm283x_base + 0x00100000; }) +#define BCM2835_WDOG_PHYSADDR rpi_wdog_base
struct bcm2835_wdog_regs { u32 unknown0[7]; diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c index af23b9711a..1c5c748484 100644 --- a/arch/arm/mach-bcm283x/init.c +++ b/arch/arm/mach-bcm283x/init.c @@ -151,7 +151,11 @@ static void rpi_update_mem_map(void) static void rpi_update_mem_map(void) {} #endif
-unsigned long rpi_bcm283x_base = 0x3f000000; +/* Default bcm283x devices addresses */ +unsigned long rpi_mbox_base = 0x3f00b880; +unsigned long rpi_sdhci_base = 0x3f300000; +unsigned long rpi_wdog_base = 0x3f100000; +unsigned long rpi_timer_base = 0x3f003000;
int arch_cpu_init(void) { @@ -162,22 +166,45 @@ int arch_cpu_init(void)
int mach_cpu_init(void) { - int ret, soc_offset; + int ret, soc, offset; u64 io_base, size;
rpi_update_mem_map();
/* Get IO base from device tree */ - soc_offset = fdt_path_offset(gd->fdt_blob, "/soc"); - if (soc_offset < 0) - return soc_offset; + soc = fdt_path_offset(gd->fdt_blob, "/soc"); + if (soc < 0) + return soc;
- ret = fdt_read_range((void *)gd->fdt_blob, soc_offset, 0, NULL, - &io_base, &size); + ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL, + &io_base, &size); if (ret) return ret;
- rpi_bcm283x_base = io_base; + rpi_mbox_base = io_base + 0x00b880; + rpi_sdhci_base = io_base + 0x300000; + rpi_wdog_base = io_base + 0x100000; + rpi_timer_base = io_base + 0x003000; + + offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc, + "brcm,bcm2835-mbox"); + if (offset > soc) + rpi_mbox_base = fdt_get_base_address(gd->fdt_blob, offset); + + offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc, + "brcm,bcm2835-sdhci"); + if (offset > soc) + rpi_sdhci_base = fdt_get_base_address(gd->fdt_blob, offset); + + offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc, + "brcm,bcm2835-system-timer"); + if (offset > soc) + rpi_timer_base = fdt_get_base_address(gd->fdt_blob, offset); + + offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc, + "brcm,bcm2712-pm"); + if (offset > soc) + rpi_wdog_base = fdt_get_base_address(gd->fdt_blob, offset);
return 0; }
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
From: Dmitry Malkin dmitry@bedrocksystems.com
MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets. Find them via devicetree blob passed by bootloader.
Signed-off-by: Dmitry Malkin dmitry@bedrocksystems.com Signed-off-by: Ivan T. Ivanov iivanov@suse.de
Reviewed-by: Matthias Brugger mbrugger@suse.com
arch/arm/mach-bcm283x/include/mach/base.h | 5 ++- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 43 ++++++++++++++++++---- 6 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h b/arch/arm/mach-bcm283x/include/mach/base.h index 4ccaf69693..6de99e7ea1 100644 --- a/arch/arm/mach-bcm283x/include/mach/base.h +++ b/arch/arm/mach-bcm283x/include/mach/base.h @@ -6,7 +6,10 @@ #ifndef _BCM283x_BASE_H_ #define _BCM283x_BASE_H_
-extern unsigned long rpi_bcm283x_base; +extern unsigned long rpi_mbox_base; +extern unsigned long rpi_timer_base; +extern unsigned long rpi_sdhci_base; +extern unsigned long rpi_wdog_base;
#ifdef CONFIG_ARMV7_LPAE #ifdef CONFIG_TARGET_RPI_4_32B diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h b/arch/arm/mach-bcm283x/include/mach/mbox.h index 490664f878..35d4e2f075 100644 --- a/arch/arm/mach-bcm283x/include/mach/mbox.h +++ b/arch/arm/mach-bcm283x/include/mach/mbox.h @@ -38,8 +38,7 @@
/* Raw mailbox HW */
-#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
rpi_bcm283x_base + 0x0000b880; })+#define BCM2835_MBOX_PHYSADDR rpi_mbox_base
struct bcm2835_mbox_regs { u32 read; diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h b/arch/arm/mach-bcm283x/include/mach/sdhci.h index 7323690687..e837c679c4 100644 --- a/arch/arm/mach-bcm283x/include/mach/sdhci.h +++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h @@ -8,8 +8,7 @@
#include <asm/arch/base.h>
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
rpi_bcm283x_base + 0x00300000; })+#define BCM2835_SDHCI_PHYSADDR rpi_sdhci_base
int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h b/arch/arm/mach-bcm283x/include/mach/timer.h index 5567dbd7f3..60500a256d 100644 --- a/arch/arm/mach-bcm283x/include/mach/timer.h +++ b/arch/arm/mach-bcm283x/include/mach/timer.h @@ -11,8 +11,7 @@ #include <linux/bug.h> #endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
rpi_bcm283x_base + 0x00003000; })+#define BCM2835_TIMER_PHYSADDR rpi_timer_base
#define BCM2835_TIMER_CS_M3 (1 << 3) #define BCM2835_TIMER_CS_M2 (1 << 2) diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h b/arch/arm/mach-bcm283x/include/mach/wdog.h index 9942666720..b950560674 100644 --- a/arch/arm/mach-bcm283x/include/mach/wdog.h +++ b/arch/arm/mach-bcm283x/include/mach/wdog.h @@ -8,8 +8,7 @@
#include <asm/arch/base.h>
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
rpi_bcm283x_base + 0x00100000; })+#define BCM2835_WDOG_PHYSADDR rpi_wdog_base
struct bcm2835_wdog_regs { u32 unknown0[7]; diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c index af23b9711a..1c5c748484 100644 --- a/arch/arm/mach-bcm283x/init.c +++ b/arch/arm/mach-bcm283x/init.c @@ -151,7 +151,11 @@ static void rpi_update_mem_map(void) static void rpi_update_mem_map(void) {} #endif
-unsigned long rpi_bcm283x_base = 0x3f000000; +/* Default bcm283x devices addresses */ +unsigned long rpi_mbox_base = 0x3f00b880; +unsigned long rpi_sdhci_base = 0x3f300000; +unsigned long rpi_wdog_base = 0x3f100000; +unsigned long rpi_timer_base = 0x3f003000;
int arch_cpu_init(void) { @@ -162,22 +166,45 @@ int arch_cpu_init(void)
int mach_cpu_init(void) {
- int ret, soc_offset;
int ret, soc, offset; u64 io_base, size;
rpi_update_mem_map();
/* Get IO base from device tree */
- soc_offset = fdt_path_offset(gd->fdt_blob, "/soc");
- if (soc_offset < 0)
return soc_offset;
- soc = fdt_path_offset(gd->fdt_blob, "/soc");
- if (soc < 0)
return soc;
- ret = fdt_read_range((void *)gd->fdt_blob, soc_offset, 0, NULL,
&io_base, &size);
- ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL,
&io_base, &size);
- 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; }
Firmware on RPi5 return error on board revision query through firmware interface, but on the other hand it fills "linux,revision" in "system" node, so use it to detect board revision.
system { linux,revision = <0xc04170>; linux,serial = <0x6cf44e80 0x3c533ede>; };
Signed-off-by: Ivan T. Ivanov iivanov@suse.de --- board/raspberrypi/rpi/rpi.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index cd823ad746..2851ebc985 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -171,6 +171,11 @@ static const struct rpi_model rpi_models_new_scheme[] = { DTB_DIR "bcm2711-rpi-cm4.dtb", true, }, + [0x17] = { + "5 Model B", + DTB_DIR "bcm2712-rpi-5-b.dtb", + true, + }, };
static const struct rpi_model rpi_models_old_scheme[] = { @@ -429,15 +434,27 @@ static void get_board_revision(void) int ret; const struct rpi_model *models; uint32_t models_count; + ofnode node;
BCM2835_MBOX_INIT_HDR(msg); BCM2835_MBOX_INIT_TAG(&msg->get_board_rev, GET_BOARD_REV);
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr); if (ret) { - printf("bcm2835: Could not query board revision\n"); /* Ignore error; not critical */ - return; + node = ofnode_path("/system"); + if (!ofnode_valid(node)) { + printf("bcm2835: Could not find /system node\n"); + return; + } + + ret = ofnode_read_u32(node, "linux,revision", &revision); + if (ret) { + printf("bcm2835: Could not find linux,revision\n"); + return; + } + } else { + revision = msg->get_board_rev.body.resp.rev; }
/* @@ -451,7 +468,6 @@ static void get_board_revision(void) * http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=98367&start=2... * 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;
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
Firmware on RPi5 return error on board revision query through firmware interface, but on the other hand it fills "linux,revision" in "system" node, so use it to detect board revision.
system { linux,revision = <0xc04170>; linux,serial = <0x6cf44e80 0x3c533ede>; };
Signed-off-by: Ivan T. Ivanov iivanov@suse.de
Reviewed-by: Matthias Brugger mbrugger@suse.com
board/raspberrypi/rpi/rpi.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index cd823ad746..2851ebc985 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -171,6 +171,11 @@ static const struct rpi_model rpi_models_new_scheme[] = { DTB_DIR "bcm2711-rpi-cm4.dtb", true, },
[0x17] = {
"5 Model B",DTB_DIR "bcm2712-rpi-5-b.dtb",true,}, };
static const struct rpi_model rpi_models_old_scheme[] = {
@@ -429,15 +434,27 @@ static void get_board_revision(void) int ret; const struct rpi_model *models; uint32_t models_count;
ofnode node;
BCM2835_MBOX_INIT_HDR(msg); BCM2835_MBOX_INIT_TAG(&msg->get_board_rev, GET_BOARD_REV);
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr); if (ret) {
printf("bcm2835: Could not query board revision\n");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=2... * 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;
brcm,bcm2708-fb device provided by firmware on RPi5 uses 16 bits per pixel. Update driver to properly handle this.
Signed-off-by: Ivan T. Ivanov iivanov@suse.de --- drivers/video/bcm2835.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c index 14942526f1..245c958b6e 100644 --- a/drivers/video/bcm2835.c +++ b/drivers/video/bcm2835.c @@ -43,7 +43,7 @@ static int bcm2835_video_probe(struct udevice *dev)
uc_priv->xsize = w; uc_priv->ysize = h; - uc_priv->bpix = VIDEO_BPP32; + uc_priv->bpix = dev_get_driver_data(dev); plat->base = fb_base; plat->size = fb_size;
@@ -51,11 +51,11 @@ static int bcm2835_video_probe(struct udevice *dev) }
static const struct udevice_id bcm2835_video_ids[] = { - { .compatible = "brcm,bcm2835-hdmi" }, - { .compatible = "brcm,bcm2711-hdmi0" }, - { .compatible = "brcm,bcm2708-fb" }, + { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32}, + { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32}, + { .compatible = "brcm,bcm2708-fb", .data = VIDEO_BPP16 }, #if !IS_ENABLED(CONFIG_VIDEO_DT_SIMPLEFB) - { .compatible = "simple-framebuffer" }, + { .compatible = "simple-framebuffer", .data = VIDEO_BPP32}, #endif { } };
Hi Ivan,
Am 18.12.23 um 22:03 schrieb Ivan T. Ivanov:
brcm,bcm2708-fb device provided by firmware on RPi5 uses 16 bits per pixel. Update driver to properly handle this.
Signed-off-by: Ivan T. Ivanov iivanov@suse.de
drivers/video/bcm2835.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c index 14942526f1..245c958b6e 100644 --- a/drivers/video/bcm2835.c +++ b/drivers/video/bcm2835.c @@ -43,7 +43,7 @@ static int bcm2835_video_probe(struct udevice *dev)
uc_priv->xsize = w; uc_priv->ysize = h;
- uc_priv->bpix = VIDEO_BPP32;
- uc_priv->bpix = dev_get_driver_data(dev); plat->base = fb_base; plat->size = fb_size;
@@ -51,11 +51,11 @@ static int bcm2835_video_probe(struct udevice *dev) }
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
- { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2708-fb", .data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for brcm,bcm2708-fb. I think it's hard to explain why we should downgrade the other boards. I would expect some brcm,bcm2712 compatible at least this needs an explanation in the commit message.
#if !IS_ENABLED(CONFIG_VIDEO_DT_SIMPLEFB)
- { .compatible = "simple-framebuffer" },
- { .compatible = "simple-framebuffer", .data = VIDEO_BPP32}, #endif { } };
On 12-18 23:32, Stefan Wahren wrote:
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
- { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2708-fb", .data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for brcm,bcm2708-fb. I think it's hard to explain why we should downgrade the other boards. I would expect some brcm,bcm2712 compatible at least this needs an explanation in the commit message.
If you are confident that this semi device was working before with BPP32 I will try to find better way to handle this. Do you remember which RPi version was this?
Thanks, Ivan
Hi Ivan,
Am 19.12.23 um 09:51 schrieb Ivan T. Ivanov:
On 12-18 23:32, Stefan Wahren wrote:
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
- { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2708-fb", .data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for brcm,bcm2708-fb. I think it's hard to explain why we should downgrade the other boards. I would expect some brcm,bcm2712 compatible at least this needs an explanation in the commit message.
If you are confident that this semi device was working before with BPP32 I will try to find better way to handle this. Do you remember which RPi version was this?
as said before i'm don't have much experience with U-Boot, so i'm not confident. But downgrading the bpp value for an existing setting only to make RPi 5 work, isn't a good approach. It's a hack.
A quick search for the compatible revealed this [1], so it looks like a fallback which applies to all Raspberry Pi boards with a firmware provided DTB.
In case all of them uses 16 bit, i'm fine with this change but then the commit log should mention this. I think these are points which needs to be discussed with the Raspberry Pi guys.
Best regards
[1] - https://lists.denx.de/pipermail/u-boot/2018-July/333476.html
Thanks, Ivan
On 19/12/2023 09:51, Ivan T. Ivanov wrote:
On 12-18 23:32, Stefan Wahren wrote:
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
- { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2708-fb", .data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for brcm,bcm2708-fb. I think it's hard to explain why we should downgrade the other boards. I would expect some brcm,bcm2712 compatible at least this needs an explanation in the commit message.
If you are confident that this semi device was working before with BPP32 I will try to find better way to handle this. Do you remember which RPi version was this?
I think that was RPi1 maybe RPi2 Zero W as well.
Regards, Matthias
On 12-20 09:51, Matthias Brugger wrote:
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
- { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
- { .compatible = "brcm,bcm2708-fb", .data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for brcm,bcm2708-fb. I think it's hard to explain why we should downgrade the other boards. I would expect some brcm,bcm2712 compatible at least this needs an explanation in the commit message.
I think I found better and reliable way to find the right value.
bpp = pitch / width
Which are queried from firmware.
Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1, RPi2 Zero W, RPi5b v1.0.
I think that was RPi1 maybe RPi2 Zero W as well.
For the record: RPi2 Zero W exposes "brcm,bcm2835-hdmi" device.
Regards, Ivan
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" }, { }
On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:
Borrow SD quirks from vendor Linux driver.
"BCM2712 unfortunately carries with it a perennial bug with the SD controller register interface present on previous chips (2711/2709/2708). Accesses must be dword-sized and a read-modify-write cycle to the 32-bit registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and BLOCK_COUNT registers tramples the upper/lower 16 bits of data written. BCM2712 does not seem to need the extreme delay between each write as on previous chips, just the serialisation of writes to these registers in a single 32-bit operation."
Signed-off-by: Ivan T. Ivanov iivanov@suse.de
This is diverging from the Linux sdhci-brcmstb.c driver where no such quirk needs to be carried out, rather the logic for such quirks has been present in sdhci-iproc.c...
Hi,
Am 21.12.23 um 16:13 schrieb Florian Fainelli:
On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:
Borrow SD quirks from vendor Linux driver.
"BCM2712 unfortunately carries with it a perennial bug with the SD controller register interface present on previous chips (2711/2709/2708). Accesses must be dword-sized and a read-modify-write cycle to the 32-bit registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and BLOCK_COUNT registers tramples the upper/lower 16 bits of data written. BCM2712 does not seem to need the extreme delay between each write as on previous chips, just the serialisation of writes to these registers in a single 32-bit operation."
Signed-off-by: Ivan T. Ivanov iivanov@suse.de
This is diverging from the Linux sdhci-brcmstb.c driver where no such quirk needs to be carried out, rather the logic for such quirks has been present in sdhci-iproc.c...
it seems this patch based the downstream kernel changes [1]. I would suggest to use an existing driver which already handle this bug (iproc_sdhci or bcm2835_sdhci).
Does the Rpi 5 still works, if the compatible "brcm,bcm2712-sdhci" is added to mmc/iproc_sdhci.c?
[1] - https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fd...
On 12-21 16:39, Stefan Wahren wrote:
To: Florian Fainelli florian.fainelli@broadcom.com, "Ivan T. Ivanov"
On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:
Borrow SD quirks from vendor Linux driver.
"BCM2712 unfortunately carries with it a perennial bug with the SD controller register interface present on previous chips (2711/2709/2708). Accesses must be dword-sized and a read-modify-write cycle to the 32-bit registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and BLOCK_COUNT registers tramples the upper/lower 16 bits of data written. BCM2712 does not seem to need the extreme delay between each write as on previous chips, just the serialisation of writes to these registers in a single 32-bit operation."
Signed-off-by: Ivan T. Ivanov iivanov@suse.de
This is diverging from the Linux sdhci-brcmstb.c driver where no such quirk needs to be carried out, rather the logic for such quirks has been present in sdhci-iproc.c...
it seems this patch based the downstream kernel changes [1].
Yep.
I would suggest to use an existing driver which already handle this bug (iproc_sdhci or bcm2835_sdhci).
Does the Rpi 5 still works, if the compatible "brcm,bcm2712-sdhci" is added to mmc/iproc_sdhci.c?
No, it is not working :-)
Even after I added shadow variables usage in iproc_readw, which do not have it.
Even after I used hard coded values for "clock-freq-min-max", which are missing in RPi5 device tree.
Even after I added 2712 specific "cfg" space initialization procedure from the brcnstb driver.
On the other hand they are some tuning procedures in iproc driver which I am not sure that are relevant for 2712 controller.
And the diff stat is getting bigger that equivalent for brcmstb driver.
To me it is a bit easier to add 2712 support to brcmstb driver, because it will be easier to follow any vendor Linux driver changes.
It looks like hardware engineers are just making the same mistake when integrating 2712 SDHCI controller as for IPROC controller.
Regards, Ivan
[1] - https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fd...
RPi5 have "brcm,bcm2712-sdhci" controller which is handled by "sdhci-bcmstb" driver, so enable it.
Signed-off-by: Ivan T. Ivanov iivanov@suse.de --- configs/rpi_arm64_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index f9dade18f6..1107fd11de 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -33,6 +33,7 @@ CONFIG_BCM2835_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_MMC_SDHCI_BCMSTB=y CONFIG_BCMGENET=y CONFIG_PCI_BRCMSTB=y CONFIG_PINCTRL=y
PCIe controller have minor register map difference compared to bcm2711 variant. Handle this using device specific register offset.
Signed-off-by: Ivan T. Ivanov iivanov@suse.de --- drivers/pci/pcie_brcmstb.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c index cd45f0bee9..d63e715b2e 100644 --- a/drivers/pci/pcie_brcmstb.c +++ b/drivers/pci/pcie_brcmstb.c @@ -90,7 +90,6 @@ #define PCIE_MEM_WIN0_LIMIT_HI(win) \ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI + ((win) * 8)
-#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204 #define PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
#define PCIE_MSI_INTR2_CLR 0x4508 @@ -131,6 +130,10 @@ #define SSC_STATUS_PLL_LOCK_MASK 0x800 #define SSC_STATUS_PLL_LOCK_SHIFT 11
+struct pcie_cfg_data { + unsigned long hard_debug_offs; +}; + /** * struct brcm_pcie - the PCIe controller state * @base: Base address of memory mapped IO registers of the controller @@ -141,6 +144,7 @@ struct brcm_pcie { void __iomem *base;
+ struct pcie_cfg_data *cfg; int gen; bool ssc; }; @@ -458,7 +462,7 @@ static int brcm_pcie_probe(struct udevice *dev) /* Take the bridge out of reset */ clrbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_INIT_MASK);
- clrbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG, + clrbits_le32(base + pcie->cfg->hard_debug_offs, PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Wait for SerDes to be stable */ @@ -599,7 +603,7 @@ static int brcm_pcie_remove(struct udevice *dev) setbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_PERST_MASK);
/* Turn off SerDes */ - setbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG, + setbits_le32(base + pcie->cfg->hard_debug_offs, PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Shutdown bridge */ @@ -620,6 +624,8 @@ static int brcm_pcie_of_to_plat(struct udevice *dev) if (!pcie->base) return -EINVAL;
+ pcie->cfg = (struct pcie_cfg_data *)dev_get_driver_data(dev); + pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc");
ret = ofnode_read_u32(dn, "max-link-speed", &max_link_speed); @@ -636,8 +642,17 @@ static const struct dm_pci_ops brcm_pcie_ops = { .write_config = brcm_pcie_write_config, };
+static const struct pcie_cfg_data bcm2711_cfg = { + .hard_debug_offs = 0x4204 +}; + +static const struct pcie_cfg_data bcm2712_cfg = { + .hard_debug_offs = 0x4304 +}; + static const struct udevice_id brcm_pcie_ids[] = { - { .compatible = "brcm,bcm2711-pcie" }, + { .compatible = "brcm,bcm2711-pcie", .data = (ulong)&bcm2711_cfg }, + { .compatible = "brcm,bcm2712-pcie", .data = (ulong)&bcm2712_cfg }, { } };
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
PCIe controller have minor register map difference compared to bcm2711 variant. Handle this using device specific register offset.
Signed-off-by: Ivan T. Ivanov iivanov@suse.de
Reviewed-by: Matthias Brugger mbrugger@suse.com
drivers/pci/pcie_brcmstb.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c index cd45f0bee9..d63e715b2e 100644 --- a/drivers/pci/pcie_brcmstb.c +++ b/drivers/pci/pcie_brcmstb.c @@ -90,7 +90,6 @@ #define PCIE_MEM_WIN0_LIMIT_HI(win) \ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI + ((win) * 8)
-#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204 #define PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
#define PCIE_MSI_INTR2_CLR 0x4508 @@ -131,6 +130,10 @@ #define SSC_STATUS_PLL_LOCK_MASK 0x800 #define SSC_STATUS_PLL_LOCK_SHIFT 11
+struct pcie_cfg_data {
- unsigned long hard_debug_offs;
+};
- /**
- struct brcm_pcie - the PCIe controller state
- @base: Base address of memory mapped IO registers of the controller
@@ -141,6 +144,7 @@ struct brcm_pcie { void __iomem *base;
- struct pcie_cfg_data *cfg; int gen; bool ssc; };
@@ -458,7 +462,7 @@ static int brcm_pcie_probe(struct udevice *dev) /* Take the bridge out of reset */ clrbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_INIT_MASK);
- clrbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
clrbits_le32(base + pcie->cfg->hard_debug_offs, PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Wait for SerDes to be stable */
@@ -599,7 +603,7 @@ static int brcm_pcie_remove(struct udevice *dev) setbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_PERST_MASK);
/* Turn off SerDes */
- setbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
setbits_le32(base + pcie->cfg->hard_debug_offs, PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Shutdown bridge */
@@ -620,6 +624,8 @@ static int brcm_pcie_of_to_plat(struct udevice *dev) if (!pcie->base) return -EINVAL;
pcie->cfg = (struct pcie_cfg_data *)dev_get_driver_data(dev);
pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc");
ret = ofnode_read_u32(dn, "max-link-speed", &max_link_speed);
@@ -636,8 +642,17 @@ static const struct dm_pci_ops brcm_pcie_ops = { .write_config = brcm_pcie_write_config, };
+static const struct pcie_cfg_data bcm2711_cfg = {
- .hard_debug_offs = 0x4204
+};
+static const struct pcie_cfg_data bcm2712_cfg = {
- .hard_debug_offs = 0x4304
+};
- static const struct udevice_id brcm_pcie_ids[] = {
- { .compatible = "brcm,bcm2711-pcie" },
- { .compatible = "brcm,bcm2711-pcie", .data = (ulong)&bcm2711_cfg },
- { .compatible = "brcm,bcm2712-pcie", .data = (ulong)&bcm2712_cfg }, { } };
Hi Ivan,
On 2023-12-18 22:03, Ivan T. Ivanov wrote:
Hi,
These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much.
Thank you very much for this work!
Serial console and reset are also functional.
I've applied the patchset to v2024.01-rc5 and built the rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten anything on the serial console on pin 8/10 of the Raspberry Pi pin header. Is there anything specific needed to get the console going?
-- Stefan
Hopefully this will help others add missing pieces more easily.
Happy hacking!
Regards, Ivan
[1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1R+L24WBgpo-iP1y...
Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses
Ivan T. Ivanov (5): rpi5: Use devicetree to retrieve board revision bcm2835: brcm,bcm2708-fb device is using r5g6b5 format mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver pci: pcie-brcmstb: Add bcm2712 PCIe controller support
arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 81 ++++++++-- board/raspberrypi/rpi/rpi.c | 22 ++- configs/rpi_arm64_defconfig | 1 + drivers/mmc/bcmstb_sdhci.c | 173 ++++++++++++++++++++- drivers/pci/pcie_brcmstb.c | 23 ++- drivers/video/bcm2835.c | 10 +- 11 files changed, 296 insertions(+), 31 deletions(-)
On 21/12/2023 14:42, Stefan Agner wrote:
Hi Ivan,
On 2023-12-18 22:03, Ivan T. Ivanov wrote:
Hi,
These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much.
Thank you very much for this work!
Serial console and reset are also functional.
I've applied the patchset to v2024.01-rc5 and built the rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten anything on the serial console on pin 8/10 of the Raspberry Pi pin header. Is there anything specific needed to get the console going?
Welcome to the club! :)
The RPi5 uses a rather non-standard port for debug console: https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html#uart...
Up to now I wasn't able to get serial console on the normal pins 8/10.
Regards Matthias
-- Stefan
Hopefully this will help others add missing pieces more easily.
Happy hacking!
Regards, Ivan
[1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1R+L24WBgpo-iP1y...
Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses
Ivan T. Ivanov (5): rpi5: Use devicetree to retrieve board revision bcm2835: brcm,bcm2708-fb device is using r5g6b5 format mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver pci: pcie-brcmstb: Add bcm2712 PCIe controller support
arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 81 ++++++++-- board/raspberrypi/rpi/rpi.c | 22 ++- configs/rpi_arm64_defconfig | 1 + drivers/mmc/bcmstb_sdhci.c | 173 ++++++++++++++++++++- drivers/pci/pcie_brcmstb.c | 23 ++- drivers/video/bcm2835.c | 10 +- 11 files changed, 296 insertions(+), 31 deletions(-)
Hi Ivan,
On 2023-12-18 21:03, Ivan T. Ivanov wrote:
Hi,
These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much.
Serial console and reset are also functional.
Hopefully this will help others add missing pieces more easily.
So I've given this a go, and the basics (serial) worked out of the box (thanks for that!) after performing the memory-map change you described in your reply to patch 1.
However, I don't get anything on the PCIe front:
U-Boot> pci enum PCIe BRCM: link down PCIe BRCM: link down
despite having an nvme device connected and enabled (the RPi kernel finds it).
I'm guessing I must be missing something. How did you test PCIe?
Thanks,
M.
On 12-22 12:19, Marc Zyngier wrote:
Hi Ivan,
On 2023-12-18 21:03, Ivan T. Ivanov wrote:
Hi,
These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much.
Serial console and reset are also functional.
Hopefully this will help others add missing pieces more easily.
So I've given this a go, and the basics (serial) worked out of the box (thanks for that!) after performing the memory-map change you described in your reply to patch 1.
However, I don't get anything on the PCIe front:
U-Boot> pci enum PCIe BRCM: link down PCIe BRCM: link down
despite having an nvme device connected and enabled (the RPi kernel finds it).
I'm guessing I must be missing something. How did you test PCIe?
No, you are not missing anything. I have not tested it for real. That is why I said "it seems". Sorry.
Yesterday I started looking more closely at what's missing and unfortunately a lot more changes are needed.
Regards, Ivan
On 2023-12-22 12:33, Ivan T. Ivanov wrote:
On 12-22 12:19, Marc Zyngier wrote:
Hi Ivan,
On 2023-12-18 21:03, Ivan T. Ivanov wrote:
Hi,
These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much.
Serial console and reset are also functional.
Hopefully this will help others add missing pieces more easily.
So I've given this a go, and the basics (serial) worked out of the box (thanks for that!) after performing the memory-map change you described in your reply to patch 1.
However, I don't get anything on the PCIe front:
U-Boot> pci enum PCIe BRCM: link down PCIe BRCM: link down
despite having an nvme device connected and enabled (the RPi kernel finds it).
I'm guessing I must be missing something. How did you test PCIe?
No, you are not missing anything. I have not tested it for real. That is why I said "it seems". Sorry.
Yesterday I started looking more closely at what's missing and unfortunately a lot more changes are needed.
Ah, fair enough. I was slightly surprised that it appeared to be working out of the box, which would have been a first on the ARM side...
Happy to test whatever patches you come up with!
Thanks,
M.
participants (8)
-
Florian Fainelli -
Ivan T . Ivanov -
Ivan T. Ivanov
-
Marc Zyngier -
Matthias Brugger -
Simon Glass -
Stefan Agner -
Stefan Wahren