Re: [PATCH 1/1] rpi: Fix build error when CONFIG_VIDEO is disabled for Raspberry Pi
Hi,
On 09-20 08:32, Martin Stolpe wrote:
>
> When the CONFIG_VIDEO option is set to disabled for Raspberry Pi devices
> the build will fail with the following error message:
> "undefined reference to `fdt_simplefb_enable_and_mem_rsv'."
>
> Signed-off-by: Martin Stolpe
> ---
>
> board/raspberrypi/rpi/rpi.c | 2 +-
> boot/fdt_simplefb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index ab5ea85cf9..bc49708f85 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -572,7 +572,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
> if (node < 0)
> fdt_simplefb_add_node(blob);
> - else
> + else if (IS_ENABLED(CONFIG_VIDEO))
> fdt_simplefb_enable_and_mem_rsv(blob);
I think there is one more user of this function which end of same
situation stm32mp1.
>
> #ifdef CONFIG_EFI_LOADER
> diff --git a/boot/fdt_simplefb.c b/boot/fdt_simplefb.c
> index 5341554845..b6e916ff7d 100644
> --- a/boot/fdt_simplefb.c
> +++ b/boot/fdt_simplefb.c
> @@ -86,6 +86,7 @@ int fdt_simplefb_add_node(void *blob)
> return fdt_simplefb_configure_node(blob, off);
> }
>
> +#if IS_ENABLED(CONFIG_VIDEO)
> /**
> * fdt_simplefb_enable_existing_node() - enable simple-framebuffer DT node
> *
> @@ -103,7 +104,6 @@ static int fdt_simplefb_enable_existing_node(void *blob)
> return fdt_simplefb_configure_node(blob, off);
> }
>
> -#if IS_ENABLED(CONFIG_VIDEO)
> int fdt_simplefb_enable_and_mem_rsv(void *blob)
> {
Perhaps it will be better if above check is moved inside this function
making it empty in case of CONFIG_VIDEO is not set. This way you will
not need to modify it users.
Regards,
Ivan
Re: [PATCH v4 0/6] rpi5: initial support
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 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-svarba...@suse.de/T/ Yes. Regards, Ivan
Re: [PATCH v4 0/6] rpi5: initial support
Hi Stefan, > On 19 Sep 2024, at 12:36, Stefan Agner 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 v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi, On 2024-03-28 01:37, Laurent Pinchart wrote: On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > Hello, > > This small series includes a few drive-by fixes for DT validation > errors. > > The first patch has been posted previously in v1 ([1], and now addresses > a small review comment. I think it's good to go. > > The next two patches address the same issue as "[PATCH 1/2] dt-bindings: > arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > but this time with a (hopefully) correct approach. Patch 2/3 starts by > fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT > properties that are specified in bcm2835-rpi.dtsi but not documented in > the corresponding bindings. Patch 3/3 can then drop those properties, > getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) Sorry for taking me so long to verify this. I think on RPi U-Boot side we are fine. API used when accessing Mbox device do not follow DM model and do not use DMA, but just access device directly using this nice macros phys_to_bus/bus_to_phys. I build new DTB files with this patch included and U-Boot build from the latest sources. No obvious issues on RPi3 and RPi4. Devices boot fine. Regards, Ivan
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi, > On 28 Mar 2024, at 1:37, Laurent Pinchart > wrote: > > On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: >> Hi, >> >> [add Peter and Ivan] >> >> Am 26.03.24 um 20:58 schrieb Laurent Pinchart: >>> Hello, >>> >>> This small series includes a few drive-by fixes for DT validation >>> errors. >>> >>> The first patch has been posted previously in v1 ([1], and now addresses >>> a small review comment. I think it's good to go. >>> >>> The next two patches address the same issue as "[PATCH 1/2] dt-bindings: >>> arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), >>> but this time with a (hopefully) correct approach. Patch 2/3 starts by >>> fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT >>> properties that are specified in bcm2835-rpi.dtsi but not documented in >>> the corresponding bindings. Patch 3/3 can then drop those properties, >>> getting rid of the warnings. >> >> since this series drops properties from the device tree, does anyone >> have the chance to test it with a recent U-Boot? > > I don't have U-Boot running with my RPi, so I would appreciate if > someone could help :-) Sure, just give me some time :-) Regards, Ivan
Re: Booting RPi5B with latest git
Hi, > On 17 Feb 2024, at 20:55, Jojan wrote: > > For RPi 5B you need bcm2712 device tree . RPi4 uses 2711.So the e > rpi_arm64_confi does not work for RPi5 > Also make sure that you have the changes discussed here.[GIT PULL] rpi: > updates for v2024.04 (mail-archive.com) You don’t have to change rip_arm64_config file. For RPi5 device you should have bcm2712-rpi-5-b.dtb in dtb directory on your boot drive. You could get this file from "Raspberry Pi OS” or openSUSE Tumbleweed images, at least. You could compile it yourself from the vendor Linux tree too. Regards, Ivan
[PATCH v5 7/7] configs: rpi_arm64: build position independent code
Latest RPi5 EEPROM firmware versions after "DATE: 2023/10/30", has changed kernel load address from 0x8 to 0x20 which break boot process. Switch to position independent code to be able to boot the same binary on top of different EEPROM firmware versions. Tested on: Raspberry Pi 5 Model B Rev 1.0 Raspberry Pi 4 Model B Rev 1.1 Raspberry Pi 3 Model B Plus Rev 1.3 Raspberry Pi Zero 2 W Rev 1.0 Raspberry Pi 2 Model B Rev 1.2 Raspberry Pi Compute Module 4 Rev 1.0 Raspberry Pi Compute Module 3 Rev 1.0 Signed-off-by: Ivan T. Ivanov --- configs/rpi_arm64_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 11ede9435d..e4c4aef9a4 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_BCM283X=y -CONFIG_TEXT_BASE=0x0008 +CONFIG_POSITION_INDEPENDENT=y CONFIG_TARGET_RPI_ARM64=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x7fffe30 -- 2.43.0
[PATCH v5 6/7] configs: rpi_arm64: enable SDHCI BCMSTB driver
RPi5 have "brcm,bcm2712-sdhci" controller which is handled by "sdhci-bcmstb" driver, so enable it. Signed-off-by: Ivan T. Ivanov --- 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.43.0
[PATCH v5 5/7] mmc: bcmstb: Add support for bcm2712 SD controller
Make sure that core SDHCI accessors are used and add
device specific card detection initialization, which
is borrowed from vendor Linux driver code.
Signed-off-by: Ivan T. Ivanov
---
drivers/mmc/bcmstb_sdhci.c | 64 +++---
1 file changed, 60 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/bcmstb_sdhci.c b/drivers/mmc/bcmstb_sdhci.c
index dc96818cff..49846adcf5 100644
--- a/drivers/mmc/bcmstb_sdhci.c
+++ b/drivers/mmc/bcmstb_sdhci.c
@@ -38,15 +38,52 @@
*/
#define BCMSTB_SDHCI_MINIMUM_CLOCK_FREQUENCY 40
-/*
- * This driver has only been tested with eMMC devices; SD devices may
- * not work.
- */
+#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_SEL0x44
+#define SDIO_CFG_SD_PIN_SEL_MASK 0x3
+#define SDIO_CFG_SD_PIN_SEL_CARD BIT(1)
+
struct sdhci_bcmstb_plat {
struct mmc_config cfg;
struct mmc mmc;
};
+struct sdhci_brcmstb_dev_priv {
+ int (*init)(struct udevice *dev);
+};
+
+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);
@@ -54,14 +91,20 @@ static int sdhci_bcmstb_bind(struct udevice *dev)
return sdhci_bind(dev, &plat->mmc, &plat->cfg);
}
+/* No specific SDHCI operations are required */
+static const struct sdhci_ops bcmstb_sdhci_ops = { 0 };
+
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_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 +118,8 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
host->mmc = &plat->mmc;
host->mmc->dev = dev;
+ host->ops = &bcmstb_sdhci_ops;
+
ret = sdhci_setup_cfg(&plat->cfg, host,
BCMSTB_SDHCI_MAXIMUM_CLOCK_FREQUENCY,
BCMSTB_SDHCI_MINIMUM_CLOCK_FREQUENCY);
@@ -84,10 +129,21 @@ 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 const struct sdhci_brcmstb_dev_priv match_priv_2712 = {
+ .init = sdhci_brcmstb_init_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.43.0
[PATCH v5 4/7] bcm2835: Dynamically calculate bytes per pixel parameter
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.
Reviewed-by: Matthias Brugger
Signed-off-by: Ivan T. Ivanov
---
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.43.0
[PATCH v5 3/7] rpi5: Use devicetree to retrieve board revision
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
Signed-off-by: Ivan T. Ivanov
---
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 & 0x80) {
rev_scheme = 1;
rev_type = (revision >> 4) & 0xff;
--
2.43.0
[PATCH v5 2/7] rpi5: Use devicetree as alternative way to read IO base addresses
From: Dmitry Malkin
MBOX and Watchdog on RPi5/bcm2712 have a different base IO offsets.
Find them via devicetree blob passed by bootloader.
Signed-off-by: Dmitry Malkin
Reviewed-by: Matthias Brugger
Signed-off-by: Ivan T. Ivanov
---
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 + 0xb880; })
+#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
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x0030; })
+#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
#endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x3000; })
+#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
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0x0010; })
+#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 = 0x3f00;
+/* Default bcm283x devices addresses */
+unsigned long rpi_mbox_base = 0x3f00b880;
+unsigned long rpi_sdhci_base = 0x3f30;
+unsigned long rpi_wdog_base = 0x3f10;
+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 + 0x30;
+ rpi_wdog_base = io_base + 0x10;
+ rpi_timer_base = io_base + 0x003000;
+
+ offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+ "brcm,bcm2835-mbox");
+ if (offset &
[PATCH v5 1/7] rpi5: add initial memory map for bcm2712
From: Dmitry Malkin
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 0x3f80UL. Board setup then
will properly reserve framebuffer region.
When no HDMI cable is plugged in the size of the region will
be 0x3fc0UL.
Signed-off-by: Dmitry Malkin
Signed-off-by: Ivan T. Ivanov
---
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 = 0xUL,
+ .phys = 0xUL,
+ .size = 0x4000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ /* Beginning of AXI bus where uSD controller lives */
+ .virt = 0x10UL,
+ .phys = 0x10UL,
+ .size = 0x000200UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* SoC bus */
+ .virt = 0x107c00UL,
+ .phys = 0x107c00UL,
+ .size = 0x000400UL,
+ .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.43.0
[PATCH v5 0/7] rpi5: initial support
This is new round of patches posted earlier here[1]. They are adding basic support for RPi5 and are based on v2 series from Dmitry Malkin[2]. What changed sice v4: * Support for SDHCI controller in 2712 was simplified a lot. It turns out that special registers accessors are not needed[3]. * Latest EEPROM firmware changed "kernel" load address from 0x8 to 0x20. And because on RPi’s CONFIG_TEXT_BASE is set to 0x8 code execution run through the grass. Switching to position indeended code fixed this. These changes have been tested on following devices: Raspberry Pi 5 Model B Rev 1.0 Raspberry Pi 4 Model B Rev 1.1 Raspberry Pi 3 Model B Plus Rev 1.3 Raspberry Pi Zero 2 W Rev 1.0 Raspberry Pi 2 Model B Rev 1.2 Raspberry Pi Compute Module 4 Rev 1.0 Raspberry Pi Compute Module 3 Rev 1.0 Thanks, Ivan [1] https://lore.kernel.org/all/20240110122908.31612-1-iiva...@suse.de/ [2] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@mail.gmail.com/ [3] https://github.com/P33M/linux/commit/8a15e5d99667cb4499836d6f360246a69f020256 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: Dynamically calculate bytes per pixel parameter mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver configs: rpi_arm64: build position independent code 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| 3 +- drivers/mmc/bcmstb_sdhci.c | 64 +-- drivers/video/bcm2835.c| 18 +- 10 files changed, 171 insertions(+), 27 deletions(-) -- 2.43.0
Re: Re: [PATCH v4 0/6] rpi5: initial support
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 : > >>> > >>> 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 0x8 to 0x20. And because on RPi’s CONFIG_TEXT_BASE is hardcoded to 0x8 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=0x0008 +CONFIG_POSITION_INDEPENDENT=y
Re: [PATCH v4 0/6] rpi5: initial support
Hi, > On 20 Jan 2024, at 12:50, Stefan Wahren wrote: > > Hi, > > Am 20.01.24 um 10:48 schrieb Jens Maus: >> Hi, >> >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren : >>> >>> 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
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 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: 0003 PM_RSTS 1000 RP1_BOOT chip ID: 0x20001927 PM_RSTS: 0x1000 part reset_info PMIC reset-event rtc alarm 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 1de4:0001 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: 0003 PM_RSTS 1000 usb_pd_init status 1 Boot mode: SD (01) order f4 SD HOST: 2 CTL0: 0x0080 BUS: 40 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff delay: 276 SD HOST: 2 CTL0: 0x00800f00 BUS: 40 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff delay: 276 OCR c0ff8000 [118] CID: 00035344534e33324780fa570bda0169 CSD: 400e00325b59edb07f800a40 SD: bus-width: 4 spec: 2 SCR: 0x02358483 0x SD HOST: 2 CTL0: 0x00800f04 BUS: 5000 Hz actual: 5000 HZ div: 4 (2) status: 0x1fff delay: 2 MBR: 0x2000, 131072 type: 0x0c MBR: 0x00022000, 1024000 type: 0x82 MBR: 0x0011c000,10321887 type: 0x83 MBR: 0x, 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 bytes79357 hnd 0x139f dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712 PM_RSTS 1000 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 = 0x3fc0 fdtdec_setup_memory_banksize: DRAM Bank #1: start = 0x4000, size = 0xc000 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@110: 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
> On 19 Jan 2024, at 16:08, Jens Maus wrote: > > >> Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov : >> >> On 01-19 14:54, Jens Maus wrote: >>> >>>> Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov : >>>> >>>> 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: Re: [PATCH v4 0/6] rpi5: initial support
Hi, On 01-19 14:54, Jens Maus wrote: > > > Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov : > > > > 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: Re: [PATCH v4 0/6] rpi5: initial support
+ 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 :
> >
> > On 01-19 11:49, Jens Maus wrote:
> >>> Am 19.01.2024 um 10:20 schrieb Stefan Wahren :
> >>>
> >>> 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 0x3f80 0x00 0x4000 0xc000>;
> > };
> >
> > 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 = <0x3f80 0x80>;
> + memreserve = <0x3fc0 0x40>;
> 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 0x3f80 0x00 0x4000 0xc000 0x01
> 0x00 0x8000 0x01 0x8000 0x8000>;
> + reg = <0x00 0x00 0x3fc0 0x00 0x4000 0xc000 0x01
> 0x00 0x8000 0x01 0x8000 0x8000>;
> };
>
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: Re: [PATCH v4 0/6] rpi5: initial support
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
>From f9e039d3febbb046fe06f72731e7ba558927aa55 Mon Sep 17 00:00:00 2001
From: "Ivan T. Ivanov"
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
Hi, > On 18 Jan 2024, at 1:06, Jens Maus wrote: > > Hi, > >> Am 17.01.2024 um 17:45 schrieb Ivan T. Ivanov : >> >> 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
Hi, > On 17 Jan 2024, at 17:30, Jens Maus wrote: > > Hi, > >> Am 17.01.2024 um 16:23 schrieb Ivan T. Ivanov : >> >>> 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
Hi, > On 17 Jan 2024, at 17:13, Jens Maus wrote: > > Hi, > >> Am 17.01.2024 um 16:07 schrieb Ivan T. Ivanov : >> >> 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: Re: [PATCH v4 0/6] rpi5: initial support
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: Re: Re: [PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller
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 > > 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
Re: Re: [PATCH v4 2/6] rpi5: Use devicetree as alternative way to read IO base addresses
On 01-10 10:00, Florian Fainelli wrote: > On 1/10/24 04:29, Ivan T. Ivanov wrote: > > From: Dmitry Malkin > > > > 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 > > Reviewed-by: Matthias Brugger > > Signed-off-by: Ivan T. Ivanov > > --- > > 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
Re: Re: [PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller
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 > did you noticed this commit/pull request? > > https://github.com/raspberrypi/linux/pull/5842/commits/3c9d840dc933cfb13a77fd3c03356ee4adacc30b Doh, no. Let me check. Thanks! Ivan
[PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller
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
---
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 40
+#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_SEL0x44
+#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 i
[PATCH v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter
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
---
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
[PATCH v4 6/6] configs: rpi_arm64: enable SDHCI BCMSTB driver
RPi5 have "brcm,bcm2712-sdhci" controller which is handled by "sdhci-bcmstb" driver, so enable it. Signed-off-by: Ivan T. Ivanov --- 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
[PATCH v4 3/6] rpi5: Use devicetree to retrieve board revision
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
Signed-off-by: Ivan T. Ivanov
---
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 & 0x80) {
rev_scheme = 1;
rev_type = (revision >> 4) & 0xff;
--
2.35.3
[PATCH v4 2/6] rpi5: Use devicetree as alternative way to read IO base addresses
From: Dmitry Malkin
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
Reviewed-by: Matthias Brugger
Signed-off-by: Ivan T. Ivanov
---
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 + 0xb880; })
+#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
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x0030; })
+#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
#endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x3000; })
+#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
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0x0010; })
+#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 = 0x3f00;
+/* Default bcm283x devices addresses */
+unsigned long rpi_mbox_base = 0x3f00b880;
+unsigned long rpi_sdhci_base = 0x3f30;
+unsigned long rpi_wdog_base = 0x3f10;
+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 + 0x30;
+ rpi_wdog_base = io_base + 0x10;
+ rpi_timer_base = io_base + 0x003000;
+
+ offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+ "brcm,bcm2835-mbox");
+ if (offset &
[PATCH v4 1/6] rpi5: add initial memory map for bcm2712
From: Dmitry Malkin
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 0x3f80UL. Board setup then
will properly reserve frameboofer region.
When no HDMI cable is plugged in size of the region will be
0x3fc0UL.
Signed-off-by: Dmitry Malkin
Signed-off-by: Ivan T. Ivanov
---
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 = 0xUL,
+ .phys = 0xUL,
+ .size = 0x4000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ /* Beginning of AXI bus where uSD controller lives */
+ .virt = 0x10UL,
+ .phys = 0x10UL,
+ .size = 0x000200UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* SoC bus */
+ .virt = 0x107c00UL,
+ .phys = 0x107c00UL,
+ .size = 0x000400UL,
+ .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
[PATCH v4 0/6] rpi5: initial support
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-iiva...@suse.de/ [2] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@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
Re: [PATCH v3 0/7] rpi5: initial support
On 12-22 12:19, Marc Zyngier wrote: > > Hi Ivan, > > On 2023-12-18 21:03, Ivan T. Ivanov wrote: > > Hi, > > > > These patches are adding basic support for RPi5. > > They are based on v2 series from Dmitry Malkin[1]. > > > > With them I am able to _start_ current openSUSE > > Tumbleweed without modification. They are still > > a lot of things to be added to the upstream Linux > > before it runs flawlessly on this device, but at > > least in U-Booot SD controller used for uSD card > > and Frameboffer and HDMI0 devices are working fine > > now. It seems that PCIe controller is working fine > > too, but I have not tested it too much. > > > > Serial console and reset are also functional. > > > > Hopefully this will help others add missing pieces > > more easily. > > So I've given this a go, and the basics (serial) worked > out of the box (thanks for that!) after performing the > memory-map change you described in your reply to patch 1. > > However, I don't get anything on the PCIe front: > > U-Boot> pci enum > PCIe BRCM: link down > PCIe BRCM: link down > > despite having an nvme device connected and enabled > (the RPi kernel finds it). > > I'm guessing I must be missing something. How did you > test PCIe? > No, you are not missing anything. I have not tested it for real. That is why I said "it seems". Sorry. Yesterday I started looking more closely at what's missing and unfortunately a lot more changes are needed. Regards, Ivan
Re: [PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller
On 12-21 16:39, Stefan Wahren wrote: > To: Florian Fainelli , "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 > > > > This is diverging from the Linux sdhci-brcmstb.c driver where no such > > quirk needs to be carried out, rather the logic for such quirks has > > been present in sdhci-iproc.c... > > it seems this patch based the downstream kernel changes [1]. Yep. > I would > suggest to use an existing driver which already handle this bug > (iproc_sdhci or bcm2835_sdhci). > > Does the Rpi 5 still works, if the compatible "brcm,bcm2712-sdhci" is > added to mmc/iproc_sdhci.c? No, it is not working :-) Even after I added shadow variables usage in iproc_readw, which do not have it. Even after I used hard coded values for "clock-freq-min-max", which are missing in RPi5 device tree. Even after I added 2712 specific "cfg" space initialization procedure from the brcnstb driver. On the other hand they are some tuning procedures in iproc driver which I am not sure that are relevant for 2712 controller. And the diff stat is getting bigger that equivalent for brcmstb driver. To me it is a bit easier to add 2712 support to brcmstb driver, because it will be easier to follow any vendor Linux driver changes. It looks like hardware engineers are just making the same mistake when integrating 2712 SDHCI controller as for IPROC controller. Regards, Ivan > > [1] - > https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9
Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
On 12-20 09:51, Matthias Brugger wrote:
> > > >
> > > >static const struct udevice_id bcm2835_video_ids[] = {
> > > > - { .compatible = "brcm,bcm2835-hdmi" },
> > > > - { .compatible = "brcm,bcm2711-hdmi0" },
> > > > - { .compatible = "brcm,bcm2708-fb" },
> > > > + { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
> > > > + { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
> > > > + { .compatible = "brcm,bcm2708-fb",.data = VIDEO_BPP16 },
> > > this change looks wrong to me. Before we used VIDEO_BPP32 for
> > > brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
> > > the other boards. I would expect some brcm,bcm2712 compatible at least
> > > this needs an explanation in the commit message.
> > >
I think I found better and reliable way to find the right value.
bpp = pitch / width
Which are queried from firmware.
Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1, RPi2 Zero W, RPi5b v1.0.
>
> I think that was RPi1 maybe RPi2 Zero W as well.
>
For the record: RPi2 Zero W exposes "brcm,bcm2835-hdmi" device.
Regards,
Ivan
Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712
Hi,
On 12-18 23:03, Ivan T. Ivanov wrote:
>
> +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
> + {
> + .virt = 0xUL,
> + .phys = 0xUL,
> + .size = 0x3f80UL,
Something that I realized just now. This memory map is valid only if
HDMI cable is plugged in. Otherwise size of this section is 0x3fc0.
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 0x3Fc0 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 = 0x3f80UL,
> + .phys = 0x3f80UL,
> + .size = 0x0080UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
Sorry that I missed it the first time.
Regards,
Ivan
Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712
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 = 0xUL,
> > + .phys = 0xUL,
> > + .size = 0x3f80UL,
> > + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> > +PTE_BLOCK_INNER_SHARE
> > + }, {
>
Regards,
Ivan
Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
On 12-18 23:32, Stefan Wahren wrote:
> >
> > static const struct udevice_id bcm2835_video_ids[] = {
> > - { .compatible = "brcm,bcm2835-hdmi" },
> > - { .compatible = "brcm,bcm2711-hdmi0" },
> > - { .compatible = "brcm,bcm2708-fb" },
> > + { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
> > + { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
> > + { .compatible = "brcm,bcm2708-fb",.data = VIDEO_BPP16 },
> this change looks wrong to me. Before we used VIDEO_BPP32 for
> brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
> the other boards. I would expect some brcm,bcm2712 compatible at least
> this needs an explanation in the commit message.
>
If you are confident that this semi device was working before with
BPP32 I will try to find better way to handle this. Do you remember
which RPi version was this?
Thanks,
Ivan
Re: [PATCH v3 1/7] rpi5: add initial memory map for bcm2712
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 = 0xUL,
> > + .phys = 0xUL,
> > + .size = 0x3f80UL,
> > + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> > +PTE_BLOCK_INNER_SHARE
> > + }, {
> > + .virt = 0x3f80UL,
> > + .phys = 0x3f80UL,
> > + .size = 0x0080UL,
> > + .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 = 0x10UL,
> > + .phys = 0x10UL,
> > + .size = 0x000200UL,
> > + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +PTE_BLOCK_NON_SHARE |
> > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > + }, {
> > + .virt = 0x107c00UL,
> > + .phys = 0x107c00UL,
> > + .size = 0x000400UL,
> > + .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
[PATCH v3 7/7] pci: pcie-brcmstb: Add bcm2712 PCIe controller support
PCIe controller have minor register map difference compared
to bcm2711 variant. Handle this using device specific register
offset.
Signed-off-by: Ivan T. Ivanov
---
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 0x0800
#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;
boolssc;
};
@@ -458,7 +462,7 @@ static int brcm_pcie_probe(struct udevice *dev)
/* Take the bridge out of reset */
clrbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_INIT_MASK);
- clrbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
+ clrbits_le32(base + pcie->cfg->hard_debug_offs,
PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Wait for SerDes to be stable */
@@ -599,7 +603,7 @@ static int brcm_pcie_remove(struct udevice *dev)
setbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_PERST_MASK);
/* Turn off SerDes */
- setbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
+ setbits_le32(base + pcie->cfg->hard_debug_offs,
PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Shutdown bridge */
@@ -620,6 +624,8 @@ static int brcm_pcie_of_to_plat(struct udevice *dev)
if (!pcie->base)
return -EINVAL;
+ pcie->cfg = (struct pcie_cfg_data *)dev_get_driver_data(dev);
+
pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc");
ret = ofnode_read_u32(dn, "max-link-speed", &max_link_speed);
@@ -636,8 +642,17 @@ static const struct dm_pci_ops brcm_pcie_ops = {
.write_config = brcm_pcie_write_config,
};
+static const struct pcie_cfg_data bcm2711_cfg = {
+ .hard_debug_offs= 0x4204
+};
+
+static const struct pcie_cfg_data bcm2712_cfg = {
+ .hard_debug_offs= 0x4304
+};
+
static const struct udevice_id brcm_pcie_ids[] = {
- { .compatible = "brcm,bcm2711-pcie" },
+ { .compatible = "brcm,bcm2711-pcie", .data = (ulong)&bcm2711_cfg },
+ { .compatible = "brcm,bcm2712-pcie", .data = (ulong)&bcm2712_cfg },
{ }
};
--
2.35.3
[PATCH v3 6/7] configs: rpi_arm64: enable SDHCI BCMSTB driver
RPi5 have "brcm,bcm2712-sdhci" controller which is handled by "sdhci-bcmstb" driver, so enable it. Signed-off-by: Ivan T. Ivanov --- configs/rpi_arm64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index f9dade18f6..1107fd11de 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -33,6 +33,7 @@ CONFIG_BCM2835_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_MMC_SDHCI_BCMSTB=y CONFIG_BCMGENET=y CONFIG_PCI_BRCMSTB=y CONFIG_PINCTRL=y -- 2.35.3
[PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller
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
---
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 40
+#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_SEL0x44
+#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 i
[PATCH v3 3/7] rpi5: Use devicetree to retrieve board revision
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
---
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 & 0x80) {
rev_scheme = 1;
rev_type = (revision >> 4) & 0xff;
--
2.35.3
[PATCH v3 4/7] bcm2835: brcm, bcm2708-fb device is using r5g6b5 format
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
---
drivers/video/bcm2835.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 14942526f1..245c958b6e 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -43,7 +43,7 @@ static int bcm2835_video_probe(struct udevice *dev)
uc_priv->xsize = w;
uc_priv->ysize = h;
- uc_priv->bpix = VIDEO_BPP32;
+ uc_priv->bpix = dev_get_driver_data(dev);
plat->base = fb_base;
plat->size = fb_size;
@@ -51,11 +51,11 @@ static int bcm2835_video_probe(struct udevice *dev)
}
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
+ { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
+ { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
+ { .compatible = "brcm,bcm2708-fb",.data = VIDEO_BPP16 },
#if !IS_ENABLED(CONFIG_VIDEO_DT_SIMPLEFB)
- { .compatible = "simple-framebuffer" },
+ { .compatible = "simple-framebuffer", .data = VIDEO_BPP32},
#endif
{ }
};
--
2.35.3
[PATCH v3 2/7] rpi5: Use devicetree as alternative way to read IO base addresses
From: Dmitry Malkin
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
Signed-off-by: Ivan T. Ivanov
---
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 + 0xb880; })
+#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
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x0030; })
+#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
#endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x3000; })
+#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
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0x0010; })
+#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 = 0x3f00;
+/* Default bcm283x devices addresses */
+unsigned long rpi_mbox_base = 0x3f00b880;
+unsigned long rpi_sdhci_base = 0x3f30;
+unsigned long rpi_wdog_base = 0x3f10;
+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 + 0x30;
+ rpi_wdog_base = io_base + 0x10;
+ rpi_timer_base = io_base + 0x003000;
+
+ offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+ "brcm,bcm2835-mbox");
+ if (offset > soc)
+
[PATCH v3 1/7] rpi5: add initial memory map for bcm2712
From: Dmitry Malkin
includes:
* 1GB of RAM (from 4GB or 8GB total)
* VPU memory interface
* AXI ranges (main peripherals)
Signed-off-by: Dmitry Malkin
Signed-off-by: Ivan T. Ivanov
---
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
-#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 = 0xUL,
+ .phys = 0xUL,
+ .size = 0x3f80UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0x3f80UL,
+ .phys = 0x3f80UL,
+ .size = 0x0080UL,
+ .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 = 0x10UL,
+ .phys = 0x10UL,
+ .size = 0x000200UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ .virt = 0x107c00UL,
+ .phys = 0x107c00UL,
+ .size = 0x000400UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
struct mm_region *mem_map = bcm283x_mem_map;
/*
@@ -78,6 +113,7 @@ static const struct udevice_id board_ids[] = {
{ .compatible = "brcm,bcm2837", .data = (ulong)&bcm283x_mem_map},
{ .compatible = "brcm,bcm2838", .data = (ulong)&bcm2711_mem_map},
{ .compatible = "brcm,bcm2711", .data = (ulong)&bcm2711_mem_map},
+ { .compatible = "brcm,bcm2712", .data = (ulong)&bcm2712_mem_map},
{ },
};
--
2.35.3
[PATCH v3 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...@mail.gmail.com/ Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses Ivan T. Ivanov (5): rpi5: Use devicetree to retrieve board revision bcm2835: brcm,bcm2708-fb device is using r5g6b5 format mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver pci: pcie-brcmstb: Add bcm2712 PCIe controller support arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 81 -- board/raspberrypi/rpi/rpi.c| 22 ++- configs/rpi_arm64_defconfig| 1 + drivers/mmc/bcmstb_sdhci.c | 173 - drivers/pci/pcie_brcmstb.c | 23 ++- drivers/video/bcm2835.c| 10 +- 11 files changed, 296 insertions(+), 31 deletions(-) -- 2.35.3
Re: [PATCH 0/4] bootstd: Test and boot_targets improvements
On 10-23 00:02, Simon Glass wrote: > > This series makes another attempt to support things like "mmc" in the > boot_targets variable. The previous attempt introduced a bug which made > iteration fail. > > New test coverage is provided for some previously untested behaviour, to > prevent regressions. > > Thank you! Booting RPi4 from USB and uSB looks fine now. I have updated also our Bugzilla entry with the boot log. Tested-by: Ivan T.Ivanov Regards, Ivan [1] https://bugzilla.suse.com/show_bug.cgi?id=1216036 > Simon Glass (4): > Revert "bootstd: Scan all bootdevs in a boot_targets entry" > bootstd: Expand boot-ordering test to include USB > bootstd: Correct logic for single uclass > bootstd: Scan all bootdevs in a boot_targets entry (take 2) >
Re: [External] - Slow MMC IO with Raspberry CM3+ Module
On 11-03 20:57, Vincent Fazio wrote: > Date: Wed, 3 Nov 2021 20:57:13 + > From: Vincent Fazio > To: Mario Lombardo , "u-boot@lists.denx.de" > > Subject: RE: [External] - Slow MMC IO with Raspberry CM3+ Module > Message-ID: > Tags: all uboot Hi Vincent, > > Mario, > > > -Original Message- > > From: U-Boot On Behalf Of Mario > > Lombardo > > Sent: Wednesday, November 3, 2021 5:40 AM > > To: u-boot@lists.denx.de > > Subject: [External] - Slow MMC IO with Raspberry CM3+ Module > > > > Dear u-boot list, > > > > I recently compiled (latest: 2021.10) code of uboot as a boot loader > > for the Compute Module 3+ (Raspberry). Everything works fine except one > > issue: > > the IO from the storage is extreme slow. I read about issues in the > > past related to ext file systems. However the present issue relates to > > both ext and fat file systems so I assume its cause is different. > > Please see this series: > https://patchwork.ozlabs.org/project/uboot/list/?series=262375 > And this RPi issue: https://github.com/raspberrypi/firmware/issues/1619 Are your patches still needed? If I read the comments on the issue it was fixed in RPi firmware and your workaround is not needed, correct? Regards, Ivan
Re: [PATCH] rpi: Conditionally add simple-framebuffer node
Hi,
Quoting Ivan T. Ivanov (2021-08-10 17:31:14)
> It appears that RPi firmware has already added framebuffer
> node under /chosen, at least on RPi 2 versions. So check
> for this and don't add duplicate node.
>
> Signed-off-by: Ivan T. Ivanov
> ---
> board/raspberrypi/rpi/rpi.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index df52a4689f..372b26b6f2 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -497,12 +497,11 @@ void *board_fdt_blob_setup(void)
>
> int ft_board_setup(void *blob, struct bd_info *bd)
> {
> - /*
> -* For now, we simply always add the simplefb DT node. Later, we
> -* should be more intelligent, and e.g. only do this if no enabled DT
> -* node exists for the "real" graphics driver.
> -*/
> - lcd_dt_simplefb_add_node(blob);
> + int node;
> +
> + node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
> + if (node < 0)
> + lcd_dt_simplefb_add_node(blob);
>
> #ifdef CONFIG_EFI_LOADER
> /* Reserve the spin table */
Could someone take a look into this fix, please.
BTW, original message still awaits list moderator approval.
Thank you!
Ivan
[PATCH] rpi: Conditionally add simple-framebuffer node
It appears that RPi firmware has already added framebuffer
node under /chosen, at least on RPi 2 versions. So check
for this and don't add duplicate node.
Signed-off-by: Ivan T. Ivanov
---
board/raspberrypi/rpi/rpi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..372b26b6f2 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -497,12 +497,11 @@ void *board_fdt_blob_setup(void)
int ft_board_setup(void *blob, struct bd_info *bd)
{
- /*
-* For now, we simply always add the simplefb DT node. Later, we
-* should be more intelligent, and e.g. only do this if no enabled DT
-* node exists for the "real" graphics driver.
-*/
- lcd_dt_simplefb_add_node(blob);
+ int node;
+
+ node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
+ if (node < 0)
+ lcd_dt_simplefb_add_node(blob);
#ifdef CONFIG_EFI_LOADER
/* Reserve the spin table */
--
2.32.0
