Re: [PATCH 4/7] smbios: string table always needs two terminating NUL bytes
On Mon, Jan 29, 2024 at 10:04:50PM +0100, Heinrich Schuchardt wrote:
> The string section of the different SMBIOS structures is always terminated
> by two NUL bytes even if there is no string at all. This is described in
> section 6.1.3 "Text string" of the SMBIOS 3.7.0 specification.
>
> Signed-off-by: Heinrich Schuchardt
I send the very same patch some years ago [1], unfortunately it got
somehow lost. Happy to see you trying to fix the same problem, so:
Reviewed-by: Matthias Brugger
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias@kernel.org/
> ---
> lib/smbios.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 7bd9805fec0..81908e89610 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -311,6 +311,9 @@ int smbios_update_version(const char *version)
> */
> static int smbios_string_table_len(const struct smbios_ctx *ctx)
> {
> + /* If the structure contains no string it is followed by to NUL bytes */
> + if (ctx->next_ptr == ctx->eos)
> + return 2;
> /* Allow for the final \0 after all strings */
> return (ctx->next_ptr + 1) - ctx->eos;
> }
> --
> 2.43.0
Re: [PATCH v3 3/3] cmd: rng: Add rng list command
On Wed, Jan 31, 2024 at 02:14:26PM +, Weizhao Ouyang wrote:
> The 'rng list' command probes all RNG devices and list those devices
> that are successfully probed. Also update the help info.
>
> Reviewed-by: Heinrich Schuchardt
> Signed-off-by: Weizhao Ouyang
Reviewed-by: Matthias Brugger
> ---
> cmd/rng.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/rng.c b/cmd/rng.c
> index 52f722c7af..b073a6c849 100644
> --- a/cmd/rng.c
> +++ b/cmd/rng.c
> @@ -19,6 +19,22 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> struct udevice *dev;
> int ret = CMD_RET_SUCCESS;
>
> + if (argc == 2 && !strcmp(argv[1], "list")) {
> + int idx = 0;
> +
> + uclass_foreach_dev_probe(UCLASS_RNG, dev) {
> + idx++;
> + printf("RNG #%d - %s\n", dev->seq_, dev->name);
> + }
> +
> + if (!idx) {
> + log_err("No RNG device\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + return CMD_RET_SUCCESS;
> + }
> +
> switch (argc) {
> case 1:
> devnum = 0;
> @@ -56,12 +72,9 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> return ret;
> }
>
> -U_BOOT_LONGHELP(rng,
> - "[dev [n]]\n"
> - " - print n random bytes(max 64) read from dev\n");
> -
> U_BOOT_CMD(
> rng, 3, 0, do_rng,
> "print bytes from the hardware random number generator",
> - rng_help_text
> + "list - list all the probed rng devices\n"
> + "rng [dev] [n]- print n random bytes(max 64) read from dev\n"
> );
> --
> 2.39.2
Re: [PATCH v3 2/3] driver: rng: Fix SMCCC TRNG crash
On Wed, Jan 31, 2024 at 02:14:25PM +, Weizhao Ouyang wrote:
> Fix a SMCCC TRNG null pointer crash due to a failed smccc feature
> binding.
>
> Fixes: 53355bb86c25 ("drivers: rng: add smccc trng driver")
> Reviewed-by: Heinrich Schuchardt
> Signed-off-by: Weizhao Ouyang
Reviewed-by: Matthias Brugger
> ---
> v3: add Fixes tag
> ---
> drivers/rng/smccc_trng.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rng/smccc_trng.c b/drivers/rng/smccc_trng.c
> index 3a4bb33941..3087cb991a 100644
> --- a/drivers/rng/smccc_trng.c
> +++ b/drivers/rng/smccc_trng.c
> @@ -166,7 +166,7 @@ static int smccc_trng_probe(struct udevice *dev)
> struct smccc_trng_priv *priv = dev_get_priv(dev);
> struct arm_smccc_res res;
>
> - if (!(smccc_trng_is_supported(smccc->invoke_fn)))
> + if (!smccc || !(smccc_trng_is_supported(smccc->invoke_fn)))
> return -ENODEV;
>
> /* At least one of 64bit and 32bit interfaces is available */
> --
> 2.39.2
[GIT PULL] rpi: updates for v2024.04
Hi Tom, Here come a small set of patches for v2024.04 for the RaspberryPi. It adds basic support for RPi5 to be able to boot on a SD card. You can find the passing tests here: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/19512 It's the same commit ID as the tag, although it's not the same test-run. Regards, Matthias --- The following changes since commit 6faba41927bdc8973b59678649ef83c564cc421e: Prepare v2024.04-rc1 (2024-01-29 20:53:19 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2024.04 for you to fetch changes up to 12d479d01849c164020e17c3ae921f974b96372d: configs: rpi_arm64: build position independent code (2024-01-30 17:40:13 +0100) Add RaspberryPi5 basic support. 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(-)
Re: [PATCH v4 0/6] rpi5: initial support
On 10/01/2024 13:29, Ivan T. Ivanov wrote: Hi, These patches are slight update for patches posted earlier here[1]. They are adding basic support for RPi5 and are based on v2 series from Dmitry Malkin[2]. What changed: * Initial memory map now includes whole first 1GB of DRAM. At runtime, the firmware will adjust this size depending on whether an HDMI cable is plugged in or not. If there is HDMI monitor connected it will reserve framebufer memory region and will add simple-framebuffer device into devicetree. * Dynamically calculate bits per pixel in video driver. This works on all prevous RPi's models that I have. * I am dropping PCIe patch for now. I made some progress on porting changes from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit tricky. They are many devices behind PCIe, but more or less all of them requires missing either "reset-controller" or "clock-controller" or "pin-controller" drivers. I was able to probe "cdns,macb" device, but access to ethernet PHY over MDIO bus is stucking. Then I ported "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires missing clock. And on top of that machine that I used for developing this crashed and I lost my PCIe changes :-|. Anyway. These patches allows me to boot current openSUSE Tumbleweed without modification. I can see serial console log and boot process on HDMI connected monitor. I think these patches should be enough for start. Please consider for inclusion. Thanks, Ivan [1] https://lore.kernel.org/all/20231218210341.30073-1-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 In the meantime I was able to test this series. So here my: Tested-by: Matthias Brugger arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 74 - board/raspberrypi/rpi/rpi.c| 22 ++- configs/rpi_arm64_defconfig| 1 + drivers/mmc/bcmstb_sdhci.c | 173 - drivers/video/bcm2835.c| 18 ++- 10 files changed, 282 insertions(+), 23 deletions(-)
Re: [PATCH v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter
On 10/01/2024 13:29, Ivan T. Ivanov wrote:
brcm,bcm2708-fb device provided by firmware on RPi5 uses
16 bits per pixel, so lets calculate framebuffer bytes
per pixel dynamically based on queried information.
Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1,
RPi2 Zero W, RPi5b v1.0.
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
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;
Re: [PATCH v3 7/7] pci: pcie-brcmstb: Add bcm2712 PCIe controller support
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
PCIe controller have minor register map difference compared
to bcm2711 variant. Handle this using device specific register
offset.
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
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_CLR0x4508
@@ -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", _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)_cfg },
+ { .compatible = "brcm,bcm2712-pcie", .data = (ulong)_cfg },
{ }
};
Re: [PATCH v3 3/7] rpi5: Use devicetree to retrieve board revision
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
Firmware on RPi5 return error on board revision query
through firmware interface, but on the other hand it fills
"linux,revision" in "system" node, so use it to detect board
revision.
system {
linux,revision = <0xc04170>;
linux,serial = <0x6cf44e80 0x3c533ede>;
};
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
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(>get_board_rev, GET_BOARD_REV);
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, >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", );
+ 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=98367=250
* http://www.raspberrypi.org/forums/viewtopic.php?f=31=20594
*/
- revision = msg->get_board_rev.body.resp.rev;
if (revision & 0x80) {
rev_scheme = 1;
rev_type = (revision >> 4) & 0xff;
Re: [PATCH v3 2/7] rpi5: Use devicetree as alternative way to read IO base addresses
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
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
Reviewed-by: Matthias Brugger
---
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,
- _base, );
+ ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL,
+_base, );
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,
+
Re: [PATCH v3 0/7] rpi5: initial support
On 21/12/2023 14:42, Stefan Agner wrote: Hi Ivan, On 2023-12-18 22:03, Ivan T. Ivanov wrote: Hi, These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1]. With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much. Thank you very much for this work! Serial console and reset are also functional. I've applied the patchset to v2024.01-rc5 and built the rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten anything on the serial console on pin 8/10 of the Raspberry Pi pin header. Is there anything specific needed to get the console going? Welcome to the club! :) The RPi5 uses a rather non-standard port for debug console: https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html#uart-connector Up to now I wasn't able to get serial console on the normal pins 8/10. Regards Matthias -- Stefan Hopefully this will help others add missing pieces more easily. Happy hacking! Regards, Ivan [1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-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(-)
Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
On 19/12/2023 09:51, Ivan T. Ivanov wrote:
On 12-18 23:32, Stefan Wahren wrote:
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
+ { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
+ { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
+ { .compatible = "brcm,bcm2708-fb",.data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for
brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
the other boards. I would expect some brcm,bcm2712 compatible at least
this needs an explanation in the commit message.
If you are confident that this semi device was working before with
BPP32 I will try to find better way to handle this. Do you remember
which RPi version was this?
I think that was RPi1 maybe RPi2 Zero W as well.
Regards,
Matthias
Re: ELCE 2023 - Prague
On 16/06/2023 14:13, Michal Simek wrote: Hi, I have had a chat with Marek that ELCE 2023 in Prague is coming. It is good opportunity to talk to each other in person. That's why we are interested to know who from U-Boot community is going. Me, Marek and Simon are going to be there. Who else is coming? Cheers, Michal I'll be around as well. Regards, Matthias
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On 02/05/2023 14:41, Andreas Schwab wrote: On Apr 14 2023, Matthias Brugger wrote: My opinion isIn my opinion user-friendlyness is more important then developer friendly that from an end-user point of view it's much easier to have one binary that works on all different board versions. If not users will have to know which board version they have to flash the correct U-Boot. As long as the kernel uses separate device trees, U-Boot needs to know which one to load. As it currently stands, U-Boot uses the wrong name that does not match either of the names used by the kernel, which means it will not be able find any of them. I'm not sure I get your point. The devicetree will be passed to the kernel via a pointer in a register, the kernel does not need to load the devicetree into memory, it will use the one passed by U-Boot. Regards, Matthias
Re: [RFC] riscv: visionfive2: use OF_BOARD_SETUP
Hi Torsten, On 20/04/2023 09:43, Torsten Duwe wrote: Hi Leo, thanks for the quick reply! On Thu, 20 Apr 2023 06:33:57 + Leo Liang wrote: Hi, Torsten, Matthias, On Wed, Apr 19, 2023 at 02:34:03PM +0200, Matthias Brugger wrote: On 19/04/2023 13:28, Torsten Duwe wrote: This is only a proof of concept; let me know if you like it and I can add the other 12 DT patches to adjust_for_rev13b(), or maybe start with 1.3b as the default and go the other way, or something in between. LGTM as well! Thank you very much! Again, this is only a PoC; if you agree with the concept, I clean it up and fill in the complete DT patching. Questions: shall I default to 1.3B and patch older 1.2A, or vice versa, or do it like your (starfive) patch set and start with something "neutral" and then patch both ways? And, more important, what is the I would go with the common case (I suppose that's version 1.3B) and detect and patch older version 1.2A. Regards, Matthias correct interpretation of the board revision byte -- I assume it's offset 0x76 in the EEPROM? Is it always? Is ">= 0xB2" the correct discriminator? Torsten
Re: [RFC] riscv: visionfive2: use OF_BOARD_SETUP
On 19/04/2023 13:28, Torsten Duwe wrote:
U-Boot already has a mechanism to fix up the DT before OS boot.
This avoids the excessive duplication of data and work proposed
by the explicit separation of 1.2a and 1.3b board revisions. It
will also, to a good degree, improve the user experience, as
pointed out by Matthias.
The defconfig changes required (in diffconfig format) are
-I2C n
-NET_RANDOM_ETHADDR y
+CMD_I2C y
+CMD_MISC y
+DM_I2C y
+I2C_EEPROM y
+MISC y
+MISC_INIT_R y
+OF_BOARD_SETUP y
+SPL_DM_I2C n
+SPL_MISC n
+SYS_I2C_DW y
+SYS_I2C_EEPROM_ADDR 0x0
along with the patch below. It has the neat side effect of providing
the network with the proper MAC addresses ;)
I take advantage of the fact that I²C-5 is also required to talk to the
PMIC, so it must already be initialised by OpenSBI. All that's required
is to declare the EEPROM and to pull in the drivers.
This is only a proof of concept; let me know if you like it and I can
add the other 12 DT patches to adjust_for_rev13b(), or maybe start with
1.3b as the default and go the other way, or something in between.
The last hunk, to the i2c Makefile, is IMHO an independent fix, because
the implication PCI => ACPI in designware_i2c_pci is invalid, and the
VisionFive2 config proves it. Use this quick hack for now.
Looks like a neat approach to enable a signle U-Boot binary to boot on both
platforms.
Thanks for investigating this.
Signed-off-by: Torsten Duwe
---
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index ff9df56ec2..fd3a1d057a 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -119,6 +119,12 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "okay";
+
+ eeprom@50 {
+ compatible = "atmel,24c04";
+ reg = <0x50>;
+ pagesize = <0x10>;
+ };
};
{
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index 613fe793c4..d7f846a357 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -7,6 +7,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
@@ -38,3 +42,62 @@ int board_init(void)
return 0;
}
+
+#ifdef CONFIG_MISC_INIT_R
As this is will be enabled for the board config I think we don't need the
ifedef.
+int misc_init_r(void)
+{
+ int ret = 0;
+
+#ifdef CONFIG_I2C_EEPROM
+ struct udevice *dev;
+ char mac_addr[6];
+ unsigned char pcb_rev, BOM;
+
+ ret = uclass_first_device_err(UCLASS_I2C_EEPROM, );
+ if (ret)
+ goto out;
+
+ if (eth_env_get_enetaddr("ethaddr", mac_addr) == 0) {
+ int i;
+ for (i=0; i<2; i++) {
+ ret = i2c_eeprom_read(dev, 0x78+6*i, mac_addr, 6);
+ if (!ret && is_valid_ethaddr(mac_addr))
+ eth_env_set_enetaddr_by_index("eth", i,
mac_addr);
+ }
+ }
+
+ ret = i2c_eeprom_read(dev, 0x76, _rev, 1);
+ if (!ret)
+ env_set_hex("board_revision", pcb_rev);
+
+ ret = i2c_eeprom_read(dev, 0x77, , 1);
+
+ out:
+#endif
+return ret;
+}
+#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
Same here.
Regards,
Matthias
+static void adjust_for_rev13b(void * fdt)
+{
+ do_fixup_by_path(fdt, "/soc/ethernet@1604",
+"phy-mode", "rgmii-id", 9, 0);
+ /*
+ ... other fixups ...
+
+*/
+}
+
+int ft_board_setup(void *fdt, struct bd_info *bdip)
+{
+ unsigned char pcb_rev = 0;
+
+ pcb_rev = env_get_hex("board_revision", pcb_rev);
+ if (pcb_rev >= 0xB2) {
+ printf("Adjusting FDT for v1.3B board rev\n");
+ adjust_for_rev13b(fdt);
+ }
+ return 0;
+}
+#endif
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 99545df2e5..828856e40d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -19,8 +19,10 @@ obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
ifdef CONFIG_PCI
+ifdef CONFIG_ACPIGEN
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c_pci.o
endif
+endif
obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
obj-$(CONFIG_SYS_I2C_IHS) += ihs_i2c.o
obj-$(CONFIG_SYS_I2C_INTEL) += intel_i2c.o
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On 13/04/2023 12:05, yanhong wang wrote: On 2023/4/13 17:03, Torsten Duwe wrote: On Thu, 13 Apr 2023 10:05:28 +0800 yanhong wang wrote: the definition of DT refers to Linux and is consistent with the definition framework of Linux. This is one of the desired goals, to avoid confusion, usually. But note there are already the -u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be simple, the kernel required a different treatment. As long as the resulting tree matches the hardware! The difference between 1.2A and 1.3B is the PHY type and phy clock delay configuration, which are reflected in DT, and the difference in defconfig is the configuration of the DT file. Is defconfig defined separately or merged? You are the implementer, this is your decision. You make a proposal, and it will get accepted or not. We only make suggestions, with the intention to improve the code. Thanks. A defconfig matches a piece of hardware, which is more developer-friendly and less confusing, so defconfig is better defined separately. My opinion isIn my opinion user-friendlyness is more important then developer friendly that from an end-user point of view it's much easier to have one binary that works on all different board versions. If not users will have to know which board version they have to flash the correct U-Boot. For the RaspberryPi we even went further and put effort into U-Boot development to have one U-Boot binary which can boot RPi3 and RPi4 boards. In that sense I would advise you to revisit your decision to put a developer-friendly approach over an end-user-friendly one. As Torsten said, it shouldn't be too difficult to update the device-tree at boot time to fit the actual board you are running U-Boot on. Just my thoughts about the issue :) Best regards, Matthias The EEPROM is being prepared and will be submitted as soon as possible. Is it necessary to incorporate EEPROM into this submission? When eeprom is supported, the MAC address will be read from eeprom. The board reversion can be read from eeprom, but phy clock delay configuration cannot be read from eeprom, only in DT. But the board revision number in EEPROM can be used to differentiate between 1.2 and 1.3, right? Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B. 1.2A and 1.3B are two sets of hardware, and the differences between the hardware are defined by DT, which is more concise and clear. When I look at the code and my test results, this is my proposal to pull this in, in order to simplify things and avoid duplication. Whether you do so is up to you, see above. Let me recap: * the device tree *must* match the hardware at hand. * the differences are minor and could be patched, Copy is error prone and causes extra work. It is my firm conviction that this patch set does not introduce hardware variants, and it would be the task of the ethernet driver patch set to split the code (DT+defconfig) OR to provide a patching method. Maybe I find a few cycles to look at the EEPROM. Torsten
Re: [PATCH] rpi: Update the RPi Zero 2W DT filename
On 28/02/2023 11:19, Peter Robinson wrote:
Update the Raspberry Pi Zero 2W device tree file
name to match what landed upstream.
Signed-off-by: Peter Robinson
Acked-by: Matthias Brugger
Peter will you take care to push the patch?
Regards,
Matthias
---
board/raspberrypi/rpi/rpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 8603c93de77..1fa65d51212 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -158,7 +158,7 @@ static const struct rpi_model rpi_models_new_scheme[] = {
},
[0x12] = {
"Zero 2 W",
- DTB_DIR "bcm2837-rpi-zero-2.dtb",
+ DTB_DIR "bcm2837-rpi-zero-2-w.dtb",
false,
},
[0x13] = {
Re: [PATCH 117/171] Correct SPL uses of OF_BOARD
On 30/01/2023 16:15, Simon Glass wrote:
This converts 3 usages of this option to the non-SPL form, since there is
no SPL_OF_BOARD defined in Kconfig
Signed-off-by: Simon Glass
---
drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 2 +-
drivers/serial/serial_bcm283x_mu.c | 2 +-
drivers/serial/serial_bcm283x_pl011.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial_bcm283x_mu.c
b/drivers/serial/serial_bcm283x_mu.c
index 12cbcb9858c..7585f790d22 100644
--- a/drivers/serial/serial_bcm283x_mu.c
+++ b/drivers/serial/serial_bcm283x_mu.c
@@ -197,7 +197,7 @@ U_BOOT_DRIVER(serial_bcm283x_mu) = {
.plat_auto = sizeof(struct bcm283x_mu_serial_plat),
.probe = bcm283x_mu_serial_probe,
.ops = _mu_serial_ops,
-#if !CONFIG_IS_ENABLED(OF_CONTROL) || CONFIG_IS_ENABLED(OF_BOARD)
+#if !CONFIG_IS_ENABLED(OF_CONTROL) || IS_ENABLED(CONFIG_OF_BOARD)
.flags = DM_FLAG_PRE_RELOC,
#endif
.priv_auto = sizeof(struct bcm283x_mu_priv),
diff --git a/drivers/serial/serial_bcm283x_pl011.c
b/drivers/serial/serial_bcm283x_pl011.c
index 7d172cdac0a..09a9868a38f 100644
--- a/drivers/serial/serial_bcm283x_pl011.c
+++ b/drivers/serial/serial_bcm283x_pl011.c
@@ -94,7 +94,7 @@ U_BOOT_DRIVER(bcm283x_pl011_uart) = {
.probe = bcm283x_pl011_serial_probe,
.plat_auto = sizeof(struct pl01x_serial_plat),
.ops= _pl011_serial_ops,
-#if !CONFIG_IS_ENABLED(OF_CONTROL) || CONFIG_IS_ENABLED(OF_BOARD)
+#if !CONFIG_IS_ENABLED(OF_CONTROL) || IS_ENABLED(CONFIG_OF_BOARD)
.flags = DM_FLAG_PRE_RELOC,
#endif
.priv_auto = sizeof(struct pl01x_priv),
For bcm283x:
Reviewed-by: Matthias Brugger
Re: [PATCH] rpi: Set FDT for RPi CM4 to the IO Board one
Hi Ariel,
On 16/09/2022 17:13, Ariel D'Alessandro wrote:
For the RPi CM4 (Compute Module 4), we currently try to load the dtb
file bcm2711-rpi-cm4.dtb, which is not built by the upstream kernel.
Instead, the only CM4 dtb file provided by linux upstream is the
bcm2711-rpi-cm4-io.dtb, so let's use that.
Signed-off-by: Ariel D'Alessandro
---
board/raspberrypi/rpi/rpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 17b8108cc8..b88f80ce05 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -168,8 +168,8 @@ static const struct rpi_model rpi_models_new_scheme[] = {
true,
},
[0x14] = {
- "Compute Module 4",
- DTB_DIR "bcm2711-rpi-cm4.dtb",
+ "Compute Module 4 IO Board",
+ DTB_DIR "bcm2711-rpi-cm4-io.dtb",
We had that discussion in the past. It is supposed that most CM4s will be used
with a custom board. I don't think it's a good idea to tie the ID of the module
to a specific IO board.
Regards,
Matthias
true,
},
};
Re: [PATCH v2 0/7] Add video damage tracking
On 10/06/2022 00:59, Alexander Graf wrote: This patch set speeds up graphics output on ARM by a factor of 60x. On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached, but need it accessible by the display controller which reads directly from a later point of consistency. Hence, we flush the frame buffer to DRAM on every change. The full frame buffer. Unfortunately, with the advent of 4k displays, we are seeing frame buffers that can take a while to flush out. This was reported by Da Xue with grub, which happily print 1000s of spaces on the screen to draw a menu. Every printed space triggers a cache flush. This patch set implements the easiest mitigation against this problem: Damage tracking. We remember the lowest common denominator region that was touched since the last video_sync() call and only flush that. The most typical writer to the frame buffer is the video console, which always writes rectangles of characters on the screen and syncs afterwards. With this patch set applied, we reduce drawing a large grub menu (with serial console attached for size information) on an RK3399-ROC system at 1440p from 55 seconds to less than 1 second. Version 2 also implements VIDEO_COPY using this mechanism, reducing its overhead compared to before as well. So even x86 systems should be faster with this now :). Series tested on RPi4, thanks a lot! Tested-by: Matthias Brugger Alternatives considered: 1) Lazy sync - Sandbox does this. It only calls video_sync(true) ever so often. We are missing timers to do this generically. 2) Double buffering - We could try to identify whether anything changed at all and only draw to the FB if it did. That would require maintaining a second buffer that we need to scan. 3) Text buffer - Maintain a buffer of all text printed on the screen with respective location. Don't write if the old and new character are identical. This would limit applicability to text only and is an optimization on top of this patch set. 4) Hash screen lines - Create a hash (sha256?) over every line when it changes. Only flush when it does. I'm not sure if this would waste more time, memory and cache than the current approach. It would make full screen updates much more expensive. v1 -> v2: - new patch: video: Use VIDEO_DAMAGE for VIDEO_COPY - Remove ifdefs - Fix dcache range; we were flushing too much before - Fix ranges in truetype target - Limit rotate to necessary damange Alexander Graf (7): dm: video: Add damage tracking API dm: video: Add damage notification on display clear vidconsole: Add damage notifications to all vidconsole drivers video: Add damage notification on bmp display efi_loader: GOP: Add damage notification on BLT video: Only dcache flush damaged lines video: Use VIDEO_DAMAGE for VIDEO_COPY configs/chromebook_coral_defconfig | 1 + configs/chromebook_link_defconfig| 1 + configs/chromebook_samus_defconfig | 1 + configs/minnowmax_defconfig | 1 + configs/sandbox_defconfig| 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + drivers/video/Kconfig| 21 ++- drivers/video/console_normal.c | 22 ++-- drivers/video/console_rotate.c | 87 - drivers/video/console_truetype.c | 30 +++-- drivers/video/vidconsole-uclass.c| 16 --- drivers/video/video-uclass.c | 185 --- drivers/video/video_bmp.c| 7 +- include/video.h | 54 +++- include/video_console.h | 49 --- lib/efi_loader/efi_gop.c | 7 +- 16 files changed, 247 insertions(+), 237 deletions(-)
Re: Vulnerability Disclosure in net/
Hi Ramon,
On 26/05/2022 04:46, Ramon Fried wrote:
On Wed, May 18, 2022 at 7:14 PM Nicolas Bidron
wrote:
Hello,
We found a couple of bugs in net/net.s in the IP defragmentation
function __net_defragment(). Below the writeup for the 2 bugs:
---BUG 1---
# Hole Descriptor Overwrite in U-Boot IP Packet Defragmentation Leads to
Arbitrary Out of Bounds Write Primitive (CVE-TBD)
| | |
| --- | --- |
|Project | U-Boot |
|Project URL | https://github.com/u-boot/u-boot |
|Versions affected | all versions up to commit TBD |
|Systems affected | All systems defining `CONFIG_IP_DEFRAG` |
|CVE identifier | TBD |
|Advisory URL | TBD |
|Risk | Critical 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) |
|Authors | Nicolas Guigo, Nicolas Bidron |
### Summary
U-boot is a popular boot loader for embedded systems with
implementations for a large number of architectures and prominent in
most linux based embedded systems.
### Location
In `u-boot/net/net.c` the `__net_defragment` function line 900 through 1018.
### Impact
The U-Boot implementation of
[RFC815](https://datatracker.ietf.org/doc/html/rfc815) IP DATAGRAM
REASSEMBLY ALGORITHMS is susceptible to a Hole Descriptor overwrite
attack which ultimately leads to an arbitrary write primitve.
### Description
In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of
`ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE`
and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len`
comprised between `0` and `7`. This will ultimately result in a
truncated division by `8` resulting value of `0` forcing the hole
metadata and fragment to point to the same location. The subsequent
memcopy will overwrite the hole metadata with the fragment data. Through
a second fragment, this can be exploited to write to an arbitrary offset
controlled by that overwritten hole metadata value.
This bug is only exploitable locally as it requires crafting two packets
the first of which would most likely be dropped through routing due to
its unexpectedly low Total Length. However, this bug can potentially be
exploited to root linux based embedded devices locally.
```C
static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
{
static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
static u16 first_hole, total_len;
struct hole *payload, *thisfrag, *h, *newh;
struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
uchar *indata = (uchar *)ip;
int offset8, start, len, done = 0;
u16 ip_off = ntohs(ip->ip_off);
/* payload starts after IP header, this fragment is in there */
payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
offset8 = (ip_off & IP_OFFS);
thisfrag = payload + offset8;
start = offset8 * 8;
len = ntohs(ip->ip_len) - IP_HDR_SIZE;
```
The last line of the previous excerpt from `u-boot/net/net.c` shows how
the attacker can control the value of `len` to be strictly lower than
`8` by issuing a packet with `ip_len` between `21` and `27`
(`IP_HDR_SIZE` has a value of `20`).
Also note that `offset8` here is `0` which leads to `thisfrag = payload`.
```C
} else if (h >= thisfrag) {
/* overlaps with initial part of the hole: move this hole */
newh = thisfrag + (len / 8);
*newh = *h;
h = newh;
if (h->next_hole)
payload[h->next_hole].prev_hole = (h - payload);
if (h->prev_hole)
payload[h->prev_hole].next_hole = (h - payload);
else
first_hole = (h - payload);
} else {
```
Lower down the same function, execution reaches the above code path.
Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note
that `first_hole` here is `0` since `h` and `payload` point to the same
location.
```C
/* finally copy this fragment and possibly return whole packet */
memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);
```
Finally, in the above excerpt the `memcpy` overwrites the hole metadata
since `thisfrag` and `h` both point to the same location. The hole
metadata is effectively overwritten with arbitrary data from the
fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`,
`next_hole`, and `prev_hole` of the `first_hole` can be controlled by
the attacker.
Finally the arbitrary offset write occurs through a second fragment that
only needs to be crafted to write data in the hole pointed to by the
previously controlled hole metadata (`next_hole`) from the first packet.
### Recommendation
Handle cases where `len` is strictly lower than 8 by preventing the
overwrite of the hole metadata during the memcpy of the fragment. This
could be achieved by either:
* Moving the location where the hole metadata is stored when `len` is
lower than `8`.
* Or outright rejecting fragmented IP datagram with a Total Length
(`ip_len`) lower than 28 bytes which is the minimum valid fragmented IP
Re: Raspberry Pi won’t boot from compressed subvolume (BTRFS)
On 22/05/2022 17:36, Nathan Henrie wrote: Hello u-boot team, I’ve been experimenting for about a year with a NixOS-based Raspberry Pi image, with the end goal of a zstd-compressed image that uses BTRFS subvolumes, having the root filesystem at @ and boot at @boot (with several other subvolumes). The NixOS Raspberry Pi images use u-boot by default. I’ve started a few discussions in the NixOS community as I learn and iterate: https://discourse.nixos.org/t/raspberry-pi-nixos-on-btrfs-root/14081 and I’ve made my code available at: https://github.com/n8henrie/nixos-btrfs-pi . I’m sure it’s obvious (or will be soon) that I’m a hobbyist, a novice with NixOS, and that I understand very little about u-boot and bootloaders in general, so I hope you can be patient as I humbly ask for someone to point me in the right direction. For reference, the official NixOS code for generating u-boot images is here: https://github.com/NixOS/nixpkgs/blob/3d4e586313d292c9e764a8e88a1fdccb16ffb2d3/pkgs/misc/uboot/default.nix I’ve made a lot of progress, including an image that reliably boots from @boot to the @ root subvolume with the u-boot configuration: CONFIG_CMD_BTRFS=y CONFIG_ZSTD=y CONFIG_BOOTCOMMAND="setenv boot_prefixes / /boot/ /@/ /@boot/; run distro_bootcmd;" with kernel params: "root=LABEL=NIXOS_SD" "rootfstype=btrfs" "rootflags=subvol=@" Unfortunately, after the initial boot and going through the initial OS installation steps, if I have compression enabled, it reboots into a boot loop with the following error messages: Scanning mmc 0:2... Found /@boot/extlinux/extlinux.conf Retrieving file: /@boot/extlinux/extlinux.conf 2938 bytes read in 27 ms (105.5 KiB/s) 1 NixOS Default 2 NixOS Configuration 4 (2022-02-24 21:34 22.05pre356135.7f9b6c2babf) 3 NixOS Configuration 3 (2022-02-25 03:59 22.05pre356435.7/9b6eZbabf) 4: NixOS Configuration 2 (2022-02-24 21:34 22.05pre356435.7/9b6c2babr) 5: NixOS Enter choice: 1: NixOS - Default Retrieving file: /@boot/extlinux/..nixos/zhbharzhzqga617uc37uk0g6q1bx891u-initrd-linux-5.10.101-initrd 20588420 bytes read in 1910 ms (10.3 MiB/s) Retrieving file: /@boot/extlinux/..nixos/6c1m6j0k1gmjrmikOyyizariiry?Zlqr-linux-5.10.101-Image 50629120 bytes read in 6863 ms (7 MiB/s) append: init-mix/store/pikl8ju4077iaix36n8mifzu6l6rcajz-nixos-system-nixpi-22.05p re356435-7/9b6eZbabf/init console=tty1 console=ttyAMAO console=ttyS0, 1115200 root= LABEL=-NIXOS_SD rootfstype=btrfs rootflags=subvol=@ loglevel=4 Retrieving file: /@boot/extlinux/../nixos/6c16j0k1gmjrmikOyyizari1ry72lqr-linux-5.10.101-dtbs/broadcon/bcn2837-rpi-3-b.dtb Just a random guess, but bcn2837-rpi-3-b.dtb does look right, the DTB should be called bcm2837-rpi-3-b.dtb 14310 bytes read in 66 ms (210.9 KiB/s) Moving Image from 0x8 to 0x20, end=32f ## Flattened Device Tree blob at 0370 Booting using the fdt blob at 0x370 Using Device Tree in place at 0370 end 037067e5 fdt_find_or_add_subnode: memory: FDT_ERR_BADSTRUCTURE ERROR: arch-specific fdt fixup failed - must RESET the board to recover. Then you try to fixup that address which has no valid DTB and fails. Anyway to me that sounds like a nixOS problem rather then a U-Boot problem. I'm not even sure which version of U-Boot you are using and if it has any patches on top of the upstream version. Regards, Matthias FDT creation failed! resetting ... This happens even though I have CONFIG_ZSTD=y. If I do *not* enable compression (in my BTRFS mount options), it reboots normally and everything works! I may have made some OCR / C errors above; I’ve posted some pictures of the error messages (and similar discussion to this email, with no responses) here: https://discourse.nixos.org/t/btrfs-pi-wont-boot-from-compressed-subvolume/18462/2 I’m not currently using BTRFS RAID, just a single device. One of my other (x86_64) machines uses a similar setup with @, @boot, and zstd-compression with grub and works well, so I’m hoping this is also possible with u-boot. Seeing that the errors mention the FDT and fixup, I tried CONFIG_ARCH_FIXUP_FDT_MEMORY with both =y and =n without interesting changes to the error messages. What I’m assuming, based on the above, is that re-writing the @boot subvolume with compression is moving the location of the device tree files and that u-boot is no longer able to find the necessary files (some of which I think may also be in the nix store in the @nix subvolume). Does that sound like a reasonable guess as to what is going on? If so, are there config options or settings that I might be able to use to help u-boot find the necessary files after things are re-written with compression? Many thanks in advance for your time and attention, and thanks for your hard work on u-boot!
Re: [PATCH] rpi: always set fdt_addr to the correct value
On 15/02/2022 15:55, Matthias Brugger wrote:
On 18/02/2022 03:44, Jaehoon Chung wrote:
On 22. 2. 14. 20:25, Marek Szyprowski wrote:
The fdt_addr env have meaning only for the current runtime and it depends
on the dtb size or firmware version. If one save the environment to disk
and the loads it on the latter boot, the fdt_addr might change, what
result in passing incorrect dtb address to the kernel. Fix this by always
setting the fdt_addr env. This fixes system operation after saving the
env to disk and updating i.e. dtb files or firmware.
Signed-off-by: Marek Szyprowski
Reviewed-by: Jaehoon Chung
Could we keep the discussion where we left it the last time you submitted the
patch?
I forgot to add the link to the old discussion:
https://patchwork.ozlabs.org/project/uboot/patch/20210512123945.25649-1-m.salv...@koansoftware.com/
Regards,
Matthias
Thanks! :)
Regards,
Matthias
Best Regards,
Jaehoon Chung
---
board/raspberrypi/rpi/rpi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index bc3cc597adb..6d6d2e69234 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -347,9 +347,6 @@ static void set_fdtfile(void)
*/
static void set_fdt_addr(void)
{
- if (env_get("fdt_addr"))
- return;
-
if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
return;
Re: [PATCH] rpi: always set fdt_addr to the correct value
On 18/02/2022 03:44, Jaehoon Chung wrote:
On 22. 2. 14. 20:25, Marek Szyprowski wrote:
The fdt_addr env have meaning only for the current runtime and it depends
on the dtb size or firmware version. If one save the environment to disk
and the loads it on the latter boot, the fdt_addr might change, what
result in passing incorrect dtb address to the kernel. Fix this by always
setting the fdt_addr env. This fixes system operation after saving the
env to disk and updating i.e. dtb files or firmware.
Signed-off-by: Marek Szyprowski
Reviewed-by: Jaehoon Chung
Could we keep the discussion where we left it the last time you submitted the
patch?
Thanks! :)
Regards,
Matthias
Best Regards,
Jaehoon Chung
---
board/raspberrypi/rpi/rpi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index bc3cc597adb..6d6d2e69234 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -347,9 +347,6 @@ static void set_fdtfile(void)
*/
static void set_fdt_addr(void)
{
- if (env_get("fdt_addr"))
- return;
-
if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
return;
Re: [PATCH 13/14] video: Convert CONFIG_VIDEO_BCM2835 to Kconfig
On 23/01/2022 15:04, Simon Glass wrote: This converts the following to Kconfig: CONFIG_VIDEO_BCM2835 This is the final ad-hoc CONFIG_VIDEO_... to convert. Signed-off-by: Simon Glass Acked-by: Matthias Brugger --- configs/rpi_0_w_defconfig | 1 + configs/rpi_2_defconfig| 1 + configs/rpi_3_32b_defconfig| 1 + configs/rpi_3_b_plus_defconfig | 1 + configs/rpi_3_defconfig| 1 + configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 1 + configs/rpi_arm64_defconfig| 1 + configs/rpi_defconfig | 1 + drivers/video/Kconfig | 8 include/configs/rpi.h | 1 - scripts/config_whitelist.txt | 1 - 12 files changed, 17 insertions(+), 2 deletions(-) diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index 195541c6e76..819618280f7 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -41,6 +41,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index eb63fbdd8d9..9ccd69cbd88 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig index 46102899f03..de4a14e69ce 100644 --- a/configs/rpi_3_32b_defconfig +++ b/configs/rpi_3_32b_defconfig @@ -45,6 +45,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_3_b_plus_defconfig b/configs/rpi_3_b_plus_defconfig index 91b63b62721..1d4346c0ec8 100644 --- a/configs/rpi_3_b_plus_defconfig +++ b/configs/rpi_3_b_plus_defconfig @@ -44,6 +44,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig index 528b12ea5b5..c7615403d33 100644 --- a/configs/rpi_3_defconfig +++ b/configs/rpi_3_defconfig @@ -44,6 +44,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 8f87a4336d2..d9d9331f580 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -59,6 +59,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_ADDR_MAP=y diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 461a7655ab9..eac55ccbcb8 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -59,6 +59,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 351d247daeb..a0cbdbef02f 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -51,6 +51,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index 0baef3b6abf..bd4e3dc42d7 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -41,6 +41,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index e74a3dd9285..2fba1f2e122 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -421,6 +421,14 @@ config VIDEO_LCD_ANX9804 from a parallel LCD interface and translate it on the fy into a DP interface for driving eDP TFT displays. It uses I2C for configuration. +config VIDEO_BCM2835 + bool "Display support for BCM2835" + help + The graphics processor already sets up the display so this driver + sim
Re: [PATCH] socfpga: enable EFI partition support for de0-nano-soc
Hi Simon, On 28/10/2021 08:52, Matthias Brugger wrote: On 22/10/2021 19:59, Frank Kunz wrote: This fixes boot problems with distributions that use EFI boot like opensuse. Signed-off-by: Frank Kunz Reviewed-by: Matthias Brugger I can see that this patched got delegated to you in patchwork. Is there anything blocking it from being accepted? Regards, Matthias --- configs/socfpga_de0_nano_soc_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/socfpga_de0_nano_soc_defconfig b/configs/socfpga_de0_nano_soc_defconfig index 17c160dd2a..3068f5615a 100644 --- a/configs/socfpga_de0_nano_soc_defconfig +++ b/configs/socfpga_de0_nano_soc_defconfig @@ -35,7 +35,7 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)" CONFIG_CMD_UBI=y # CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_VERSION_VARIABLE=y From Received: from DB8PR04MB7148.eurprd04.prod.outlook.com (2603:10a6:10:12d::17) by AM6PR04MB5366.eurprd04.prod.outlook.com with HTTPS; Fri, 22 Oct 2021 17:59:43 + Received: from AM6PR0502CA0064.eurprd05.prod.outloo
[GIT PULL] rpi: updates for v2022.01
Hi Tom, Here come a small set of patches for v2022.01 for the RaspberryPi. You can find the passing tests here: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/10047 It's the same commit ID as the tag, although it's not the same test-run. Regards, Matthias --- The following changes since commit ade37460a944aed36ae6ee634c4d4a9a22690461: Prepare v2022.01-rc3 (2021-11-29 11:16:03 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2022.01 for you to fetch changes up to 874e544e89a7f9f42796b23f8d43c56e203b6e69: Fix MMC numbering issue for Raspberry Pi 3 (2021-11-30 16:07:40 +0100) - enable RPi Zero 2 W - fix MMC numbering issue - Update link to documentation Mike Karels (1): Fix MMC numbering issue for Raspberry Pi 3 Peter Robinson (2): rpi: Update the Raspberry Pi doucmentation URL rpi: Add identifier for the new RPi Zero 2 W board/raspberrypi/rpi/rpi.c | 7 ++- include/configs/rpi.h | 3 ++- 2 files changed, 8 insertions(+), 2 deletions(-)
Re: [PATCH] Fix MMC numbering issue for Raspberry Pi 3
On Thu, Oct 28, 2021 at 09:44:09AM +0200, Emmanuel Vadot wrote: > On Wed, 27 Oct 2021 22:26:15 + > kar...@freebsd.org wrote: > > > From: Mike Karels > > > > Using mmc.dtbo from rpi-firmware to switch the controller for the SD > > card slot from sdhci to sdhost causes the numbering to change; the > > SD card is then not recognized at boot. Add to the range checked. > > --- > > include/configs/rpi.h | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > index 55768a46da..4c5c1ac31f 100644 > > --- a/include/configs/rpi.h > > +++ b/include/configs/rpi.h > > @@ -137,7 +137,8 @@ > > #if CONFIG_IS_ENABLED(CMD_MMC) > > #define BOOT_TARGET_MMC(func) \ > > func(MMC, mmc, 0) \ > > - func(MMC, mmc, 1) > > + func(MMC, mmc, 1) \ > > + func(MMC, mmc, 2) > > #else > > #define BOOT_TARGET_MMC(func) > > #endif > > -- > > 2.32.0 > > > > Reviewed-by: Emmanuel Vadot Applied to rpi-next Thanks! > > -- > Emmanuel Vadot
Re: [PATCH 2/2] rpi: Add identifier for the new RPi Zero 2 W
On Sun, Nov 21, 2021 at 05:03:46PM +, Peter Robinson wrote:
> The Raspberry Pi Foundation released the new Zero 2 W which we
> want to detect, so we can detect the correct device tree file name.
>
> Signed-off-by: Peter Robinson
Applied to rpi-next
Thanks!
> ---
> board/raspberrypi/rpi/rpi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index e7bcee3746..ff69607d3c 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -157,6 +157,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
> DTB_DIR "bcm2711-rpi-4-b.dtb",
> true,
> },
> + [0x12] = {
> + "Zero 2 W",
> + DTB_DIR "bcm2837-rpi-zero-2.dtb",
> + false,
> + },
> [0x13] = {
> "400",
> DTB_DIR "bcm2711-rpi-400.dtb",
> --
> 2.33.1
Re: [PATCH 1/2] rpi: Update the Raspberry Pi doucmentation URL
On Sun, Nov 21, 2021 at 05:03:45PM +, Peter Robinson wrote:
> The Raspberry Pi Foundation has updated their documentation so update
> the URL to the latest place to find the HW device revision codes.
>
> Signed-off-by: Peter Robinson
Applied to rpi-next
Thanks!
> ---
> board/raspberrypi/rpi/rpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 55afaa54d9..e7bcee3746 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -72,7 +72,7 @@ struct msg_get_clock_rate {
> #endif
>
> /*
> - *
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> + *
> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-revision-codes
> */
> struct rpi_model {
> const char *name;
> --
> 2.33.1
Re: [RESEND PATCH] rpi: Copy properties from firmware dtb to the loaded dtb
On 25/11/2021 20:42, Sjoerd Simons wrote:
The RPI firmware adjusts several property values in the dtb it passes
to u-boot depending on the board/SoC revision. Inherit some of these
when u-boot loads a dtb itself. Specificaly copy:
* /model: The firmware provides a more specific string
* /memreserve: The firmware defines a reserved range, better keep it
* emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as
present on rpi 400 and some rpi 4B boards) has different values for
these then the B0T revision. So these need to be adjusted to boot on
these boards
* blconfig: The firmware defines the memory area where the blconfig
stored. Copy those over so it can be enabled.
* /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage
of that.
So my question is, why don't you want to use the devicetree provided by the
firmware in the first place?
Wouldn't that fix all the problems you have?
Regards,
Matthias
Signed-off-by: Sjoerd Simons
---
board/raspberrypi/rpi/rpi.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 55afaa54d9f..cdde32c8143 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -499,10 +499,58 @@ void *board_fdt_blob_setup(int *err)
return (void *)fw_dtb_pointer;
}
+int copy_property(void *dst, void *src, char *path, char *property)
+{
+ int dst_offset, src_offset;
+ const fdt32_t *prop;
+ int len;
+
+ src_offset = fdt_path_offset(src, path);
+ dst_offset = fdt_path_offset(dst, path);
+
+ if (src_offset < 0 || dst_offset < 0)
+ return -1;
+
+ prop = fdt_getprop(src, src_offset, property, );
+ if (!prop)
+ return -1;
+
+ return fdt_setprop(dst, dst_offset, property, prop, len);
+}
+
+/* Copy tweaks from the firmware dtb to the loaded dtb */
+void update_fdt_from_fw(void *fdt, void *fw_fdt)
+{
+ /* Using dtb from firmware directly; leave it alone */
+ if (fdt == fw_fdt)
+ return;
+
+ /* The firmware provides a more precie model; so copy that */
+ copy_property(fdt, fw_fdt, "/", "model");
+
+ /* memory reserve as suggested by the firmware */
+ copy_property(fdt, fw_fdt, "/", "memreserve");
+
+ /* Adjust dma-ranges for the SD card and PCI bus as they can depend on
+* the SoC revision
+*/
+ copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");
+ copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");
+
+ /* Bootloader configuration template exposes as nvmem */
+ if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)
+ copy_property(fdt, fw_fdt, "blconfig", "status");
+
+ /* kernel address randomisation seed as provided by the firmware */
+ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
+}
+
int ft_board_setup(void *blob, struct bd_info *bd)
{
int node;
+ update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
+
node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
if (node < 0)
lcd_dt_simplefb_add_node(blob);
Re: [PATCH 3/7] common: rename functions lcd_dt_simplefb to fdt_simplefb
On 15/11/2021 16:32, Patrick Delaunay wrote:
Rename the function named lcd_dt_simplefb* to fdt_simplefb* to be aligned
with the associated file name fdt_simplefb.h/fdt_simplefb.c
Signed-off-by: Patrick Delaunay
Reviewed-by: Matthias Brugger
---
board/raspberrypi/rpi/rpi.c | 2 +-
common/fdt_simplefb.c | 10 +-
include/fdt_simplefb.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 55afaa54d9..cd7d6df2a5 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -505,7 +505,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
if (node < 0)
- lcd_dt_simplefb_add_node(blob);
+ fdt_simplefb_add_node(blob);
#ifdef CONFIG_EFI_LOADER
/* Reserve the spin table */
diff --git a/common/fdt_simplefb.c b/common/fdt_simplefb.c
index 1650615cdb..32173030ab 100644
--- a/common/fdt_simplefb.c
+++ b/common/fdt_simplefb.c
@@ -16,7 +16,7 @@
DECLARE_GLOBAL_DATA_PTR;
-static int lcd_dt_simplefb_configure_node(void *blob, int off)
+static int fdt_simplefb_configure_node(void *blob, int off)
{
int xsize, ysize;
int bpix; /* log2 of bits per pixel */
@@ -58,7 +58,7 @@ static int lcd_dt_simplefb_configure_node(void *blob, int off)
xsize * (1 << bpix) / 8, name);
}
-int lcd_dt_simplefb_add_node(void *blob)
+int fdt_simplefb_add_node(void *blob)
{
static const char compat[] = "simple-framebuffer";
static const char disabled[] = "disabled";
@@ -76,10 +76,10 @@ int lcd_dt_simplefb_add_node(void *blob)
if (ret < 0)
return -1;
- return lcd_dt_simplefb_configure_node(blob, off);
+ return fdt_simplefb_configure_node(blob, off);
}
-int lcd_dt_simplefb_enable_existing_node(void *blob)
+int fdt_simplefb_enable_existing_node(void *blob)
{
int off;
@@ -87,5 +87,5 @@ int lcd_dt_simplefb_enable_existing_node(void *blob)
if (off < 0)
return -1;
- return lcd_dt_simplefb_configure_node(blob, off);
+ return fdt_simplefb_configure_node(blob, off);
}
diff --git a/include/fdt_simplefb.h b/include/fdt_simplefb.h
index 7cc305e1fd..7e54723591 100644
--- a/include/fdt_simplefb.h
+++ b/include/fdt_simplefb.h
@@ -8,6 +8,6 @@
#ifndef _FDT_SIMPLEFB_H_
#define _FDT_SIMPLEFB_H_
-int lcd_dt_simplefb_add_node(void *blob);
-int lcd_dt_simplefb_enable_existing_node(void *blob);
+int fdt_simplefb_add_node(void *blob);
+int fdt_simplefb_enable_existing_node(void *blob);
#endif
Re: [PATCH 1/7] Convert CONFIG_LCD_DT_SIMPLEFB to Kconfig
On 15/11/2021 16:32, Patrick Delaunay wrote: This converts the following to Kconfig: CONFIG_LCD_DT_SIMPLEFB This patch also renames this config to CONFIG_FDT_SIMPLEFB as the code in common/lcd_simplefb.c support CONFIG_LCD and CONFIG_VIDEO. Signed-off-by: Patrick Delaunay Reviewed-by: Matthias Brugger --- common/Kconfig | 9 + common/Makefile| 2 +- configs/rpi_0_w_defconfig | 1 + configs/rpi_2_defconfig| 1 + configs/rpi_3_32b_defconfig| 1 + configs/rpi_3_b_plus_defconfig | 1 + configs/rpi_3_defconfig| 1 + configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 1 + configs/rpi_arm64_defconfig| 1 + configs/rpi_defconfig | 1 + include/configs/rpi.h | 1 - scripts/config_whitelist.txt | 1 - 13 files changed, 19 insertions(+), 3 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index fdcf4536d0..c97814c6ad 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -766,3 +766,12 @@ config SPL_IMAGE_SIGN_INFO Enable image_sign_info helper functions in SPL. endif + +config FDT_SIMPLEFB + bool "FDT tools for simplefb support" + depends on OF_LIBFDT + help + Enable the fdt tools to manage the simple fb nodes in device tree. + These functions can be used by board to indicate to the OS + the presence of the simple frame buffer with associated reserved + memory diff --git a/common/Makefile b/common/Makefile index c500bcd7d8..fed7e482e6 100644 --- a/common/Makefile +++ b/common/Makefile @@ -40,7 +40,7 @@ ifndef CONFIG_DM_VIDEO obj-$(CONFIG_LCD) += lcd.o lcd_console.o endif obj-$(CONFIG_LCD_ROTATION) += lcd_console_rotation.o -obj-$(CONFIG_LCD_DT_SIMPLEFB) += lcd_simplefb.o +obj-$(CONFIG_FDT_SIMPLEFB) += lcd_simplefb.o obj-$(CONFIG_MENU) += menu.o obj-$(CONFIG_UPDATE_COMMON) += update.o obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index 6d76d12910..195541c6e7 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -13,6 +13,7 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 1931607132..eb63fbdd8d 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -14,6 +14,7 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig index 060fd36da5..46102899f0 100644 --- a/configs/rpi_3_32b_defconfig +++ b/configs/rpi_3_32b_defconfig @@ -15,6 +15,7 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y diff --git a/configs/rpi_3_b_plus_defconfig b/configs/rpi_3_b_plus_defconfig index 0a69f97342..91b63b6272 100644 --- a/configs/rpi_3_b_plus_defconfig +++ b/configs/rpi_3_b_plus_defconfig @@ -14,6 +14,7 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig index 8016fe1d55..528b12ea5b 100644 --- a/configs/rpi_3_defconfig +++ b/configs/rpi_3_defconfig @@ -14,6 +14,7 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 990589de64..88f7504a60 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -12,6 +12,7 @@ CONFIG_PREBOOT="pci enum; usb start;" # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 0720505c6a..59a7103154 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -12,6 +12,7 @@ CONFIG_PREBOOT="pci enum; usb start;" # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_FDT_SIMPLEFB=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_d
Re: [PATCH 4/7] common: board_r: drop initr_addr_map wrapper
On 30/10/2021 08:51, Ovidiu Panait wrote:
Add a return value to init_addr_map and use it directly in the
post-relocation init sequence, rather than using a wrapper stub.
Signed-off-by: Ovidiu Panait
---
arch/arm/include/asm/mmu.h | 2 +-
arch/arm/mach-bcm283x/init.c | 4 +++-
arch/powerpc/cpu/mpc85xx/tlb.c | 4 ++--
arch/powerpc/include/asm/mmu.h | 2 +-
common/board_r.c | 11 +--
5 files changed, 8 insertions(+), 15 deletions(-)
[...]
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 9803499985..183650a90a 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -152,7 +152,7 @@ int mach_cpu_init(void)
#include
#include
-void init_addr_map(void)
+int init_addr_map(void)
{
mmu_set_region_dcache_behaviour_phys(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
For the bcm283x part:
Reviewed-by: Matthias Brugger
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 22/10/2021 17:09, Tom Rini wrote: On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: On Fri, 22 Oct 2021 12:09:19 +0200 Heinrich Schuchardt wrote: On 10/21/21 15:00, Marek Behún wrote: BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu platform in Kconfig? We should only use 'imply' for suggested settings and never for hard requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it for mvebu would be redundant. In an OS distribution we only want to ship a single version of mkimage. So it is good to elimate symbol CONFIG_MXS. How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. Tom wrote regarding this aspect in https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: "if we're building a generically useful tool, we don't want another symbol for it." OK, so mkimage and dumpimage should be always generic and always support all platforms, that makes sense, since the tools can be installed as a distribution package. But I still think it should be possible to cripple these tools if the developer wants to disable libcrypto due to embedded environment. This is probably the time to reach out to some of the distro folks to see how they would like to see things handled for "build the tools we need to package for the user" and also "build the binary for the platform". in openSUSE we are building the tools for each u-boot binary but those are not part of our u-boot-tools package. For that package we use sandbox_defconfig to only build the tools. So we are using openSSL in our packaging. AFAIK that's not an issue for us. Regards, Matthias
Re: [PATCH] socfpga: enable EFI partition support for de0-nano-soc
On 22/10/2021 19:59, Frank Kunz wrote: This fixes boot problems with distributions that use EFI boot like opensuse. Signed-off-by: Frank Kunz Reviewed-by: Matthias Brugger --- configs/socfpga_de0_nano_soc_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/socfpga_de0_nano_soc_defconfig b/configs/socfpga_de0_nano_soc_defconfig index 17c160dd2a..3068f5615a 100644 --- a/configs/socfpga_de0_nano_soc_defconfig +++ b/configs/socfpga_de0_nano_soc_defconfig @@ -35,7 +35,7 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)" CONFIG_CMD_UBI=y # CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_VERSION_VARIABLE=y
Re: [ANN] U-Boot v2021.10 released
Hi Wolfgang, On 05/10/2021 13:01, Wolfgang Denk wrote: Dear Tom, In message <20211004151108.GR31748@bill-the-cat> you wrote: In terms of a changelog, git log --merges v2021.10-rc4..v2021.10-rc5 contains what I've pulled since the last RC or: git log --merges v2021.07..v2021.10 for changes since the last full release. As always, more details in pull requests (or the tags referenced by them) will result in more details here. ...and as usual, the release statistics can be fount at [1] [1] http://www.denx.de/wiki/U-Boot/UbootStat_2021_10 Here is the abbreviated version: (Changes since v2021.07) * Processed 1509 csets from 176 developers * 27 employers found * A total of 98664 lines added, 74614 removed (delta 24050) [...] Employers with the most signoffs (total 325) Texas Instruments 137 (42.2%) Xilinx 44 (13.5%) (Unknown) 39 (12.0%) BayLibre SAS35 (10.8%) NXP 15 (4.6%) Konsulko Group 13 (4.0%) ARM 10 (3.1%) Rockchip 6 (1.8%) Toradex 4 (1.2%) Novell 4 (1.2%) ... I wasn't able to find any commits from Novell email addresses. I wonder if SUSE still maps to Novell, which would be a long-time oversight :) Are the script to generate this email available somewhere? Regards, Matthias
Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address
On 29/09/2021 23:05, Ricardo Salveti wrote:
On Wed, Sep 29, 2021 at 1:49 PM Matthias Brugger wrote:
On 29/09/2021 14:19, Mauro Salvini wrote:
Hi Matthias,
On 29/09/21 13:41, Matthias Brugger wrote:
Hi Mauro,
On 29/09/2021 12:14, Mauro Salvini wrote:
Hi Matthias
On 15/09/21 13:16, mbrugger at suse.com (Matthias Brugger) wrote:
Hi Mauro,
On 07/06/2021 11:27, Mauro Salvini wrote:
On 12/05/21 14:39, Mauro Salvini wrote:
Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.
When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Removing the fdt_addr variable in saved environment allows to boot.
With this patch set_fdt_addr() function always overwrite fdt_addr value.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
First of all sorry for the very late reply.
I'm hesitant to apply this patch, basically because it can break other setups
where people load a custom DTB to fdt_addr.
I wonder why you can't erase fdt_addr from your persistent storage. There is a
command called eraseenv that should to the job.
Sorry me too for the late reply.
So your suggestion is to erase the fdt_addr variable from the environment
each time one needs to "refresh" it (one example could be the situation that
I ponted out).
Yes, this could be the solution, but the need to delete the fdt_addr variable
when e.g. one changes the dtb loaded by rpi firmware should be documented
somewhere.
Hm, maybe I didn't understand the problem. My understanding is, that when you
save the environment with saveenv, you also save the fdt_addr. And that's a
problem because if you add a overlay later, the fdt_addr changed, which will
not be reflected. So my question was if you couldn't just delete the fdt_addr
variable from you saved environment so that when lateron you load overlays,
you won't hit the problem. >
My understanding was that you are setting a custom environment for your
boards, but later your customers might add a overlay via e.g. config.txt and
that will break booting the system.
But from your response it seems thats not what you are experiencing. Or do you
change the DTB loaded from FW in the U-Boot shell?
Maybe I wasn't too clear in my explanation ;-)
At every boot, u-boot executes set_fdt_addr() function. At the very first boot,
if nobody has changed the default u-boot environment built in u-boot, adding a
custom fdt_addr variable, this function saves the fdt_addr variable in
Which function are we talking about? Adding a custom fdt_addr can be done via
the CLI or by adding that to the U-Boot sources (include/configs/rpi.h) but not
through a 'function'.
Do you mean that in some script you made saveenv is called? I used overlays in
RPi and never had that problem.
Actually I'm a bit puzzled about the problem. Can you give me a step by step
reproducer, starting with which config I should use to compile U-Boot?
Yes, this issue only happens if you save the environment at least
once, as then on following boots it won't set the address based on
what the firmware uses, but instead restore the value from the saved
environment, which can be wrong.
So can't we just delete the environment variable before saving the environment?
Something like "env delete fdt_addr; saveenv" ?
Regards,
Matthias
I noticed the same when moving one sdcard between boards, and I was
only able to get it to boot correctly after removing the saved
environment.
Cheers,
Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address
On 29/09/2021 14:19, Mauro Salvini wrote:
Hi Matthias,
On 29/09/21 13:41, Matthias Brugger wrote:
Hi Mauro,
On 29/09/2021 12:14, Mauro Salvini wrote:
Hi Matthias
On 15/09/21 13:16, mbrugger at suse.com (Matthias Brugger) wrote:
Hi Mauro,
On 07/06/2021 11:27, Mauro Salvini wrote:
On 12/05/21 14:39, Mauro Salvini wrote:
Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.
When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Removing the fdt_addr variable in saved environment allows to boot.
With this patch set_fdt_addr() function always overwrite fdt_addr value.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
First of all sorry for the very late reply.
I'm hesitant to apply this patch, basically because it can break other setups
where people load a custom DTB to fdt_addr.
I wonder why you can't erase fdt_addr from your persistent storage. There is a
command called eraseenv that should to the job.
Sorry me too for the late reply.
So your suggestion is to erase the fdt_addr variable from the environment
each time one needs to "refresh" it (one example could be the situation that
I ponted out).
Yes, this could be the solution, but the need to delete the fdt_addr variable
when e.g. one changes the dtb loaded by rpi firmware should be documented
somewhere.
Hm, maybe I didn't understand the problem. My understanding is, that when you
save the environment with saveenv, you also save the fdt_addr. And that's a
problem because if you add a overlay later, the fdt_addr changed, which will
not be reflected. So my question was if you couldn't just delete the fdt_addr
variable from you saved environment so that when lateron you load overlays,
you won't hit the problem. >
My understanding was that you are setting a custom environment for your
boards, but later your customers might add a overlay via e.g. config.txt and
that will break booting the system.
But from your response it seems thats not what you are experiencing. Or do you
change the DTB loaded from FW in the U-Boot shell?
Maybe I wasn't too clear in my explanation ;-)
At every boot, u-boot executes set_fdt_addr() function. At the very first boot,
if nobody has changed the default u-boot environment built in u-boot, adding a
custom fdt_addr variable, this function saves the fdt_addr variable in
Which function are we talking about? Adding a custom fdt_addr can be done via
the CLI or by adding that to the U-Boot sources (include/configs/rpi.h) but not
through a 'function'.
Do you mean that in some script you made saveenv is called? I used overlays in
RPi and never had that problem.
Actually I'm a bit puzzled about the problem. Can you give me a step by step
reproducer, starting with which config I should use to compile U-Boot?
Regards,
Matthias
persistent u-boot env. Variable contains the address where RPI firmware has
loaded the dtb, passed to u-boot by RPI firmware.
This variable is not changed anymore by u-boot itself (to change it, you have to
use u-boot cli). If you still use the same dtb, loaded by the RPI firmware, it's
not a problem, because the fdt address computed by RPI firmware is always the
same at every boot, and equal to the one saved in persistent env. If you delete
the variable from saved env, at next boot it will be re-created in persistent
env, with the value from RPI firmware.
Suppose that after some time one changes the config.txt and adds an overlay.
On the next boot, RPI firmware applies the overlay, and the new fdt address
could be different from the one computed until last boot (why it changes, I
don't know).
But set_fdt_addr() function does not update the value in env, because fdt_addr
is set yet.
Then, u-boot uses the fdt from a wrong address, and, if it executes a script to
manupulate e.g. bootargs, you got the error.
Applying the patch, the variable will be saved at every boot, the the value
saved is always the right one. Conversely, as you pointed out, a fdt_addr
variable set in the persistent environment by the user will be overwritten.
Then, the best option should be to write somewhere in the documentation that, if
one loads the dtb using RPI firmware instead of u-boot, after changing
config.txt or the dtb itself, the fdt_addr variable in u-boot envir
[GIT PULL] rpi: updates for v2021.10 second round
Hi Tom, Last minute changes for v2021.10 but I think they are small enough to get into the release. First we have a problem on RPi4 when you stop and start USB via the console commands. That is fixed. Second Nicolas has changed job and now uses a generic email address for his communication. I'd like to see that in the mailmap rather sooner then later, as extra regression probability by this will be zero ;) Also probably not needed, you can find the CI pipeline here: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/9292 Please have a look and let me know. Regards, Matthias --- The following changes since commit 0b9bcf665cd98fe9db0956c894006b250a7d465f: Prepare v2021.10-rc5 (2021-09-27 09:34:20 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ tags/rpi-next-2021.10.2 for you to fetch changes up to 33166054c72716e46d492a0588f00900a9684a97: arm: rpi: perform XHCI firmware upload only once (2021-09-29 15:44:16 +0200) - fix usb stopt; usb start; bug - update Nicolas email address Marek Szyprowski (1): arm: rpi: perform XHCI firmware upload only once Nicolas Saenz Julienne (1): mailmap: Update mail address for Nicolas Saenz julienne .mailmap| 1 + arch/arm/mach-bcm283x/msg.c | 6 ++ 2 files changed, 7 insertions(+)
Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address
Hi Mauro,
On 29/09/2021 12:14, Mauro Salvini wrote:
Hi Matthias
On 15/09/21 13:16, mbrugger at suse.com (Matthias Brugger) wrote:
Hi Mauro,
On 07/06/2021 11:27, Mauro Salvini wrote:
On 12/05/21 14:39, Mauro Salvini wrote:
Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.
When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Removing the fdt_addr variable in saved environment allows to boot.
With this patch set_fdt_addr() function always overwrite fdt_addr value.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
First of all sorry for the very late reply.
I'm hesitant to apply this patch, basically because it can break other setups
where people load a custom DTB to fdt_addr.
I wonder why you can't erase fdt_addr from your persistent storage. There is a
command called eraseenv that should to the job.
Sorry me too for the late reply.
So your suggestion is to erase the fdt_addr variable from the environment each
time one needs to "refresh" it (one example could be the situation that I ponted
out).
Yes, this could be the solution, but the need to delete the fdt_addr variable
when e.g. one changes the dtb loaded by rpi firmware should be documented
somewhere.
Hm, maybe I didn't understand the problem. My understanding is, that when you
save the environment with saveenv, you also save the fdt_addr. And that's a
problem because if you add a overlay later, the fdt_addr changed, which will not
be reflected. So my question was if you couldn't just delete the fdt_addr
variable from you saved environment so that when lateron you load overlays, you
won't hit the problem.
My understanding was that you are setting a custom environment for your boards,
but later your customers might add a overlay via e.g. config.txt and that will
break booting the system.
But from your response it seems thats not what you are experiencing. Or do you
change the DTB loaded from FW in the U-Boot shell?
Regards,
Matthias
Thanks, regards
Mauro
Regards,
Matthias
Signed-off-by: Mauro Salvini
Cc: C?dric Schieli
Cc: Matthias Brugger
---
? board/raspberrypi/rpi/rpi.c | 3 ---
? 1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..611013471e 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -318,9 +318,6 @@ static void set_fdtfile(void)
?? */
? static void set_fdt_addr(void)
? {
-??? if (env_get("fdt_addr"))
-??? return;
-
? if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
? return;
Hi all,
kind ping.
Regards
Re: [PATCH] board: rpi: always set fdt_addr if provided by firmware
Hi Oleksandr,
Thanks for your patch.
There was the very same patch posted already, please follow-up in that thread
for any comments from your side:
https://patchwork.ozlabs.org/project/uboot/patch/20210512123945.25649-1-m.salv...@koansoftware.com/
Regards,
Matthias
On 25/09/2021 12:22, Oleksandr Suvorov wrote:
From: Ricardo Salveti
Otherwise if the env gets saved with an incorrect or different
fdt_addr (by moving sdcard between different rpi versions), it won't
be able to boot with the correct address.
This allows fdt_addr to always be in sync with what gets set by the
firmware.
Signed-off-by: Ricardo Salveti
Signed-off-by: Oleksandr Suvorov
---
board/raspberrypi/rpi/rpi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 372b26b6f2..e12f8c0c31 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -318,9 +318,6 @@ static void set_fdtfile(void)
*/
static void set_fdt_addr(void)
{
- if (env_get("fdt_addr"))
- return;
-
if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
return;
Re: [PATCH] arm: rpi: perform XHCI firmware upload only once
On 17/09/2021 10:42, Matthias Brugger wrote: On 17/09/2021 10:19, Marek Szyprowski wrote: XHCI firmware upload must be performed only once after initializing the PCI bridge. This fixes USB stack initialization after calling "usb stop; usb start" on Raspberry Pi 4B. Signed-off-by: Marek Szyprowski Looks good to me. I'll wait a bit more to see if Nicolas can do a review as well before queuing it. There was a race condition, I'll queque it now :) Regards, Matthias --- arch/arm/mach-bcm283x/msg.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c index 347aece3cd..345f7fe2b7 100644 --- a/arch/arm/mach-bcm283x/msg.c +++ b/arch/arm/mach-bcm283x/msg.c @@ -170,6 +170,12 @@ int bcm2711_notify_vl805_reset(void) ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset, msg_notify_vl805_reset, 1); int ret; + static int done = false; + + if (done) + return 0; + + done = true; BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset); BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,
Re: [PATCH] arm: rpi: perform XHCI firmware upload only once
On 17/09/2021 10:19, Marek Szyprowski wrote: XHCI firmware upload must be performed only once after initializing the PCI bridge. This fixes USB stack initialization after calling "usb stop; usb start" on Raspberry Pi 4B. Signed-off-by: Marek Szyprowski Looks good to me. I'll wait a bit more to see if Nicolas can do a review as well before queuing it. Regards, Matthias --- arch/arm/mach-bcm283x/msg.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c index 347aece3cd..345f7fe2b7 100644 --- a/arch/arm/mach-bcm283x/msg.c +++ b/arch/arm/mach-bcm283x/msg.c @@ -170,6 +170,12 @@ int bcm2711_notify_vl805_reset(void) ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset, msg_notify_vl805_reset, 1); int ret; + static int done = false; + + if (done) + return 0; + + done = true; BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset); BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,
Re: [PATCH] mailmap: Update mail address for Nicolas Saenz julienne
On 16/09/2021 11:55, Nicolas Saenz Julienne wrote: From: Nicolas Saenz Julienne The @suse.de address doesn't exist anymore. Update it to something not dependent on my workplace. Signed-off-by: Nicolas Saenz Julienne Thanks for doing this to keep you in the loop on RPi stuff going on. Reviewed-by: Matthias Brugger --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index b76f02283c..b09fc321bd 100644 --- a/.mailmap +++ b/.mailmap @@ -32,6 +32,7 @@ Jagan Teki Igor Opaniuk Igor Opaniuk Markus Klotzbuecher +Nicolas Saenz Julienne Patrice Chotard Patrick Delaunay Paul Burton
[GIT PULL] rpi: updates for v2021.10
Hi Tom,
I know, quite a bit late but here come the updates for RPi for v2021.10.
Actually most of the patches are fixes.
Ivan's patch fixes a kernel warning when booting RPi2, as the firmware already
provides a frambebuffer node.
Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.
My SMBIOS patchesfixes an issue that show up with
e4f8e543f1 ("smbios: Drop the unused Kconfig options").
Basically the SMBIOS table broke and wasn't readable anymore.
I think we can argue if the last one is a real fix. In case you just want to
take the first two so late in the cycle, let me know and I can provide you with
a separate pull request.
Regards,
Matthias
---
The following changes since commit bb92678ced0b1594b93ab2f10b2c17750c789c96:
Prepare v2021.10-rc4 (2021-09-14 18:58:10 -0400)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ rpi-next
for you to fetch changes up to acc6987e59137485dbac0ee4a07cc349210954f3:
rpi: Conditionally add simple-framebuffer node (2021-09-15 13:34:06 +0200)
Ivan T. Ivanov (1):
rpi: Conditionally add simple-framebuffer node
Marek Szyprowski (1):
ARM: bcm283x: change the virtual address of the XHCI PCI device base
Matthias Brugger (2):
arm: dts: bcm283x: Add minimal smbios information
configs: rpi: Enable SMBIOS sysinfo driver
arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++
arch/arm/mach-bcm283x/init.c | 4 ++--
board/raspberrypi/rpi/rpi.c | 11 +--
configs/rpi_0_w_defconfig| 2 ++
configs/rpi_2_defconfig | 2 ++
configs/rpi_3_32b_defconfig | 2 ++
configs/rpi_3_b_plus_defconfig | 2 ++
configs/rpi_3_defconfig | 2 ++
configs/rpi_4_32b_defconfig | 2 ++
configs/rpi_4_defconfig | 2 ++
configs/rpi_arm64_defconfig | 2 ++
configs/rpi_defconfig| 2 ++
12 files changed, 44 insertions(+), 8 deletions(-)
Re: [PATCH] rpi: Conditionally add simple-framebuffer node
On 10/08/2021 16:31, Ivan T. Ivanov wrote:
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
Applied to rpi-next now.
Thanks,
Matthias
---
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 */
Re: [PATCH v2 1/2] arm: dts: bcm283x: Add minimal smbios information
On 12/04/2021 15:38, matthias@kernel.org wrote:
From: Matthias Brugger
At present SMBIOS tables are empty, which breaks some use-cases that
rely on that. Add some minimal information to fulfill this.
Signed-off-by: Matthias Brugger
Both patches now queued in rpi-next.
---
Changes in v2:
- drop product from chassi
- fix typo in commit message
arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi b/arch/arm/dts/bcm283x-u-boot.dtsi
index 68d03627f4..22c67c4218 100644
--- a/arch/arm/dts/bcm283x-u-boot.dtsi
+++ b/arch/arm/dts/bcm283x-u-boot.dtsi
@@ -6,6 +6,25 @@
* (C) Copyright 2016 Fabian Vogt
*/
+/ {
+ smbios {
+ compatible = "u-boot,sysinfo-smbios";
+ smbios {
+ system {
+ manufacturer = "raspberrypi";
+ product = "rpi";
+ };
+ baseboard {
+ manufacturer = "raspberrypi";
+ product = "rpi";
+ };
+ chassis {
+ manufacturer = "raspberrypi";
+ };
+ };
+ };
+};
+
{
skip-init;
u-boot,dm-pre-reloc;
Re: [PATCH] ARM: bcm283x: change the virtual address of the XHCI PCI device base
On 17/06/2021 11:22, Marek Szyprowski wrote:
Move the XHCI PCI device base up in the virtual address space. This fixes
initialization failure observed with newer Raspberry Pi firmware, later
than 63b1922311 ("firmware: arm_loader: Update armstubs with those from
PR 117). It looks that chosing 0xff80 as the XHCI PCI device base
conflicts with the updated ARM/VideoCore firmware.
This also requires to reduce the size of the mapped PCI device region
from 8MiB to 4MiB to fit into 32bit address space. This is still enough
for the XHCI PCI device.
Signed-off-by: Marek Szyprowski
Queued in rpi-next now.
Thanks,
Matthias
---
This fixes the issue observed on ARM 32bit after upgrading the RPi4
firmware files, described some time ago here:
https://lists.denx.de/pipermail/u-boot/2021-February/442317.html
---
arch/arm/mach-bcm283x/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 49027ce0a2..9803499985 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -14,7 +14,7 @@
#include
#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS 0x6UL
-#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x80UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x40UL
#ifdef CONFIG_ARM64
#include
@@ -148,7 +148,7 @@ int mach_cpu_init(void)
#ifdef CONFIG_ARMV7_LPAE
#ifdef CONFIG_TARGET_RPI_4_32B
-#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xffc0UL
#include
#include
Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address
Hi Mauro,
On 07/06/2021 11:27, Mauro Salvini wrote:
On 12/05/21 14:39, Mauro Salvini wrote:
Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.
When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Removing the fdt_addr variable in saved environment allows to boot.
With this patch set_fdt_addr() function always overwrite fdt_addr value.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
First of all sorry for the very late reply.
I'm hesitant to apply this patch, basically because it can break other setups
where people load a custom DTB to fdt_addr.
I wonder why you can't erase fdt_addr from your persistent storage. There is a
command called eraseenv that should to the job.
Regards,
Matthias
Signed-off-by: Mauro Salvini
Cc: Cédric Schieli
Cc: Matthias Brugger
---
board/raspberrypi/rpi/rpi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..611013471e 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -318,9 +318,6 @@ static void set_fdtfile(void)
*/
static void set_fdt_addr(void)
{
- if (env_get("fdt_addr"))
- return;
-
if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
return;
Hi all,
kind ping.
Regards
Re: Bug: qemu_arm64: Cannot access the second flash bank
On 13/09/2021 11:40, Peter Maydell wrote:
On Mon, 13 Sept 2021 at 10:31, Matthias Brugger wrote:
Hi Robin,
It's a long long time that you reported this issue.
I prepared a fix in qemu for it. Would you mind to try it out? You can find a
branch with the fix on top here:
https://github.com/mbgg/qemu/tree/vrit-flash-dtb-bug
Basically I fix the reg property to reflect the fact that the size-cell is one.
Isn't #size-cells here inherited from the fdt root node (where we
set it to 2) ?
Yes, you are right. After a lot of digging I realized that this should be
fixed, by:
492b9917c68 ("cfi_flash: Fix devicetree address determination")
ae6b33dcc34 ("dm: fix ofnode_read_addr/size_cells()")
Sorry for the noise.
Matthias
Re: Bug: qemu_arm64: Cannot access the second flash bank
Hi Robin,
It's a long long time that you reported this issue.
I prepared a fix in qemu for it. Would you mind to try it out? You can find a
branch with the fix on top here:
https://github.com/mbgg/qemu/tree/vrit-flash-dtb-bug
Basically I fix the reg property to reflect the fact that the size-cell is one.
Please let me know if that fixes the issue for you and I'll send the fix
upstream.
Regards,
Matthias
On 01/01/2020 19:20, Robin Randhawa wrote:
Hi folks.
[CC'ing some hopefully relevant folks].
As of:
commit 0ba41ce1b7816c229cc19e0621148b98f990cb68
libfdt: return correct value if #size-cells property is not present
.. accesses to the second flash bank on the qemu_arm64 virtual board
appear broken.
To demonstrate, consider that the physical memory map for the 2 flash
banks is:
Bank 1: 0x_ - 0x03FC_
Bank 2: 0x0400_ - 0x7FC0_
Now, consider the abbreviated output of the flinfo command pre and post
the above commit:
Pre:
===
=> flinfo
Bank # 1: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
Erase timeout: 16384 ms, write timeout: 3 ms
Buffer write timeout: 3 ms, buffer size: 2048 bytes
Sector Start Addresses:
RO 0004 RO 0008 RO 000C0010
00140018001C00200024
.
.
03E803EC03F003F403F8
03FC
Bank # 2: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
Erase timeout: 16384 ms, write timeout: 3 ms
Buffer write timeout: 3 ms, buffer size: 2048 bytes
Sector Start Addresses:
0400 RO 04040408040C0410
04140418041C04200424
.
.
07E807EC07F007F407F8
07FC
Post:
=> flinfo
Bank # 1: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
Erase timeout: 16384 ms, write timeout: 3 ms
Buffer write timeout: 3 ms, buffer size: 2048 bytes
Sector Start Addresses:
RO 0004 RO 0008 RO 000C0010
00140018001C00200024
.
.
03E803EC03F003F403F8
03FC
Bank # 2: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
Erase timeout: 16384 ms, write timeout: 3 ms
Buffer write timeout: 3 ms, buffer size: 2048 bytes
Sector Start Addresses:
400404408
40C410
41441841C
420424
.
.
40003E840003EC40003F040
003F440003F8
40003FC
As a result, the second bank is unusable for environment stores
(CONFIG_ENV_ADDR is 0x400):
=> saveenv
Saving Environment to Flash... Error: start and/or end address not on
sector boundary
Error: start and/or end address not on sector boundary
Failed (1)
Rewinding the u-boot repo to before this commit fixes the problem.
Manually (uncleanly) reverting the commit and it's dependent commits
fixes the problem.
Here are the HEAD commits from the relevant repos that I used for the data
above:
qemu: commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc
u-boot: commit 6cb87cbb1475f668689f95911d1521ee6ba7f55c
Here is the qemu invocation I used:
$ dd if=/dev/zero of=./flash0-with-uboot.img bs=1M count=64 && dd
if=/path/to/u-boot.bin of=./flash0-with-uboot.img conv=notrunc
$ qemu-system-aarch64 -M virt -cpu cortex-a53 -m 1024M -nographic -drive
if=pflash,format=raw,index=0,file=flash0-with-uboot.img -drive
if=pflash,format=raw,index=1,file=flash1.img
I'm happy to help test any fixes if and as needed.
Cheers,
Robin
Re: [PATCH] btrfs: Use default subvolume as filesystem root
On 01/09/2021 13:36, Tom Rini wrote: > On Wed, Sep 01, 2021 at 01:28:30PM +0200, Matthias Brugger wrote: >> Hi Tom, >> >> On 02/08/2021 01:06, Qu Wenruo wrote: >>> >>> >>> On 2021/8/2 上午4:52, Matwey V. Kornilov wrote: >>>> BTRFS volume consists of a number of subvolumes which can be mounted >>>> separately >>>> from each other. The top-level subvolume always exists even if no >>>> subvolumes >>>> were created manually. A subvolume can be denoted as the default subvolume >>>> i.e. >>>> the subvolume which is mounted by default. >>>> >>>> The default "default subvolume" is the top-level one, but this is far from >>>> the >>>> common practices used in the wild. For instance, openSUSE provides an OS >>>> snapshot/rollback feature based on BTRFS. To achieve this, the actual OS >>>> root >>>> filesystem is located into a separate subvolume which is "default" but not >>>> "top-level". That means that the /boot/dtb/ directory is also located >>>> inside >>>> this default subvolume instead of top-level one. >>>> >>>> However, the existing btrfs u-boot driver always uses the top-level >>>> subvolume >>>> as the filesystem root. This behaviour 1) is inconsistent with >>>> >>>> mount /dev/sda1 /target >>>> >>>> command, which mount the default subvolume 2) leads to the issues when >>>> /boot/dtb cannot be found properly (see the reference). >>> >>> I also noticed the problem in the past, but forgot to fix it >>> >>>> >>>> This patch uses the default subvolume as the filesystem root to overcome >>>> mentioned issues. >>>> >>>> Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656 >>>> Signed-off-by: Matwey V. Kornilov >>> >>> Reviewed-by: Qu Wenruo >>> >> >> I can see that this patch is marked in your patchwork queue as "Need Review / >> ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart >> from >> that we have it running on openSUSE on top of v2021.07 for some time without >> any >> issues. > > Ah, yup. Qu is one of the people I do look for to have reviewed a btrfs > patch before I apply it (and I throw things under Need Review / ACK as a > note-to-self to make sure a patch does have one, when I can expect one, > before applying, FWIW). > >> Would it be possible to merge this for v2021.10 or do you see any blocker >> here? > > I think I had mentally filed it was feature not bugfix and was going to > hold off, but since you're asking, yes, I can grab it for this release. > Thanks! > It's a bugfix, as loading files from BTRFS, at least in openSUSE does not work without it. Thanks for the quick answer! Matthias
Re: [PATCH] btrfs: Use default subvolume as filesystem root
Hi Tom,
On 02/08/2021 01:06, Qu Wenruo wrote:
>
>
> On 2021/8/2 上午4:52, Matwey V. Kornilov wrote:
>> BTRFS volume consists of a number of subvolumes which can be mounted
>> separately
>> from each other. The top-level subvolume always exists even if no subvolumes
>> were created manually. A subvolume can be denoted as the default subvolume
>> i.e.
>> the subvolume which is mounted by default.
>>
>> The default "default subvolume" is the top-level one, but this is far from
>> the
>> common practices used in the wild. For instance, openSUSE provides an OS
>> snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
>> filesystem is located into a separate subvolume which is "default" but not
>> "top-level". That means that the /boot/dtb/ directory is also located inside
>> this default subvolume instead of top-level one.
>>
>> However, the existing btrfs u-boot driver always uses the top-level subvolume
>> as the filesystem root. This behaviour 1) is inconsistent with
>>
>> mount /dev/sda1 /target
>>
>> command, which mount the default subvolume 2) leads to the issues when
>> /boot/dtb cannot be found properly (see the reference).
>
> I also noticed the problem in the past, but forgot to fix it
>
>>
>> This patch uses the default subvolume as the filesystem root to overcome
>> mentioned issues.
>>
>> Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
>> Signed-off-by: Matwey V. Kornilov
>
> Reviewed-by: Qu Wenruo
>
I can see that this patch is marked in your patchwork queue as "Need Review /
ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart from
that we have it running on openSUSE on top of v2021.07 for some time without any
issues.
Would it be possible to merge this for v2021.10 or do you see any blocker here?
Regards,
Matthias
> Thanks,
> Qu
>
>> ---
>> fs/btrfs/disk-io.c | 38 +++---
>> 1 file changed, 35 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>> index 349411c3cc..12f9579fcf 100644
>> --- a/fs/btrfs/disk-io.c
>> +++ b/fs/btrfs/disk-io.c
>> @@ -804,6 +804,30 @@ static int setup_root_or_create_block(struct
>> btrfs_fs_info *fs_info,
>> return 0;
>> }
>> +static int get_default_subvolume(struct btrfs_fs_info *fs_info,
>> + struct btrfs_key *key_ret)
>> +{
>> + struct btrfs_root *root = fs_info->tree_root;
>> + struct btrfs_dir_item *dir_item;
>> + struct btrfs_path path;
>> + int ret = 0;
>> +
>> + btrfs_init_path();
>> +
>> + dir_item = btrfs_lookup_dir_item(NULL, root, ,
>> + BTRFS_ROOT_TREE_DIR_OBJECTID,
>> + "default", 7, 0);
>> + if (IS_ERR(dir_item)) {
>> + ret = PTR_ERR(dir_item);
>> + goto out;
>> + }
>> +
>> + btrfs_dir_item_key_to_cpu(path.nodes[0], dir_item, key_ret);
>> +out:
>> + btrfs_release_path();
>> + return ret;
>> +}
>> +
>> int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info)
>> {
>> struct btrfs_super_block *sb = fs_info->super_copy;
>> @@ -833,9 +857,17 @@ int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info)
>> fs_info->last_trans_committed = generation;
>> - key.objectid = BTRFS_FS_TREE_OBJECTID;
>> - key.type = BTRFS_ROOT_ITEM_KEY;
>> - key.offset = (u64)-1;
>> + ret = get_default_subvolume(fs_info, );
>> + if (ret) {
>> + /*
>> + * The default dir item isn't there. Linux kernel behaviour is
>> + * to silently use the top-level subvolume in this case.
>> + */
>> + key.objectid = BTRFS_FS_TREE_OBJECTID;
>> + key.type = BTRFS_ROOT_ITEM_KEY;
>> + key.offset = (u64)-1;
>> + }
>> +
>> fs_info->fs_root = btrfs_read_fs_root(fs_info, );
>> if (IS_ERR(fs_info->fs_root))
>>
>
Re: [PATCH v3] usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig
On 01/06/2021 13:21, Aswath Govindraju wrote: > Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and > CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/.h > files and also in _defconfig files without a Kconfig option. It > is easier for users to set these configs in defconfig files than in config > header files as they are a part of the source code. > > Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py > script. > > Suggested-by: Pratyush Yadav > Signed-off-by: Aswath Govindraju > Acked-by: Oleksandr Suvorov For Raspberry Pi parts: Acked-by: Matthias Brugger > --- > > Changes since v2: > - Rebased the patch on top of current HEAD > - Picked up Oleksandr Suvorov's Acked-by > > Link to v2 patch, > https://patchwork.ozlabs.org/project/uboot/patch/20210226071849.29070-1-a-govindr...@ti.com/ > > Changes since v1: > - Removed CONFIG_SYS_DFU_MAX_FILE_SIZE in defconfig files, where it was > not defined previously. The list of files in which this change is made > are listed below, > configs/colibri-imx6ull_defconfig > configs/colibri_vf_defconfig > configs/corvus_defconfig > configs/dh_imx6_defconfig > configs/draco_defconfig > configs/etamin_defconfig > configs/odroid-xu3_defconfig > configs/odroid_defconfig > configs/origen_defconfig > configs/pico-dwarf-imx6ul_defconfig > configs/pico-hobbit-imx6ul_defconfig > configs/pico-imx6_defconfig > configs/pico-imx6ul_defconfig > configs/pico-pi-imx6ul_defconfig > configs/pxm2_defconfig > configs/rastaban_defconfig > configs/rut_defconfig > configs/s5p_goni_defconfig > configs/s5pc210_universal_defconfig > configs/smartweb_defconfig > configs/socfpga_arria5_defconfig > configs/socfpga_cyclone5_defconfig > configs/socfpga_dbm_soc1_defconfig > configs/socfpga_de0_nano_soc_defconfig > configs/socfpga_de10_nano_defconfig > configs/socfpga_mcvevk_defconfig > configs/socfpga_sockit_defconfig > configs/socfpga_socrates_defconfig > configs/socfpga_vining_fpga_defconfig > configs/taurus_defconfig > configs/thuban_defconfig > configs/topic_miami_defconfig > configs/topic_miamilite_defconfig > configs/topic_miamiplus_defconfig > configs/trats2_defconfig > configs/trats_defconfig > configs/warp7_bl33_defconfig > configs/warp7_defconfig > configs/warp_defconfig > configs/xilinx_versal_virt_defconfig > configs/xilinx_zynq_virt_defconfig > configs/xilinx_zynqmp_virt_defconfig > > Link to v1, > https://patchwork.ozlabs.org/project/uboot/patch/20210223061427.20742-1-a-govindr...@ti.com/ > > > configs/am65x_evm_a53_defconfig | 2 ++ > configs/am65x_evm_r5_usbdfu_defconfig | 2 ++ > configs/am65x_hs_evm_a53_defconfig| 2 ++ > configs/beaver_defconfig | 2 ++ > configs/cei-tk1-som_defconfig | 2 ++ > configs/colibri-imx6ull_defconfig | 1 + > configs/colibri_vf_defconfig | 1 + > configs/corvus_defconfig | 1 + > configs/dalmore_defconfig | 2 ++ > configs/dh_imx6_defconfig | 1 + > configs/draco_defconfig | 1 + > configs/etamin_defconfig | 1 + > configs/jetson-tk1_defconfig | 2 ++ > configs/nyan-big_defconfig| 2 ++ > configs/odroid-xu3_defconfig | 1 + > configs/odroid_defconfig | 1 + > configs/origen_defconfig | 1 + > configs/p2371-_defconfig | 2 ++ > configs/p2371-2180_defconfig | 2 ++ > configs/p2571_defconfig | 2 ++ > configs/p3450-_defconfig | 2 ++ > configs/pico-dwarf-imx6ul_defconfig | 1 + > configs/pico-hobbit-imx6ul_defconfig | 1 + > configs/pico-imx6_defconfig | 1 + > configs/pico-imx6ul_defconfig | 1 + > configs/pico-pi-imx6ul_defconfig | 1 + > configs/pxm2_defconfig| 1 + > configs/rastaban_defconfig| 1 + > configs/rpi_4_32b_defconfig | 2 ++ > configs/rpi_4_defconfig | 2 ++ > configs/rut_defconfig | 1 + > configs/s5p_goni_defconfig| 1 + > configs/s5pc210_universal_defconfig | 1 + > configs/smartweb_defconfig| 1 + > configs/socfpga_arria5_defconfig | 1 + > configs/socfpga_cyclone5_defconfig| 1 + > configs/socfpga_dbm_soc1_defconfig| 1 + > configs/socfpga_de0_nano_soc_defconfig| 1 + > configs/socfpga_de10_nano_defconfig
Re: [PATCH] Add support for Raspberry Pi 3B+(32bit)
On 20/04/2021 08:05, Toshifumi NISHINAGA wrote: > Hello all. > > I will add rpi_3_32b_plus_defconfig to easy to build u-boot for > Raspberry Pi 3B+(32bit). > Could you merge this patch? > This file is already present [1]. Please provide patches against the latest U-Boot tree. Is there anything missing in the config? Regards, Matthias [1] https://source.denx.de/u-boot/u-boot/-/blob/master/configs/rpi_3_b_plus_defconfig > Thanks, > Toshifumi NISHINAGA > > > From 28d13f48761ab7c137a5fdf07c76a857967e3590 Mon Sep 17 00:00:00 2001 > From: Toshifumi NISHINAGA > Date: Thu, 15 Apr 2021 16:53:33 +0900 > Subject: [PATCH] Add support for Raspberry Pi 3B+(32bit) > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > It also boots on Raspberry Pi 3B+ using rpi_3_32b_defconfig, > but the network card doesn't work. > > This defconfig is based on rpi_3_32b_defconfig. > > Signed-off-by: Toshifumi NISHINAGA > --- > > configs/rpi_3_32b_plus_defconfig | 46 > 1 file changed, 46 insertions(+) > create mode 100644 configs/rpi_3_32b_plus_defconfig > > diff --git a/configs/rpi_3_32b_plus_defconfig > b/configs/rpi_3_32b_plus_defconfig > new file mode 100644 > index 00..d147a46ae7 > --- /dev/null > +++ b/configs/rpi_3_32b_plus_defconfig > @@ -0,0 +1,46 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_CPU_INIT=y > +CONFIG_ARCH_BCM283X=y > +CONFIG_SYS_TEXT_BASE=0x8000 > +CONFIG_TARGET_RPI_3_32B=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_NR_DRAM_BANKS=1 > +CONFIG_ENV_SIZE=0x4000 > +CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b-plus" > +CONFIG_DISTRO_DEFAULTS=y > +CONFIG_OF_BOARD_SETUP=y > +CONFIG_USE_PREBOOT=y > +# CONFIG_DISPLAY_CPUINFO is not set > +# CONFIG_DISPLAY_BOARDINFO is not set > +CONFIG_MISC_INIT_R=y > +CONFIG_SYS_PROMPT="U-Boot> " > +CONFIG_CMD_GPIO=y > +CONFIG_CMD_MMC=y > +CONFIG_CMD_USB=y > +CONFIG_CMD_FS_UUID=y > +CONFIG_OF_EMBED=y > +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > +CONFIG_DM_MMC=y > +CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_BCM2835=y > +CONFIG_PHYLIB=y > +CONFIG_DM_ETH=y > +CONFIG_PINCTRL=y > +# CONFIG_PINCTRL_GENERIC is not set > +# CONFIG_REQUIRE_SERIAL_CONSOLE is not set > +CONFIG_USB=y > +CONFIG_DM_USB=y > +CONFIG_USB_DWC2=y > +CONFIG_USB_KEYBOARD=y > +CONFIG_USB_HOST_ETHER=y > +CONFIG_USB_ETHER_LAN78XX=y > +CONFIG_USB_ETHER_SMSC95XX=y > +CONFIG_DM_VIDEO=y > +# CONFIG_VIDEO_BPP8 is not set > +# CONFIG_VIDEO_BPP16 is not set > +CONFIG_SYS_WHITE_ON_BLACK=y > +CONFIG_CONSOLE_SCROLL_LINES=10 > +CONFIG_PHYS_TO_BUS=y > +CONFIG_OF_LIBFDT_OVERLAY=y >
Re: [PATCH 1/2] arm: dts: bcm283x: Add minimal smbios information
On Fri, Apr 09, 2021 at 03:13:25PM +0200, Fabian Vogt wrote:
> Am Freitag, 9. April 2021, 14:35:10 CEST schrieb matthias@kernel.org:
> > From: Matthias Brugger
> >
> > At present SMBIOS tables are emtpy,
> ^ typo
>
> > which breaks some use-cases that rely on that.
> Can you give an example?
Management software that want's to know what HW a node is based on.
>
> > Add some minimal information to
> Isn't it possible to get the complete information from the firmware here?
> That would allow to have the correct product and serial at least.
That's the plan for the long run.
> If that's not possible or too complex, then I suggest to use the proper
> strings, e.g. "Raspberry Pi", as those are user visible.
I'd like to stay backwards compatible to older U-Boot versions for now.
>
> > fullfill this.
> ^ typo
>
> > Signed-off-by: Matthias Brugger
> > ---
> >
> > arch/arm/dts/bcm283x-u-boot.dtsi | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> > b/arch/arm/dts/bcm283x-u-boot.dtsi
> > index 68d03627f4..f5235cb083 100644
> > --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> > +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> > @@ -6,6 +6,26 @@
> > * (C) Copyright 2016 Fabian Vogt
> > */
> >
> > +/ {
> > + smbios {
> > + compatible = "u-boot,sysinfo-smbios";
> > + smbios {
> > + system {
> > + manufacturer = "raspberrypi";
> > + product = "rpi";
> > + };
> > + baseboard {
> > + manufacturer = "raspberrypi";
> > + product = "rpi";
> > + };
> > + chassis {
> > + manufacturer = "raspberrypi";
> > + product = "rpi";
>
> According to doc/device-tree-bindings/sysinfo/smbios.txt, "chassis"
> doesn't have a "product".
>
You are correct. I'll fix the typos and this in the next version.
Regards,
Matthias
> Cheers,
> Fabian
>
> > + };
> > + };
> > + };
> > +};
> > +
> > {
> > skip-init;
> > u-boot,dm-pre-reloc;
> >
>
Re: Running u-boot 2021.04 on Raspberry Pi 4
On 09/04/2021 20:06, Roman Shaposhnik wrote:
> On Fri, Apr 9, 2021 at 3:15 AM Matthias Brugger wrote:
>
>>
>>
>> On 09/04/2021 10:14, Nicolas Saenz Julienne wrote:
>>> [ Adding Matthias for the SMBIOS part ]
>>>
>>> On Fri, 2021-04-09 at 00:00 -0700, Roman Shaposhnik wrote:
>>>> On Thu, Apr 8, 2021 at 8:59 PM Sean Anderson wrote:
>>>>> On 4/8/21 8:18 PM, Roman Shaposhnik wrote:
>>>>>> Hi!
>>>>>>
>>>>>> first time poster, long time lurker here. Over at Project EVE
>>>>>> https://github.com/lf-edge/eve I've been trying to migrate
>>>>>> from our current u-boot v2020.07 + patches:
>>>>>>
>>>>>>
>> https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
>>>>>> to the latest u-boot 2021.04.
>>>>>>
>>>>>> Great news is that most of the patches we dependent
>>>>>> on seem to have been pulled upstream. However, this
>>>>>> single *chunk* of one patchset wasn't:
>>>>>>
>>>>>>
>> https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293
>>>>>>
>>>>>> I'm wondering what was the reason for leaving it behind,
>>>>>
>>>>> +CC Nicolas
>>>>>
>>>>>> - Get rid of PCI core patch as not needed with correct DT PCI
>> topology
>>>>>
>>>>> also from the cover letter
>>>>>
>>>>>> This also depends on a DT/bindings patch available on the
>> linux-mailing lists:
>>>>>> https://www.mail-archive.com/linux-kernel@.../msg2205783.html
>>>>>
>>>>> The merged version of this series is
>>>>>
>>>>>
>> https://patchwork.kernel.org/project/linux-usb/list/?series=310015=%2A=both
>>>>>
>>>>>> Here is the relevant bit for reference/discussion:
>>>>>>
>>>>>> {
>>>>>> pci@1,0 {
>>>>>> #address-cells = <3>;
>>>>>> #size-cells = <2>;
>>>>>> ranges;
>>>>>>
>>>>>> reg = <0 0 0 0 0>;
>>>>>>
>>>>>> usb@1,0 {
>>>>>> reg = <0x1 0 0 0 0>;
>>>>>> resets = <
>> RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>
>>>
>>> Yes, instead of using a PCI quirk we settled on a reset controller. All
>> in all
>>> it is less hacky. But needs changes in DT.
>>>
>>>> Aha! Thank you so much -- this is super helpful!
>>>>
>>>>>> since without it I don't seem to have functioning USB
>>>>>> devices on my Raspberry Pi 4. In fact, adding it back:
>>>>>>
>>>>>>
>> https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
>>>>>> (just that one chunk -- 'cuz the reset got upstreamed)
>>>>>> seems to solve the issue for me.
>>>>>>
>>>>>> Another question I have is that the new u-boot seems to have
>>>>>> some kind of a regression that I can't quite debug. The SMBIOS
>>>>>> tables that it constructs during EFI boot sequence seem to be
>>>>>> broken (see the dmidecode output below). Again, this seems
>>>>>> to be a regression compared to v2020.07. Any ideas on what
>>>>>> could be wrong or how can I start debugging it would be
>>>>>
>>
>> Yes, that's not working right now. I'm working on a fix for the tables:
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias@kernel.org/
>>
>> This will fix the error en dmidecode but the tables will be basically
>> empty.
>> Before that there was some information that helped you to identify that
>> you are
>> running on a RaspberryPi.
>>
>> A quick fix would be to add that information to the DTS. Like for example
>> done here:
>>
>> https://sourc
Re: Running u-boot 2021.04 on Raspberry Pi 4
On 09/04/2021 10:14, Nicolas Saenz Julienne wrote:
> [ Adding Matthias for the SMBIOS part ]
>
> On Fri, 2021-04-09 at 00:00 -0700, Roman Shaposhnik wrote:
>> On Thu, Apr 8, 2021 at 8:59 PM Sean Anderson wrote:
>>> On 4/8/21 8:18 PM, Roman Shaposhnik wrote:
Hi!
first time poster, long time lurker here. Over at Project EVE
https://github.com/lf-edge/eve I've been trying to migrate
from our current u-boot v2020.07 + patches:
https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
to the latest u-boot 2021.04.
Great news is that most of the patches we dependent
on seem to have been pulled upstream. However, this
single *chunk* of one patchset wasn't:
https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293
I'm wondering what was the reason for leaving it behind,
>>>
>>> +CC Nicolas
>>>
- Get rid of PCI core patch as not needed with correct DT PCI topology
>>>
>>> also from the cover letter
>>>
This also depends on a DT/bindings patch available on the linux-mailing
lists:
https://www.mail-archive.com/linux-kernel@.../msg2205783.html
>>>
>>> The merged version of this series is
>>>
>>> https://patchwork.kernel.org/project/linux-usb/list/?series=310015=%2A=both
>>>
Here is the relevant bit for reference/discussion:
{
pci@1,0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
reg = <0 0 0 0 0>;
usb@1,0 {
reg = <0x1 0 0 0 0>;
resets = <
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
};
};
};
>>>
>
> Yes, instead of using a PCI quirk we settled on a reset controller. All in all
> it is less hacky. But needs changes in DT.
>
>> Aha! Thank you so much -- this is super helpful!
>>
since without it I don't seem to have functioning USB
devices on my Raspberry Pi 4. In fact, adding it back:
https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
(just that one chunk -- 'cuz the reset got upstreamed)
seems to solve the issue for me.
Another question I have is that the new u-boot seems to have
some kind of a regression that I can't quite debug. The SMBIOS
tables that it constructs during EFI boot sequence seem to be
broken (see the dmidecode output below). Again, this seems
to be a regression compared to v2020.07. Any ideas on what
could be wrong or how can I start debugging it would be
>>>
Yes, that's not working right now. I'm working on a fix for the tables:
https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias@kernel.org/
This will fix the error en dmidecode but the tables will be basically empty.
Before that there was some information that helped you to identify that you are
running on a RaspberryPi.
A quick fix would be to add that information to the DTS. Like for example done
here:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3328-rock64-u-boot.dtsi#L13
On the long run we want to add a sysinfo driver to read the information for the
mailbox driver and use that. But my understanding is that for that we would need
to create a SPL for the mailbox driver to provide that info in a shared data
structure. It's still on my list for investigation.
Regards,
Matthias
>>> You can always bisect it ;)
>>>
>>
>>
>> LOL -- true! I was just hoping someone would recognize the issue perhaps.
>>
>> Thanks,
>> Roman.
>
>
Re: [PATCH] smbios: Fix table when no string is present
On 25/03/2021 01:38, Simon Glass wrote:
> Hi Matthias,
>
> On Thu, 18 Mar 2021 at 00:30, wrote:
>>
>> From: Matthias Brugger
>>
>> When no string is present in a table, next_ptr points to the same
>> location as eos. When calculating the string table length, we would only
>> reserve one \0. By spec a SMBIOS table has to end with two \0\0 when no
>> strings a present.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> lib/smbios.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> There is a bug here but I don't think this is right fix. I remember
> worrying about this, making the same change as you did, reverting it
> and then forgetting about it :-( It has no tests.
>
> You are effectively changing the definition of next_ptr here:
>
> * @next_ptr: pointer to the start of the next string to be added. When the
> * table is not empty, this points to the byte after the \0 of the
> * previous string.
>
That's true.
> (there is a typo in that in the code)
>
> I think that breaks adding new strings.
>
Well it doesn't because when adding a new string, ctx->next_ptr gets overwritten
[1]. It is only used to calculate the lenght of the string in
smbios_string_table_len() to calculate the size of the table [2]. But yes it's
not the obvious way to handle the case when no string is present.
> Can you instead change smbios_string_table_len() to add 2?
>
Do you mean returning 2 when no string is present (ctx->next_ptr == ctx->eos)?
Adding 2 will break the case when we have a string present, as a string already
finishes with '\0' and we only need a second '\0'.
Regards,
Matthias
[1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/smbios.c#L95
[2] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/smbios.c#L196
>>
>> diff --git a/lib/smbios.c b/lib/smbios.c
>> index 7d463c84a9..d21d37cdac 100644
>> --- a/lib/smbios.c
>> +++ b/lib/smbios.c
>> @@ -153,7 +153,7 @@ static int smbios_add_prop(struct smbios_ctx *ctx, const
>> char *prop)
>> static void smbios_set_eos(struct smbios_ctx *ctx, char *eos)
>> {
>> ctx->eos = eos;
>> - ctx->next_ptr = eos;
>> + ctx->next_ptr = eos + 1;
>> ctx->last_str = NULL;
>> }
>>
>> --
>> 2.30.2
>>
>
> Regards,
> Simon
>
[GIT PULL] rpi: second round of updates for v2021.04
Hi Tom, Below are the second round of updates for Raspberry Pi aimed for the v2021.04 release. The green CI loop can be found here: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/6579 Please have a look. Regards, Matthias --- The following changes since commit c5219c4a18f2b27547ecd799914f94e48b0fa86f: Prepare v2021.04-rc3 (2021-03-01 22:46:41 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2021.04.2 for you to fetch changes up to fae165b5a1991ca55acfb3dc78f3c473275b3faf: configs: rpi4_32: Enable iProc RNG200 (2021-03-02 13:53:53 +0100) - Disable Grub workaround for RPi2 - enable HS200 mode for iproc sdhci - add armv7 support for iproc_rng200 Bharat Gooty (1): drivers: mmc: iproc_sdhci: enable HS200 mode Matthias Brugger (4): configs: RPi2: Disable EFI Grub workaround MAINTAINERS: Update info for Raspberry Pi rng: iproc_rng200: Enable support for RPi4 armv7 configs: rpi4_32: Enable iProc RNG200 MAINTAINERS | 4 +- configs/rpi_2_defconfig | 1 + configs/rpi_4_32b_defconfig | 2 + drivers/mmc/iproc_sdhci.c | 92 - drivers/rng/iproc_rng200.c | 8 ++-- 5 files changed, 93 insertions(+), 14 deletions(-)
Re: [PATCH] rng: iProc rng200: Rename ..._platdata variables to just ..._plat
On Fri, Feb 19, 2021 at 04:00:50PM -0500, Tom Rini wrote:
> On Thu, Feb 18, 2021 at 08:39:42PM +, Peter Robinson wrote:
> > On Thu, Feb 18, 2021 at 8:36 PM Heinrich Schuchardt
> > wrote:
> > >
> > > On 18.02.21 21:06, Peter Robinson wrote:
> > > > In 8a8d24bd Simon dropped data from all the various _platdata calls
> > > > but it seems this wasn't caught for the RNG200 driver from when it
> > > > was posted to merged. This fixes that issue.
> > > >
> > > > Fixes: 537f0018 (rng: Add iProc RNG200 driver)
> > > > Signed-off-by: Peter Robinson
> > > > ---
> > > > drivers/rng/iproc_rng200.c | 20 ++--
> > > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/rng/iproc_rng200.c b/drivers/rng/iproc_rng200.c
> > > > index f71f285f53..1126bbd797 100644
> > > > --- a/drivers/rng/iproc_rng200.c
> > > > +++ b/drivers/rng/iproc_rng200.c
> > > > @@ -33,11 +33,11 @@
> > > > #define RNG_FIFO_COUNT_OFFSET0x24
> > > > #define RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK 0x00FF
> > > >
> > > > -struct iproc_rng200_platdata {
> > > > +struct iproc_rng200_plat {
> > >
> > > The renaming of the structure seems to be unrelated to the commit message.
> > >
> > > You are moving from allocating via plat_auto to priv_auto. So a
> > > reasonable name for the structure would be iproc_rng200_priv.
> > >
> > > > fdt_addr_t base;
> > > > };
> > > >
> > > > -static void iproc_rng200_enable(struct iproc_rng200_platdata *pdata,
> > > > bool enable)
> > > > +static void iproc_rng200_enable(struct iproc_rng200_plat *pdata, bool
> > > > enable)
> > > > {
> > > > fdt_addr_t rng_base = pdata->base;
> > > > u32 val;
> > > > @@ -52,7 +52,7 @@ static void iproc_rng200_enable(struct
> > > > iproc_rng200_platdata *pdata, bool enable
> > > > writel(val, rng_base + RNG_CTRL_OFFSET);
> > > > }
> > > >
> > > > -static void iproc_rng200_restart(struct iproc_rng200_platdata *pdata)
> > > > +static void iproc_rng200_restart(struct iproc_rng200_plat *pdata)
> > > > {
> > > > fdt_addr_t rng_base = pdata->base;
> > > > u32 val;
> > > > @@ -84,7 +84,7 @@ static void iproc_rng200_restart(struct
> > > > iproc_rng200_platdata *pdata)
> > > >
> > > > static int iproc_rng200_read(struct udevice *dev, void *data, size_t
> > > > len)
> > > > {
> > > > - struct iproc_rng200_platdata *priv = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *priv = dev_get_plat(dev);
> > >
> > > At the end of the patch you move from plat_auto to priv_auto. So
> > > shouldn't you call dev_get_priv(dev)?
> > >
> > > > char *buf = (char *)data;
> > > > u32 num_remaining = len;
> > > > u32 status;
> > > > @@ -136,7 +136,7 @@ static int iproc_rng200_read(struct udevice *dev,
> > > > void *data, size_t len)
> > > >
> > > > static int iproc_rng200_probe(struct udevice *dev)
> > > > {
> > > > - struct iproc_rng200_platdata *priv = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *priv = dev_get_plat(dev);
> > > >
> > > > iproc_rng200_enable(priv, true);
> > > >
> > > > @@ -145,16 +145,16 @@ static int iproc_rng200_probe(struct udevice *dev)
> > > >
> > > > static int iproc_rng200_remove(struct udevice *dev)
> > > > {
> > > > - struct iproc_rng200_platdata *priv = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *priv = dev_get_plat(dev);
> > > >
> > > > iproc_rng200_enable(priv, false);
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > -static int iproc_rng200_ofdata_to_platdata(struct udevice *dev)
> > > > +static int iproc_rng200_of_to_plat(struct udevice *dev)
> > > > {
> > > > - struct iproc_rng200_platdata *pdata = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *pdata = dev_get_plat(dev);
> > > >
> > > > pdata->base = dev_read_addr(dev);
> > > > if (!pdata->base)
> > > > @@ -180,6 +180,6 @@ U_BOOT_DRIVER(iproc_rng200_rng) = {
> > > > .ops = _rng200_ops,
> > > > .probe = iproc_rng200_probe,
> > > > .remove = iproc_rng200_remove,
> > > > - .plat_auto = sizeof(struct iproc_rng200_platdata),
> > > > - .of_to_plat = iproc_rng200_ofdata_to_platdata,
> > > > + .priv_auto = sizeof(struct iproc_rng200_plat),
> > > > + .of_to_plat = iproc_rng200_of_to_plat,
> > >
> > > Why do you set of_to_plat if you are using priv_auto data?
> > > I would have expected the probe function to fill the auto allocated
> > > private data.
> >
> > I based the change on Simon's changes
>
> Yeah, this is fine, it was generally a global search and replace on all
> the structs and funcs. I'll pick this up (and some similar patches)
> soon, and just be a little annoyed at all the code that's clearly not
> getting built somehow today. It'd be great to figure out if it should
> be in some defconfig or what.
>
Tom, please keep me in the loop when you notify that you pushed this to
master. I have some patches in my queue that will enable
[GIT PULL] rpi: updates for v2021.04
Hi Tom, Please find below the updates for the Raspberry Pi for v202.04. The most important are the support for Compute Module 4 and RPi400. Apart from that we now have support for the RNG device found on RPi4. I run the patches through the gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/6416 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/6415 It took quite a while to get all this patches ready for mainline, as the pytests were failing. This is got fixed by Andy Shevchenko and is now merge upstream, so everything is green :) Regards, Matthias --- The following changes since commit 496f49464d90b564da5f1a2f4eecb5553e01edf9: Merge branch '2021-02-16-assorted-improvements' (2021-02-16 15:14:34 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2021.04 for you to fetch changes up to 0059ef0be903a1f0a9afe5259fb2e0874f78a8ac: video: arm: rpi: Add brcm,bcm2711-hdmi0 compatible (2021-02-18 11:59:08 +0100) - add iProc RNG2000 driver for RPi4 - add support for CM4 and RPi400 Marek Szyprowski (1): rpi: limit size of the RAM to the multiple of the MMU_SECTION_SIZE Matthias Brugger (2): rng: Add iProc RNG200 driver config: Enable iProc RNG200 driver in RPi4 configs Nicolas Saenz Julienne (15): usb: xhci-pci: Add DM_FLAG_OS_PREPARE flag pci: brcmstb: Cleanup controller state before handover rpi: Add identifier for the new RPi400 rpi: Add identifier for the new CM4 pci: pcie-brcmstb: Fix inbound window configurations dm: Introduce xxx_get_dma_range() dm: test: Add test case for dev_get_dma_ranges() dm: Introduce DMA constraints into the core device model dm: test: Add test case for dev->dma_offset dm: Introduce dev_phys_to_bus()/dev_bus_to_phys() dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys() xhci: translate virtual addresses into the bus's address space mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys() configs: rpi4: Enable DM_DMA across all RPi4 configurations video: arm: rpi: Add brcm,bcm2711-hdmi0 compatible arch/sandbox/dts/test.dts | 21 + board/raspberrypi/rpi/rpi.c| 17 common/fdt_support.c | 73 +++ configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 3 + configs/rpi_arm64_defconfig| 3 + configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + drivers/core/Kconfig | 10 ++ drivers/core/device.c | 41 drivers/core/of_addr.c | 78 drivers/core/ofnode.c | 9 ++ drivers/core/read.c| 6 ++ drivers/mmc/sdhci.c| 10 +- drivers/pci/pcie_brcmstb.c | 32 +-- drivers/rng/Kconfig| 6 ++ drivers/rng/Makefile | 1 + drivers/rng/iproc_rng200.c | 185 + drivers/usb/host/xhci-mem.c| 45 - drivers/usb/host/xhci-pci.c| 2 +- drivers/usb/host/xhci-ring.c | 13 ++- drivers/usb/host/xhci.c| 4 +- drivers/video/bcm2835.c| 1 + include/dm/device.h| 13 +++ include/dm/of_addr.h | 17 include/dm/ofnode.h| 16 include/dm/read.h | 21 + include/fdt_support.h | 14 +++ include/mmc.h | 6 ++ include/phys2bus.h | 17 include/usb/xhci.h | 20 +++- test/dm/Makefile | 2 + test/dm/core.c | 30 ++ test/dm/phys2bus.c | 37 test/dm/read.c | 49 ++ 37 files changed, 766 insertions(+), 41 deletions(-) create mode 100644 drivers/rng/iproc_rng200.c create mode 100644 test/dm/phys2bus.c create mode 100644 test/dm/read.c
Re: [RFC PATCH] efi_loader: disable GRUB workaround by default
On 09/02/2021 13:22, Heinrich Schuchardt wrote: > On 09.02.21 12:38, matthias@kernel.org wrote: >> From: Matthias Brugger >> >> GRUB version 2.04 was published over a year ago. We should expect that >> distros use this version now. So disable the workaround by default. >> As we know that i.MX6 CPUs lack proper handling of caches, enable the >> workaround on these only. > > Hello Matthias, > > Where did the current setting hurt? > I hit this on BananaPi R2 where the time from exiting the boot services until the kernel gets loaded was three times bigger with the workaround. Similar numbers, ~40 down to 12 seconds. > Did you really check all 32bit ARM defconfig? No I didn't, that's why I send it as RFC. If you think this is a can of worms we would open, then I just disable the workaround for these two defconfigs. Regards, Matthias > Which other devices have caches that are not controlled by CP15? > How about all non-i.mx6 devices using CONFIG_SYS_L2_PL310? > > Best regards > > Heinrich > >> >> Signed-off-by: Matthias Brugger >> >> --- >> >> configs/imx6dl_icore_nand_defconfig | 1 + >> configs/imx6dl_mamoj_defconfig | 1 + >> configs/imx6q_icore_nand_defconfig | 1 + >> configs/imx6q_logic_defconfig| 1 + >> configs/imx6qdl_icore_mipi_defconfig | 1 + >> configs/imx6qdl_icore_mmc_defconfig | 1 + >> configs/imx6qdl_icore_nand_defconfig | 1 + >> configs/imx6qdl_icore_rqs_defconfig | 1 + >> configs/imx6ul_geam_mmc_defconfig| 1 + >> configs/imx6ul_geam_nand_defconfig | 1 + >> configs/imx6ul_isiot_emmc_defconfig | 1 + >> configs/imx6ul_isiot_nand_defconfig | 1 + >> lib/efi_loader/Kconfig | 2 +- >> 13 files changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/configs/imx6dl_icore_nand_defconfig >> b/configs/imx6dl_icore_nand_defconfig >> index 06005c4288..44fbbe6bd1 100644 >> --- a/configs/imx6dl_icore_nand_defconfig >> +++ b/configs/imx6dl_icore_nand_defconfig >> @@ -68,3 +68,4 @@ CONFIG_SPLASH_SCREEN=y >> CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_RLE8=y >> CONFIG_BMP_16BPP=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6dl_mamoj_defconfig b/configs/imx6dl_mamoj_defconfig >> index fa2adaf47d..7ebbb5830b 100644 >> --- a/configs/imx6dl_mamoj_defconfig >> +++ b/configs/imx6dl_mamoj_defconfig >> @@ -57,3 +57,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" >> CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> CONFIG_CI_UDC=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6q_icore_nand_defconfig >> b/configs/imx6q_icore_nand_defconfig >> index f38b06dab9..cef5f3448d 100644 >> --- a/configs/imx6q_icore_nand_defconfig >> +++ b/configs/imx6q_icore_nand_defconfig >> @@ -69,3 +69,4 @@ CONFIG_SPLASH_SCREEN=y >> CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_RLE8=y >> CONFIG_BMP_16BPP=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig >> index 36dc24d080..b5a4d3d24d 100644 >> --- a/configs/imx6q_logic_defconfig >> +++ b/configs/imx6q_logic_defconfig >> @@ -103,3 +103,4 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> CONFIG_CI_UDC=y >> CONFIG_USB_GADGET_DOWNLOAD=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6qdl_icore_mipi_defconfig >> b/configs/imx6qdl_icore_mipi_defconfig >> index f1b5389470..1d9e021844 100644 >> --- a/configs/imx6qdl_icore_mipi_defconfig >> +++ b/configs/imx6qdl_icore_mipi_defconfig >> @@ -63,3 +63,4 @@ CONFIG_PINCTRL=y >> CONFIG_PINCTRL_IMX6=y >> CONFIG_MXC_UART=y >> CONFIG_IMX_THERMAL=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6qdl_icore_mmc_defconfig >> b/configs/imx6qdl_icore_mmc_defconfig >> index a32ae6a75d..b46d19ad88 100644 >> --- a/configs/imx6qdl_icore_mmc_defconfig >> +++ b/configs/imx6qdl_icore_mmc_defconfig >> @@ -86,3 +86,4 @@ CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_RLE8=y >> CONFIG_BMP_16BPP=y >> CONFIG_IMX_WATCHDOG=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6qdl_icore_nand_defconfig >> b/configs/imx6qdl_icore_nand_defconfig >> index f38b06dab9..cef5f3448d 100644 >> --- a/configs/imx6qdl_icore_nand_defconfig >> +++ b/configs/imx6qdl_icore_nand_defconfig >> @@ -69,3 +69,4 @@ CONFIG_SPLASH_SCREEN=y >> CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_R
Re: [QUESTION] Kernel 5.10 image might be too big to be loaded by U-Boot on RPi 4B
On Thu, Jan 28, 2021 at 04:54:03PM +0800, Jian-Hong Pan wrote: > Load u-Boot environment ... from mmc 0:2 > 622 bytes read in 24 ms (24.4 KiB/s) > Load device tree ... > 25693 bytes read in 30 ms (835.9 KiB/s) > fdt_addr_r @ 0x0260 , size= 645d > Load kernel and unzip it ... > 13013555 bytes read in 574 ms (21.6 MiB/s) > Uncompressed size: 38742528 = 0x24F2A00 > kernel_addr_r @ 0x0008 , size= 24f2a00 > Load RAM disk ... > 54360540 bytes read in 2298 ms (22.6 MiB/s) > ramdisk_addr_r @ 0x0270 , size= 33d79dc > Boot ... > Moving Image from 0x8 to 0x20, end=282 > ERROR: RD image overlaps OS image (OS=0x20..0x282) > SCRIPT FAILED: continuing... > Card did not respond to voltage select! > genet@7d58 Waiting for PHY auto negotiation to complete > > It shows error: "RD image overlaps OS image (OS=0x20..0x282)" > > So, I calculated the memory address and space: > > 0x20 (kernel start address) + 0x24F2A00 (kernel size) = 0x26F2A00 < > 282 (kernel end), but > 0x270 (ramdisk start address) & > 0x260 > (FDT start address) > > The kernel image size 0x24F2A00 bytes is too fat to sit in the memory space > prepared by U-Boot and overlaps ramdisk and FDT's memory spaces. > It is more than 36.9MB, which is over 36MB mentioned in U-Boot's comment > [2]. > If I did the math right, we should have a lot of space left. You could try to bump up fdt_addr_r=0x0290 and ramdisk_addr_r=0x02A0 and see what happens. Regards, Matthias > We understand this can be fixed by a workaround like tuning/reducing the > kernel's build config. However, is it possible to have another way to > resolve this problem? > > [1] > https://kernel.ubuntu.com/git/ubuntu/unstable.git/tree/?h=Ubuntu-5.10-5.10.0-10.11 > [2] > https://github.com/u-boot/u-boot/blob/v2021.01/include/configs/rpi.h#L140 > > Jain-Hong Pan
Re: [PATCH v2 2/2] console: Don't start/stop console if stdio device invalid
On 28/01/2021 16:52, Andy Shevchenko wrote:
> On Thu, Jan 28, 2021 at 02:12:40PM +0100, Nicolas Saenz Julienne wrote:
>> Don't start/stop an stdio device that might have been already freed.
>>
>> Signed-off-by: Nicolas Saenz Julienne
>> Fixes: 70c2525c0d3c ("IOMUX: Stop dropped consoles")
>
> ...
>
>> +/*
>> + * TODO: This is a workaround to avoid accessing freed memory:
>> + * console_stop() might be called on an stdio_dev that has already been
>> + * de-registered, due to the fact that stdio_deregister_dev()
>> + * doesn't update the global console_devices array.
>> + */
>
> I see now. I think I have experienced this issue from time to time. I will
> look
> at it. Tom, Simon, please hold on applying these for a while.
>
Just for the notes, the failing tests hold back Nicolas series to support
RPi400/CM4 [1] as it does not run the new tests added successfully. If it takes
a long time to fix the test environment, I'd vote to take this series as a
stop-gap so that we can support that HW in the next release.
Regards,
Matthias
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=223890
Re: [PATCH v2 1/2] lib: uuid: use RNG device if present
On Wed, Jan 20, 2021 at 12:50:56PM -0700, Simon Glass wrote: > Hi Matthias, > > On Wed, 20 Jan 2021 at 04:17, Matthias Brugger wrote: > > > > > > > > On 29/12/2020 04:32, Simon Glass wrote: > > > Hi guys, > > > > > > On Wed, 23 Dec 2020 at 03:24, Torsten Duwe wrote: > > >> > > >> On Sun, 20 Dec 2020 11:17:50 -0700 > > >> Simon Glass wrote: > > >> > > >>> Hi Torsten, > > >>> > > >>> On Sun, 20 Dec 2020 at 10:00, Torsten Duwe wrote: > > >>>> > > >>>> On Fri, 18 Dec 2020 19:29:12 -0700 > > >>>> Simon Glass wrote: > > >>>> > > >>>>>> - int i; > > >>>>>> - > > >>>>>> - srand(get_ticks() + rand()); > > >>>>>> + int i, ret; > > >>>>>> + struct udevice *devp; > > >>>>>> + u8 randv = 0; > > >>>>>> + > > >>>>>> +#if defined(CONFIG_DM_RNG) > > >>>>> > > >>>>> This seems a little backwards to me. The caller should request a > > >>>>> RNG device, getting either a hardware one or a software one, and > > >>>>> then call the uclass method to get the uuid. > > >>>> > > >>>> Strictly speaking, there's no such thing as a "software RNG". The > > >>>> term "DRBG" was coined for accurateness, "deterministic random bit > > >>>> generator". The oxymoron "deterministic random" pretty much nails > > >>>> it. Alternatively, it can be called "pseudo" RNG. > > >>>> rand() and srand() exactly implement such a mechanism already, with > > >>>> low coding overhead. U-Boot runs fine with them most of the time, > > >>>> but there are rare cases where real entropy would be needed. This > > >>>> is what these two patches are about. In case there's more, I > > >>>> already speculated about a centralised entity in my response to the > > >>>> v1 cover letter, but for now these two changes should do. > > >>> > > >>> I am used to the term pseudo-random, but it doesn't much matter what > > >>> kind of random number is used. It is still covered by the RNG class. > > >> > > >> Well, in these 2 cases, it _does_ matter. And besides, as I wrote > > >> above, pseudo randomness is produced by the rand() function, and RNG > > >> devices provide _real_ entropy to a system. > > >> > > >> So, while every other entity in U-Boot is happy with a DRBG, a UUID and > > >> a BOOTP delay need this real entropy, hence the different code, for a > > >> start. > > >> > > >>> You are currently burying device access in a utility function. That > > >>> really isn't the right way to do it. See my comment above. There is no > > >>> way to control which RNG device is used and no visibility that this is > > >>> happening at all, outside this function. > > >> > > >> The code looks a bit odd to me, too, as I mentioned. I imagined > > >> something not so full blown as in the Linux kernel, but still some > > >> central mechanism to get entropy from, for those who really need it (in > > >> the current situation, just these 2 cases). This alternative would > > >> result in a real /dev/random in U-Boot, which would yield a cleaner > > >> structure, but would require more code to be produced and more code > > >> needing change. That given, I'd agree to these 2 hacks, especially > > >> because there are security implications. > > >> > > >> What's your opinion, how would you like to create really unique UUIDs? > > >> How should BOOTP clients wait randomly (esp. in a large group)? > > >> Shall we create some U-Boot version of /dev/random and haveged? > > >> > > >> I'm really open to suggestions. > > >> > > > > > > I really don't mind too much about that side of it. But I do worry > > > when I see code that buries hard-coded DM access in a lib/ function. > > > > > > > v3 of this series got merged, which should not stop us from making the code > > better. > > > > > > > If boot wants a random device it should get one, at the top level, not > &g
Re: [PATCH v2 1/2] lib: uuid: use RNG device if present
On 29/12/2020 04:32, Simon Glass wrote: > Hi guys, > > On Wed, 23 Dec 2020 at 03:24, Torsten Duwe wrote: >> >> On Sun, 20 Dec 2020 11:17:50 -0700 >> Simon Glass wrote: >> >>> Hi Torsten, >>> >>> On Sun, 20 Dec 2020 at 10:00, Torsten Duwe wrote: On Fri, 18 Dec 2020 19:29:12 -0700 Simon Glass wrote: >> - int i; >> - >> - srand(get_ticks() + rand()); >> + int i, ret; >> + struct udevice *devp; >> + u8 randv = 0; >> + >> +#if defined(CONFIG_DM_RNG) > > This seems a little backwards to me. The caller should request a > RNG device, getting either a hardware one or a software one, and > then call the uclass method to get the uuid. Strictly speaking, there's no such thing as a "software RNG". The term "DRBG" was coined for accurateness, "deterministic random bit generator". The oxymoron "deterministic random" pretty much nails it. Alternatively, it can be called "pseudo" RNG. rand() and srand() exactly implement such a mechanism already, with low coding overhead. U-Boot runs fine with them most of the time, but there are rare cases where real entropy would be needed. This is what these two patches are about. In case there's more, I already speculated about a centralised entity in my response to the v1 cover letter, but for now these two changes should do. >>> >>> I am used to the term pseudo-random, but it doesn't much matter what >>> kind of random number is used. It is still covered by the RNG class. >> >> Well, in these 2 cases, it _does_ matter. And besides, as I wrote >> above, pseudo randomness is produced by the rand() function, and RNG >> devices provide _real_ entropy to a system. >> >> So, while every other entity in U-Boot is happy with a DRBG, a UUID and >> a BOOTP delay need this real entropy, hence the different code, for a >> start. >> >>> You are currently burying device access in a utility function. That >>> really isn't the right way to do it. See my comment above. There is no >>> way to control which RNG device is used and no visibility that this is >>> happening at all, outside this function. >> >> The code looks a bit odd to me, too, as I mentioned. I imagined >> something not so full blown as in the Linux kernel, but still some >> central mechanism to get entropy from, for those who really need it (in >> the current situation, just these 2 cases). This alternative would >> result in a real /dev/random in U-Boot, which would yield a cleaner >> structure, but would require more code to be produced and more code >> needing change. That given, I'd agree to these 2 hacks, especially >> because there are security implications. >> >> What's your opinion, how would you like to create really unique UUIDs? >> How should BOOTP clients wait randomly (esp. in a large group)? >> Shall we create some U-Boot version of /dev/random and haveged? >> >> I'm really open to suggestions. >> > > I really don't mind too much about that side of it. But I do worry > when I see code that buries hard-coded DM access in a lib/ function. > v3 of this series got merged, which should not stop us from making the code better. > If boot wants a random device it should get one, at the top level, not > in the bowels of U-Boot. It can pass that device down to other > functions as needed. > So you mean we should get the RNG udevice at the caller of gen_rand_uuid_str and then pass it down to gen_rand_uuid? And if no device has been found, we will call srand(get_ticks() + rand())? I'm not quite sure how we would need to implement this in the case of srand_mac() though. Regards, Matthias > To my reading, the current definition of the RNG uclass looks similar > to a /dev/random > > Let me know if I am missing something. >
Re: [PATCH 1/2] timer: mtk_timer: initialize the timer before use
On Mon, Jan 18, 2021 at 08:44:42AM +0800, Weijie Gao wrote: > On Fri, 2021-01-15 at 17:36 +0100, Matthias Brugger wrote: > > On Tue, Jan 12, 2021 at 01:44:02PM +0800, Weijie Gao wrote: > > > The timer being used by this driver may have already been used by first > > > stage bootloader (e.g. ATF/preloader), and it's settings may differ from > > > what this driver is going to use. > > > > > > This may cause issues, such as inaccurate timer frequency due to > > > incorrect clock divider. > > > > > > This patch adds the initialization code to avoid them. > > > > > > Signed-off-by: Weijie Gao > > > --- > > > drivers/timer/mtk_timer.c | 10 ++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c > > > index 448a76a7e1..f6b97f868c 100644 > > > --- a/drivers/timer/mtk_timer.c > > > +++ b/drivers/timer/mtk_timer.c > > > @@ -61,6 +61,16 @@ static int mtk_timer_probe(struct udevice *dev) > > > if (!uc_priv->clock_rate) > > > return -EINVAL; > > > > > > + /* > > > + * Initialize the timer: > > > + * 1. set clock source to system clock with clock divider setting to 1 > > > + * 2. set timer mode to free running > > > + * 3. reset timer counter to 0 then enable the timer > > > + */ > > > + writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK); > > > + writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE, > > > > GPT4_FREERUN is defined as GENMASK(5,4) while in the Linux kernel it has > > the value of 3. Can you explain where this difference comes from? > > GENMASK(5,4) == 3 << 4, which is exactly the same as what's being used > in kernel: > > #define GPT_CTRL_OP(val)(((val) & 0x3) << 4) > #define GPT_CTRL_OP_FREERUN (3) > You are right, sorry my fault: Reviewed-by: Matthias Brugger > > > > Regards, > > Matthias > > > > > +priv->base + MTK_GPT4_CTRL); > > > + > > > return 0; > > > } > > > > > > -- > > > 2.17.1 >
Re: [PATCH 1/2] timer: mtk_timer: initialize the timer before use
On Tue, Jan 12, 2021 at 01:44:02PM +0800, Weijie Gao wrote: > The timer being used by this driver may have already been used by first > stage bootloader (e.g. ATF/preloader), and it's settings may differ from > what this driver is going to use. > > This may cause issues, such as inaccurate timer frequency due to > incorrect clock divider. > > This patch adds the initialization code to avoid them. > > Signed-off-by: Weijie Gao > --- > drivers/timer/mtk_timer.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c > index 448a76a7e1..f6b97f868c 100644 > --- a/drivers/timer/mtk_timer.c > +++ b/drivers/timer/mtk_timer.c > @@ -61,6 +61,16 @@ static int mtk_timer_probe(struct udevice *dev) > if (!uc_priv->clock_rate) > return -EINVAL; > > + /* > + * Initialize the timer: > + * 1. set clock source to system clock with clock divider setting to 1 > + * 2. set timer mode to free running > + * 3. reset timer counter to 0 then enable the timer > + */ > + writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK); > + writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE, GPT4_FREERUN is defined as GENMASK(5,4) while in the Linux kernel it has the value of 3. Can you explain where this difference comes from? Regards, Matthias > +priv->base + MTK_GPT4_CTRL); > + > return 0; > } > > -- > 2.17.1
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 11/01/2021 09:57, Heinrich Schuchardt wrote: > On 11.01.21 08:48, Stefan Roese wrote: >> >> >> On 11.01.21 08:17, Heinrich Schuchardt wrote: >>> Am 11. Januar 2021 08:02:12 MEZ schrieb Stefan Roese : >>>> Added Heinrich to Cc. >>>> >>>> On 10.01.21 19:44, Matthias Brugger wrote: >>>>> On 09/01/2021 15:57, Stefan Roese wrote: >>>>>> On 09.01.21 03:32, Matthias Brugger wrote: >>>>>>> On 08/01/2021 08:39, Stefan Roese wrote: >>>>>>>> On 07.01.21 16:36, matthias@kernel.org wrote: >>>>>>>>> From: Matthias Brugger >>>>>>>>> >>>>>>>>> Watchdog timeout comes in before we are able to load the >>>>>>>>> kernel and reset the watchdog. Disable the watchdog late in the >>>> boot >>>>>>>>> process to be able to boot the board. >>>>>>>> >>>>>>>> Can't you change the WDT reset timeout instead to a higher value? >>>>>>>> >>>>>>> >>>>>>> I tried that, but the HW has a max timeout of 15984 ms. >>>> Unfortunately that's not >>>>>>> enough. >>>>>> >>>>>> Nearly 16 seconds is not enough to boot into Linux so that the Linux >>>>>> watchdog daemon can take control? >>>>>> >>>>> >>>>> Exactly. I'm using a standard distro image. I think the main problem >>>> is, that it >>>>> needs 14 seconds for the EFI stub to actually boot the kernel. > > Hello Matthias, Hi Heinrich :) > > I observed that on some recent version Linux before 5.10 booting seemed > to be delayed by dozens of seconds on many boards. On which Linux > version did you see the problem? > I think it started on 5.9 or 5.10. Right now I'm seeing it with 5.10 and 5.11-rc2. >>>> >>>> I've not much experience (yet) with the "EFI stub". But if it takes >>>> this >>>> long, wouldn't it make sense that this stub also supports the WDT? >>> >>> efi_timer_check() calls WATCHDOG_RESET() trying to avoid that the >>> hardware watchdog is triggered. >> >> So efi_timer_check() is called quite frequently and should be enough >> to reset the U-Boot WDT while residing in EFI? Not sure, why the reset >> occurs in Matthias's case then. > > efi_timer_check() is only invoked, if the UEFI API is invoked. > Especially if the problem occurs after ExitBootServices() it is not > called anymore. > >> >>> There is a software watchdog >>> defaulting to 5 minutes in efi_watchdog.c which can be modified >>> via the EFI API. >>> >>> Is there a U-Boot API to disable the hardware watchdog? >> >> Yes: >> >> /* >> * Stop the timer, thus disabling the Watchdog. Use wdt_start to start >> it again. >> * >> * @dev: WDT Device >> * @return: 0 if OK, -ve on error >> */ >> int wdt_stop(struct udevice *dev); > > It would be interesting to understand if your problem occurs before or > after efi_exit_boot_services() is called. You could you add printf() > statements after EFI_ENTRY() and before EFI_EXIT() to see if it is reached. > It happens after EFI_EXIT(): [2021-01-11 14:06:04.621] EFI stub: Booting Linux Kernel... [2021-01-11 14:06:04.624] EFI stub: Using DTB from configuration table [2021-01-11 14:06:04.628] EFI stub: Exiting boot services and installing virtual address map... [2021-01-11 14:06:04.637] efi_exit_boot_services EFI_ENTRY [2021-01-11 14:06:04.641] efi_exit_boot_services EFI_EXIT [2021-01-11 14:06:20.972] [2021-01-11 14:06:20.973] [USBD] USB PRB0 LineState: 40 So reboot after around 16 seconds. > Could you further, please, test if adding wdt_stop() to the start of > do_bootefi() in cmd/bootefi.c solves your problem. Yes, that works. Do you want me to disable watchdog for all EFI boot cases? Regards, Matthias > > Best regards > > Heinrich > >> >> Thanks, >> Stefan >> >>> Best regards >>> >>> Heinrich >>> >>> >>>> >>>> Thanks, >>>> Stefan >>>> >>>>> I've already the >>>>> watchdog timer as build-in (which is not the best to do, taking into >>>> account >>>>> that we don't want to bloat our distro kernel with random board >>>> specific drivers >>>>> build-in. If we I had the watchdog driver as kernel module it would >
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 10/01/2021 19:44, Matthias Brugger wrote:
>
>
> On 09/01/2021 15:57, Stefan Roese wrote:
>> On 09.01.21 03:32, Matthias Brugger wrote:
>>> On 08/01/2021 08:39, Stefan Roese wrote:
>>>> On 07.01.21 16:36, matthias@kernel.org wrote:
>>>>> From: Matthias Brugger
>>>>>
>>>>> Watchdog timeout comes in before we are able to load the
>>>>> kernel and reset the watchdog. Disable the watchdog late in the boot
>>>>> process to be able to boot the board.
>>>>
>>>> Can't you change the WDT reset timeout instead to a higher value?
>>>>
>>>
>>> I tried that, but the HW has a max timeout of 15984 ms. Unfortunately
>>> that's not
>>> enough.
>>
>> Nearly 16 seconds is not enough to boot into Linux so that the Linux
>> watchdog daemon can take control?
>>
>
> Exactly. I'm using a standard distro image. I think the main problem is, that
> it
> needs 14 seconds for the EFI stub to actually boot the kernel. I've already
> the
> watchdog timer as build-in (which is not the best to do, taking into account
> that we don't want to bloat our distro kernel with random board specific
> drivers
> build-in. If we I had the watchdog driver as kernel module it would take
> forever
> to get that loaded.
I just checked and "forever" was a bit of a overstatement. Kernel modules get
loaded after around 2 seconds into kernel booting. But adding this to the 14
seconds the EFI stub needs we already got reset by the watchdog.
Regards,
Matthias
>
> You can find a serial log with timestamp from the moment U-Boot got loaded
> until
> the kernel actually boots here:
> https://paste.opensuse.org/98390849
>
> Regards,
> Matthias
>
>> Thanks,
>> Stefan
>>
>>> Regards,
>>> Matthias
>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>> Signed-off-by: Matthias Brugger
>>>>>
>>>>> ---
>>>>>
>>>>> board/mediatek/mt7623/mt7623_rfb.c | 8
>>>>> configs/mt7623n_bpir2_defconfig | 1 +
>>>>> 2 files changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/board/mediatek/mt7623/mt7623_rfb.c
>>>>> b/board/mediatek/mt7623/mt7623_rfb.c
>>>>> index 984e75ccaf..22120be412 100644
>>>>> --- a/board/mediatek/mt7623/mt7623_rfb.c
>>>>> +++ b/board/mediatek/mt7623/mt7623_rfb.c
>>>>> @@ -5,6 +5,7 @@
>>>>> #include
>>>>> #include
>>>>> +#include
>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>> @@ -40,3 +41,10 @@ int mmc_get_env_dev(void)
>>>>> return mmc_get_boot_dev();
>>>>> }
>>>>> #endif
>>>>> +
>>>>> +#ifdef CONFIG_BOARD_LATE_INIT
>>>>> +int board_late_init(void)
>>>>> +{
>>>>> + wdt_stop(gd->watchdog_dev);
>>>>> +}
>>>>> +#endif
>>>>> diff --git a/configs/mt7623n_bpir2_defconfig
>>>>> b/configs/mt7623n_bpir2_defconfig
>>>>> index 9177c17dff..fe0b6259dd 100644
>>>>> --- a/configs/mt7623n_bpir2_defconfig
>>>>> +++ b/configs/mt7623n_bpir2_defconfig
>>>>> @@ -14,6 +14,7 @@ CONFIG_FIT_VERBOSE=y
>>>>> CONFIG_BOOTDELAY=3
>>>>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>>>> CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2.dtb"
>>>>> +CONFIG_BOARD_LATE_INIT=y
>>>>> # CONFIG_DISPLAY_BOARDINFO is not set
>>>>> CONFIG_SYS_PROMPT="U-Boot> "
>>>>> CONFIG_CMD_BOOTMENU=y
>>>>>
>>>>
>>>>
>>>> Viele Grüße,
>>>> Stefan
>>>>
>>>
>>
>>
>> Viele Grüße,
>> Stefan
>>
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 09/01/2021 15:57, Stefan Roese wrote:
> On 09.01.21 03:32, Matthias Brugger wrote:
>> On 08/01/2021 08:39, Stefan Roese wrote:
>>> On 07.01.21 16:36, matthias@kernel.org wrote:
>>>> From: Matthias Brugger
>>>>
>>>> Watchdog timeout comes in before we are able to load the
>>>> kernel and reset the watchdog. Disable the watchdog late in the boot
>>>> process to be able to boot the board.
>>>
>>> Can't you change the WDT reset timeout instead to a higher value?
>>>
>>
>> I tried that, but the HW has a max timeout of 15984 ms. Unfortunately that's
>> not
>> enough.
>
> Nearly 16 seconds is not enough to boot into Linux so that the Linux
> watchdog daemon can take control?
>
Exactly. I'm using a standard distro image. I think the main problem is, that it
needs 14 seconds for the EFI stub to actually boot the kernel. I've already the
watchdog timer as build-in (which is not the best to do, taking into account
that we don't want to bloat our distro kernel with random board specific drivers
build-in. If we I had the watchdog driver as kernel module it would take forever
to get that loaded.
You can find a serial log with timestamp from the moment U-Boot got loaded until
the kernel actually boots here:
https://paste.opensuse.org/98390849
Regards,
Matthias
> Thanks,
> Stefan
>
>> Regards,
>> Matthias
>>
>>> Thanks,
>>> Stefan
>>>
>>>> Signed-off-by: Matthias Brugger
>>>>
>>>> ---
>>>>
>>>> board/mediatek/mt7623/mt7623_rfb.c | 8
>>>> configs/mt7623n_bpir2_defconfig | 1 +
>>>> 2 files changed, 9 insertions(+)
>>>>
>>>> diff --git a/board/mediatek/mt7623/mt7623_rfb.c
>>>> b/board/mediatek/mt7623/mt7623_rfb.c
>>>> index 984e75ccaf..22120be412 100644
>>>> --- a/board/mediatek/mt7623/mt7623_rfb.c
>>>> +++ b/board/mediatek/mt7623/mt7623_rfb.c
>>>> @@ -5,6 +5,7 @@
>>>> #include
>>>> #include
>>>> +#include
>>>> DECLARE_GLOBAL_DATA_PTR;
>>>> @@ -40,3 +41,10 @@ int mmc_get_env_dev(void)
>>>> return mmc_get_boot_dev();
>>>> }
>>>> #endif
>>>> +
>>>> +#ifdef CONFIG_BOARD_LATE_INIT
>>>> +int board_late_init(void)
>>>> +{
>>>> + wdt_stop(gd->watchdog_dev);
>>>> +}
>>>> +#endif
>>>> diff --git a/configs/mt7623n_bpir2_defconfig
>>>> b/configs/mt7623n_bpir2_defconfig
>>>> index 9177c17dff..fe0b6259dd 100644
>>>> --- a/configs/mt7623n_bpir2_defconfig
>>>> +++ b/configs/mt7623n_bpir2_defconfig
>>>> @@ -14,6 +14,7 @@ CONFIG_FIT_VERBOSE=y
>>>> CONFIG_BOOTDELAY=3
>>>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>>> CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2.dtb"
>>>> +CONFIG_BOARD_LATE_INIT=y
>>>> # CONFIG_DISPLAY_BOARDINFO is not set
>>>> CONFIG_SYS_PROMPT="U-Boot> "
>>>> CONFIG_CMD_BOOTMENU=y
>>>>
>>>
>>>
>>> Viele Grüße,
>>> Stefan
>>>
>>
>
>
> Viele Grüße,
> Stefan
>
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 08/01/2021 08:39, Stefan Roese wrote:
> On 07.01.21 16:36, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Watchdog timeout comes in before we are able to load the
>> kernel and reset the watchdog. Disable the watchdog late in the boot
>> process to be able to boot the board.
>
> Can't you change the WDT reset timeout instead to a higher value?
>
I tried that, but the HW has a max timeout of 15984 ms. Unfortunately that's not
enough.
Regards,
Matthias
> Thanks,
> Stefan
>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> board/mediatek/mt7623/mt7623_rfb.c | 8
>> configs/mt7623n_bpir2_defconfig | 1 +
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/board/mediatek/mt7623/mt7623_rfb.c
>> b/board/mediatek/mt7623/mt7623_rfb.c
>> index 984e75ccaf..22120be412 100644
>> --- a/board/mediatek/mt7623/mt7623_rfb.c
>> +++ b/board/mediatek/mt7623/mt7623_rfb.c
>> @@ -5,6 +5,7 @@
>> #include
>> #include
>> +#include
>> DECLARE_GLOBAL_DATA_PTR;
>> @@ -40,3 +41,10 @@ int mmc_get_env_dev(void)
>> return mmc_get_boot_dev();
>> }
>> #endif
>> +
>> +#ifdef CONFIG_BOARD_LATE_INIT
>> +int board_late_init(void)
>> +{
>> + wdt_stop(gd->watchdog_dev);
>> +}
>> +#endif
>> diff --git a/configs/mt7623n_bpir2_defconfig
>> b/configs/mt7623n_bpir2_defconfig
>> index 9177c17dff..fe0b6259dd 100644
>> --- a/configs/mt7623n_bpir2_defconfig
>> +++ b/configs/mt7623n_bpir2_defconfig
>> @@ -14,6 +14,7 @@ CONFIG_FIT_VERBOSE=y
>> CONFIG_BOOTDELAY=3
>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>> CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2.dtb"
>> +CONFIG_BOARD_LATE_INIT=y
>> # CONFIG_DISPLAY_BOARDINFO is not set
>> CONFIG_SYS_PROMPT="U-Boot> "
>> CONFIG_CMD_BOOTMENU=y
>>
>
>
> Viele Grüße,
> Stefan
>
Re: [PATCH v2 1/2] lib: uuid: use RNG device if present
Hi Simon,
On 19/12/2020 03:29, Simon Glass wrote:
> Hi Mattias,
>
> On Wed, 16 Dec 2020 at 09:28, wrote:
>>
>> From: Matthias Brugger
>>
>> When calculating a random UUID we use a weak seed.
>> Use a RNG device if present to increase entropy.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> Changes in v2:
>> - fix dm_rng_read() parameters
>> - add missing include
>>
>> lib/uuid.c | 21 ++---
>> 1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/uuid.c b/lib/uuid.c
>> index e62d5ca264..e3487380c3 100644
>> --- a/lib/uuid.c
>> +++ b/lib/uuid.c
>> @@ -15,6 +15,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> /*
>> * UUID - Universally Unique IDentifier - 128 bits unique number.
>> @@ -249,9 +251,22 @@ void gen_rand_uuid(unsigned char *uuid_bin)
>> {
>> u32 ptr[4];
>> struct uuid *uuid = (struct uuid *)ptr;
>> - int i;
>> -
>> - srand(get_ticks() + rand());
>> + int i, ret;
>> + struct udevice *devp;
>> + u8 randv = 0;
>> +
>> +#if defined(CONFIG_DM_RNG)
>
> This seems a little backwards to me. The caller should request a RNG
> device, getting either a hardware one or a software one, and then call
> the uclass method to get the uuid.
>
The problem I see here is, that in case no DM_RNG is present the seed used is
different for uuid (get_ticks() + rand()) and bootp (seed_mac() uses the mac
address)
So we would need to pass this alternatives to the generic DM code, which makes
it a bit ugly. Apart from that beware that the seed used for srand() can vary
depending on the caller and the entropy it needs.
Regards,
Matthias
>> + ret = uclass_get_device(UCLASS_RNG, 0, );
>> + if (ret) {
>> + ret = dm_rng_read(devp, , sizeof(randv));
>> + if (ret < 0)
>> + randv = 0;
>> + }
>> + if (randv)
>> + srand(randv);
>> + else
>> +#endif
>> + srand(get_ticks() + rand());
>>
>> /* Set all fields randomly */
>> for (i = 0; i < 4; i++)
>> --
>> 2.29.2
>>
>
> Regards,
> Simon
>
Re: U-Boot failures on CM4 and Pi4-8Gb
On 16/12/2020 17:20, Peter Robinson wrote: > On Wed, Dec 16, 2020 at 4:15 PM Matthias Brugger > wrote: >> >> Hi Dave, >> >> On 16/12/2020 15:23, Dave Jones wrote: >>> Hi, >>> >>> We've recently run across some failures with U-Boot on a couple of >>> platforms, >>> specifically the relatively new Pi Compute Module 4, and the Pi 4 8GB of >>> RAM. On >>> the CM4, U-Boot failed to identify the eMMC storage, and on the Pi 4 8GB, a >>> crash and reset occurred when U-Boot tried to read from the boot >>> file-system on >>> the SD card, but only when booted with no monitor attached (attaching a >>> monitor >>> results in a successful boot, at least under arm64). These were with >>> more-or-less stock rpi_4_defconfig and rpi_4_32b_defconfig configurations >>> from >>> v2020.10 (our local config changes bump the env-size, enable OF_BOARD, and >>> RAW_INITRD, but that's it). >>> >>> I've bisected the source and figured out roughly the commits responsible; >>> for >>> the CM4 eMMC case it's the enabling of DMA for the SDHCI interface in >>> c6b9fbf756. >>> >>> The Pi 4 8GB failure was a little more complex in that the bisection >>> pointed to >>> 3113c84ba2 (a merge), however that gave me a few clues to try and after a >>> little >>> experimenting I found that disabling CONFIG_PCI_BRCMSTB (effectively >>> disabling >>> the PCI driver for the platform) got things working happily again. >>> >>> I'm happy to submit the local patches I'm adding to the Ubuntu build to work >>> around these, but obviously those fixes are "brute force and ignorance" >>> patches >>> that just disable the relevant config; would such patches be wanted, or >>> would >>> the community prefer to figure out the root causes in each case? I'm happy >>> to >>> test any patches on the relevant hardware if anyone doesn't have access to >>> the >>> necessary boards. >>> >> >> Thanks for looking into this. I'm aware of problems booting CM4 and RPi 400 >> with >> PCI. I wasn't aware that RPi4 8GB problem was related to PCI as well. Would >> you >> mind to test this series, if this fixes your problems: >> https://patchwork.ozlabs.org/user/todo/uboot/?series=220661 > > That's your todo list so the link doesn't work for an anonymous consumer. > Right, sorry not my day today: https://patchwork.ozlabs.org/project/uboot/list/?series=220661 Regards, Matthias
Re: U-Boot failures on CM4 and Pi4-8Gb
Hi Dave, On 16/12/2020 15:23, Dave Jones wrote: > Hi, > > We've recently run across some failures with U-Boot on a couple of platforms, > specifically the relatively new Pi Compute Module 4, and the Pi 4 8GB of RAM. > On > the CM4, U-Boot failed to identify the eMMC storage, and on the Pi 4 8GB, a > crash and reset occurred when U-Boot tried to read from the boot file-system > on > the SD card, but only when booted with no monitor attached (attaching a > monitor > results in a successful boot, at least under arm64). These were with > more-or-less stock rpi_4_defconfig and rpi_4_32b_defconfig configurations from > v2020.10 (our local config changes bump the env-size, enable OF_BOARD, and > RAW_INITRD, but that's it). > > I've bisected the source and figured out roughly the commits responsible; for > the CM4 eMMC case it's the enabling of DMA for the SDHCI interface in > c6b9fbf756. > > The Pi 4 8GB failure was a little more complex in that the bisection pointed > to > 3113c84ba2 (a merge), however that gave me a few clues to try and after a > little > experimenting I found that disabling CONFIG_PCI_BRCMSTB (effectively disabling > the PCI driver for the platform) got things working happily again. > > I'm happy to submit the local patches I'm adding to the Ubuntu build to work > around these, but obviously those fixes are "brute force and ignorance" > patches > that just disable the relevant config; would such patches be wanted, or would > the community prefer to figure out the root causes in each case? I'm happy to > test any patches on the relevant hardware if anyone doesn't have access to the > necessary boards. > Thanks for looking into this. I'm aware of problems booting CM4 and RPi 400 with PCI. I wasn't aware that RPi4 8GB problem was related to PCI as well. Would you mind to test this series, if this fixes your problems: https://patchwork.ozlabs.org/user/todo/uboot/?series=220661 Regards, Matthias
Re: [PATCH 2/2] net: Use NDRNG device in srand_mac()
On 16/12/2020 14:20, Torsten Duwe wrote:
> On Wed, 16 Dec 2020 11:41:17 +0100
> matthias@kernel.org wrote:
>
>> From: Matthias Brugger
>>
>> When calling srand_mac we use a weak seed dependent on the
>> mac address. If present, use a RNG device instead to incerase entropy.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> net/net_rand.h | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/net_rand.h b/net/net_rand.h
>> index 4bf9bd817e..600c3d825e 100644
>> --- a/net/net_rand.h
>> +++ b/net/net_rand.h
>> @@ -10,6 +10,7 @@
>> #define __NET_RAND_H__
>>
>> #include
>> +#include
>>
>> /*
>> * Return a seed for the PRNG derived from the eth0 MAC address.
>> @@ -37,7 +38,22 @@ static inline unsigned int seed_mac(void)
>> */
>> static inline void srand_mac(void)
>> {
>> -srand(seed_mac());
>> +#if defined(CONFIG_DM_RNG)
>> +int ret;
>> +struct udevice *devp;
>> +u32 randv = 0;
>> +
>> +ret = uclass_get_device(UCLASS_RNG, 0, );
>> +if (ret) {
>> +ret = dm_rng_read(dev, randv, sizeof(randv));
> Haven't tested this (yet), but shouldn't this be
> ret = dm_rng_read(devp, , sizeof(randv));
>^ ^ ?
Ups, yes you are right. I'll send a v2.
Regards,
Matthias
Re: [PATCH v2 4/8] dm: Introduce xxx_get_dma_range()
On 10/12/2020 10:42, Nicolas Saenz Julienne wrote:
> Add the following functions to get a specific device's DMA ranges:
> - dev_get_dma_range()
> - ofnode_get_dma_range()
> - of_get_dma_range()
> - fdt_get_dma_range()
> They are specially useful in oder to be able validate a physical address
> space range into a bus's and to convert addresses from and to address
> spaces.
>
> Signed-off-by: Nicolas Saenz Julienne
>
> ---
> Changes since v1:
> - Fix wrong arguments in of_get_dma_range()'s call to
> of_translate_dma_address()
> - Fix build in SPL/TPL and no LIBFDT supprt
> - Add missing declaration in 'core/read.c'
> - Address Matthias' comments
>
> common/fdt_support.c | 73 ++
> drivers/core/of_addr.c | 71
> drivers/core/ofnode.c | 9 ++
> drivers/core/read.c| 9 ++
> include/dm/of_addr.h | 17 ++
> include/dm/ofnode.h| 16 +
> include/dm/read.h | 21
> include/fdt_support.h | 14
> 8 files changed, 230 insertions(+)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 5ae75df3c6..4bcd6720d2 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -1342,6 +1342,79 @@ u64 fdt_translate_dma_address(const void *blob, int
> node_offset,
> return __of_translate_address(blob, node_offset, in_addr, "dma-ranges");
> }
>
> +int fdt_get_dma_range(const void *blob, int node, phys_addr_t *cpu,
> + dma_addr_t *bus, u64 *size)
> +{
> + bool found_dma_ranges = false;
> + struct of_bus *bus_node;
> + const fdt32_t *ranges;
> + int na, ns, pna, pns;
> + int parent = node;
> + int ret = 0;
> + int len;
> +
> + /* Find the closest dma-ranges property */
> + while (parent >= 0) {
> + ranges = fdt_getprop(blob, parent, "dma-ranges", );
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
> +
> + /* Once we find 'dma-ranges', then a missing one is an error */
> + if (found_dma_ranges && !ranges) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + if (ranges)
> + found_dma_ranges = true;
> +
> + parent = fdt_parent_offset(blob, parent);
> + }
> +
> + if (!ranges || parent < 0) {
> + debug("no dma-ranges found for node %s\n",
> + fdt_get_name(blob, node, NULL));
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + /* switch to that node */
> + node = parent;
> + parent = fdt_parent_offset(blob, node);
> + if (parent < 0) {
> + printf("Found dma-ranges in root node, shoudln't happen\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* Get the address sizes both for the bus and its parent */
> + bus_node = of_match_bus(blob, node);
> + bus_node->count_cells(blob, node, , );
> + if (!OF_CHECK_COUNTS(na, ns)) {
> + printf("%s: Bad cell count for %s\n", __FUNCTION__,
> +fdt_get_name(blob, node, NULL));
> + return -EINVAL;
> + goto out;
> + }
> +
> + bus_node = of_match_bus(blob, parent);
> + bus_node->count_cells(blob, parent, , );
> + if (!OF_CHECK_COUNTS(pna, pns)) {
> + printf("%s: Bad cell count for %s\n", __FUNCTION__,
> +fdt_get_name(blob, parent, NULL));
> + return -EINVAL;
> + goto out;
> + }
> +
> + *bus = fdt_read_number(ranges, na);
> + *cpu = fdt_translate_dma_address(blob, node, ranges + na);
> + *size = fdt_read_number(ranges + na + pna, ns);
> +out:
> + return ret;
> +}
> +
> /**
> * fdt_node_offset_by_compat_reg: Find a node that matches compatiable and
> * who's reg property matches a physical cpu address
> diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
> index ca34d84922..b1d6165b0a 100644
> --- a/drivers/core/of_addr.c
> +++ b/drivers/core/of_addr.c
> @@ -325,6 +325,77 @@ u64 of_translate_dma_address(const struct device_node
> *dev, const __be32 *in_add
> return __of_translate_address(dev, in_addr, "dma-ranges");
> }
>
> +int of_get_dma_range(const struct device_node *dev, phys_addr_t *cpu,
> + dma_addr_t *bus, u64 *size)
> +{
> + bool found_dma_ranges = false;
> + struct device_node *parent;
> + struct of_bus *bus_node;
> + int na, ns, pna, pns;
> + const __be32 *ranges;
> + int ret = 0;
> + int len;
> +
> + /* Find the closest dma-ranges property */
> + while (dev) {
> + ranges = of_get_property(dev, "dma-ranges", );
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
Re: [PATCH 4/8] dm: Introduce xxx_get_dma_range()
On 19/11/2020 18:48, Nicolas Saenz Julienne wrote:
> Add the follwing functions to get a specific device's DMA ranges:
> - dev_get_dma_range()
> - ofnode_get_dma_range()
> - of_get_dma_range()
> - fdt_get_dma_range()
> They are specially useful in oder to be able validate a physical address
> space range into a bus's and to convert addresses from and to address
> spaces.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> common/fdt_support.c | 72 ++
> drivers/core/of_addr.c | 68 +++
> drivers/core/ofnode.c | 9 ++
> drivers/core/read.c| 5 +++
> include/dm/of_addr.h | 17 ++
> include/dm/ofnode.h| 16 ++
> include/dm/read.h | 6
> include/fdt_support.h | 14
> 8 files changed, 207 insertions(+)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 5ae75df3c6..78dc7906bd 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -1342,6 +1342,78 @@ u64 fdt_translate_dma_address(const void *blob, int
> node_offset,
> return __of_translate_address(blob, node_offset, in_addr, "dma-ranges");
> }
>
> +int fdt_get_dma_range(const void *blob, int node, phys_addr_t *cpu,
> + dma_addr_t *bus, u64 *size)
> +{
> + bool found_dma_ranges = false;
> + const fdt32_t *ranges;
> + int na, ns, pna, pns;
> + int parent = node;
> + u64 cpu_addr;
> + int ret = 0;
> + int len;
> +
> + /* Find the closest dma-ranges property */
> + while (parent >= 0) {
> + ranges = fdt_getprop(blob, parent, "dma-ranges", );
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
> +
> + /* Once we find 'dma-ranges', then a missing one is an error */
> + if (found_dma_ranges && !ranges) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + if (ranges)
> + found_dma_ranges = true;
> +
> + parent = fdt_parent_offset(blob, parent);
> + }
> +
> + if (!ranges || parent < 0) {
> + debug("no dma-ranges found for node %s\n",
> + fdt_get_name(blob, node, NULL));
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + /* switch to that node */
> + node = parent;
> + parent = fdt_parent_offset(blob, node);
> + if (parent < 0) {
> + printf("Found dma-ranges in root node, shoudln't happen\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* Get the address sizes both for the bus and its parent */
> + of_match_bus(blob, node)->count_cells(blob, node, , );
Please see comment in of_get_dma_range().
> + if (!OF_CHECK_COUNTS(na, ns)) {
> + printf("%s: Bad cell count for %s\n", __FUNCTION__,
> +fdt_get_name(blob, node, NULL));
> + return -EINVAL;
> + goto out;
> + }
> +
> + of_match_bus(blob, parent)->count_cells(blob, parent, , );
> + if (!OF_CHECK_COUNTS(pna, pns)) {
> + printf("%s: Bad cell count for %s\n", __FUNCTION__,
> +fdt_get_name(blob, parent, NULL));
> + return -EINVAL;
> + goto out;
> + }
> +
> + *bus = fdt_read_number(ranges, na);
> + cpu_addr = fdt_read_number(ranges + na, pna);
> + *cpu = fdt_translate_dma_address(blob, node, (const fdt32_t*)_addr);
> + *size = fdt_read_number(ranges + na + pna, ns);
> +out:
> + return ret;
> +}
> +
> /**
> * fdt_node_offset_by_compat_reg: Find a node that matches compatiable and
> * who's reg property matches a physical cpu address
> diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
> index ca34d84922..8457e04a25 100644
> --- a/drivers/core/of_addr.c
> +++ b/drivers/core/of_addr.c
> @@ -325,6 +325,74 @@ u64 of_translate_dma_address(const struct device_node
> *dev, const __be32 *in_add
> return __of_translate_address(dev, in_addr, "dma-ranges");
> }
>
> +int of_get_dma_range(const struct device_node *dev, phys_addr_t *cpu,
> + dma_addr_t *bus, u64 *size)
> +{
> + bool found_dma_ranges = false;
> + struct device_node parent;
> + int na, ns, pna, pns;
> + const __be32 *ranges;
> + int ret = 0;
> + int len;
> +
> + /* Find the closest dma-ranges property */
> + while (dev) {
> + ranges = of_get_property(dev, "dma-ranges", );
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
> +
> + /* Once we find 'dma-ranges', then a missing one is an error */
> + if (found_dma_ranges && !ranges) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> +
Re: [PATCH 2/8] rpi: Add identifier for the new CM4
On 19/11/2020 18:48, Nicolas Saenz Julienne wrote:
The Raspberry Pi Foundation released the new Compute Module 4which we
"Module 4 which we "
(missing space)
want to detect, so we can enable Ethernet on it and know the correct
device tree file name.
Note that this sets the Ethernet option to true since the official CM4
IO board has an Ethernet port. But that might not be the case when using
custom ones.
Signed-off-by: Nicolas Saenz Julienne
---
---
board/raspberrypi/rpi/rpi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index ce60a24352..4ffd23c6ac 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -162,6 +162,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-4-b.dtb",
true,
},
+ [0x14] = {
+ "Compute Modue 4",
+ DTB_DIR "bcm2711-rpi-cm4.dtb",
+ true,
+ },
};
static const struct rpi_model rpi_models_old_scheme[] = {
Re: [PATCH 1/8] rpi: Add identifier for the new RPi400
On 19/11/2020 18:48, Nicolas Saenz Julienne wrote:
The Raspberry Pi Foundation released the new RPi400 which we want to
detect, so we can enable Ethernet on it and know the correct device tree
file name.
So far the Raspberry Pi foundation is using the RPi4b device-tree file
to boot RPi400. I see no reason not to do the same as they are
completely compatible.
Signed-off-by: Nicolas Saenz Julienne
---
board/raspberrypi/rpi/rpi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 6b1fa5fc14..ce60a24352 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -157,6 +157,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-4-b.dtb",
true,
},
+ [0x13] = {
+ "400",
Holding to the documentation this should be "Pi 400". If I don't find any other
issues, I can fix that up for you. No need for a v2.
+ DTB_DIR "bcm2711-rpi-4-b.dtb",
+ true,
+ },
};
static const struct rpi_model rpi_models_old_scheme[] = {
[GIT PULL] u-boot-rpi/rpi-next to next
Hi Tom, I have a few patches for the next branch, please pull :) Regards, Matthias --- The following changes since commit 7e373a1a6ac27492ffebba146d70c4d39a9b9f36: Merge branch 'next' of git://git.denx.de/u-boot-usb into next (2020-10-01 14:52:56 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git rpi-next for you to fetch changes up to 0db912de153743e2ec97bd022640c5722eb07737: pinctrl: bcm283x: Store the return value of dev_read_u32_default to int (2020-10-02 17:32:28 +0200) Ovidiu Panait (3): pinctrl: bcm283x: DM_FLAG_PRE_RELOC: Remove OF_CONTROL check pinctrl: bcm283x: Read address from DT in ofdata_to_platdata pinctrl: bcm283x: Store the return value of dev_read_u32_default to int drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-)
Re: U-Boot issue
Hi Matteo, On 16/09/2020 00:27, Heinrich Schuchardt wrote: On 8/17/20 11:59 AM, 0x5c4r3 wrote: Hello guys, I am Matteo Peruzzi, a cyber-security expert. I am currently working on a project, creating a root of trust on RPI 2 using a TPM2 module and U-Boot. I noticed that in the latest update, u-boot has an issue: it does not detect my USB keyboard connected to the RPI (if I use an early version it works, no problems), so I am not able to interrupt the autobooting and communicate with u-boot. Are you planning to solve this in further updates? Also, I am not able to use the UART because it uses the same pins used by the TPM2 module. Thanks for your time, if you need more details just text me. Sorry for the late answer. Can give some details of your USB keyboard. Is it just a normal keyboard, or has it touchpad integrated? Is it USB2.0 or older? Regards, Matthias The board/raspberrypi/rpi/MAINTAINERS file provides the right contact. Cc: Matthias Brugger Thanks Matteo Peruzzi
Re: [PATCH v2 1/1] examples: make examples/ optional
On 23/09/2020 19:09, Heinrich Schuchardt wrote: Most users don't need the standalone API examples. Distributions like SUSE do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/. Make examples selectable via symbol CONFIG_EXAMPLES. It defaults to yes on ARCH_QEMU to ensure that we compile the API as part of our continuous integration. Cc: Matthias Brugger Signed-off-by: Heinrich Schuchardt Reviewed-by: Matthias Brugger --- v2: default=y on ARCH_QEMU only --- Kconfig | 8 examples/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 883e3f71d0..d0eae2ceba 100644 --- a/Kconfig +++ b/Kconfig @@ -422,6 +422,14 @@ config SYS_SRAM_SIZE default 0x1 if TARGET_TRICORDER default 0x0 +config EXAMPLES + bool "Compile API examples" + depends on !SANDBOX + default y if ARCH_QEMU + help + U-Boot provides an API for standalone applications. Examples are + provided in directory examples/. + endmenu # General setup menu "Boot images" diff --git a/examples/Makefile b/examples/Makefile index d440bc5655..bf518bd221 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+ -ifndef CONFIG_SANDBOX +ifdef CONFIG_EXAMPLES ifdef FTRACE subdir-ccflags-y += -finstrument-functions -DFTRACE -- 2.28.0
Re: [PATCH 1/1] examples: make examples customizable
On 22/09/2020 20:03, Heinrich Schuchardt wrote: Most users don't need the standalone API examples. Distributions like Suse Nit: It's SUSE not Suse Regards, Matthias do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/. Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI. Cc: Matthias Brugger Signed-off-by: Heinrich Schuchardt --- I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application. --- Kconfig | 8 examples/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 883e3f71d0..d0eae2ceba 100644 --- a/Kconfig +++ b/Kconfig @@ -422,6 +422,14 @@ config SYS_SRAM_SIZE default 0x1 if TARGET_TRICORDER default 0x0 +config EXAMPLES + bool "Compile API examples" + depends on !SANDBOX + default y + help + U-Boot provides an API for standalone applications. Examples are + provided in directory examples/. + endmenu # General setup menu "Boot images" diff --git a/examples/Makefile b/examples/Makefile index d440bc5655..bf518bd221 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+ -ifndef CONFIG_SANDBOX +ifdef CONFIG_EXAMPLES ifdef FTRACE subdir-ccflags-y += -finstrument-functions -DFTRACE -- 2.28.0
Re: [RFC 1/1] doc/build/gcc.rst: required packages for Suse
Hi Heinrich, On 20/09/2020 12:09, Heinrich Schuchardt wrote: Describe the packages required to build U-Boot on Suse. Signed-off-by: Heinrich Schuchardt --- Hello Matthias, I would like to add a sub-chapter to our documentation describing what is needed to build U-Boot on Suse. Cf. https://u-boot.readthedocs.io/en/latest/build/gcc.html Unfortunately I could not find all the packages that need to be installed in the Suse Tumbleweed Docker image. For 'make qemu_arm64_defconfig && make' I get an error aarch64-suse-linux-ld.bfd: cannot find -lgcc If I remember correctly, that's a known problem in our cross toolchain (ouch!). I forwarded the info to our toolchain team, but didn't got any response up to now. For 'make tests' a lot more seems to be missing. Do you have a list of required packages? No I don't. I suppose I installed all packages once on my laptop, but I didn't kept track which one these are. Regards, Matthias Best regards Heinrich --- doc/build/gcc.rst | 20 1 file changed, 20 insertions(+) diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst index fcb0b1ffb3..6250dc1880 100644 --- a/doc/build/gcc.rst +++ b/doc/build/gcc.rst @@ -29,6 +29,26 @@ Depending on the build targets further packages maybe needed lzma-alone openssl python3 python3-coverage python3-pyelftools \ python3-pytest python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme swig +Suse based +~~ + +On Suse based systems the cross compiler packages are named +cross--gcc. + +You could install GCC and the GCC 10 cross compiler for the ARMv8 architecture +with + +.. code-block:: bash + +sudo zypper install gcc cross-aarch64-gcc10 + +Depending on the build targets further packages maybe needed. + +.. code-block:: bash + +zypper install bc bison flex gcc libopenssl-devel libSDL2-devel make \ + ncurses-devel python3-devel python3-pytest swig + Prerequisites - -- 2.28.0
Re: RPi4 U-Boot freeze
On 10/09/2020 23:12, Stefan Agner wrote: On 2020-09-07 16:36, Peter Robinson wrote: Any thoughts on this issue? Any reason why you're using 2020.01 and not at least 2020.07, or at least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has changed quite a bit since then I suspect. Hi Peter, It's a stable release and we support a couple of devices with the same U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well. We are on 2020.07 on development branch, and it does work fine there. So I thought it can't be that hard, just bisect and backport whatever fixes it... Unfortunately, it seems that there is no particular commit which fixes it (the bisect ended up in a random unrelated commit, and it seems that the issue appears/disappears depending on alignment/size...). I also did applied pretty much every RPi4 related commit made after 2020.01 up until master back to 2020.01, no success either. Which version of the Raspberry Pi firmware did you use? Unfortunately changes in the FW breaks stuff on U-Boot from time to time. Regards, Mathias I fear that the problem in fact is still in master, but only appears if certain things align a certain way... That is why I thought I bring it up, to see if anybody else has noticed something along this lines. We do have a rather trimmed down configuration, which might make the problem appear more (fit in a D cache...). I probably will just disable cached around relocation for 2020.01 and see if it resurfaces on development branch. -- Stefan Just to be sure, I did some memory testing on the 2GB module, but no issues found. I still somehow suspected that something else might be wrong with my hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the very same with that: U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +) DRAM: 3.9 GiB I still think there is something wrong with caching. From what I understand caches are enabled by the RPi (4) firmware. Is it safe to run 32-bit ARM U-Boot with enabled caches? -- Stefan On 2020-08-23 19:06, Stefan Agner wrote: Hi, I noticed a quite common freeze when running 32-bit U-Boot 2020.01 (rpi_4_32b_defconfig) on a 2GB RPi4 model: U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +) DRAM: 1.9 GiB This happens fairly often, I would say 4 out of 5 boot tries. However, if it boots, everything seems to run fine. The issue seems to go away when using 2020.04 or any newer release, however, when trying to find the actual patch fixing the issue using git bisect I ended up with a MMC merge request which really seems unrelated (36bdcf7f3b). It seems that the problem is quite evasive and disappears if certain structure are aligned differently etc. Enabling initcall debugging showed that U-Boot crashes right after relocation: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 4000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 00016ec8 [clear_bss] initcall: 0004465c [display_options?? only appears sometimes] I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to disappear. But to be 100% certain that it is cache related, I used my original configuration (which is known to "reliably" freeze), and replaced 00016ec8 with 8688 manually in the binary, essentially swapping out function pointers in "init_sequence_f" [8688 is cleanup_before_linux, which flushes and disables I-cache/D-cache]. And indeed, that hacked up binary does boot reliably every time: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 4000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 8688 initcall: 3b38c10c initcall: 3b38c114 initcall: 000172e0 (relocated to 3b38c2e0) initcall: 0001712c (relocated to 3b38c12c) ... From what I understand on RPi4 caches are enabled when entering U-Boot. I was wondering if the relocation code really can handle that? -- Stefan
Re: [GIT PULL] rpi: second round for v2020.10
On 09/09/2020 21:20, Petr Tesarik wrote: On Wed, 9 Sep 2020 10:13:50 +0200 Matthias Brugger wrote: Hi Tom, Please have a look at the second round of patches for the RPi. Two patches fixes the network driver of the RPi4 which didn't work reliable. Another patch enables USB keyboard for 32 bit RPi4. Petr tested the network patches, but his mail with the Tested-by tag didn't come through. I added it anyway. What do you mean by "didn't come through"? I can see it in the mailing list archive: http://u-boot.10912.n7.nabble.com/PATCH-bcmgenet-fix-DMA-buffer-management-td419536.html#a424854 Did I send my answer to the wrong thread? Ups, it seems I rely too much on my inbox instead of the filtered U-Boot list. In any case I exepcted the Tested-by for the two patches you mentioned in the thread. Anyway it's no big deal. Regards, Matthias Petr T As always you can find the CI outcome here: https://travis-ci.org/github/mbgg/u-boot/builds/725262009 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/4622 I ran the CI against the rpi-next branch and not the tag, but you can verify that this is basically the same commit id. Thanks for having a look! Regards, Matthias -- The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ tags/rpi-next-2020.10.2 for you to fetch changes up to 40877a1a949edf7066b3e4ed16101153624bb314: config: Enable USB Keyboard suuport on RPi4 32 bit (2020-09-08 16:45:01 +0200) - fixes for bcmgenet - enable USB keyboard for RPi4 32 bit Jason Wessel (2): bcmgenet: fix DMA buffer management bcmgenet: Add support for rgmii-rxid Matthias Brugger (1): config: Enable USB Keyboard suuport on RPi4 32 bit configs/rpi_4_32b_defconfig | 1 + drivers/net/bcmgenet.c | 20 +++- 2 files changed, 12 insertions(+), 9 deletions(-)
[GIT PULL] rpi: second round for v2020.10
Hi Tom, Please have a look at the second round of patches for the RPi. Two patches fixes the network driver of the RPi4 which didn't work reliable. Another patch enables USB keyboard for 32 bit RPi4. Petr tested the network patches, but his mail with the Tested-by tag didn't come through. I added it anyway. As always you can find the CI outcome here: https://travis-ci.org/github/mbgg/u-boot/builds/725262009 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/4622 I ran the CI against the rpi-next branch and not the tag, but you can verify that this is basically the same commit id. Thanks for having a look! Regards, Matthias -- The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ tags/rpi-next-2020.10.2 for you to fetch changes up to 40877a1a949edf7066b3e4ed16101153624bb314: config: Enable USB Keyboard suuport on RPi4 32 bit (2020-09-08 16:45:01 +0200) - fixes for bcmgenet - enable USB keyboard for RPi4 32 bit Jason Wessel (2): bcmgenet: fix DMA buffer management bcmgenet: Add support for rgmii-rxid Matthias Brugger (1): config: Enable USB Keyboard suuport on RPi4 32 bit configs/rpi_4_32b_defconfig | 1 + drivers/net/bcmgenet.c | 20 +++- 2 files changed, 12 insertions(+), 9 deletions(-)
Re: [GIT PULL] rpi-next for v2020.10
On 10/07/2020 16:50, Matthias Brugger wrote: Hi Tom, Please have a look on the first pull request for RPi for the future v2020.10 release. With this patches accepted we will have USB support on 64 bit. 32 bit support is in the works and should land in v2020.10 as well. Like many times I forgot to add the links to the CI pipelines: https://travis-ci.org/github/mbgg/u-boot/builds/706819202 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/3987 The branch is rpi-next but the commit ID should be the same as the tag. Regards, Matthias Please pull :) Regards, Matthias --- The following changes since commit 61608f395e7dcb2be6060407a72a1149b046430a: Merge branch '2020-07-08-misc-features-and-fixes' (2020-07-08 20:20:24 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.10 for you to fetch changes up to d6ecb71a1f0c764c94f1bb381f085734d57e94e9: config: Enable USB Keyboard support on RPi4 (2020-07-10 11:50:36 +0200) - add support for PCI and XHCI for RPi4 (64 bit only) - optionally reset XHCI device on registration - enable USB_KEYBOARD for rpi_4_defconfig Marek Szyprowski (3): rpi4: shorten a mapping for the DRAM rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit) configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit) Nicolas Saenz Julienne (6): linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian arm: rpi: Add function to trigger VL805's firmware load reset: Add Raspberry Pi 4 firmware reset controller configs: Enable support for reset controllers on RPi4 usb: xhci: Add reset controller support config: Enable USB Keyboard support on RPi4 Sylwester Nawrocki (5): usb: xhci: Add missing cache flush in the scratchpad array initialization usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq pci: Move some PCIe register offset definitions to a common header pci: Add some PCI Express capability register offset definitions pci: Add driver for Broadcom BCM2711 SoC PCIe controller arch/arm/mach-bcm283x/include/mach/mbox.h | 13 + arch/arm/mach-bcm283x/include/mach/msg.h | 7 + arch/arm/mach-bcm283x/init.c | 20 +- arch/arm/mach-bcm283x/msg.c | 46 ++ configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 11 + configs/rpi_arm64_defconfig | 9 +- drivers/pci/Kconfig | 9 + drivers/pci/Makefile | 1 + drivers/pci/pci-rcar-gen3.c | 8 - drivers/pci/pcie_brcmstb.c | 623 + drivers/pci/pcie_intel_fpga.c | 3 - drivers/reset/Kconfig | 11 + drivers/reset/Makefile | 1 + drivers/reset/reset-raspberrypi.c | 60 ++ drivers/usb/host/xhci-mem.c | 5 + drivers/usb/host/xhci.c | 35 ++ .../dt-bindings/reset/raspberrypi,firmware-reset.h | 13 + include/linux/bitfield.h | 53 ++ include/pci.h | 22 +- include/usb/xhci.h | 10 +- 21 files changed, 935 insertions(+), 26 deletions(-) create mode 100644 drivers/pci/pcie_brcmstb.c create mode 100644 drivers/reset/reset-raspberrypi.c create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
[GIT PULL] rpi-next for v2020.10
Hi Tom, Please have a look on the first pull request for RPi for the future v2020.10 release. With this patches accepted we will have USB support on 64 bit. 32 bit support is in the works and should land in v2020.10 as well. Please pull :) Regards, Matthias --- The following changes since commit 61608f395e7dcb2be6060407a72a1149b046430a: Merge branch '2020-07-08-misc-features-and-fixes' (2020-07-08 20:20:24 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.10 for you to fetch changes up to d6ecb71a1f0c764c94f1bb381f085734d57e94e9: config: Enable USB Keyboard support on RPi4 (2020-07-10 11:50:36 +0200) - add support for PCI and XHCI for RPi4 (64 bit only) - optionally reset XHCI device on registration - enable USB_KEYBOARD for rpi_4_defconfig Marek Szyprowski (3): rpi4: shorten a mapping for the DRAM rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit) configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit) Nicolas Saenz Julienne (6): linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian arm: rpi: Add function to trigger VL805's firmware load reset: Add Raspberry Pi 4 firmware reset controller configs: Enable support for reset controllers on RPi4 usb: xhci: Add reset controller support config: Enable USB Keyboard support on RPi4 Sylwester Nawrocki (5): usb: xhci: Add missing cache flush in the scratchpad array initialization usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq pci: Move some PCIe register offset definitions to a common header pci: Add some PCI Express capability register offset definitions pci: Add driver for Broadcom BCM2711 SoC PCIe controller arch/arm/mach-bcm283x/include/mach/mbox.h | 13 + arch/arm/mach-bcm283x/include/mach/msg.h | 7 + arch/arm/mach-bcm283x/init.c | 20 +- arch/arm/mach-bcm283x/msg.c| 46 ++ configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 11 + configs/rpi_arm64_defconfig| 9 +- drivers/pci/Kconfig| 9 + drivers/pci/Makefile | 1 + drivers/pci/pci-rcar-gen3.c| 8 - drivers/pci/pcie_brcmstb.c | 623 + drivers/pci/pcie_intel_fpga.c | 3 - drivers/reset/Kconfig | 11 + drivers/reset/Makefile | 1 + drivers/reset/reset-raspberrypi.c | 60 ++ drivers/usb/host/xhci-mem.c| 5 + drivers/usb/host/xhci.c| 35 ++ .../dt-bindings/reset/raspberrypi,firmware-reset.h | 13 + include/linux/bitfield.h | 53 ++ include/pci.h | 22 +- include/usb/xhci.h | 10 +- 21 files changed, 935 insertions(+), 26 deletions(-) create mode 100644 drivers/pci/pcie_brcmstb.c create mode 100644 drivers/reset/reset-raspberrypi.c create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
Re: [PATCH] include/bitfield.h: include byteorder.h
On 09/07/2020 19:41, Nicolas Saenz Julienne wrote: This is needed in order to use the cpu_to_*()/*_to_cpu() family of functions. Signed-off-by: Nicolas Saenz Julienne --- IMO the ideal thing would be to squash this into the original patch. I'll test and squash, thanks! include/linux/bitfield.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h index 7ad8b088ed..7ad02f8cbb 100644 --- a/include/linux/bitfield.h +++ b/include/linux/bitfield.h @@ -16,6 +16,7 @@ #define _LINUX_BITFIELD_H #include +#include /* * Bitfield access macros
Re: [PATCH] xhci: Only build xhci_reset_hw() if CONFIG_DM_USB is enabled
On 09/07/2020 19:31, Nicolas Saenz Julienne wrote: This was breaking build on some configurations. Signed-off-by: Nicolas Saenz Julienne --- Matthias, I don't know if it's possible at this stage, but I'd ideally squash this into the offending patch. I'll test the patch and squash. Thanks! drivers/usb/host/xhci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index e252964d0d..f635bb39f6 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -190,6 +190,7 @@ static int xhci_start(struct xhci_hcor *hcor) return ret; } +#if CONFIG_IS_ENABLED(DM_USB) /** * Resets XHCI Hardware * @@ -218,6 +219,7 @@ static int xhci_reset_hw(struct xhci_ctrl *ctrl) return 0; } +#endif /** * Resets the XHCI Controller
Re: [PATCH v6 4/4] usb: xhci: Add reset controller support
On 29/06/2020 18:37, Nicolas Saenz Julienne wrote:
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v5:
- Take !CONFIG_IS_ENABLED(DM_RESET) into account
drivers/usb/host/xhci-mem.c | 2 ++
drivers/usb/host/xhci.c | 33 +
include/usb/xhci.h | 2 ++
3 files changed, 37 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f446520528..108f4bd8cf 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -180,6 +180,8 @@ void xhci_cleanup(struct xhci_ctrl *ctrl)
xhci_free_virt_devices(ctrl);
free(ctrl->erst.entries);
free(ctrl->dcbaa);
+ if (reset_valid(>reset))
+ reset_free(>reset);
memset(ctrl, '\0', sizeof(struct xhci_ctrl));
}
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ebd2954571..e252964d0d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -190,6 +190,35 @@ static int xhci_start(struct xhci_hcor *hcor)
return ret;
}
+/**
+ * Resets XHCI Hardware
+ *
+ * @param ctrl pointer to host controller
+ * @return 0 if OK, or a negative error code.
+ */
+static int xhci_reset_hw(struct xhci_ctrl *ctrl)
+{
+ int ret;
+
+ ret = reset_get_by_index(ctrl->dev, 0, >reset);
That seems to break arm32 builds:
https://pastebin.com/eHBf7Xp0
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/jobs/121247
Nicolas, can you have a look?
Thanks
Matthias
+ if (ret && ret != -ENOENT && ret != -ENOTSUPP) {
+ dev_err(ctrl->dev, "failed to get reset\n");
+ return ret;
+ }
+
+ if (reset_valid(>reset)) {
+ ret = reset_assert(>reset);
+ if (ret)
+ return ret;
+
+ ret = reset_deassert(>reset);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* Resets the XHCI Controller
*
@@ -1508,6 +1537,10 @@ int xhci_register(struct udevice *dev, struct xhci_hccr
*hccr,
ctrl->dev = dev;
+ ret = xhci_reset_hw(ctrl);
+ if (ret)
+ goto err;
+
/*
* XHCI needs to issue a Address device command to setup
* proper device context structures, before it can interact
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 1170c0ac69..7d34103fd5 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -16,6 +16,7 @@
#ifndef HOST_XHCI_H_
#define HOST_XHCI_H_
+#include
#include
#include
#include
@@ -1209,6 +1210,7 @@ struct xhci_ctrl {
#if CONFIG_IS_ENABLED(DM_USB)
struct udevice *dev;
#endif
+ struct reset_ctl reset;
struct xhci_hccr *hccr; /* R/O registers, not need for volatile */
struct xhci_hcor *hcor;
struct xhci_doorbell_array *dba;
Re: [PATCH v4 6/9] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
On 09/07/2020 17:35, Matthias Brugger wrote:
On 25/05/2020 13:39, Sylwester Nawrocki wrote:
From: Nicolas Saenz Julienne
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
e7d4a95da86e0 "bitfield: fix *_encode_bits()",
37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki
This seems to break compilation of
arch/arm/mach-uniphier/clk/pll-base-ld20.c
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/jobs/121248
Nicolas, Sylwester, can you please have a look.
Just in case you can't access the URL:
https://pastebin.com/KhDHf8e1
Regards,
Matthias
---
Changes since v3:
- none.
Changes since v2:
- added some more missing whitespaces as pointed out by checkpatch.pl.
Changes since v1:
- added empty lines between functions and macros.
Changes since RFC:
- new patch.
---
include/linux/bitfield.h | 52
1 file changed, 52 insertions(+)
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 8b9d6ff..7ad8b08 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -103,4 +103,56 @@
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})
+extern void __compiletime_error("value doesn't fit into mask")
+__field_overflow(void);
+extern void __compiletime_error("bad bitfield mask")
+__bad_mask(void);
+
+static __always_inline u64 field_multiplier(u64 field)
+{
+ if ((field | (field - 1)) & ((field | (field - 1)) + 1))
+ __bad_mask();
+ return field & -field;
+}
+
+static __always_inline u64 field_mask(u64 field)
+{
+ return field / field_multiplier(field);
+}
+
+#define MAKE_OP(type, base, to, from) \
+static __always_inline __##type type##_encode_bits(base v, base field) \
+{ \
+ if (__builtin_constant_p(v) && (v & ~field_mask(field))) \
+ __field_overflow(); \
+ return to((v & field_mask(field)) * field_multiplier(field)); \
+} \
+static __always_inline __##type type##_replace_bits(__##type old, \
+ base val, base field) \
+{ \
+ return (old & ~to(field)) | type##_encode_bits(val, field); \
+} \
+static __always_inline void type##p_replace_bits(__##type * p, \
+ base val, base field) \
+{ \
+ *p = (*p & ~to(field)) | type##_encode_bits(val, field); \
+} \
+static __always_inline base type##_get_bits(__##type v, base field) \
+{ \
+ return (from(v) & field) / field_multiplier(field); \
+}
+
+#define __MAKE_OP(size) \
+ MAKE_OP(le##size, u##size, cpu_to_le##size, le##size##_to_cpu) \
+ MAKE_OP(be##size, u##size, cpu_to_be##size, be##size##_to_cpu) \
+ MAKE_OP(u##size, u##size, ,)
+
+MAKE_OP(u8, u8, ,)
+__MAKE_OP(16)
+__MAKE_OP(32)
+__MAKE_OP(64)
+
+#undef __MAKE_OP
+#undef MAKE_OP
+
#endif
Re: [PATCH v4 6/9] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
On 25/05/2020 13:39, Sylwester Nawrocki wrote:
From: Nicolas Saenz Julienne
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
e7d4a95da86e0 "bitfield: fix *_encode_bits()",
37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki
This seems to break compilation of
arch/arm/mach-uniphier/clk/pll-base-ld20.c
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/jobs/121248
Nicolas, Sylwester, can you please have a look.
Regards,
Matthias
---
Changes since v3:
- none.
Changes since v2:
- added some more missing whitespaces as pointed out by checkpatch.pl.
Changes since v1:
- added empty lines between functions and macros.
Changes since RFC:
- new patch.
---
include/linux/bitfield.h | 52
1 file changed, 52 insertions(+)
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 8b9d6ff..7ad8b08 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -103,4 +103,56 @@
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})
+extern void __compiletime_error("value doesn't fit into mask")
+__field_overflow(void);
+extern void __compiletime_error("bad bitfield mask")
+__bad_mask(void);
+
+static __always_inline u64 field_multiplier(u64 field)
+{
+ if ((field | (field - 1)) & ((field | (field - 1)) + 1))
+ __bad_mask();
+ return field & -field;
+}
+
+static __always_inline u64 field_mask(u64 field)
+{
+ return field / field_multiplier(field);
+}
+
+#define MAKE_OP(type, base, to, from) \
+static __always_inline __##type type##_encode_bits(base v, base field) \
+{ \
+ if (__builtin_constant_p(v) && (v & ~field_mask(field)))\
+ __field_overflow(); \
+ return to((v & field_mask(field)) * field_multiplier(field)); \
+} \
+static __always_inline __##type type##_replace_bits(__##type old, \
+ base val, base field) \
+{ \
+ return (old & ~to(field)) | type##_encode_bits(val, field); \
+} \
+static __always_inline void type##p_replace_bits(__##type * p, \
+ base val, base field) \
+{ \
+ *p = (*p & ~to(field)) | type##_encode_bits(val, field);\
+} \
+static __always_inline base type##_get_bits(__##type v, base field)\
+{ \
+ return (from(v) & field) / field_multiplier(field); \
+}
+
+#define __MAKE_OP(size)
\
+ MAKE_OP(le##size, u##size, cpu_to_le##size, le##size##_to_cpu) \
+ MAKE_OP(be##size, u##size, cpu_to_be##size, be##size##_to_cpu) \
+ MAKE_OP(u##size, u##size, ,)
+
+MAKE_OP(u8, u8, ,)
+__MAKE_OP(16)
+__MAKE_OP(32)
+__MAKE_OP(64)
+
+#undef __MAKE_OP
+#undef MAKE_OP
+
#endif
Re: [PATCH v5 0/6] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support
Hi Marek, On 09/07/2020 08:33, Marek Szyprowski wrote: Hi Matthias, On 11.06.2020 10:39, Matthias Brugger wrote: ... Series looks good to me. The problem is that on RPi4 with 8 GB the USB FW get's loaded via the RPi FW. Nicolas provided a series which is under review right now. Without this series the 8 GB RPi4 won't boot. As soon as the series is ready I'll take all the RPi4 PCI/USB related patches into the next branch. I've noticed that You took both required patchsets to rpi-next branch. May I ask for taking this one too? I didn't forgot that series. The thing is, that it is assigned to Tom in patchwork, so I wanted to sync with him, if he is OK that I take the series. He provided already his Reviewed-by tags for the parts that I was concerned about. @Tom, is it OK if I take this series through my rpi-next branch? Regards, Matthias
Re: [PATCH] config: Enable USB Keyboard support on RPi4
On 05/05/2020 16:51, Nicolas Saenz Julienne wrote: Supporting USB keyboards out of the box is both handy for development and production. Notably if u-boot is used to boot into GRUB. Signed-off-by: Nicolas Saenz Julienne Applied to rpi-next now. I dropped the hunk for 32 bit for now, please resend once 32 bit support got accepted. Regards, Matthias --- Note that rpi_arm64_defconfig already supports USB keyboard. This is to be applied on top of Sylwester Nawrocki's PCIe/xHCI on RPi4 series. configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index dd7da1cf06..9c5ad7684e 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y +CONFIG_USB_KEYBOARD=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 6eeec4592e..1a92cd637e 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y +CONFIG_USB_KEYBOARD=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525
CONFIG_NR_DRAM_BANKS in configs/rpi_4* deleted
Hi Tom,
I just realized that
88bd5b1793 ("configs: Resync with savedefconfig")
Delete the CONFIG_NR_DRAM_BANKS entries as added in this patch, which leads to a
regression in RPi4 (only one GB of memory visible to the kernel if you use Grub
for booting).
Is it generally wrong to add CONFIG_NR_DRAM_BANKS to the config files? What is
the correct approach then?
Regards,
Matthias
On 29/05/2020 16:42, matthias@kernel.org wrote:
From: Matthias Brugger
With the new RPi4 which has 8 GB of RAM, we can have up to four DRAM
banks. Bump up the configuration files to detect all the memory in
U-Boot.
Signed-off-by: Matthias Brugger
---
configs/rpi_4_32b_defconfig | 2 +-
configs/rpi_4_defconfig | 2 +-
configs/rpi_arm64_defconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index b22316cbcb..f369bb93bd 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8000
CONFIG_TARGET_RPI_4_32B=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 165e166bbd..9b90790f06 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_4=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 0cc4efad70..db375eeba7 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_ARM64=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_PREBOOT=y
