Re: [PATCH] doc: Add documentation about devicetree usage
> From: Simon Glass > Date: Fri, 27 Aug 2021 21:23:48 -0600 > > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. > > Signed-off-by: Simon Glass > --- > > doc/develop/index.rst | 1 + > doc/develop/package/devicetree.rst | 315 + > doc/develop/package/index.rst | 1 + > 3 files changed, 317 insertions(+) > create mode 100644 doc/develop/package/devicetree.rst > > diff --git a/doc/develop/index.rst b/doc/develop/index.rst > index 83c929babda..d5ad8f9fe53 100644 > --- a/doc/develop/index.rst > +++ b/doc/develop/index.rst > @@ -36,6 +36,7 @@ Packaging > :maxdepth: 1 > > package/index > + package/devicetree > > Testing > --- > diff --git a/doc/develop/package/devicetree.rst > b/doc/develop/package/devicetree.rst > new file mode 100644 > index 000..fccbb182f3e > --- /dev/null > +++ b/doc/develop/package/devicetree.rst > @@ -0,0 +1,315 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Updating the devicetree > +=== > + > +U-Boot uses devicetree for runtime configuration and storing required blobs > or > +any other information it needs to operate. It is possible to update the > +devicetree separately from actually building U-Boot. This provides a good > degree > +of control and flexibility for firmware that uses U-Boot in conjunction with > +other project. > + > +There are many reasons why it is useful to modify the devicetree after > building > +it: > + > +- Configuration can be changed, e.g. which UART to use > +- A serial number can be added > +- Public keys can be added to allow image verification > +- Console output can be changed (e.g. to select serial or vidconsole) > + > +This section describes how to work with devicetree to accomplish your goals. > + > +See also :doc:`../devicetree/control` for a basic summary of the available > +features. > + > + > +Devicetree source > +- > + > +Every board in U-Boot must include a devicetree sufficient to build and boot > +that board on suitable hardware (or emulation). This is specified using the > +`CONFIG DEFAULT_DEVICE_TREE` option. > + > + > +Current situation (August 2021) > +~~~ > + > +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be > empty, > +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has > +unfortunately created an enormous amount of confusion and some wasted effort. > +This was not intended and this bug will be fixed soon. Specifically: > + > +- `CONFIG_OF_BOARD` was added in rpi_patch_ for Raspberry Pi, which does have > + an in-tree devicetree, but this feature has since been used for boards that > + don't > +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_patch_ as part of a larger > Broadcom > + change with a tag indicating it only affected one board, so the change in > + behaviour was not noticed at the time. It has since been used by RISC-V > qemu > + boards. > + > +Once this bug is fixed, CONFIG_OF_BOARD and CONFIG_OF_PRIOR_STAGE will > override > +(at runtime) the devicetree suppled with U-Boot, but will otherwise use > +CONFIG_OF_SEPARATE for the in-tree build. So these two will become options, > +moving out of the 'choice' in `dts/Kconfig` Not entirely sure what you mean by this, but for the Raspberry Pi this should remain a configure option. For OpenBSD we deliberately opt to use the device tree provided by the Raspberry Pi firmware because of the DT overlays. > + > +Offending boards are: > + > +- bcm7260 > +- bcm7445 > +- qemu_arm64 > +- qemu_arm > +- qemu-ppce500 > +- qemu-riscv32 > +- qemu-riscv32_smode > +- qemu-riscv64 > +- qemu-riscv64_smode > + > +All of these need to have a devicetree added in-tree. This is targeted to be > +fixed in the 2022.01 release. The Linux kernel doesn't seem to have such a requirement and doesn't provide any device trees for QEMU. So we can't just copy a device tree from there and one has to be invented. IMHO this requirement makes zero technical sense. > +Building the devicetree > +--- > + > +U-Boot automatically builds the devicetree for a board, from the > +`arch//dts` directory. The Makefile in those directories has rules for > +building devicetree files. It is preferable to avoid target-specific rules in > +those files: i.e. all boards for a particular SoC should be built at once, > +where practical. Apart from simplifying the Makefile, this helps to > efficiently > +(and immediately) ensure that changes in one board's DT do not break others > that > +are related. Building devicetrees is fast, so performance is seldom a concern > +here. > + > + > +Overriding the default devicetree > +- > + > +When building U-Boot, the `DEVICE_TREE` environment
Re: [PATCH 10/11] sandbox: mmc: Support a backing file
On 8/19/21 12:40 PM, Simon Glass wrote:
> Provide a way for sandbox MMC to present data from a backing file. This
> allows a filesystem to be created on the host and easily served via an
> emulated mmc device.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> doc/device-tree-bindings/mmc/sandbox,mmc.txt | 18
> drivers/mmc/sandbox_mmc.c| 46
> 2 files changed, 55 insertions(+), 9 deletions(-)
> create mode 100644 doc/device-tree-bindings/mmc/sandbox,mmc.txt
>
> diff --git a/doc/device-tree-bindings/mmc/sandbox,mmc.txt
> b/doc/device-tree-bindings/mmc/sandbox,mmc.txt
> new file mode 100644
> index 000..1170bcd6a00
> --- /dev/null
> +++ b/doc/device-tree-bindings/mmc/sandbox,mmc.txt
> @@ -0,0 +1,18 @@
> +Sandbox MMC
> +===
> +
> +Required properties:
> +- compatible : "sandbox,mmc"
> +
> +Optional properties:
> +- filename : Name of backing file, if any. This is mapped into the MMC device
> +so can be used to provide a filesystem or other test data
> +
> +
> +Example
> +---
> +
> +mmc2 {
> + compatible = "sandbox,mmc";
> + non-removable;
> +};
> diff --git a/drivers/mmc/sandbox_mmc.c b/drivers/mmc/sandbox_mmc.c
> index 895fbffecfc..1139951c626 100644
> --- a/drivers/mmc/sandbox_mmc.c
> +++ b/drivers/mmc/sandbox_mmc.c
> @@ -9,23 +9,26 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> struct sandbox_mmc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> + const char *fname;
> };
>
> -#define MMC_CSIZE 0
> -#define MMC_CMULT 8 /* 8 because the card is high-capacity */
> -#define MMC_BL_LEN_SHIFT 10
> -#define MMC_BL_LEN BIT(MMC_BL_LEN_SHIFT)
> -#define MMC_CAPACITY (((MMC_CSIZE + 1) << (MMC_CMULT + 2)) \
> - * MMC_BL_LEN) /* 1 MiB */
> +#define MMC_CMULT8 /* 8 because the card is high-capacity */
> +#define MMC_BL_LEN_SHIFT 10
> +#define MMC_BL_LEN BIT(MMC_BL_LEN_SHIFT)
> +#define SIZE_MULTIPLE((1 << (MMC_CMULT + 2)) * MMC_BL_LEN)
>
> struct sandbox_mmc_priv {
> - u8 buf[MMC_CAPACITY];
> + int csize; /* CSIZE value to report */
> + char *buf;
> + int size;
> };
>
> /**
> @@ -60,8 +63,8 @@ static int sandbox_mmc_send_cmd(struct udevice *dev, struct
> mmc_cmd *cmd,
> case MMC_CMD_SEND_CSD:
> cmd->response[0] = 0;
> cmd->response[1] = (MMC_BL_LEN_SHIFT << 16) |
> -((MMC_CSIZE >> 16) & 0x3f);
> - cmd->response[2] = (MMC_CSIZE & 0x) << 16;
> +((priv->csize >> 16) & 0x3f);
> + cmd->response[2] = (priv->csize & 0x) << 16;
> cmd->response[3] = 0;
> break;
> case SD_CMD_SWITCH_FUNC: {
> @@ -143,6 +146,8 @@ static int sandbox_mmc_of_to_plat(struct udevice *dev)
> struct blk_desc *blk;
> int ret;
>
> + plat->fname = dev_read_string(dev, "filename");
> +
> ret = mmc_of_parse(dev, cfg);
> if (ret)
> return ret;
> @@ -156,6 +161,29 @@ static int sandbox_mmc_of_to_plat(struct udevice *dev)
> static int sandbox_mmc_probe(struct udevice *dev)
> {
> struct sandbox_mmc_plat *plat = dev_get_plat(dev);
> + struct sandbox_mmc_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + if (plat->fname) {
> + ret = os_map_file(plat->fname, OS_O_RDWR | OS_O_CREAT,
> + (void **)>buf, >size);
> + if (ret) {
> + log_err("%s: Unable to map file '%s'\n", dev->name,
> + plat->fname);
> + return ret;
> + }
> + priv->csize = priv->size / SIZE_MULTIPLE - 1;
> + } else {
> + priv->csize = 0;
> + priv->size = (priv->csize + 1) * SIZE_MULTIPLE; /* 1 MiB */
> +
> + priv->buf = malloc(priv->size);
> + if (!priv->buf) {
> + log_err("%s: Not enough memory (%x bytes)\n",
> + dev->name, priv->size);
> + return -ENOMEM;
> + }
> + }
>
> return mmc_init(>mmc);
> }
>
Re: [PATCH 07/13] i2c: S3C24X0: Finish Kconfig migration
On 8/18/21 6:59 AM, Tom Rini wrote: > Finish moving this driver to Kconfig. > - Update the dependency logic for Exynos5 too > - Remove the unused CONFIG_SYS_I2C_S3C24X0_SPEED variable > - Drop CONFIG_SYS_I2C_S3C24X0_SLAVE as it's always set to 0. > - Move the internal SYS_I2C_S3C24X0_SLAVE define closer to the only user. > > Cc: Jaehoon Chung > Signed-off-by: Tom Rini Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > configs/arndale_defconfig| 1 + > configs/odroid-xu3_defconfig | 1 + > configs/peach-pi_defconfig | 1 + > configs/peach-pit_defconfig | 1 + > configs/smdk5250_defconfig | 1 + > configs/smdk5420_defconfig | 1 + > configs/snow_defconfig | 1 + > configs/spring_defconfig | 1 + > drivers/i2c/Kconfig | 2 +- > drivers/i2c/s3c24x0_i2c.c| 8 ++-- > include/configs/exynos5-common.h | 5 - > 11 files changed, 11 insertions(+), 12 deletions(-) > > diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig > index 133c0eb8884e..f475bdefe5f7 100644 > --- a/configs/arndale_defconfig > +++ b/configs/arndale_defconfig > @@ -31,6 +31,7 @@ CONFIG_CMD_EXT4_WRITE=y > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_IS_IN_MMC=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_DW=y > CONFIG_MMC_SDHCI=y > diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig > index f56dfb7d8e2f..150eacdbebe8 100644 > --- a/configs/odroid-xu3_defconfig > +++ b/configs/odroid-xu3_defconfig > @@ -42,6 +42,7 @@ CONFIG_ADC_EXYNOS=y > CONFIG_DFU_MMC=y > CONFIG_SET_DFU_ALT_INFO=y > CONFIG_SYS_DFU_DATA_BUF_SIZE=0x200 > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_DW=y > CONFIG_MTD=y > diff --git a/configs/peach-pi_defconfig b/configs/peach-pi_defconfig > index 92d6be43f817..e8509d8dcbc2 100644 > --- a/configs/peach-pi_defconfig > +++ b/configs/peach-pi_defconfig > @@ -38,6 +38,7 @@ CONFIG_USE_ENV_SPI_BUS=y > CONFIG_ENV_SPI_BUS=1 > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_I2C_CROS_EC_TUNNEL=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_I2C_MUX=y > CONFIG_I2C_ARB_GPIO_CHALLENGE=y > CONFIG_CROS_EC_KEYB=y > diff --git a/configs/peach-pit_defconfig b/configs/peach-pit_defconfig > index 824a664904e8..aaec917c177f 100644 > --- a/configs/peach-pit_defconfig > +++ b/configs/peach-pit_defconfig > @@ -37,6 +37,7 @@ CONFIG_USE_ENV_SPI_BUS=y > CONFIG_ENV_SPI_BUS=1 > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_I2C_CROS_EC_TUNNEL=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_I2C_MUX=y > CONFIG_I2C_ARB_GPIO_CHALLENGE=y > CONFIG_CROS_EC_KEYB=y > diff --git a/configs/smdk5250_defconfig b/configs/smdk5250_defconfig > index 3ed1947fd682..d0a25139ac0f 100644 > --- a/configs/smdk5250_defconfig > +++ b/configs/smdk5250_defconfig > @@ -38,6 +38,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_USE_ENV_SPI_BUS=y > CONFIG_ENV_SPI_BUS=1 > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_DW=y > CONFIG_MMC_SDHCI=y > diff --git a/configs/smdk5420_defconfig b/configs/smdk5420_defconfig > index 7b739400a5bf..e484b234dd0b 100644 > --- a/configs/smdk5420_defconfig > +++ b/configs/smdk5420_defconfig > @@ -33,6 +33,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_USE_ENV_SPI_BUS=y > CONFIG_ENV_SPI_BUS=1 > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_DW=y > CONFIG_MMC_SDHCI=y > diff --git a/configs/snow_defconfig b/configs/snow_defconfig > index a5fbd1d346da..f91cfeda8b9c 100644 > --- a/configs/snow_defconfig > +++ b/configs/snow_defconfig > @@ -43,6 +43,7 @@ CONFIG_USE_ENV_SPI_BUS=y > CONFIG_ENV_SPI_BUS=1 > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_I2C_CROS_EC_LDO=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_I2C_MUX=y > CONFIG_I2C_ARB_GPIO_CHALLENGE=y > CONFIG_CROS_EC_KEYB=y > diff --git a/configs/spring_defconfig b/configs/spring_defconfig > index 53c375e5b4f2..dbebf0ba6191 100644 > --- a/configs/spring_defconfig > +++ b/configs/spring_defconfig > @@ -43,6 +43,7 @@ CONFIG_USE_ENV_SPI_BUS=y > CONFIG_ENV_SPI_BUS=1 > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_I2C_CROS_EC_LDO=y > +CONFIG_SYS_I2C_S3C24X0=y > CONFIG_I2C_MUX=y > CONFIG_I2C_ARB_GPIO_CHALLENGE=y > CONFIG_CROS_EC_KEYB=y > diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig > index 63d03a3cebfc..a50c1f38336d 100644 > --- a/drivers/i2c/Kconfig > +++ b/drivers/i2c/Kconfig > @@ -449,7 +449,7 @@ config SYS_I2C_OCTEON > > config SYS_I2C_S3C24X0 > bool "Samsung I2C driver" > - depends on ARCH_EXYNOS4 && DM_I2C > + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) && DM_I2C > help > Support for Samsung I2C controller as Samsung SoCs. > > diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c > index 56f0f69885e4..e0f499d759f8 100644 > --- a/drivers/i2c/s3c24x0_i2c.c > +++ b/drivers/i2c/s3c24x0_i2c.c > @@ -21,12 +21,6 @@ > #include > #include "s3c24x0_i2c.h" > >
Re: [PATCH 2/2] drivers: mmc: Add wait_dat0 support for sdhci driver
On 8/18/21 4:46 AM, stcar...@linux.microsoft.com wrote:
> From: Stephen Carlson
>
> Adds an implementation of the wait_dat0 MMC operation for the DM SDHCI
> driver, allowing the driver to continue when the card is ready rather
> than waiting for the worst case time on each MMC switch operation.
>
> Signed-off-by: Stephen Carlson
> ---
> drivers/mmc/sdhci.c | 20
> include/sdhci.h | 2 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index eea4701d8a..bb55e00ef5 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -775,6 +775,25 @@ static int sdhci_get_cd(struct udevice *dev)
> return value;
> }
>
> +static int sdhci_wait_dat0(struct udevice *dev, int state,
> +int timeout_us)
> +{
> + int tmp;
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
> + struct sdhci_host *host = mmc->priv;
> + unsigned long timeout = timer_get_us() + timeout_us;
> +
> + // readx_poll_timeout is unsuitable because sdhci_readl accepts
> + // two arguments
Removed the comment or use "/* */" instead of "//"
And i didn't understand what's unsuitable?
Best Regards,
Jaehoon Chung
> + do {
> + tmp = sdhci_readl(host, SDHCI_PRESENT_STATE);
> + if (!!(tmp & SDHCI_DATA_0_LVL_MASK) == !!state)
> + return 0;
> + } while (!timeout_us || !time_after(timer_get_us(), timeout));
> +
> + return -ETIMEDOUT;
> +}
> +
> const struct dm_mmc_ops sdhci_ops = {
> .send_cmd = sdhci_send_command,
> .set_ios= sdhci_set_ios,
> @@ -783,6 +802,7 @@ const struct dm_mmc_ops sdhci_ops = {
> #ifdef MMC_SUPPORTS_TUNING
> .execute_tuning = sdhci_execute_tuning,
> #endif
> + .wait_dat0 = sdhci_wait_dat0,
> };
> #else
> static const struct mmc_ops sdhci_ops = {
> diff --git a/include/sdhci.h b/include/sdhci.h
> index 0ae9471ad7..dd4eb41442 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -65,6 +65,8 @@
> #define SDHCI_CARD_STATE_STABLE BIT(17)
> #define SDHCI_CARD_DETECT_PIN_LEVEL BIT(18)
> #define SDHCI_WRITE_PROTECT BIT(19)
> +#define SDHCI_DATA_LVL_MASK 0x00F0
> +#define SDHCI_DATA_0_LVL_MASK BIT(20)
>
> #define SDHCI_HOST_CONTROL 0x28
> #define SDHCI_CTRL_LED BIT(0)
>
Re: [PATCH 1/2] drivers: mmc: Add wait_dat0 support for Freescale eSDHC driver
On 8/18/21 4:46 AM, stcar...@linux.microsoft.com wrote:
> From: Stephen Carlson
>
> Adds an implementation of the wait_dat0 MMC operation for the Freescale
> eSHDC driver, allowing the driver to continue when the card is ready
> rather than waiting for the worst case time on each MMC switch operation.
>
> Signed-off-by: Stephen Carlson
> ---
> drivers/mmc/fsl_esdhc.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 1d98fa65c4..f74289a677 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -1145,6 +1146,20 @@ int fsl_esdhc_hs400_prepare_ddr(struct udevice *dev)
> return 0;
> }
>
> +static int fsl_esdhc_wait_dat0(struct udevice *dev, int state,
> +int timeout_us)
> +{
> + int ret;
nitpick, doesn't need to use the ret variable.
> + u32 tmp;
> + struct fsl_esdhc_priv *priv = dev_get_priv(dev);
> + struct fsl_esdhc *regs = priv->esdhc_regs;
> +
> + ret = readx_poll_timeout(esdhc_read32, >prsstat, tmp,
> + !!(tmp & PRSSTAT_DAT0) == !!state,
> + timeout_us);
> + return ret;
return readx_poll_timeout(); ?
Other things look good to me.
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> +}
> +
> static const struct dm_mmc_ops fsl_esdhc_ops = {
> .get_cd = fsl_esdhc_get_cd,
> .send_cmd = fsl_esdhc_send_cmd,
> @@ -1154,6 +1169,7 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
> #endif
> .reinit = fsl_esdhc_reinit,
> .hs400_prepare_ddr = fsl_esdhc_hs400_prepare_ddr,
> + .wait_dat0 = fsl_esdhc_wait_dat0,
> };
>
> static const struct udevice_id fsl_esdhc_ids[] = {
>
Re: [PATCH 2/2] mmc: fix device_remove when HS400_ES is enabled
On 8/17/21 6:20 PM, Ye Li wrote:
> HS400_ES is missed when down grade to HS mode during
> device_remove the mmc device
>
> Signed-off-by: Ye Li
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mmc.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a1fd533..3cb6fda 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2092,14 +2092,16 @@ static int mmc_select_mode_and_width(struct mmc *mmc,
> uint card_caps)
> }
>
> #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
> +CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) || \
> +CONFIG_IS_ENABLED(MMC_HS400_ES_SUPPORT)
> /*
>* In case the eMMC is in HS200/HS400 mode, downgrade to HS mode
>* before doing anything else, since a transition from either of
>* the HS200/HS400 mode directly to legacy mode is not supported.
>*/
> if (mmc->selected_mode == MMC_HS_200 ||
> - mmc->selected_mode == MMC_HS_400)
> + mmc->selected_mode == MMC_HS_400 ||
> + mmc->selected_mode == MMC_HS_400_ES)
> mmc_set_card_speed(mmc, MMC_HS, true);
> else
> #endif
> @@ -2952,7 +2954,7 @@ int mmc_deinit(struct mmc *mmc)
> return sd_select_mode_and_width(mmc, caps_filtered);
> } else {
> caps_filtered = mmc->card_caps &
> - ~(MMC_CAP(MMC_HS_200) | MMC_CAP(MMC_HS_400));
> + ~(MMC_CAP(MMC_HS_200) | MMC_CAP(MMC_HS_400) |
> MMC_CAP(MMC_HS_400_ES));
>
> return mmc_select_mode_and_width(mmc, caps_filtered);
> }
>
Re: [PATCH 1/2] mmc: fix switch issue with send_status disabled
On 8/17/21 6:20 PM, Ye Li wrote:
> When send_status is false or wait_dat0 is not supported, the switch
> function should not send CMD13 but directly return.
>
> Signed-off-by: Ye Li
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 8078a89..a1fd533 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -823,7 +823,7 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8
> index, u8 value,
>* capable of polling by using mmc_wait_dat0, then rely on waiting the
>* stated timeout to be sufficient.
>*/
> - if (ret == -ENOSYS && !send_status) {
> + if (ret == -ENOSYS || !send_status) {
> mdelay(timeout_ms);
> return 0;
> }
>
Re: [PATCH v4 1/2] mmc: Add support for enumerating MMC card in a given mode using mmc command
Hi Aswath,
On 8/14/21 2:34 AM, Aswath Govindraju wrote:
> Add support for enumerating MMC card in a given mode using mmc rescan and
> mmc dev commands. The speed mode is provided as the last argument in these
> commands and is indicated using the index from enum bus_mode in
> include/mmc.h. A speed mode can be set only if it has already been enabled
> in the device tree.
Sorry for replying too late. I have tested with your patch.
It's confused the usage.
>
> Signed-off-by: Aswath Govindraju
> ---
> cmd/Kconfig | 10
> cmd/mmc.c| 52 +---
> drivers/mmc/mmc-uclass.c | 5 +++-
> drivers/mmc/mmc.c| 22 -
> include/mmc.h| 2 ++
> 5 files changed, 81 insertions(+), 10 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index ffef3cc76ca4..3a857b3f6e2e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
> help
> UBIFS is a file system for flash devices which works on top of UBI.
>
> +config MMC_SPEED_MODE_SET
> + bool "set speed mode using mmc command"
> + depends on CMD_MMC
> + default n
> + help
> + Enable setting speed mode using mmc rescan and mmc dev commands.
> + The speed mode is provided as the last argument in these commands
> + and is indicated using the index from enum bus_mode in
> + include/mmc.h. A speed mode can be set only if it has already
> + been enabled in the device tree.
> endmenu
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index c67ad7624227..f1e30d0cf64b 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
> }
> }
> }
> -static struct mmc *init_mmc_device(int dev, bool force_init)
> +
> +static struct mmc *__init_mmc_device(int dev, bool force_init,
> + enum bus_mode speed_mode)
> {
> struct mmc *mmc;
> mmc = find_mmc_device(dev);
> @@ -134,6 +136,10 @@ static struct mmc *init_mmc_device(int dev, bool
> force_init)
>
> if (force_init)
> mmc->has_init = 0;
> +
> + if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET))
> + mmc->user_speed_mode = speed_mode;
> +
> if (mmc_init(mmc))
> return NULL;
>
> @@ -145,6 +151,11 @@ static struct mmc *init_mmc_device(int dev, bool
> force_init)
> return mmc;
> }
>
> +static struct mmc *init_mmc_device(int dev, bool force_init)
> +{
> + return __init_mmc_device(dev, force_init, MMC_MODES_END);
> +}
> +
> static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, int argc,
> char *const argv[])
> {
> @@ -482,8 +493,17 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int flag,
>int argc, char *const argv[])
> {
> struct mmc *mmc;
> + enum bus_mode speed_mode = MMC_MODES_END;
> +
> + if (argc == 1) {
> + mmc = init_mmc_device(curr_device, true);
> + } else if (argc == 2) {
> + speed_mode = (int)dectoul(argv[1], NULL);
> + mmc = __init_mmc_device(curr_device, true, speed_mode);
> + } else {
> + return CMD_RET_USAGE;
> + }
>
> - mmc = init_mmc_device(curr_device, true);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -515,11 +535,14 @@ static int do_mmc_dev(struct cmd_tbl *cmdtp, int flag,
> {
> int dev, part = 0, ret;
> struct mmc *mmc;
> + enum bus_mode speed_mode = MMC_MODES_END;
>
> if (argc == 1) {
> dev = curr_device;
> + mmc = init_mmc_device(dev, true);
> } else if (argc == 2) {
> - dev = dectoul(argv[1], NULL);
> + dev = (int)dectoul(argv[1], NULL);
> + mmc = init_mmc_device(dev, true);
> } else if (argc == 3) {
> dev = (int)dectoul(argv[1], NULL);
> part = (int)dectoul(argv[2], NULL);
> @@ -528,11 +551,21 @@ static int do_mmc_dev(struct cmd_tbl *cmdtp, int flag,
> PART_ACCESS_MASK);
> return CMD_RET_FAILURE;
> }
> + mmc = init_mmc_device(dev, true);
> + } else if (argc == 4) {
> + dev = (int)dectoul(argv[1], NULL);
> + part = (int)dectoul(argv[2], NULL);
> + if (part > PART_ACCESS_MASK) {
> + printf("#part_num shouldn't be larger than %d\n",
> +PART_ACCESS_MASK);
> + return CMD_RET_FAILURE;
> + }
> + speed_mode = (int)dectoul(argv[3], NULL);
> + mmc = __init_mmc_device(dev, true, speed_mode);
> } else {
> return CMD_RET_USAGE;
> }
>
> - mmc = init_mmc_device(dev, true);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -983,9 +1016,9 @@ static struct cmd_tbl cmd_mmc[] = {
> #if CONFIG_IS_ENABLED(CMD_MMC_SWRITE)
>
Re: [PATCH] doc: Add documentation about devicetree usage
On 8/27/21 11:23 PM, Simon Glass wrote: At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass --- doc/develop/index.rst | 1 + doc/develop/package/devicetree.rst | 315 + doc/develop/package/index.rst | 1 + 3 files changed, 317 insertions(+) create mode 100644 doc/develop/package/devicetree.rst diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 83c929babda..d5ad8f9fe53 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -36,6 +36,7 @@ Packaging :maxdepth: 1 package/index + package/devicetree Testing --- diff --git a/doc/develop/package/devicetree.rst b/doc/develop/package/devicetree.rst new file mode 100644 index 000..fccbb182f3e --- /dev/null +++ b/doc/develop/package/devicetree.rst @@ -0,0 +1,315 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +=== + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. It is possible to update the +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. nit: projects + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (August 2021) +~~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has +unfortunately created an enormous amount of confusion and some wasted effort. +This was not intended and this bug will be fixed soon. Specifically: + +- `CONFIG_OF_BOARD` was added in rpi_patch_ for Raspberry Pi, which does have + an in-tree devicetree, but this feature has since been used for boards that + don't +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_patch_ as part of a larger Broadcom + change with a tag indicating it only affected one board, so the change in + behaviour was not noticed at the time. It has since been used by RISC-V qemu + boards. + +Once this bug is fixed, CONFIG_OF_BOARD and CONFIG_OF_PRIOR_STAGE will override +(at runtime) the devicetree suppled with U-Boot, but will otherwise use +CONFIG_OF_SEPARATE for the in-tree build. So these two will become options, +moving out of the 'choice' in `dts/Kconfig` + +Offending boards are: + +- bcm7260 +- bcm7445 +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode + +All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release. + + +Building the devicetree +--- + +U-Boot automatically builds the devicetree for a board, from the +`arch//dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here. + + +Overriding the default devicetree +- + +When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement. + + +Modifying the devicetree after building +--- + +While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useul to do so, e.g. to add nit: useful +configuration information like serial numbers, enabling/disabling features, etc. + +Devicetree provides a very nice solution
Re: [PATCH] doc: Add documentation about devicetree usage
+Ilias Apalodimas On Fri, 27 Aug 2021 at 21:23, Simon Glass wrote: > > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. > > Signed-off-by: Simon Glass > --- > > doc/develop/index.rst | 1 + > doc/develop/package/devicetree.rst | 315 + > doc/develop/package/index.rst | 1 + > 3 files changed, 317 insertions(+) > create mode 100644 doc/develop/package/devicetree.rst > > diff --git a/doc/develop/index.rst b/doc/develop/index.rst > index 83c929babda..d5ad8f9fe53 100644 > --- a/doc/develop/index.rst > +++ b/doc/develop/index.rst > @@ -36,6 +36,7 @@ Packaging > :maxdepth: 1 > > package/index > + package/devicetree > > Testing > --- > diff --git a/doc/develop/package/devicetree.rst > b/doc/develop/package/devicetree.rst > new file mode 100644 > index 000..fccbb182f3e > --- /dev/null > +++ b/doc/develop/package/devicetree.rst > @@ -0,0 +1,315 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Updating the devicetree > +=== > + > +U-Boot uses devicetree for runtime configuration and storing required blobs > or > +any other information it needs to operate. It is possible to update the > +devicetree separately from actually building U-Boot. This provides a good > degree > +of control and flexibility for firmware that uses U-Boot in conjunction with > +other project. > + > +There are many reasons why it is useful to modify the devicetree after > building > +it: > + > +- Configuration can be changed, e.g. which UART to use > +- A serial number can be added > +- Public keys can be added to allow image verification > +- Console output can be changed (e.g. to select serial or vidconsole) > + > +This section describes how to work with devicetree to accomplish your goals. > + > +See also :doc:`../devicetree/control` for a basic summary of the available > +features. > + > + > +Devicetree source > +- > + > +Every board in U-Boot must include a devicetree sufficient to build and boot > +that board on suitable hardware (or emulation). This is specified using the > +`CONFIG DEFAULT_DEVICE_TREE` option. > + > + > +Current situation (August 2021) > +~~~ > + > +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be > empty, > +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has > +unfortunately created an enormous amount of confusion and some wasted effort. > +This was not intended and this bug will be fixed soon. Specifically: > + > +- `CONFIG_OF_BOARD` was added in rpi_patch_ for Raspberry Pi, which does have > + an in-tree devicetree, but this feature has since been used for boards that > + don't > +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_patch_ as part of a larger > Broadcom > + change with a tag indicating it only affected one board, so the change in > + behaviour was not noticed at the time. It has since been used by RISC-V > qemu > + boards. > + > +Once this bug is fixed, CONFIG_OF_BOARD and CONFIG_OF_PRIOR_STAGE will > override > +(at runtime) the devicetree suppled with U-Boot, but will otherwise use > +CONFIG_OF_SEPARATE for the in-tree build. So these two will become options, > +moving out of the 'choice' in `dts/Kconfig` > + > +Offending boards are: > + > +- bcm7260 > +- bcm7445 > +- qemu_arm64 > +- qemu_arm > +- qemu-ppce500 > +- qemu-riscv32 > +- qemu-riscv32_smode > +- qemu-riscv64 > +- qemu-riscv64_smode > + > +All of these need to have a devicetree added in-tree. This is targeted to be > +fixed in the 2022.01 release. > + > + > +Building the devicetree > +--- > + > +U-Boot automatically builds the devicetree for a board, from the > +`arch//dts` directory. The Makefile in those directories has rules for > +building devicetree files. It is preferable to avoid target-specific rules in > +those files: i.e. all boards for a particular SoC should be built at once, > +where practical. Apart from simplifying the Makefile, this helps to > efficiently > +(and immediately) ensure that changes in one board's DT do not break others > that > +are related. Building devicetrees is fast, so performance is seldom a concern > +here. > + > + > +Overriding the default devicetree > +- > + > +When building U-Boot, the `DEVICE_TREE` environment variable allows the > +default devicetree file to be overridden at build time. This can be useful if > +modifications have to be made to the in-tree devicetree file, for the benefit > +of a downstream build system. Note that the in-tree devicetree must be > +sufficient to build and boot, so this is not a way to bypass that > requirement. > + > + > +Modifying the devicetree after building > +--- > + > +While it is
Re: Usage of device-tree for blobs
Hi Heinrich, On Wed, 25 Aug 2021 at 02:05, Heinrich Schuchardt wrote: > > Hello Simon, > > some boards like qemu-riscv64_defconfig do not use any device-tree at > build time. A device-tree is only supplied at runtime by the prior boot > stage (CONFIG_OF_PRIOR_STAGE=y). > > In doc/develop/devicetree/intro.rst you suggest to put binary blobs into > the device-tree. > > Could you, please, update the documentation to explain how adding blobs > to the device-tree works in the different scenarios depending on the > values of: > > CONFIG_OF_EMBED > CONFIG_OF_SEPARATE > CONFIG_OF_BOARD > CONFIG_OF_HOSTFILE > CONFIG_OF_PRIOR_STAGE > > It would be especially important to understand how one can develop a > board independent feature which works for all of these settings. > > Please, describe CONFIG_OF_PRIOR_STAGE in > doc/develop/devicetree/control.rst. Back to this original request, I've taken a crack at this and sent out a patch. Regards, SImon
[PATCH] doc: Add documentation about devicetree usage
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass --- doc/develop/index.rst | 1 + doc/develop/package/devicetree.rst | 315 + doc/develop/package/index.rst | 1 + 3 files changed, 317 insertions(+) create mode 100644 doc/develop/package/devicetree.rst diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 83c929babda..d5ad8f9fe53 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -36,6 +36,7 @@ Packaging :maxdepth: 1 package/index + package/devicetree Testing --- diff --git a/doc/develop/package/devicetree.rst b/doc/develop/package/devicetree.rst new file mode 100644 index 000..fccbb182f3e --- /dev/null +++ b/doc/develop/package/devicetree.rst @@ -0,0 +1,315 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +=== + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. It is possible to update the +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (August 2021) +~~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has +unfortunately created an enormous amount of confusion and some wasted effort. +This was not intended and this bug will be fixed soon. Specifically: + +- `CONFIG_OF_BOARD` was added in rpi_patch_ for Raspberry Pi, which does have + an in-tree devicetree, but this feature has since been used for boards that + don't +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_patch_ as part of a larger Broadcom + change with a tag indicating it only affected one board, so the change in + behaviour was not noticed at the time. It has since been used by RISC-V qemu + boards. + +Once this bug is fixed, CONFIG_OF_BOARD and CONFIG_OF_PRIOR_STAGE will override +(at runtime) the devicetree suppled with U-Boot, but will otherwise use +CONFIG_OF_SEPARATE for the in-tree build. So these two will become options, +moving out of the 'choice' in `dts/Kconfig` + +Offending boards are: + +- bcm7260 +- bcm7445 +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode + +All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release. + + +Building the devicetree +--- + +U-Boot automatically builds the devicetree for a board, from the +`arch//dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here. + + +Overriding the default devicetree +- + +When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement. + + +Modifying the devicetree after building +--- + +While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useul to do so, e.g. to add +configuration information like serial numbers, enabling/disabling features, etc. + +Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it,
Re: [PATCH u-boot-marvell 00/29] kwboot higher baudrate
On Sat, 28 Aug 2021, 12:31 AM Marek Behún, wrote: > On Fri, 27 Aug 2021 14:45:07 +1200 > Chris Packham wrote: > > > The higher speed settings weren't so good. I started with 3125000 and > > that doesn't get onto the 2nd part of the download, same for 1152000 > > and 400 (I stopped trying higher speeds at that point). Using > > 230400 and 460800 it does make it through the 2nd part of the download > > but when I go back on to the console it appears to be unresponsive. > > Did you try v2 or v1? If you tried v1 with old kwb images (created > before the previous kwbimage patch series), this is expected. v2 fixes > this issue. > I pulled the from the repo/branch you posted and built fresh images. >
[PATCH 2/2] armv8/cache.S: Triple with single instruction
Replace the current 2-instruction 2-step tripling code by a corresponding single instruction leveraging ARMv8-A's "flexible second operand as a register with optional shift". This has the added benefit (albeit arguably negligible) of reducing the final code size. Fix the comment as the tripled cache level is placed in x12, not x0. Signed-off-by: Pierre-Clément Tosi --- arch/arm/cpu/armv8/cache.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S index aabb3dff61..5051597f6f 100644 --- a/arch/arm/cpu/armv8/cache.S +++ b/arch/arm/cpu/armv8/cache.S @@ -80,8 +80,7 @@ ENTRY(__asm_dcache_all) /* x15 <- return address */ loop_level: - lsl x12, x0, #1 - add x12, x12, x0/* x0 <- tripled cache level */ + add x12, x0, x0, lsl #1 /* x12 <- tripled cache level */ lsr x12, x10, x12 and x12, x12, #7/* x12 <- cache type */ cmp x12, #2 -- 2.33.0.259.gc128427fd7-goog -- Pierre
[PATCH 1/2] armv8/cache.S: Read sysreg fields through ubfx
Improve the file's readability and conciseness by using the appropriate Aarch64 instruction: ubfx (unsigned bitfield extract). This makes the code easier to follow as it directly manipulates the offsets and widths of the fields read from system registers, as they are expressed in the Standard (ARM ARM). This has the added benefit (albeit arguably negligible) of reducing the final code size. Signed-off-by: Pierre-Clément Tosi --- arch/arm/cpu/armv8/cache.S | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S index 443d94c262..aabb3dff61 100644 --- a/arch/arm/cpu/armv8/cache.S +++ b/arch/arm/cpu/armv8/cache.S @@ -27,13 +27,11 @@ ENTRY(__asm_dcache_level) msr csselr_el1, x12 /* select cache level */ isb /* sync change of cssidr_el1 */ mrs x6, ccsidr_el1 /* read the new cssidr_el1 */ - and x2, x6, #7 /* x2 <- log2(cache line size)-4 */ + ubfxx2, x6, #0, #3/* x2 <- log2(cache line size)-4 */ + ubfxx3, x6, #3, #10/* x3 <- number of cache ways - 1 */ + ubfxx4, x6, #13, #15/* x4 <- number of cache sets - 1 */ add x2, x2, #4 /* x2 <- log2(cache line size) */ - mov x3, #0x3ff - and x3, x3, x6, lsr #3 /* x3 <- max number of #ways */ clz w5, w3 /* bit position of #ways */ - mov x4, #0x7fff - and x4, x4, x6, lsr #13 /* x4 <- max number of #sets */ /* x12 <- cache level << 1 */ /* x2 <- line length offset */ /* x3 <- number of cache ways - 1 */ @@ -72,8 +70,7 @@ ENTRY(__asm_dcache_all) mov x1, x0 dsb sy mrs x10, clidr_el1 /* read clidr_el1 */ - lsr x11, x10, #24 - and x11, x11, #0x7 /* x11 <- loc */ + ubfxx11, x10, #24, #3 /* x11 <- loc */ cbz x11, finished /* if loc is 0, exit */ mov x15, lr mov x0, #0 /* start flush at cache level 0 */ @@ -131,8 +128,7 @@ ENDPROC(__asm_invalidate_dcache_all) .pushsection .text.__asm_flush_dcache_range, "ax" ENTRY(__asm_flush_dcache_range) mrs x3, ctr_el0 - lsr x3, x3, #16 - and x3, x3, #0xf + ubfxx3, x3, #16, #4 mov x2, #4 lsl x2, x2, x3 /* cache line size */ @@ -158,7 +154,7 @@ ENDPROC(__asm_flush_dcache_range) .pushsection .text.__asm_invalidate_dcache_range, "ax" ENTRY(__asm_invalidate_dcache_range) mrs x3, ctr_el0 - ubfmx3, x3, #16, #19 + ubfxx3, x3, #16, #4 mov x2, #4 lsl x2, x2, x3 /* cache line size */ -- 2.33.0.259.gc128427fd7-goog -- Pierre
Re: imx8mm memory env in U-Boot
On Thu, Aug 26, 2021 at 12:41 PM Tom Rini wrote:
>
> On Thu, Aug 26, 2021 at 09:39:20AM -0700, Tim Harvey wrote:
>
> > Greetings,
> >
> > I'm trying to understand what the best memory usage is in U-Boot for
> > IMX8M boards for generic distro configs such as: loadaddr,
> > kernel_addr_r, fdt_addr_r, ramdisk_addr, scriptaddr.
> >
> > My understanding is that the following is a good rule of thumb:
> > loadaddr = DDR start + 32MB (as FIT images may load kernel at DDR
> > start; but this only allows for a 32MB kernel)
> > kernel_addr_r = $loadaddr
> > fdt_addr_r = $kernel_addr_r + 128MB (allows you up to 128MB for your
> > kernel; handy if you want a kernel with internal ramdisk)
> > ramdisk_addr = fdt_addr_r + 512KB (512KB should be plenty for a dt)
> > scriptaddr = $loadaddr
>
Hi Tom,
Thanks for the reply.
> Missing from the list here is bootm_size, so that we make sure
> everything that does need relocation is relocated within a specific size
> range.
I still don't quite understand bootm_size, you say it sets the limit
to where things are relocated to. Shouldn't this just be the size of
dram then? A few IMX8MM boards set this but most do not.
> Where much of this comes from is (or should be) the huge comment
> in ti_armv7_common.h that's based off of the Linux kernel arm "booting"
> document (now converted to rST):
> /*
> * We setup defaults based on constraints from the Linux kernel, which should
> * also be safe elsewhere. We have the default load at 32MB into DDR (for
> * the kernel), FDT above 128MB (the maximum location for the end of the
> * kernel), and the ramdisk 512KB above that (allowing for hopefully never
> * seen large trees). We say all of this must be within the first 256MB
> * as that will normally be within the kernel lowmem and thus visible via
> * bootm_size and we only run on platforms with 256MB or more of memory.
> *
> * As a temporary storage for DTBO blobs (which should be applied into DTB
> * blob), we use the location 15.5 MB above the ramdisk. If someone wants to
> * use ramdisk bigger than 15.5 MB, then DTBO can be loaded and applied to DTB
> * blob before loading the ramdisk, as DTBO location is only used as a
> temporary
> * storage, and can be re-used after 'fdt apply' command is done.
> */
Right, that's where I got my recommendations and I don't understand
the reasoning behind the default loadaddr be 32MB into DDR.
>
> At this point, re-reading and referencing both:
> https://www.kernel.org/doc/Documentation/arm64/booting.rst
> https://www.kernel.org/doc/Documentation/arm/Booting
> would be good, and note that there's not currently a similar document
> for RISC-V, they often follow the same guidelines. And I know you're
> talking about imx8 specifically right now but due to the copy/paste
> nature of these kinds of values, I like to err on the side of maximal
> safety. Which means that we should bump the DTB size to 2MB, per arm64.
ok, good to know 2MB should be allotted for dtb.
>
> It also doesn't cover kernel_comp_addr_r / kernel_comp_size for
> automatic decompression of Image files, but should.
>
interesting... I didn't even realize booti supported compressed images!
I see now commit 414c34ed55: ("image: Add compressed Image parsing
support in booti."). I'm not clear why the uncompressed kernel needs
to be moved to kernel_addr_r after decompression... why can't it
simply be decompressed directly to kernel_addr_r?
I would think kernel_comp_size would typically be set to filesize as
currently that is set by tftp as well as fs load commands.
> Note that I believe (but would have to think on and re-read a bunch of
> stuff to be sure), it's not that saying the kernel address is at 32MB
> from the start of memory limits us to 32MB, but that it makes life
> easier all around.
>
> > Looking at the various imx8mm boards upstream they are kind of all
> > over the place but do follow some patterns likely due to some of us
> > just going with what prior boards used.
> >
> > While I'm at it I've encountered a couple other questions:
> > - why on IMX8MM is CONFIG_LOADADDR is 0x4048 when DDR starts at
> > 0x4000. Why the 4608KB offset?
any idea why IMX8MM boards are using DDR+4608KB for loadaddr vs just
DDR? I am hoping some of the IMX8MM board maintainers I've cc'd here
can answer that.
> > - what is CONFIG_SYS_INIT_RAM_SIZE? Most boards are setting this to
> > 2MB but a couple (cl-iot-gate/phycore) set it to 512KB
>
> I feel like it's pretty likely CONFIG_SYS_INIT_RAM_SIZE has been
> copy-pasted around as part of setting CONFIG_SYS_INIT_SP_OFFSET which is
> unused. A lot of unused (outside of m68k / PowerPC generally) options
> in that area.
>
> > - what are people using for the load address for the kernel within FIT
> > images? I expect start of DDR is appropriate (0x4000) however for
> > whatever reason I've been using 0x4020. This plays into the env as
> > you can't overlap where you loaded the FIT image with where you told
> >
[PATCH 2/2] arm: rmobile: Remove duplicate code from beacon-rzg2m and hihope-rzg2
With reset_cpu() now existing in common code, there is no need to
have this exist in each board.
Signed-off-by: Adam Ford
diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
index c12ff77fb2..f5146594b5 100644
--- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
+++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
@@ -27,12 +27,3 @@ int board_init(void)
return 0;
}
-
-#define RST_BASE 0xE616
-#define RST_CA57RESCNT (RST_BASE + 0x40)
-#define RST_CODE 0xA5A5000F
-
-void reset_cpu(void)
-{
- writel(RST_CODE, RST_CA57RESCNT);
-}
diff --git a/board/hoperun/hihope-rzg2/hihope-rzg2.c
b/board/hoperun/hihope-rzg2/hihope-rzg2.c
index c1db387b27..59e124c829 100644
--- a/board/hoperun/hihope-rzg2/hihope-rzg2.c
+++ b/board/hoperun/hihope-rzg2/hihope-rzg2.c
@@ -16,12 +16,6 @@
#include
#include
-#define RST_BASE 0xE616
-#define RST_CA57RESCNT (RST_BASE + 0x40)
-#define RST_CA53RESCNT (RST_BASE + 0x44)
-#define RST_CA57_CODE 0xA5A5000F
-#define RST_CA53_CODE 0x5A5A000F
-
DECLARE_GLOBAL_DATA_PTR;
#define HSUSB_MSTP704 BIT(4) /* HSUSB */
@@ -65,19 +59,6 @@ int board_init(void)
return 0;
}
-void reset_cpu(void)
-{
- unsigned long midr, cputype;
-
- asm volatile("mrs %0, midr_el1" : "=r" (midr));
- cputype = (midr >> 4) & 0xfff;
-
- if (cputype == 0xd03)
- writel(RST_CA53_CODE, RST_CA53RESCNT);
- else
- writel(RST_CA57_CODE, RST_CA57RESCNT);
-}
-
#if defined(CONFIG_MULTI_DTB_FIT)
/* If the firmware passed a device tree, use it for board identification. */
extern u64 rcar_atf_boot_args[];
--
2.25.1
[PATCH 1/2] arm: mach-rmobile: Move cpu_reset to rzg2-reset.c
Various RZ/G2[MNH] boards have copies of cpu_reset which
creates duplicate code, so move this to a common file shared
among all users of the RZG2 and declare it weak so it can be
overwritten if necessary.
Signed-off-by: Adam Ford
diff --git a/arch/arm/mach-rmobile/Makefile b/arch/arm/mach-rmobile/Makefile
index 195bbeb5c8..2bd173ec3a 100644
--- a/arch/arm/mach-rmobile/Makefile
+++ b/arch/arm/mach-rmobile/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_SH73A0) += lowlevel_init.o cpu_info-sh73a0.o
pfc-sh73a0.o
obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o
obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
obj-$(CONFIG_RCAR_GEN3) += lowlevel_init_gen3.o cpu_info-rcar.o memmap-gen3.o
-obj-$(CONFIG_RZ_G2) += cpu_info-rzg.o
+obj-$(CONFIG_RZ_G2) += cpu_info-rzg.o rzg2-reset.o
ifneq ($(CONFIG_R8A779A0),)
obj-$(CONFIG_ARMV8_PSCI) += psci-r8a779a0.o
diff --git a/arch/arm/mach-rmobile/rzg2-reset.c
b/arch/arm/mach-rmobile/rzg2-reset.c
new file mode 100644
index 00..8c3608f34a
--- /dev/null
+++ b/arch/arm/mach-rmobile/rzg2-reset.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Renesas Electronics Corporation
+ */
+
+#include
+
+#define RST_BASE 0xE616
+#define RST_CA57RESCNT (RST_BASE + 0x40)
+#define RST_CA53RESCNT (RST_BASE + 0x44)
+#define RST_CA57_CODE 0xA5A5000F
+#define RST_CA53_CODE 0x5A5A000F
+
+__weak void reset_cpu(void)
+{
+ unsigned long midr, cputype;
+
+ asm volatile("mrs %0, midr_el1" : "=r" (midr));
+ cputype = (midr >> 4) & 0xfff;
+
+ if (cputype == 0xd03)
+ writel(RST_CA53_CODE, RST_CA53RESCNT);
+ else
+ writel(RST_CA57_CODE, RST_CA57RESCNT);
+}
+
--
2.25.1
Re: Usage of device-tree for blobs
> From: Simon Glass > Date: Thu, 26 Aug 2021 21:57:19 -0600 > Cc: Heinrich Schuchardt , > Ilias Apalodimas , > U-Boot Mailing List > Content-Type: text/plain; charset="UTF-8" > > Hi Mark, > > On Thu, 26 Aug 2021 at 14:18, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 26 Aug 2021 13:54:49 -0600 > > > > > > Hi Heinrich, > > > > > > > > > On Thu, 26 Aug 2021 at 01:10, Heinrich Schuchardt > > > wrote: > > > > > > > > On 8/26/21 5:15 AM, Simon Glass wrote: > > > > > Hi Heinrich, > > > > > > > > > > On Wed, 25 Aug 2021 at 02:05, Heinrich Schuchardt > > > > > wrote: > > > > >> > > > > >> Hello Simon, > > > > >> > > > > >> some boards like qemu-riscv64_defconfig do not use any device-tree at > > > > >> build time. A device-tree is only supplied at runtime by the prior > > > > >> boot > > > > >> stage (CONFIG_OF_PRIOR_STAGE=y). > > > > >> > > > > >> In doc/develop/devicetree/intro.rst you suggest to put binary blobs > > > > >> into > > > > >> the device-tree. > > > > >> > > > > >> Could you, please, update the documentation to explain how adding > > > > >> blobs > > > > >> to the device-tree works in the different scenarios depending on the > > > > >> values of: > > > > >> > > > > >> CONFIG_OF_EMBED > > > > >> CONFIG_OF_SEPARATE > > > > >> CONFIG_OF_BOARD > > > > >> CONFIG_OF_HOSTFILE > > > > >> CONFIG_OF_PRIOR_STAGE > > > > >> > > > > >> It would be especially important to understand how one can develop a > > > > >> board independent feature which works for all of these settings. > > > > > > > > > > OK I will take a crack at this tomorrow. > > > > > > > > > > But I think there is a disconnect here, since the only options that > > > > > matter within U-Boot are OF_SEPARATE and OF_HOSTFILE, which both use a > > > > > u-boot.dtb file. There is nothing tricky here. > > > > > > > > The following boards use OF_PRIO_STAGE: > > > > > > > > * QEMU > > > > * bcm7260_defconfig > > > > * bcm7445_defconfig > > > > * ae350_rv32_defconfig > > > > * ae350_rv32_spl_defconfig > > > > * ae350_rv64_defconfig > > > > * ae350_rv64_spl_defconfig > > > > > > Most of these seem OK as they have an in-tree DT. But the arm and > > > riscv qemus and the bcm builds do not: > > > > > > bcm7260_defconfig > > > bcm7445_defconfig > > > configs/qemu_arm64_defconfig > > > configs/qemu_arm_defconfig > > > configs/qemu-ppce500_defconfig > > > configs/qemu-riscv32_defconfig > > > configs/qemu-riscv32_smode_defconfig > > > configs/qemu-riscv64_defconfig > > > configs/qemu-riscv64_smode_defconfig > > > > > > I think we are going to have to ban this. We are not really testing > > > the build at all, and it presumably depends on the version of qemu > > > that is used. It's OK to provide the DT to U-Boot as one flow, but not > > > to completely drop it from the tree. > > > > So you want to have a DT in the U-Boot tree that is completely unused? > > Why would I want it to be unused? > > It is used by the U-Boot build, at least. To do what? > Does this all work because the qemu support has been in there for ages > and never changes? Otherwise I wonder about version compatibility. Well, DT bindings are supposed to be stable. See the discussion we had earlier this week about the layerscape bindings... So yes, I think the folks involved on both the QEMU and Linux side are committed to backwards compatibility here. > > > Where is the qemu source code that creates these DTs? > > > > For ARM the code is in: > > > > https://github.com/qemu/qemu/blob/master/hw/arm/virt.c > > Gosh that's 3k LOC that I didn't even imagine existed! Thank you for > the pointer. > > I don't see any mention in there about U-Boot. Are you sure that it is > passed to U-Boot, or is it just passed to Linux? If U-Boot uses it, > someone should make a note of that in the file. I don't know why you want to single out U-Boot and Linux. The DT bindings are OS agnostic. They work equally well for OpenBSD and FreeBSD. So why wouldn't they work for U-Boot? > > > > > The OF_BOARD business is for when the board does special things. > > > > > Presumably signing will do special things too. We cannot really know > > > > > what those things are because the board as 'opted out' of the standard > > > > > options. > > > > > > > > > >> > > > > >> Please, describe CONFIG_OF_PRIOR_STAGE in > > > > >> doc/develop/devicetree/control.rst. > > > > > > > > > > So I'm not allowed to delete that option? :-) > > > > > > > > No. > > > > > > > > > It seems to me to be > > > > > extremely sparse on documentation. We need an explanation of what it > > > > > means and what effect it has on the build system, U-Boot and some > > > > > discussion of how qemu works. It seems to have been added as part of > > > > > an unrelated broadcom commit. The tags were incorrect so I doubt > > > > > anyone noticed it. Since then it has apparently proved useful > > > > > elsewhere, but no one has added more docs. > > > > > > > > > > So perhaps you can help me with my doc by
Re: [PATCH] pwm: Add driver for cadence TTC
On 8/27/21 7:55 AM, Michal Simek wrote:
TTC has three modes of operations. Timer, PWM and input counters.
There is already driver for timer under CADENCE_TTC_TIMER which is used for
ZynqMP R5 configuration.
This driver is targeting PWM which is for example configuration which can
be used for fan control.
The driver has been tested on Xilinx Kria SOM platform where fan is
connected to one PL pin. When TTC output is connected via EMIO to PL pin
TTC pwm can be configured and tested for example like this:
pwm config 0 0 1 1200
pwm enable 0 0
pwm config 0 0 1 1400
pwm config 0 0 1 1600
Signed-off-by: Michal Simek
---
MAINTAINERS | 1 +
drivers/pwm/Kconfig | 7 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-cadence-ttc.c | 217 ++
4 files changed, 226 insertions(+)
create mode 100644 drivers/pwm/pwm-cadence-ttc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4cf0c33c5d58..889813382249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -600,6 +600,7 @@ F: drivers/mmc/zynq_sdhci.c
F:drivers/mtd/nand/raw/zynq_nand.c
F:drivers/net/phy/xilinx_phy.c
F:drivers/net/zynq_gem.c
+F: drivers/pwm/pwm-cadence-ttc.c
F:drivers/serial/serial_zynq.c
F:drivers/reset/reset-zynqmp.c
F:drivers/rtc/zynqmp_rtc.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index cf7f4c6840ce..176e703c8fbb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -9,6 +9,13 @@ config DM_PWM
frequency/period can be controlled along with the proportion of that
time that the signal is high.
+config PWM_CADENCE_TTC
+ bool "Enable support for the Cadence TTC PWM"
+ depends on DM_PWM && !CADENCE_TTC_TIMER
+ help
+ Cadence TTC can be configured as timer which is done via
+ CONFIG_CADENCE_TTC_TIMER or as PWM. This is covering only PWM now.
+
config PWM_CROS_EC
bool "Enable support for the Chrome OS EC PWM"
depends on DM_PWM
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 10d244bfb79d..abf5af41d2cc 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -10,6 +10,7 @@
obj-$(CONFIG_DM_PWM) += pwm-uclass.o
+obj-$(CONFIG_PWM_CADENCE_TTC) += pwm-cadence-ttc.o
obj-$(CONFIG_PWM_CROS_EC) += cros_ec_pwm.o
obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o
diff --git a/drivers/pwm/pwm-cadence-ttc.c b/drivers/pwm/pwm-cadence-ttc.c
new file mode 100644
index ..1d007676bb3b
--- /dev/null
+++ b/drivers/pwm/pwm-cadence-ttc.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021 Xilinx, Inc. Michal Simek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TTC_COUNTER_CONTROL_1 0xc
+#define TTC_INTERVAL_COUNTER_1 0x24
+#define TTC_MATCH_1_COUNTER_1 0x30
+
+#define CPWM_CLK_FALLING_EDGE 0x40
BIT(6)
+#define CPWM_CLK_SRC_EXTERNAL 0x20
BIT(5)
+#define CPWM_CLK_PRESCALE_SHIFT1
+#define CPWM_CLK_PRESCALE_MASK (15 << 1)
GENMASK(4, 1)
+#define CPWM_CLK_PRESCALE_ENABLE 1
Why CPWM_? And please use register names which match the datasheet. E.g.
XXX_EX_E instead of XXX_FALLING_EDGE.
+
+#define CPWM_COUNTER_CTRL_WAVE_POL 0x40
+#define CPWM_COUNTER_CTRL_WAVE_DISABLE 0x20
+#define CPWM_COUNTER_CTRL_RESET0x10
+#define CPWM_COUNTER_CTRL_MATCH_ENABLE 0x8
+#define CPWM_COUNTER_CTRL_DECREMENT_ENABLE 0x4
+#define CPWM_COUNTER_CTRL_INTERVAL_ENABLE 0x2
+#define CPWM_COUNTER_CTRL_COUNTING_DISABLE 0x1
ditto
+
+struct cadence_ttc_pwm_priv {
+ uchar *regs;
+ unsigned long frequency;
+ bool invert[2];
+};
+
+static int cadence_ttc_pwm_set_invert(struct udevice *dev, uint channel,
+ bool polarity)
+{
+ struct cadence_ttc_pwm_priv *priv = dev_get_priv(dev);
+
+ if (channel > 2) {
+ dev_err(dev, "Unsupported channel number %d(max 2)\n", channel);
+ return -EINVAL;
+ }
+
+ priv->invert[channel] = polarity;
+
+ dev_dbg(dev, "polarity=%u. Please config PWM again\n", polarity);
+
+ return 0;
+}
+
+static int cadence_ttc_pwm_set_config(struct udevice *dev, uint channel,
+ uint period_ns, uint duty_ns)
+{
+ struct cadence_ttc_pwm_priv *priv = dev_get_priv(dev);
+ u32 counter_ctrl, x;
+ int period_clocks, duty_clocks, prescaler;
+
+ dev_dbg(dev, "channel %d, duty %d/ period %d ns\n", channel,
+ duty_ns, period_ns);
+
+ if (channel > 2) {
+ dev_err(dev, "Unsupported channel number %d(max 2)\n", channel);
+ return -EINVAL;
+ }
+
+ /* Make sure counter is stopped */
Shouldn't this be a write?
Re: [PATCH 2/2] arm: mach-k3: common: Add a release_resources_for_core_shutdown() stub
On 18:24-20210727, Suman Anna wrote:
> Add a weak release_resources_for_core_shutdown() stub implementation
> that can be overridden by actual implementation if a SoC supports that
> function.
>
> Signed-off-by: Suman Anna
> ---
> arch/arm/mach-k3/common.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index bb0f64194f4e..08b7344df749 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -193,6 +193,11 @@ int load_firmware(char *name_fw, char *name_loadaddr,
> u32 *loadaddr)
> }
> #endif
>
> +__weak void release_resources_for_core_shutdown(void)
> +{
> + debug("%s not implemented...\n", __func__);
> +}
> +
> void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
> {
> typedef void __noreturn (*image_entry_noargs_t)(void);
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 1/2] firmware: ti_sci: Include linux/err.h in ti_sci_protocol.h
On 18:24-20210727, Suman Anna wrote:
> The common TI SCI header file uses some macros from err.h and these
> get exercised when CONFIG_TI_SCI_PROTOCOL is not defined. Include
> the linux/err.h header file in this header file directly rather
> than relying on source files to include it to eliminate any
> potential build errors.
>
> While at this, reorder the existing header file include to the
> beginning of the file.
>
> Signed-off-by: Suman Anna
> ---
> include/linux/soc/ti/ti_sci_protocol.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/soc/ti/ti_sci_protocol.h
> b/include/linux/soc/ti/ti_sci_protocol.h
> index 794737923cf1..7f9941894cdf 100644
> --- a/include/linux/soc/ti/ti_sci_protocol.h
> +++ b/include/linux/soc/ti/ti_sci_protocol.h
> @@ -11,6 +11,9 @@
> #ifndef __TISCI_PROTOCOL_H
> #define __TISCI_PROTOCOL_H
>
> +#include
> +#include
> +
> /**
> * struct ti_sci_version_info - version information structure
> * @abi_major: Major ABI version. Change here implies risk of backward
> @@ -20,7 +23,6 @@
> * @firmware_revision: Firmware revision (not usually used).
> * @firmware_description: Firmware description (not usually used).
> */
> -#include
> struct ti_sci_version_info {
> u8 abi_major;
> u8 abi_minor;
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [GIT PULL] xilinx patches for v2021.10-rc3
On Fri, Aug 27, 2021 at 01:00:09PM +0200, Michal Simek wrote: > Hi Tom, > > please pull these patches to your tree. Gitlab CI is not showing any > issue and I have also tested qspi/sd flows on zynq and zynqmp boards. > > There are a lot of fixes and alignments with also some features like > rtc/soc drivers and correcting capsule update. Code for multi_fit is > also added but not enabled by default. > > SPI driver needs to be fixed. Patches have been sent today. I will take > care about them soon. > > Thanks, > Michal > > The following changes since commit ab97eb341cb4fdbd69e33bd4a53714db95b5b63e: > > Merge branch '2021-08-04-assorted-minor-fixes' (2021-08-04 21:18:33 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2021.10-rc3 > > for you to fetch changes up to 229cb5c6ba3469cbc4a0bcc69389fe61c51fd3b4: > > xilinx: zynqmp: Enable stack relocation to DDR (2021-08-26 08:14:43 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Broken CONFIG_SPL_SATA_SUPPORT=y
On Fri, Aug 27, 2021 at 05:17:25PM +0200, Pali Rohár wrote: > On Sunday 15 August 2021 10:23:03 Tom Rini wrote: > > On Sun, Aug 15, 2021 at 01:48:26PM +0200, Pali Rohár wrote: > > > On Monday 02 August 2021 21:40:07 Tom Rini wrote: > > > > OK, thanks. Then the right fix is to introduce whatever SPL_xxx symbols > > > > you need so that you can turn off what you don't want in SPL but leave > > > > it enabled in full U-Boot, and update the code to use > > > > CONFIG_IS_ENABLED(xxx). If you can do that part, I can iterate over > > > > converting everyone else that assumes what we have today is what it > > > > wants in SPL and non-SPL. > > > > > > Hello Tom! Below is patch which adds SPL_AHCI_PCI symbol. I'm not sure > > > if this is correct approach but it looks like that it fixed that issue. > > > With this patch I can compile U-Boot with and also without enabling of > > > CONFIG_SPL_SATA_SUPPORT option. > > > > > > > > > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig > > > index 0c1490a9f900..96c7c30375bd 100644 > > > --- a/drivers/ata/Kconfig > > > +++ b/drivers/ata/Kconfig > > > @@ -41,6 +41,12 @@ config AHCI_PCI > > > help > > > Enables support for the PCI-based AHCI controller. > > > > > > +config SPL_AHCI_PCI > > > + bool "Support for PCI-based AHCI controller for SPL" > > > + depends on SPL > > > + depends on SPL_PCI > > > + depends on SPL_SATA_SUPPORT && DM_SCSI > > > + > > > config SATA_CEVA > > > bool "Ceva Sata controller" > > > depends on AHCI > > > diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile > > > index 4811b2f82c4e..cd88131dcd13 100644 > > > --- a/drivers/ata/Makefile > > > +++ b/drivers/ata/Makefile > > > @@ -5,7 +5,7 @@ > > > > > > obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o > > > obj-$(CONFIG_AHCI) += ahci-uclass.o > > > -obj-$(CONFIG_AHCI_PCI) += ahci-pci.o > > > +obj-$(CONFIG_$(SPL_)AHCI_PCI) += ahci-pci.o > > > obj-$(CONFIG_SCSI_AHCI) += ahci.o > > > obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o > > > obj-$(CONFIG_FSL_SATA) += fsl_sata.o > > > > Looks right to me, please submit it as a proper patch, thanks! > > Patches are already waiting here: > https://patchwork.ozlabs.org/project/uboot/list/?series=258094 Yes, thanks, I'll pick them up for the merge window. -- Tom signature.asc Description: PGP signature
Re: Broken CONFIG_SPL_SATA_SUPPORT=y
On Sunday 15 August 2021 10:23:03 Tom Rini wrote: > On Sun, Aug 15, 2021 at 01:48:26PM +0200, Pali Rohár wrote: > > On Monday 02 August 2021 21:40:07 Tom Rini wrote: > > > OK, thanks. Then the right fix is to introduce whatever SPL_xxx symbols > > > you need so that you can turn off what you don't want in SPL but leave > > > it enabled in full U-Boot, and update the code to use > > > CONFIG_IS_ENABLED(xxx). If you can do that part, I can iterate over > > > converting everyone else that assumes what we have today is what it > > > wants in SPL and non-SPL. > > > > Hello Tom! Below is patch which adds SPL_AHCI_PCI symbol. I'm not sure > > if this is correct approach but it looks like that it fixed that issue. > > With this patch I can compile U-Boot with and also without enabling of > > CONFIG_SPL_SATA_SUPPORT option. > > > > > > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig > > index 0c1490a9f900..96c7c30375bd 100644 > > --- a/drivers/ata/Kconfig > > +++ b/drivers/ata/Kconfig > > @@ -41,6 +41,12 @@ config AHCI_PCI > > help > > Enables support for the PCI-based AHCI controller. > > > > +config SPL_AHCI_PCI > > + bool "Support for PCI-based AHCI controller for SPL" > > + depends on SPL > > + depends on SPL_PCI > > + depends on SPL_SATA_SUPPORT && DM_SCSI > > + > > config SATA_CEVA > > bool "Ceva Sata controller" > > depends on AHCI > > diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile > > index 4811b2f82c4e..cd88131dcd13 100644 > > --- a/drivers/ata/Makefile > > +++ b/drivers/ata/Makefile > > @@ -5,7 +5,7 @@ > > > > obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o > > obj-$(CONFIG_AHCI) += ahci-uclass.o > > -obj-$(CONFIG_AHCI_PCI) += ahci-pci.o > > +obj-$(CONFIG_$(SPL_)AHCI_PCI) += ahci-pci.o > > obj-$(CONFIG_SCSI_AHCI) += ahci.o > > obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o > > obj-$(CONFIG_FSL_SATA) += fsl_sata.o > > Looks right to me, please submit it as a proper patch, thanks! Patches are already waiting here: https://patchwork.ozlabs.org/project/uboot/list/?series=258094
Re: [RFC PATCH v1 2/5] arm64: dts: imx8mm: add common -binman.dtsi
On Fri, Aug 27, 2021 at 3:59 AM Marcel Ziswiler wrote: > > Hi Teresa > > On Fri, 2021-08-27 at 09:21 +, Teresa Remmet wrote: > > Hello Marcel, > > > > Am Donnerstag, den 26.08.2021, 14:14 +0200 schrieb Marcel Ziswiler: > > > From: Marcel Ziswiler > > > > > > With the move to using binman to generate SPL aka u-boot-spl-ddr.bin > > > and > > > U-Boot proper aka u-boot.itb every board now covers such > > > configuration > > > in its own U-Boot specific device tree include. Introduce a new > > > common > > > imx8mm-binman.dtsi which covers the common part of that > > > configuration. > > > > > > Signed-off-by: Marcel Ziswiler > > > > > > --- > > > > > > arch/arm/dts/imx8mm-binman.dtsi | 136 > > > ++ > > > arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 126 ++-- > > > arch/arm/dts/imx8mm-evk-u-boot.dtsi | 124 +--- > > > .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi| 123 +--- > > > arch/arm/dts/imx8mm-venice-u-boot.dtsi| 120 +--- > > > arch/arm/dts/imx8mm-verdin-u-boot.dtsi| 123 +--- > > > 6 files changed, 156 insertions(+), 596 deletions(-) > > > create mode 100644 arch/arm/dts/imx8mm-binman.dtsi > > > > > > diff --git a/arch/arm/dts/imx8mm-binman.dtsi b/arch/arm/dts/imx8mm- > > > binman.dtsi > > > new file mode 100644 > > > index 000..2d98c1ef577 > > > --- /dev/null > > > +++ b/arch/arm/dts/imx8mm-binman.dtsi > > > > is it really necessary to create a new binman include? > > No, I guess not. That's just what we loosely discussed. But this is also > exactly why I only posted it as an RFC > to get such feedback. > > > I have added the > > nodes for imx8mp directly to the imx8mp-u-boot.dtsi. I guess you did > > this because not all boards are converted yet. But I have tried this > > when I moved binman to the common include for imx8mp. As the phycore- > > imx8mp was also not converted at that point. It did not hurt having the > > binman nodes included. At least back then. > > Yes, maybe we can indeed just put it all into the same imx8mp-u-boot.dtsi. If > nobody objects to that idea I can > try it that way for a v2. > > > > I just not like to see that the file structure diverges. If there is a > > good reason I'd rather also move the binman nodes for imx8mp to a > > imx8mp-binman.dtsi. > > No, I guess either way will work. Let's hope we get some more feedback on > what the others prefer. Thanks! > I'm not sure if I understand correctly but if the suggestion is to create a dtsi that is shared between the imx8mm and imx8mp I don't think that would be a good idea as there are differences in addresses and such. In fact, there's a difference in DDR training firmware between ddr3 and lpddr4 so trying to even combine them into an imx8mm-u-boot.dtsi doesn't even make sense to me. If anything maybe it should be a imx8mm-binman-lpddr4-u-boot.dtsi or something like that? Perhaps ifdef's could handle these differences allowing you to combine ddr types and SoC's? Tim
[PATCH 1/2] include: dt-bindings: mfd: add atmel flexcom include file
Add dt-bindings include file for Atmel Flexcom hardware block. This file is copied from Linux kernel. It is used in devicetrees from Linux. Signed-off-by: Eugen Hristev --- MAINTAINERS | 1 + include/dt-bindings/mfd/atmel-flexcom.h | 15 +++ 2 files changed, 16 insertions(+) create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h diff --git a/MAINTAINERS b/MAINTAINERS index 776ff703b9..f4059c1cf4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -312,6 +312,7 @@ F: arch/arm/mach-at91/ F: board/atmel/ F: drivers/cpu/at91_cpu.c F: drivers/misc/microchip_flexcom.c +F: include/dt-bindings/mfd/atmel-flexcom.h F: drivers/timer/mchp-pit64b-timer.c ARM NEXELL S5P4418 diff --git a/include/dt-bindings/mfd/atmel-flexcom.h b/include/dt-bindings/mfd/atmel-flexcom.h new file mode 100644 index 00..4e2fc32363 --- /dev/null +++ b/include/dt-bindings/mfd/atmel-flexcom.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * This header provides macros for Atmel Flexcom DT bindings. + * + * Copyright (C) 2015 Cyrille Pitchen + */ + +#ifndef __DT_BINDINGS_ATMEL_FLEXCOM_H__ +#define __DT_BINDINGS_ATMEL_FLEXCOM_H__ + +#define ATMEL_FLEXCOM_MODE_USART 1 +#define ATMEL_FLEXCOM_MODE_SPI 2 +#define ATMEL_FLEXCOM_MODE_TWI 3 + +#endif /* __DT_BINDINGS_ATMEL_FLEXCOM_H__ */ -- 2.25.1
[PATCH 2/2] ARM: dts: at91: update flexcom defines using include file
Replace the number in the flexcom-mode property with the define from the
include file.
This corresponds to the approach in Linux kernel.
Signed-off-by: Eugen Hristev
---
arch/arm/dts/sam9x60ek.dts | 3 ++-
arch/arm/dts/sama7g5ek.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
index 77edd593b4..32ffe93b4d 100644
--- a/arch/arm/dts/sam9x60ek.dts
+++ b/arch/arm/dts/sam9x60ek.dts
@@ -7,6 +7,7 @@
* Author: Sandeep Sheriker M
*/
/dts-v1/;
+#include
#include "sam9x60.dtsi"
/ {
@@ -57,7 +58,7 @@
};
flx0: flexcom@f801c600 {
- atmel,flexcom-mode = <3>;
+ atmel,flexcom-mode = ;
status = "okay";
i2c@600 {
diff --git a/arch/arm/dts/sama7g5ek.dts b/arch/arm/dts/sama7g5ek.dts
index 3a4fdd38a5..1c59a8aaf8 100644
--- a/arch/arm/dts/sama7g5ek.dts
+++ b/arch/arm/dts/sama7g5ek.dts
@@ -8,6 +8,7 @@
* 2020, Claudiu Beznea
*/
/dts-v1/;
+#include
#include "sama7g5.dtsi"
#include "sama7g5-pinfunc.h"
@@ -64,7 +65,7 @@
};
{
- atmel,flexcom-mode = <3>;
+ atmel,flexcom-mode = ;
status = "okay";
};
--
2.25.1
Re: [PATCH u-boot-marvell 28/29] doc/kwboot.1: Update man page
On Friday 27 August 2021 15:35:55 Marek Behún wrote: > On Fri, 27 Aug 2021 10:36:52 +0200 > Pali Rohár wrote: > > > Anyway, it looks like that A385 bootrom has bugs in debug console and so > > -d is on this SoC unusable. When I enter into debug mode, boorom > > somehow does not send output from (debug) commands over UART. But it > > sends ECHO over UART... > > It's possible that debug UART is the other UART... I seem to remember > something like that from documentation, but am not entirely sure. > > Marek I can send commands in debug mode and I checked that bootrom really executes them. But it does not send any output back. So bootrom's "stdin" is working fine but bootrom's "stdout" for bootrom commands is broken. I have not found any details about it.
Re: [PATCH u-boot-marvell 28/29] doc/kwboot.1: Update man page
On Fri, 27 Aug 2021 10:36:52 +0200 Pali Rohár wrote: > Anyway, it looks like that A385 bootrom has bugs in debug console and so > -d is on this SoC unusable. When I enter into debug mode, boorom > somehow does not send output from (debug) commands over UART. But it > sends ECHO over UART... It's possible that debug UART is the other UART... I seem to remember something like that from documentation, but am not entirely sure. Marek
Re: [PATCH u-boot-marvell 00/29] kwboot higher baudrate
On Fri, 27 Aug 2021 14:45:07 +1200 Chris Packham wrote: > The higher speed settings weren't so good. I started with 3125000 and > that doesn't get onto the 2nd part of the download, same for 1152000 > and 400 (I stopped trying higher speeds at that point). Using > 230400 and 460800 it does make it through the 2nd part of the download > but when I go back on to the console it appears to be unresponsive. Did you try v2 or v1? If you tried v1 with old kwb images (created before the previous kwbimage patch series), this is expected. v2 fixes this issue. Marek
Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()
On Fri, Aug 27, 2021 at 08:30:48AM +0200, Stefan Roese wrote: > Hi Tom, > > On 17.08.21 14:35, Tom Rini wrote: > > > > > > Getting back to this to hopefully get this decided: > > > > > > It seems that we (most of us?) agree on this change, that wdt_stop_all() > > > shall be changed to return an error code and the caller can decide what > > > to do with it? > > > > > > If yes, then Rasmus, could you please re-spin this patchset accordingly > > > and send v6? > > > > Yes, please and thanks. > > Tom, would you like me to push this patchset in at this stage (rc2), or > better defer to the next merge window? I'm going to open -next on Monday, so lets put it there. Thanks! -- Tom signature.asc Description: PGP signature
Re: boot hangs on new board with SAMA5D27C-D5M
Hello, for the record … see below. Am Donnerstag, 22. Juli 2021, 19:01:36 CEST schrieb Alexander Dahl: > Hello, > > I'm currently porting a brand new custom board with Microchip's 64 MiB > SAMA5D2 SiP SoC. Second stage bootloader is at91bootstrap, for development > I load U- Boot directly to RAM with SAM-BA to the same address (0x23f0) > and execute from there. RAM base address is 0x2000 and size 0x0400 > (64 MiB). Code is based on the U-Boot v2021.07 upstream code of the > SAMA5D2-SOM1-EK1 board (which has 128 MiB). > > I get to a U-Boot shell and can access SD card and LEDs if I do not activate > NAND flash support in menuconfig. The log with debug messages is attached. > From IRC marex and I suspect some overwritten memory if the u-boot-dtb.bin > file gets too big, but I can not spot any error in those addresses in debug > output. > > The last function called is initr_malloc() from common/board_r.c but I can > not spot what's wrong with that, especially because mem_malloc_init() > prints a probably valid memory area and malloc_bin_reloc() should be a > noop. > > If I disable CONFIG_SYS_MALLOC_CLEAR_ON_INIT, I get to a shell, if I enable > it again, boot hangs. > > So the memset() of the malloc area, which is supposed to be valid to my > knowledge, causes the hang. > > I can try one of the other boards (there are 4 prototype boards) to rule out > an hardware issue, but I'm curious if anyone has an idea what's wrong here? Not sure what was the root cause of the issue, but I changed the initial load address to 0x21f0 which is 1 MiB below half of the RAM (at offset 31 MiB of 64 MiB, instead of at offset 63 MiB). Now U-Boot works without hangs or hiccups. So the change in at91bootstrap3 was: -CONFIG_JUMP_ADDR="0x23f0" +CONFIG_JUMP_ADDR="0x21f0" and in U-Boot: -CONFIG_SYS_TEXT_BASE=0x23f0 +CONFIG_SYS_TEXT_BASE=0x21f0 Greets Alex
[PATCH 2/2] arm: a37xx: pci: Implement re-issuing config requests on CRS response
According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.
Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.
This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.
Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.
Signed-off-by: Pali Rohár
---
drivers/pci/pci-aardvark.c | 58 --
1 file changed, 43 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index d3ef8f203d97..74797e984cb8 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -234,19 +234,19 @@ static int pcie_advk_addr_valid(pci_dev_t bdf, int
first_busno)
*
* Wait up to 1.5 seconds for PIO access to be accomplished.
*
- * Return 1 (true) if PIO access is accomplished.
- * Return 0 (false) if PIO access is timed out.
+ * Return positive - retry count if PIO access is accomplished.
+ * Return negative - error if PIO access is timed out.
*/
static int pcie_advk_wait_pio(struct pcie_advk *pcie)
{
uint start, isr;
uint count;
- for (count = 0; count < PIO_MAX_RETRIES; count++) {
+ for (count = 1; count <= PIO_MAX_RETRIES; count++) {
start = advk_readl(pcie, PIO_START);
isr = advk_readl(pcie, PIO_ISR);
if (!start && isr)
- return 1;
+ return count;
/*
* Do not check the PIO state too frequently,
* 100us delay is appropriate.
@@ -255,7 +255,7 @@ static int pcie_advk_wait_pio(struct pcie_advk *pcie)
}
dev_err(pcie->dev, "PIO read/write transfer time out\n");
- return 0;
+ return -ETIMEDOUT;
}
/**
@@ -265,11 +265,13 @@ static int pcie_advk_wait_pio(struct pcie_advk *pcie)
* @allow_crs: Only for read requests, if CRS response is allowed
* @read_val: Pointer to the read result
*
+ * Return: 0 on success
*/
static int pcie_advk_check_pio_status(struct pcie_advk *pcie,
bool allow_crs,
uint *read_val)
{
+ int ret;
uint reg;
unsigned int status;
char *strcomp_status, *str_posted;
@@ -282,6 +284,7 @@ static int pcie_advk_check_pio_status(struct pcie_advk
*pcie,
case PIO_COMPLETION_STATUS_OK:
if (reg & PIO_ERR_STATUS) {
strcomp_status = "COMP_ERR";
+ ret = -EFAULT;
break;
}
/* Get the read result */
@@ -289,29 +292,35 @@ static int pcie_advk_check_pio_status(struct pcie_advk
*pcie,
*read_val = advk_readl(pcie, PIO_RD_DATA);
/* No error */
strcomp_status = NULL;
+ ret = 0;
break;
case PIO_COMPLETION_STATUS_UR:
strcomp_status = "UR";
+ ret = -EOPNOTSUPP;
break;
case PIO_COMPLETION_STATUS_CRS:
if (allow_crs && read_val) {
/* For reading, CRS is not an error status. */
*read_val = CFG_RD_CRS_VAL;
strcomp_status = NULL;
+ ret = 0;
} else {
strcomp_status = "CRS";
+ ret = -EAGAIN;
}
break;
case PIO_COMPLETION_STATUS_CA:
strcomp_status = "CA";
+ ret = -ECANCELED;
break;
default:
strcomp_status = "Unknown";
+ ret = -EINVAL;
break;
}
if (!strcomp_status)
- return 0;
+ return ret;
if (reg & PIO_NON_POSTED_REQ)
str_posted = "Non-posted";
@@ -322,7 +331,7 @@ static int pcie_advk_check_pio_status(struct pcie_advk
*pcie,
str_posted, strcomp_status, reg,
advk_readl(pcie, PIO_ADDR_LS));
- return -EFAULT;
+ return ret;
}
/**
@@ -345,6 +354,7 @@ static int pcie_advk_read_config(const struct udevice *bus,
pci_dev_t bdf,
enum pci_size_t size)
{
struct pcie_advk *pcie = dev_get_priv(bus);
+ int retry_count;
bool allow_crs;
uint reg;
int ret;
@@ -379,7 +389,7 @@ static int pcie_advk_read_config(const struct udevice *bus,
pci_dev_t bdf,
return 0;
[PATCH 1/2] arm: a37xx: pci: Disable returning CRS response
There was mistake in commit 4cd61c43fd51 ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.
Therefore disable returning CRS response for now.
Signed-off-by: Pali Rohár
Fixes: 4cd61c43fd51 ("arm: a37xx: pci: Fix handling PIO config error responses")
---
drivers/pci/pci-aardvark.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 815b26162f15..d3ef8f203d97 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -358,7 +358,18 @@ static int pcie_advk_read_config(const struct udevice
*bus, pci_dev_t bdf,
return 0;
}
- allow_crs = (offset == PCI_VENDOR_ID) && (size == 4);
+ /*
+* Returning fabricated CRS value (0x0001) by PCIe Root Complex to
+* OS is allowed only for 4-byte PCI_VENDOR_ID config read request and
+* only when CRSSVE bit in Root Port PCIe device is enabled. In all
+* other error PCIe Root Complex must return all-ones.
+* Aardvark HW does not have Root Port PCIe device and U-Boot does not
+* implement emulation of this device.
+* U-Boot currently does not support handling of CRS return value for
+* PCI_VENDOR_ID config read request and also does not set CRSSVE bit.
+* Therefore disable returning CRS response for now.
+*/
+ allow_crs = false;
if (advk_readl(pcie, PIO_START)) {
dev_err(pcie->dev,
--
2.20.1
[PATCH] pwm: Add driver for cadence TTC
TTC has three modes of operations. Timer, PWM and input counters.
There is already driver for timer under CADENCE_TTC_TIMER which is used for
ZynqMP R5 configuration.
This driver is targeting PWM which is for example configuration which can
be used for fan control.
The driver has been tested on Xilinx Kria SOM platform where fan is
connected to one PL pin. When TTC output is connected via EMIO to PL pin
TTC pwm can be configured and tested for example like this:
pwm config 0 0 1 1200
pwm enable 0 0
pwm config 0 0 1 1400
pwm config 0 0 1 1600
Signed-off-by: Michal Simek
---
MAINTAINERS | 1 +
drivers/pwm/Kconfig | 7 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-cadence-ttc.c | 217 ++
4 files changed, 226 insertions(+)
create mode 100644 drivers/pwm/pwm-cadence-ttc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4cf0c33c5d58..889813382249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -600,6 +600,7 @@ F: drivers/mmc/zynq_sdhci.c
F: drivers/mtd/nand/raw/zynq_nand.c
F: drivers/net/phy/xilinx_phy.c
F: drivers/net/zynq_gem.c
+F: drivers/pwm/pwm-cadence-ttc.c
F: drivers/serial/serial_zynq.c
F: drivers/reset/reset-zynqmp.c
F: drivers/rtc/zynqmp_rtc.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index cf7f4c6840ce..176e703c8fbb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -9,6 +9,13 @@ config DM_PWM
frequency/period can be controlled along with the proportion of that
time that the signal is high.
+config PWM_CADENCE_TTC
+ bool "Enable support for the Cadence TTC PWM"
+ depends on DM_PWM && !CADENCE_TTC_TIMER
+ help
+ Cadence TTC can be configured as timer which is done via
+ CONFIG_CADENCE_TTC_TIMER or as PWM. This is covering only PWM now.
+
config PWM_CROS_EC
bool "Enable support for the Chrome OS EC PWM"
depends on DM_PWM
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 10d244bfb79d..abf5af41d2cc 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -10,6 +10,7 @@
obj-$(CONFIG_DM_PWM) += pwm-uclass.o
+obj-$(CONFIG_PWM_CADENCE_TTC) += pwm-cadence-ttc.o
obj-$(CONFIG_PWM_CROS_EC) += cros_ec_pwm.o
obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o
diff --git a/drivers/pwm/pwm-cadence-ttc.c b/drivers/pwm/pwm-cadence-ttc.c
new file mode 100644
index ..1d007676bb3b
--- /dev/null
+++ b/drivers/pwm/pwm-cadence-ttc.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021 Xilinx, Inc. Michal Simek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TTC_COUNTER_CONTROL_1 0xc
+#define TTC_INTERVAL_COUNTER_1 0x24
+#define TTC_MATCH_1_COUNTER_1 0x30
+
+#define CPWM_CLK_FALLING_EDGE 0x40
+#define CPWM_CLK_SRC_EXTERNAL 0x20
+#define CPWM_CLK_PRESCALE_SHIFT1
+#define CPWM_CLK_PRESCALE_MASK (15 << 1)
+#define CPWM_CLK_PRESCALE_ENABLE 1
+
+#define CPWM_COUNTER_CTRL_WAVE_POL 0x40
+#define CPWM_COUNTER_CTRL_WAVE_DISABLE 0x20
+#define CPWM_COUNTER_CTRL_RESET0x10
+#define CPWM_COUNTER_CTRL_MATCH_ENABLE 0x8
+#define CPWM_COUNTER_CTRL_DECREMENT_ENABLE 0x4
+#define CPWM_COUNTER_CTRL_INTERVAL_ENABLE 0x2
+#define CPWM_COUNTER_CTRL_COUNTING_DISABLE 0x1
+
+struct cadence_ttc_pwm_priv {
+ uchar *regs;
+ unsigned long frequency;
+ bool invert[2];
+};
+
+static int cadence_ttc_pwm_set_invert(struct udevice *dev, uint channel,
+ bool polarity)
+{
+ struct cadence_ttc_pwm_priv *priv = dev_get_priv(dev);
+
+ if (channel > 2) {
+ dev_err(dev, "Unsupported channel number %d(max 2)\n", channel);
+ return -EINVAL;
+ }
+
+ priv->invert[channel] = polarity;
+
+ dev_dbg(dev, "polarity=%u. Please config PWM again\n", polarity);
+
+ return 0;
+}
+
+static int cadence_ttc_pwm_set_config(struct udevice *dev, uint channel,
+ uint period_ns, uint duty_ns)
+{
+ struct cadence_ttc_pwm_priv *priv = dev_get_priv(dev);
+ u32 counter_ctrl, x;
+ int period_clocks, duty_clocks, prescaler;
+
+ dev_dbg(dev, "channel %d, duty %d/ period %d ns\n", channel,
+ duty_ns, period_ns);
+
+ if (channel > 2) {
+ dev_err(dev, "Unsupported channel number %d(max 2)\n", channel);
+ return -EINVAL;
+ }
+
+ /* Make sure counter is stopped */
+ counter_ctrl = readl(priv->regs + TTC_COUNTER_CONTROL_1 +
+(channel * 4));
+ setbits_le32(priv->regs + TTC_COUNTER_CONTROL_1 + (channel * 4),
+CPWM_COUNTER_CTRL_COUNTING_DISABLE);
Re: [PATCH 0/2] Fix qspi read and write issues
On 8/27/21 10:36 AM, Ashok Reddy Soma wrote: > This patch series fixes below issues > - Switch genfifo start to manual start mode > - Unaligned DMA reads > - Minor improvements in initialization > > > > Ashok Reddy Soma (2): > spi: zynqmp_gqspi: Switch genfifo start to manual mode > spi: zynqmp_gqspi: Fix dma alignment issue > > drivers/spi/zynqmp_gqspi.c | 30 ++ > 1 file changed, 14 insertions(+), 16 deletions(-) > Tested-by: Michal Simek Thanks, Michal
Re: [PATCH v2 0/2] Refactor and improve full help output from tools
On Fri, 13 Aug 2021 17:24:58 +0100 Paul Barker wrote: > Sorry this took so long to get back to! Got there in the end though :) > > Changes from v1: > * Collected the full help printing code from patman, buildman & binman into > a > single function so that when support for PAGER containing arguments is > added > it applies to all the relevant tools. > > Paul Barker (2): > tools: Refactor full help printing > tools: Handle PAGER containing arguments > > tools/binman/control.py | 9 +++-- > tools/buildman/control.py | 10 -- > tools/patman/main.py | 12 > tools/patman/tools.py | 14 ++ > 4 files changed, 25 insertions(+), 20 deletions(-) > Sending a quick ping on these patches as it's been 2 weeks. -- Paul Barker Principal Software Engineer SanCloud Ltd pgpbOXP5sbHKz.pgp Description: OpenPGP digital signature
[GIT PULL] xilinx patches for v2021.10-rc3
Hi Tom, please pull these patches to your tree. Gitlab CI is not showing any issue and I have also tested qspi/sd flows on zynq and zynqmp boards. There are a lot of fixes and alignments with also some features like rtc/soc drivers and correcting capsule update. Code for multi_fit is also added but not enabled by default. SPI driver needs to be fixed. Patches have been sent today. I will take care about them soon. Thanks, Michal The following changes since commit ab97eb341cb4fdbd69e33bd4a53714db95b5b63e: Merge branch '2021-08-04-assorted-minor-fixes' (2021-08-04 21:18:33 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2021.10-rc3 for you to fetch changes up to 229cb5c6ba3469cbc4a0bcc69389fe61c51fd3b4: xilinx: zynqmp: Enable stack relocation to DDR (2021-08-26 08:14:43 +0200) Xilinx changes for v2021.10-rc3 xilinx: - Disable CONFIG_ARCH_FIXUP_FDT_MEMORY - Print information about cpu via soc drivers and enable DISPLAY_CPUINFO - Wire infrastructure for DTB_RESELECT and MULTI_DTB_FIT zynq: - Wire single QSPI - Use power-source instead of io-standard properties - Enable nor on zc770-xm012 zynqmp: - Change handling around multi_boot() - Setup offset for u-boot.itb in spi - Generate run time dfu_alt_info for capsule update - Use explicit values for enums (zynqmp_firmware.h) - Enable RTC/SHA1/BUTTON/BUTTON_GPIO command - Disable WDT driver by default - Bind usb/scsi via preboot because of EFI - DT updates/fixes - Add soc driver - Fix SPL SPI boot mode versal: - Add soc driver sdhci: - Update tap delay programming for zynq_sdhci driver cmd: - Fix RTC uclass handling in date command - Update pwm help message - Update reset help message watchdog: - Fix wwdt compilation rtc: - Deal with seq alias in rtc uclass - Add zynqmp RTC driver fdt: - Add kernel-doc for fdt_fixup_memory_banks() Ashok Reddy Soma (6): mmc: zynq_sdhci: Return errors from arasan_sdhci_set_tapdelay mmc: sdhci: Change prototype of set_delay to return errors mmc: zynq_sdhci: Add xilinx_pm_request() method to set tapdelays mmc: zynq_sdhci: Move setting tapdelay code to driver mmc: zynq_sdhci: Use set_control_reg from sdhci.c watchdog: versal: Include header file needed for dev_ functions Michal Simek (37): xilinx: zynqmp: Free allocated field for target variable xilinx: zynqmp: Change multi_boot() to return value xilinx: zynqmp: use zynqmp_mmio_read() in multi_boot() xilinx: zynqmp: Config non zero SYS_SPI_U_BOOT_OFFS xilinx: zynqmp: Add support for runtime dfu_alt_info setup firmware: xilinx: Use explicit values for all enum values dm: rtc: uclass: Add flag to control sequence numbering cmd: date: rtc: Update command to read the first RTC with seq 0 rtc: zynqmp: Add support for ZynqMP RTC xilinx: zynqmp: Enable CMD_RTC command with Zynqmp RTC driver reset: zynqmp: Add reset controller for ZynqMP SoC arm64: zynqmp: Disable WDT_CDNS driver by default xilinx: zynqmp: Initialize usb and scsi via preboot arm64: zynqmp: Fix node name for ds35/36 leds arm64: zynqmp: Fix header alignment on kv260 boards arm64: zynqmp: Update comment style sm-k26 ARM: zynq: Wire single qspi on couple of boards ARM: zynq: Enable smcc and nor for zc770-xm012 xilinx: Disable ARCH_FIXUP_FDT_MEMORY fdt_support: Add kernel-doc for fdt_fixup_memory_banks() cmd: pwm: Remove additional pwm description cmd: boot: Update reset usage message xilinx: zynqmp: Add debug messages for boot mode arm64: zynqmp: Enable sha1sum command xilinx: zynqmp: Enable gpio-key/button driver xilinx: fru: Replace spaces with \0 in detected name xilinx: Use variable for passing board_name xilinx: common: Change board_info[] handling xilinx: common: Free allocated structure xilinx: Add support for generic board detection xilinx: zynqmp: Check that DT is 64bit aligned Makefile: Align fit-dtb.blob and u-boot.itb by 64bits arm64: dts: Make sure that all DTBs are 64bit aligned xilinx: zynqmp: Generate different u-boot.itb for MULTI_DTB_FIT xilinx: common: Enabling generic function for DT reselection xilinx: zynqmp: Update descriptions for u-boot.its xilinx: zynqmp: Enable stack relocation to DDR Raju Kumar Pothuraju (1): xilinx: Add jedec compatible string for QSPI (Zynq/ZynqMP) Sai Krishna Potthuri (1): ARM: zynq: Replace 'io-standard' with 'power-source' property T Karthik Reddy (6): zynqmp_firmware: Add zynqmp firmware related enums mmc: zynq_sdhci: Wait till sd card detect state is stable soc: xilinx: zynqmp: Add soc_xilinx_zynqmp driver soc: xilinx: versal: Add soc_xilinx_versal driver
Re: [PATCH u-boot-marvell 00/29] kwboot higher baudrate
On Fri, 27 Aug 2021, 8:32 PM Pali Rohár, wrote: > On Friday 27 August 2021 14:45:07 Chris Packham wrote: > > On Fri, Aug 27, 2021 at 1:39 PM Marek Behún wrote: > > > > > > On Fri, 27 Aug 2021 13:16:25 +1200 > > > Chris Packham wrote: > > > > > > > On Thu, Aug 26, 2021 at 1:46 AM Marek Behún > wrote: > > > > > > > > > > Hello Stefan and others, > > > > > > > > > > this series adds support for booting Marvell platforms via UART > (those > > > > > bootable with kwboot) at higher baudrates. > > > > > > > > > > Tested on Turris Omnia up to 5.15 MBd, which is 44x faster than > > > > > 115200 Bd. > > > > > > > > > > The user can direct kwboot to use higher baudrate via the -B > option. > > > > > (BTW this option was there before but did not work with the -b > option.) > > > > > > > > > > Only the payload part of the KWB image is uploaded at this higher > > > > > baudrate. The header part is still uploaded at 115200 Bd, since > the code > > > > > that changes baudrate is injected into header as a binary > extension. > > > > > (The payload part makes up majority of the binary, though. On > Turris > > > > > Omnia the payload currently makes ~87%.) > > > > > > > > > > The series also contains various other fixes, refactors and > improvements > > > > > of the code, upon which the main change is done. > > > > > > > > > > Marek & Pali > > > > > > > > What tree/sha is this series based on. I've tried to apply them out > of > > > > patchwork and it fails at "tools: kwbimage: Simplify iteration over > > > > version 1 optional headers" > > > > > > Applies to master and to u-boot-marvell, but you need the 6 > > > additional patches for kwbimage/kwboot that are on patchwork > > > but not yet applied to u-boot-marvell: > > > https://patchwork.ozlabs.org/project/uboot/list/?series=257577 > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210817050320.11983-1-xypron.g...@gmx.de/ > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210817051158.13283-1-xypron.g...@gmx.de/ > > > > > > Also some more fixes were yet needed, which I will sent in v2. > > > > > > To make it simpler for you I pushed v2 into > > > https://gitlab.nic.cz/turris/turris-omnia-uboot > > > branch > > > kwboot-baudrate-improvements > > > > > > > Thanks. I took it for a spin on the x530. In terms of regression > > testing the default behaviour is good. > > > > The higher speed settings weren't so good. I started with 3125000 and > > that doesn't get onto the 2nd part of the download, same for 1152000 > > and 400 (I stopped trying higher speeds at that point). Using > > 230400 and 460800 it does make it through the 2nd part of the download > > but when I go back on to the console it appears to be unresponsive. > > > > All of this could be down to the serial hardware in my system (the > > x530 uses a real RS232 interface not a TTL) and I have had problems > > with the MosChip USB-Serial adapter in my test PC in the past. I > > wouldn't reject this series based on me not being able to get it > > working, the important thing for me is the default behaviour at the > > standard baudrate which is good. > > You need to choose speed which is supported by both armada board and > your computer. Armada boards support speeds calculated by formula: > speed = TCLK / ( 16 * d ) > where d is 16-bit integer number. So for A385 board with 250 MHz TCLK > you can set speeds from above formula +/- 30%. Tested were: > 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, > 230400, 460800, 50, 576000, 921600, 100, 1152000, 150, > 200, 250, 3125000, 400, 515. > If you have a board with different TCLK you obviously need to use > different baudrates. > > But it is possible that your computer does not support these speeds. > E.g. more chinese USB TTL adapters have base clock 3 MHz and so they > could not support 315 or 250 speeds. > > > One usability thing I'd like to see is retaining support for -t (I use > > that quite a lot when recovering a system). Ideally we'd still be able > > to drop into the console at 115200 once the download is complete. > > -t is fully supported, I'm using -t with -B 515 and it is working > fine. After successful download, speed on both A38x and host computer is > changed back to the value 115200. > Ah I misread the man page update >
Re: [RFC PATCH v1 2/5] arm64: dts: imx8mm: add common -binman.dtsi
Hi Teresa On Fri, 2021-08-27 at 09:21 +, Teresa Remmet wrote: > Hello Marcel, > > Am Donnerstag, den 26.08.2021, 14:14 +0200 schrieb Marcel Ziswiler: > > From: Marcel Ziswiler > > > > With the move to using binman to generate SPL aka u-boot-spl-ddr.bin > > and > > U-Boot proper aka u-boot.itb every board now covers such > > configuration > > in its own U-Boot specific device tree include. Introduce a new > > common > > imx8mm-binman.dtsi which covers the common part of that > > configuration. > > > > Signed-off-by: Marcel Ziswiler > > > > --- > > > > arch/arm/dts/imx8mm-binman.dtsi | 136 > > ++ > > arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 126 ++-- > > arch/arm/dts/imx8mm-evk-u-boot.dtsi | 124 +--- > > .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi | 123 +--- > > arch/arm/dts/imx8mm-venice-u-boot.dtsi | 120 +--- > > arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 123 +--- > > 6 files changed, 156 insertions(+), 596 deletions(-) > > create mode 100644 arch/arm/dts/imx8mm-binman.dtsi > > > > diff --git a/arch/arm/dts/imx8mm-binman.dtsi b/arch/arm/dts/imx8mm- > > binman.dtsi > > new file mode 100644 > > index 000..2d98c1ef577 > > --- /dev/null > > +++ b/arch/arm/dts/imx8mm-binman.dtsi > > is it really necessary to create a new binman include? No, I guess not. That's just what we loosely discussed. But this is also exactly why I only posted it as an RFC to get such feedback. > I have added the > nodes for imx8mp directly to the imx8mp-u-boot.dtsi. I guess you did > this because not all boards are converted yet. But I have tried this > when I moved binman to the common include for imx8mp. As the phycore- > imx8mp was also not converted at that point. It did not hurt having the > binman nodes included. At least back then. Yes, maybe we can indeed just put it all into the same imx8mp-u-boot.dtsi. If nobody objects to that idea I can try it that way for a v2. > I just not like to see that the file structure diverges. If there is a > good reason I'd rather also move the binman nodes for imx8mp to a > imx8mp-binman.dtsi. No, I guess either way will work. Let's hope we get some more feedback on what the others prefer. Thanks! > Regards, > Teresa Cheers Marcel
[PATCH] ARM: zynq: Enable capsule update for qspi and mmc
Generate dfu_alt_info setup at runtime for capsule update.
Enabling this feature will help with upgrading boards without remembering
what is where.
The similar change was done for ZynqMP by commit b86f43de0be0 ("xilinx:
zynqmp: Add support for runtime dfu_alt_info setup").
Code needs to be enabled by CONFIG_SET_DFU_ALT_INFO.
And also enable capsule on disk for RAW firmware images with efidebug
command.
Two indexes are supported for SPL flow. Images can be generated like:
./tools/mkeficapsule --raw spl/boot.bin --index 1 capsule1.bin
./tools/mkeficapsule --raw u-boot.img --index 2 capsule2.bin
Then place them to SD card and load them:
load mmc 0 1000 capsule1.bin && efidebug capsule update -v 1000
load mmc 0 1000 capsule2.bin && efidebug capsule update -v 1000
FSBL flow will also work where only index 1 capsule is used. There
should be enough space for using boot.bin with bitstream too.
Zynq also support multiple boot locations in SPI or MMC but it is not wired
by this patch.
Signed-off-by: Michal Simek
---
board/xilinx/zynq/board.c | 35 ++
configs/xilinx_zynq_virt_defconfig | 6 +
2 files changed, 41 insertions(+)
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 61e0a90c119b..ad6fca9c 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -151,3 +152,37 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_NOWHERE;
}
}
+
+#if defined(CONFIG_SET_DFU_ALT_INFO)
+
+#define DFU_ALT_BUF_LENSZ_1K
+
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
+
+ if (env_get("dfu_alt_info"))
+ return;
+
+ memset(buf, 0, sizeof(buf));
+
+ switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) {
+ case ZYNQ_BM_SD:
+ snprintf(buf, DFU_ALT_BUF_LEN,
+"mmc 0:1=boot.bin fat 0 1;"
+"u-boot.img fat 0 1");
+ break;
+ case ZYNQ_BM_QSPI:
+ snprintf(buf, DFU_ALT_BUF_LEN,
+"sf 0:0=boot.bin raw 0 0x150;"
+"u-boot.img raw 0x%x 0x50",
+CONFIG_SYS_SPI_U_BOOT_OFFS);
+ break;
+ default:
+ return;
+ }
+
+ env_set("dfu_alt_info", buf);
+ puts("DFU alt info setting: done\n");
+}
+#endif
diff --git a/configs/xilinx_zynq_virt_defconfig
b/configs/xilinx_zynq_virt_defconfig
index 573a10fe221b..09ee066fdce2 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -49,6 +49,7 @@ CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_CACHE=y
+CONFIG_CMD_EFIDEBUG=y
CONFIG_CMD_TIME=y
CONFIG_CMD_TIMER=y
CONFIG_CMD_EXT4_WRITE=y
@@ -69,6 +70,8 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_DFU_TIMEOUT=y
CONFIG_DFU_MMC=y
CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
+CONFIG_SET_DFU_ALT_INFO=y
CONFIG_SYS_DFU_DATA_BUF_SIZE=0x60
CONFIG_FPGA_XILINX=y
CONFIG_FPGA_ZYNQPL=y
@@ -123,3 +126,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_FUNCTION_THOR=y
CONFIG_DISPLAY=y
CONFIG_SPL_GZIP=y
+CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
--
2.33.0
[PATCH] doc: Remove information about CAPSULE_FMP_HEADER
This Kconfig symbol was never added to U-Boot but it was mentioned in the
origin commit c35df7c9e43e ("qemu: arm64: Add documentation for capsule
update"). That's why remove it from documentation to be accurate.
Signed-off-by: Michal Simek
---
doc/develop/uefi/uefi.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 64fe9346c7f2..f17138f5c765 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -392,7 +392,6 @@ settings::
CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
CONFIG_EFI_CAPSULE_FIRMWARE=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
-CONFIG_EFI_CAPSULE_FMP_HEADER=y
In addition, the following config needs to be disabled(QEMU ARM specific)::
--
2.33.0
Re: [PATCH] zynqmp: restore the jtag interface
On 8/27/21 11:17 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> On 12/08/21, Michal Simek wrote:
>>
>>
>> On 7/16/21 7:16 PM, Jorge Ramirez-Ortiz wrote:
>>> As a security feature, if boot.bin was configured for secure boot the
>>> CSU will disable the JTAG interface on all cases.
>>>
>>> Some boards might rely on this interface for flashing to QSPI in which
>>> case those systems might end up bricked during development.
>>>
>>> This commit attempts to restore the interface - if the CSU allows for it.
>>
>> sorry I missed this.
>>
>>>
>>> Signed-off-by: Jorge Ramirez-Ortiz
>>> ---
>>> arch/arm/mach-zynqmp/Kconfig | 9
>>> arch/arm/mach-zynqmp/include/mach/hardware.h | 23 +--
>>> board/xilinx/zynqmp/zynqmp.c | 24
>>> 3 files changed, 49 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
>>> index 39144d654e..1e551c0020 100644
>>> --- a/arch/arm/mach-zynqmp/Kconfig
>>> +++ b/arch/arm/mach-zynqmp/Kconfig
>>> @@ -149,6 +149,15 @@ config SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
>>> Overwrite bootmode selected via boot mode pins to tell SPL what should
>>> be the next boot device.
>>>
>>> +config SPL_ZYNQMP_RESTORE_JTAG
>>> + bool "Restore JTAG"
>>> + depends on SPL
>>> + default n
>>
>> no need for default n - that's default option anyway.
>
> ok
>
>>
>>> + help
>>> +Booting SPL in secure mode causes the CSU to disable the JTAG interface
>>> +even if no eFuses were burnt. This option restores the interface if
>>> +possible.
>>
>> Indentation is weird. Please look at tabs/spaces.
>
> ok
>
>>
>>> +
>>> config ZYNQ_SDHCI_MAX_FREQ
>>> default 2
>>>
>>> diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h
>>> b/arch/arm/mach-zynqmp/include/mach/hardware.h
>>> index 3776499070..58822e3f25 100644
>>> --- a/arch/arm/mach-zynqmp/include/mach/hardware.h
>>> +++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
>>> @@ -42,17 +42,20 @@
>>> struct crlapb_regs {
>>> u32 reserved0[36];
>>> u32 cpu_r5_ctrl; /* 0x90 */
>>> - u32 reserved1[37];
>>> + u32 reserved1[7];
>>> + u32 dbg_lpd_ctrl; /* 0xB0 */
>>> + u32 reserved2[29];
>>> u32 timestamp_ref_ctrl; /* 0x128 */
>>> - u32 reserved2[53];
>>> + u32 reserved3[53];
>>> u32 boot_mode; /* 0x200 */
>>> - u32 reserved3_0[7];
>>> + u32 reserved4_0[7];
>>> u32 reset_reason; /* 0x220 */
>>> - u32 reserved3_1[6];
>>> + u32 reserved4_1[6];
>>> u32 rst_lpd_top; /* 0x23C */
>>> - u32 reserved4[4];
>>> + u32 rst_lpd_dbg; /* 0x240 */
>>> + u32 reserved5[3];
>>> u32 boot_pin_ctrl; /* 0x250 */
>>> - u32 reserved5[21];
>>> + u32 reserved6[21];
>>> };
>>>
>>> #define crlapb_base ((struct crlapb_regs *)ZYNQMP_CRL_APB_BASEADDR)
>>> @@ -141,9 +144,15 @@ struct apu_regs {
>>> struct csu_regs {
>>> u32 reserved0[4];
>>> u32 multi_boot;
>>> - u32 reserved1[11];
>>> + u32 reserved1[7];
>>> + u32 jtag_chain_status_wr;
>>> + u32 jtag_chain_status;
>>> + u32 jtag_sec;
>>> + u32 jtag_dap_cfg;
>>> u32 idcode;
>>> u32 version;
>>> + u32 reserved2[3055];
>>> + u32 pcap_prog;
>>> };
>>>
>>> #define csu_base ((struct csu_regs *)ZYNQMP_CSU_BASEADDR)
>>> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
>>> index 1748fec2e4..feffda54e7 100644
>>> --- a/board/xilinx/zynqmp/zynqmp.c
>>> +++ b/board/xilinx/zynqmp/zynqmp.c
>>> @@ -355,6 +355,25 @@ static int multi_boot(void)
>>> return 0;
>>> }
>>>
>>> +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ZYNQMP_RESTORE_JTAG)
>>> +static void restore_jtag(void)
>>> +{
>>> + const u32 disable_security_gate = 0xff;
>>> + const u32 setup_clock = 0x01002002;
>>> + const u32 setup_jtag = 0x3;
>>> + const u32 release_pl = 0x1;
>>> + const u32 enable_debug = 0xff;
>>> + const u32 do_reset = 0x0;
>>
>> All above should be just macros. Please put them to hardware.h
>
> you mean something like #define CSU_SETUP_CLOCK 0x01002002?
> I dont really agree with that because we'll lose the context where it
> is being used (and the context is given by the restore jtag function)
> unless we do CSU_RESTORE_JTAG_SETUP_CLOCK
> is this what you want?
Macro name is up to you but should register description.
For example yours disable_security_gate
is based on reg database _pmu_sec + _pltap_sec + _dap_sec
together.
#define CSU_JTAG_SEC_GATE_DISABLE 0x1ff
And then you can use directly:
writel(CSU_JTAG_SEC_GATE_DISABLE, _base->jtag_sec);
Thanks,
Michal
Re: [PATCH v2 5/6] efi_loader: writing AuditMode, DeployedMode
On Fri, Aug 27, 2021 at 06:09:25AM +0200, Heinrich Schuchardt wrote:
> On 8/27/21 5:05 AM, AKASHI Takahiro wrote:
> > Heinrich,
> >
> > On Thu, Aug 26, 2021 at 03:48:04PM +0200, Heinrich Schuchardt wrote:
> > > Writing variables AuditMode or Deployed Mode must update the secure boot
> > > state.
> > >
> > > Signed-off-by: Heinrich Schuchardt
> > > ---
> > > v2:
> > > correct variable name in lib/efi_loader/efi_variable_tee.c
> > > ---
> > > include/efi_variable.h| 1 +
> > > lib/efi_loader/efi_var_common.c | 2 ++
> > > lib/efi_loader/efi_variable.c | 6 +++---
> > > lib/efi_loader/efi_variable_tee.c | 4 +++-
> > > 4 files changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/efi_variable.h b/include/efi_variable.h
> > > index 2d97655e1f..0440d356bc 100644
> > > --- a/include/efi_variable.h
> > > +++ b/include/efi_variable.h
> > > @@ -12,6 +12,7 @@
> > >
> > > enum efi_auth_var_type {
> > > EFI_AUTH_VAR_NONE = 0,
> > > + EFI_AUTH_MODE,
> > > EFI_AUTH_VAR_PK,
> > > EFI_AUTH_VAR_KEK,
> > > EFI_AUTH_VAR_DB,
> > > diff --git a/lib/efi_loader/efi_var_common.c
> > > b/lib/efi_loader/efi_var_common.c
> > > index 63ad6fea9e..6fabcfe72c 100644
> > > --- a/lib/efi_loader/efi_var_common.c
> > > +++ b/lib/efi_loader/efi_var_common.c
> > > @@ -34,6 +34,8 @@ static const struct efi_auth_var_name_type name_type[]
> > > = {
> > > {u"dbx", _guid_image_security_database, EFI_AUTH_VAR_DBX},
> > > {u"dbt", _guid_image_security_database, EFI_AUTH_VAR_DBT},
> > > {u"dbr", _guid_image_security_database, EFI_AUTH_VAR_DBR},
> > > + {u"AuditMode", _global_variable_guid, EFI_AUTH_MODE},
> > > + {u"DeployedMode", _global_variable_guid, EFI_AUTH_MODE},
> > > };
> > >
> > > static bool efi_secure_boot;
> > > diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> > > index a7d305ffbc..80996d0f47 100644
> > > --- a/lib/efi_loader/efi_variable.c
> > > +++ b/lib/efi_loader/efi_variable.c
> > > @@ -247,7 +247,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name,
> > > const efi_guid_t *vendor,
> > > return EFI_WRITE_PROTECTED;
> > >
> > > if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) {
> > > - if (var_type != EFI_AUTH_VAR_NONE)
> > > + if (var_type >= EFI_AUTH_VAR_PK)
> >
> > This change is irrelevant to the purpose of this commit.
>
> Thank you for reviewing the series.
>
> EFI_AUTH_MODE is needed in the implementation of this patch and requires
> this change. But I can split the patch in two.
>
> >
> > > return EFI_WRITE_PROTECTED;
> > > }
> > >
> > > @@ -268,7 +268,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name,
> > > const efi_guid_t *vendor,
> > > return EFI_NOT_FOUND;
> > > }
> > >
> > > - if (var_type != EFI_AUTH_VAR_NONE) {
> > > + if (var_type >= EFI_AUTH_VAR_PK) {
> > > /* authentication is mandatory */
> > > if (!(attributes &
> > >
> > > EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)) {
> > > @@ -328,7 +328,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name,
> > > const efi_guid_t *vendor,
> > > if (ret != EFI_SUCCESS)
> > > return ret;
> > >
> > > - if (var_type == EFI_AUTH_VAR_PK)
> > > + if (var_type == EFI_AUTH_VAR_PK || var_type == EFI_AUTH_MODE)
> > > ret = efi_init_secure_state();
> >
> > As I said, calling efi_init_secure_state() is not a good idea.
> >
> > The scheme that I have in mind:
> > * if some event takes place, then trigger the transition.
> > * efi_transfer_secure_state() handles/take actions for the transition.
> >
> > Looking at "Figure 32-4 Secure Boot Modes", there are a couple of events
> > defined:
> > 1) Enroll PKpub
> > 2) Platform Specific PKpub Clear/Delete PKpub
> > 3) Audit := 1
> > 4) DeployedMode := 1
> > 5) Platform Specific DeployedMode Clear
> >
> > (Please note that "enroll/platform specific" operations should end up
> > modifying a relevant UEFI variable, any way.)
> >
> > So, in the case above, we should do like this:
> >if ("PK" is added/modified)
> > if (SetupMode)
> > efi_transfer_secure_state(UserMode)
> > else (AuditMode)
> > efi_transfer_secure_state(DeployedMode)
> >else if ("AuditMode" is set)
> > if (SetupMode || UserMode)
> > efi_transfer_secure_state(AuditMode)
> >else if
> > and so on
>
> Here we are in efi_set_variable_int(). efi_transfer_secure_state()
> itself calls efi_set_variable_int() repeatedly.
>
> Hence we need a way for a user to call SetVariable() with the side
> effects you described above and a way to alter the state variables
> without side effects.
>
> There are different ways to implement this:
>
> 1) As we are on a single threaded
Re: [RFC PATCH v1 2/5] arm64: dts: imx8mm: add common -binman.dtsi
Hello Marcel, Am Donnerstag, den 26.08.2021, 14:14 +0200 schrieb Marcel Ziswiler: > From: Marcel Ziswiler > > With the move to using binman to generate SPL aka u-boot-spl-ddr.bin > and > U-Boot proper aka u-boot.itb every board now covers such > configuration > in its own U-Boot specific device tree include. Introduce a new > common > imx8mm-binman.dtsi which covers the common part of that > configuration. > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/dts/imx8mm-binman.dtsi | 136 > ++ > arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 126 ++-- > arch/arm/dts/imx8mm-evk-u-boot.dtsi | 124 +--- > .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi| 123 +--- > arch/arm/dts/imx8mm-venice-u-boot.dtsi| 120 +--- > arch/arm/dts/imx8mm-verdin-u-boot.dtsi| 123 +--- > 6 files changed, 156 insertions(+), 596 deletions(-) > create mode 100644 arch/arm/dts/imx8mm-binman.dtsi > > diff --git a/arch/arm/dts/imx8mm-binman.dtsi b/arch/arm/dts/imx8mm- > binman.dtsi > new file mode 100644 > index 000..2d98c1ef577 > --- /dev/null > +++ b/arch/arm/dts/imx8mm-binman.dtsi is it really necessary to create a new binman include? I have added the nodes for imx8mp directly to the imx8mp-u-boot.dtsi. I guess you did this because not all boards are converted yet. But I have tried this when I moved binman to the common include for imx8mp. As the phycore- imx8mp was also not converted at that point. It did not hurt having the binman nodes included. At least back then. I just not like to see that the file structure diverges. If there is a good reason I'd rather also move the binman nodes for imx8mp to a imx8mp-binman.dtsi. Regards, Teresa
Re: [PATCH] arm64: zynqmp: Print the secure boot status information in EL3
On 12/08/21, Michal Simek wrote:
>
>
> On 7/22/21 1:19 PM, Jorge Ramirez-Ortiz wrote:
> > Confirm the secure boot configuration on the console.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > arch/arm/mach-zynqmp/include/mach/hardware.h | 3 ++-
> > board/xilinx/zynqmp/zynqmp.c | 16 +++-
> > 2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h
> > b/arch/arm/mach-zynqmp/include/mach/hardware.h
> > index 3776499070..3d3ffa086e 100644
> > --- a/arch/arm/mach-zynqmp/include/mach/hardware.h
> > +++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
> > @@ -139,7 +139,8 @@ struct apu_regs {
> > #define ZYNQMP_SILICON_VER_SHIFT 0
> >
> > struct csu_regs {
> > - u32 reserved0[4];
> > + u32 status;
> > + u32 reserved0[3];
> > u32 multi_boot;
> > u32 reserved1[11];
> > u32 idcode;
> > diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> > index 1748fec2e4..b7d11630d1 100644
> > --- a/board/xilinx/zynqmp/zynqmp.c
> > +++ b/board/xilinx/zynqmp/zynqmp.c
> > @@ -355,6 +355,18 @@ static int multi_boot(void)
> > return 0;
> > }
> >
> > +static void secure_boot(void)
> > +{
> > + u32 status;
> > +
> > + status = readl(_base->status);
> > + if (status & (BIT(0) | BIT(1))) {
>
> please create macros for these bits.
ok
>
> {} around are not needed.
yep
>
>
> > + printf("Secure Boot:\t%s%s\n",
> > + status & BIT(0) ? "authenticated" : "not authenticated",
> > + status & BIT(1) ? ", encrypted" : ", not encrypted");
>
> Isn't this more space efficient?
> printf("Secure Boot:\t%sauthenticated, %sencrypted\n",
> status & BIT(0) ? "" : "not ",
> status & BIT(1) ? "" : "not ");
>
> And as I see it is.
> aarch64: (for 1/1 boards) all -33.0 rodata -17.0 spl/u-boot-spl:all
> -33.0 spl/u-boot-spl:rodata -17.0 spl/u-boot-spl:text -16.0 text -16.0
> xilinx_zynqmp_virt: all -33 rodata -17 spl/u-boot-spl:all
> -33 spl/u-boot-spl:rodata -17 spl/u-boot-spl:text -16 text -16
>spl-u-boot-spl: add: 0/0, grow: 0/-1 bytes: 0/-16 (-16)
>
>
ok with me
> > + }
> > +}
> > +
> > #define PS_SYSMON_ANALOG_BUS_VAL 0x3210
> > #define PS_SYSMON_ANALOG_BUS_REG 0xFFA50914
> >
> > @@ -391,8 +403,10 @@ int board_init(void)
> > fpga_add(fpga_xilinx, );
> > #endif
> >
> > - if (current_el() == 3)
> > + if (current_el() == 3) {
> > multi_boot();
> > + secure_boot();
> > + }
>
> Please take a look at
> https://lists.denx.de/pipermail/u-boot/2021-July/456382.html
> I have changed multi_boot function a little bit.
ok
>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
>
Re: [PATCH] zynqmp: restore the jtag interface
On 12/08/21, Michal Simek wrote:
>
>
> On 7/16/21 7:16 PM, Jorge Ramirez-Ortiz wrote:
> > As a security feature, if boot.bin was configured for secure boot the
> > CSU will disable the JTAG interface on all cases.
> >
> > Some boards might rely on this interface for flashing to QSPI in which
> > case those systems might end up bricked during development.
> >
> > This commit attempts to restore the interface - if the CSU allows for it.
>
> sorry I missed this.
>
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > arch/arm/mach-zynqmp/Kconfig | 9
> > arch/arm/mach-zynqmp/include/mach/hardware.h | 23 +--
> > board/xilinx/zynqmp/zynqmp.c | 24
> > 3 files changed, 49 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
> > index 39144d654e..1e551c0020 100644
> > --- a/arch/arm/mach-zynqmp/Kconfig
> > +++ b/arch/arm/mach-zynqmp/Kconfig
> > @@ -149,6 +149,15 @@ config SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
> > Overwrite bootmode selected via boot mode pins to tell SPL what should
> > be the next boot device.
> >
> > +config SPL_ZYNQMP_RESTORE_JTAG
> > + bool "Restore JTAG"
> > + depends on SPL
> > + default n
>
> no need for default n - that's default option anyway.
ok
>
> > + help
> > +Booting SPL in secure mode causes the CSU to disable the JTAG interface
> > +even if no eFuses were burnt. This option restores the interface if
> > +possible.
>
> Indentation is weird. Please look at tabs/spaces.
ok
>
> > +
> > config ZYNQ_SDHCI_MAX_FREQ
> > default 2
> >
> > diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h
> > b/arch/arm/mach-zynqmp/include/mach/hardware.h
> > index 3776499070..58822e3f25 100644
> > --- a/arch/arm/mach-zynqmp/include/mach/hardware.h
> > +++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
> > @@ -42,17 +42,20 @@
> > struct crlapb_regs {
> > u32 reserved0[36];
> > u32 cpu_r5_ctrl; /* 0x90 */
> > - u32 reserved1[37];
> > + u32 reserved1[7];
> > + u32 dbg_lpd_ctrl; /* 0xB0 */
> > + u32 reserved2[29];
> > u32 timestamp_ref_ctrl; /* 0x128 */
> > - u32 reserved2[53];
> > + u32 reserved3[53];
> > u32 boot_mode; /* 0x200 */
> > - u32 reserved3_0[7];
> > + u32 reserved4_0[7];
> > u32 reset_reason; /* 0x220 */
> > - u32 reserved3_1[6];
> > + u32 reserved4_1[6];
> > u32 rst_lpd_top; /* 0x23C */
> > - u32 reserved4[4];
> > + u32 rst_lpd_dbg; /* 0x240 */
> > + u32 reserved5[3];
> > u32 boot_pin_ctrl; /* 0x250 */
> > - u32 reserved5[21];
> > + u32 reserved6[21];
> > };
> >
> > #define crlapb_base ((struct crlapb_regs *)ZYNQMP_CRL_APB_BASEADDR)
> > @@ -141,9 +144,15 @@ struct apu_regs {
> > struct csu_regs {
> > u32 reserved0[4];
> > u32 multi_boot;
> > - u32 reserved1[11];
> > + u32 reserved1[7];
> > + u32 jtag_chain_status_wr;
> > + u32 jtag_chain_status;
> > + u32 jtag_sec;
> > + u32 jtag_dap_cfg;
> > u32 idcode;
> > u32 version;
> > + u32 reserved2[3055];
> > + u32 pcap_prog;
> > };
> >
> > #define csu_base ((struct csu_regs *)ZYNQMP_CSU_BASEADDR)
> > diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> > index 1748fec2e4..feffda54e7 100644
> > --- a/board/xilinx/zynqmp/zynqmp.c
> > +++ b/board/xilinx/zynqmp/zynqmp.c
> > @@ -355,6 +355,25 @@ static int multi_boot(void)
> > return 0;
> > }
> >
> > +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ZYNQMP_RESTORE_JTAG)
> > +static void restore_jtag(void)
> > +{
> > + const u32 disable_security_gate = 0xff;
> > + const u32 setup_clock = 0x01002002;
> > + const u32 setup_jtag = 0x3;
> > + const u32 release_pl = 0x1;
> > + const u32 enable_debug = 0xff;
> > + const u32 do_reset = 0x0;
>
> All above should be just macros. Please put them to hardware.h
you mean something like #define CSU_SETUP_CLOCK 0x01002002?
I dont really agree with that because we'll lose the context where it
is being used (and the context is given by the restore jtag function)
unless we do CSU_RESTORE_JTAG_SETUP_CLOCK
is this what you want?
>
> > +
> > + writel(disable_security_gate, _base->jtag_sec);
> > + writel(enable_debug, _base->jtag_dap_cfg);
> > + writel(setup_jtag, _base->jtag_chain_status_wr);
> > + writel(setup_clock, _base->dbg_lpd_ctrl);
> > + writel(do_reset, _base->rst_lpd_dbg);
> > + writel(release_pl, _base->pcap_prog);
> > +}
> > +#endif
> > +
> > #define PS_SYSMON_ANALOG_BUS_VAL 0x3210
> > #define PS_SYSMON_ANALOG_BUS_REG 0xFFA50914
> >
> > @@ -374,6 +393,11 @@ int board_init(void)
> > zynqmp_pmufw_load_config_object(zynqmp_pm_cfg_obj,
> > zynqmp_pm_cfg_obj_size);
> > printf("Silicon version:\t%d\n", zynqmp_get_silicon_version());
> > +
> > +#if defined(CONFIG_SPL_ZYNQMP_RESTORE_JTAG)
> > + /* the CSU disables the JTAG
Re: [PATCH] loadb: Properly indicate aborted kermit transfer
On Friday 06 August 2021 18:37:15 Pali Rohár wrote:
> On Friday 06 August 2021 18:23:49 Heinrich Schuchardt wrote:
> > On 8/6/21 6:07 PM, Pali Rohár wrote:
> > > When k_recv() returns zero it indicates that kermit transfer was aborted.
> > > Function do_load_serial_bin() (caller of load_serial_bin()) interprets
> > > value ~0 as aborted transfer, so properly propagates information about
> > > aborted transfer from k_recv() to do_load_serial_bin().
> > >
> > > Signed-off-by: Pali Rohár
> > > ---
> > > cmd/load.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/cmd/load.c b/cmd/load.c
> > > index 462340ad2cde..249ebd4ae078 100644
> > > --- a/cmd/load.c
> > > +++ b/cmd/load.c
> > > @@ -551,6 +551,9 @@ static ulong load_serial_bin(ulong offset)
> > > udelay(1000);
> > > }
> > >
> > > + if (size == 0)
> > > + return ~0; /* Download aborted */
> > > +
> >
> > I cannot see where k_recv() sets the return value to 0 if the download
> > is interrupted after transferring the first packages.
>
> I must admit that I have not decoded whole kermit protocol. But by
> testing show that ETX (CTRL+C) is transferred when I abort kermit
> upload. And this ETX is handled in switch(getchar()) where is return 0;
> and also after sending more kermit packets (not only at beginning).
So in any case, this patch fixes handling of kermit termination by
pressing CTRL+C key. Simple test is to run 'loadb' and then press
CTRL+C. Other option for testing is to run 'loadb' then start kermit
transfer by ckermit, terminate ckermit transfer and then press CTRL+C.
And this patch fixes also handling of this scenario.
> > So isn't some logic in k_recv() missing to identify an abort?
>
> This is a good question. I would guess that "yes". But to answer it I
> need to fully decode kermit protocol...
>
> But at least at this one place it really returns zero on aborted file
> transfer.
>
> > Best regards
> >
> > Heinrich
> >
> > > flush_cache(offset, size);
> > >
> > > printf("## Total Size = 0x%08x = %d Bytes\n", size, size);
> > >
Re: [PATCH 0/7] xyz-modem: Fix cancelling and closing transfers
On Tuesday 03 August 2021 16:28:37 Pali Rohár wrote: > This patch series fixes U-Boot crash during cancellation of x/y-modem > transfers and contains other various fixes related to finishing > transfers. Hello! Could you review this patch series? I have already answered all questions / comments... > Pali Rohár (7): > xyz-modem: Fix crash after cancelling transfer > xyz-modem: Fix x-modem "xyzModem_eof error" at the end of file > xyz-modem: Put xyzModem_stream_close debug diagnostic message into > ZM_DEBUG() > xyz-modem: Close stream after processing/sending terminate sequence > xyz-modem: Properly abort/terminate transfer on error > xyz-modem: Show information about finished transfer > xyz-modem: Allow to cancel transfer also by CTRL+C > > cmd/load.c| 32 ++-- > common/xyzModem.c | 12 > 2 files changed, 38 insertions(+), 6 deletions(-) > > -- > 2.20.1 >
Re: [PATCH u-boot-marvell 28/29] doc/kwboot.1: Update man page
On Friday 27 August 2021 10:13:01 Pali Rohár wrote: > On Friday 27 August 2021 13:37:54 Chris Packham wrote: > > On Thu, Aug 26, 2021 at 1:46 AM Marek Behún wrote: > > > > > > Update man page for the kwboot utility. > > > > > > Signed-off-by: Marek Behún > > > --- > > > doc/kwboot.1 | 58 ++-- > > > 1 file changed, 38 insertions(+), 20 deletions(-) > > > > > > diff --git a/doc/kwboot.1 b/doc/kwboot.1 > > > index 1e9ca268f7..cf113b8b27 100644 > > > --- a/doc/kwboot.1 > > > +++ b/doc/kwboot.1 > > > @@ -1,21 +1,22 @@ > > > -.TH KWBOOT 1 "2012-05-19" > > > +.TH KWBOOT 1 "2021-08-25" > > > > > > .SH NAME > > > -kwboot \- Boot Marvell Kirkwood SoCs over a serial link. > > > +kwboot \- Boot Marvell Kirkwood (and others 32-bit) SoCs over a serial > > > link. > > > .SH SYNOPSIS > > > .B kwboot > > > .RB [ "-b \fIimage\fP" ] > > > -.RB [ "-p" ] > > > .RB [ "-t" ] > > > > I notice there's no mention of -d might be good to add it while we're here. > > Option -d is broken and does not work. So not mentioning it here is a > good idea. Maybe I could look at it and try to fix in future... Anyway, it looks like that A385 bootrom has bugs in debug console and so -d is on this SoC unusable. When I enter into debug mode, boorom somehow does not send output from (debug) commands over UART. But it sends ECHO over UART... > > > .RB [ "-B \fIbaudrate\fP" ] > > > .RB \fITTY\fP > > > .SH "DESCRIPTION" > > > > > > -The \fBmkimage\fP program boots boards based on Marvell's Kirkwood > > > -platform over their integrated UART. Boot image files will typically > > > +The \fBkwboot\fP program boots boards based on Marvell's 32-bit > > > +platforms including Orion, Kirkwood, Dove, Discovery, AXP, A37x, A38x > > > +and A39x over their integrated UART. Boot image files will typically > > > contain a second stage boot loader, such as U-Boot. The image file > > > must conform to Marvell's BootROM firmware image format > > > -(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP. > > > +(\fIkwbimage v0\fP or \fIv1\fP), created using a tool such as > > > +\fBmkimage\fP. > > > > > > Following power-up or a system reset, system BootROM code polls the > > > UART for a brief period of time, sensing a handshake message which > > > @@ -36,25 +37,23 @@ by the second-stage loader. > > > Handshake; then upload file \fIimage\fP over \fITTY\fP. > > > > > > Note that for the encapsulated boot code to be executed, \fIimage\fP > > > -must be of type "UART boot" (0x69). Boot images of different types, > > > -such as backup images of vendor firmware downloaded from flash memory > > > -(type 0x8B), will not work (or not as expected). See \fB-p\fP for a > > > -workaround. > > > +must be of type "UART boot" (0x69). The \fBkwboot\fP program changes > > > +this type automatically, unless the \fIimage\fP is signed, in which > > > +case it cannot be changed. > > > > > > This mode writes handshake status and upload progress indication to > > > -stdout. > > > +stdout. It is possible that \fIimage\fP contains an optional binary > > > +code in it's header which may also print some output via UART (for > > > +example U-Boot SPL does this). In such a case, this output is also > > > +written to stdout after the header is sent. > > > > > > .TP > > > .BI "\-p" > > > -In combination with \fB-b\fP, patches the header in \fIimage\fP prior > > > -to upload, to "UART boot" type. > > > +Obsolete. Does nothing. > > > > > > -This option attempts on-the-fly conversion of some none-UART image > > > -types, such as images which were originally formatted to be stored in > > > -flash memory. > > > - > > > -Conversion is performed in memory. The contents of \fIimage\fP will > > > -not be altered. > > > +In the past, when this option was used, the program patched the header > > > +in the image prior upload, to "UART boot" type. This is now done by > > > +default. > > > > > > .TP > > > .BI "\-t" > > > @@ -69,7 +68,22 @@ after receiving 'ctrl-\\' followed by 'c' from console > > > input. > > > > > > .TP > > > .BI "\-B \fIbaudrate\fP" > > > -Adjust the baud rate on \fITTY\fP. Default rate is 115200. > > > +If used in combination with \fB-b\fP, inject into the image header > > > +code that changes baud rate to \fIbaudrate\fP after uploading image > > > +header, and code that changes the baud rate back to the default > > > +(115200 Bd) before executing payload, and also adjust the baud rate > > > +on \fITTY\fP correspondingly. This can make the upload significantly > > > +faster. > > > + > > > +If used in combination with \fB-t\fP, adjust the baud rate to > > > +\fIbaudrate\fP on \fITTY\fP before starting terminal. > > > + > > > +If both \fB-b\fP and \fB-t\fP are used, the baud rate is changed > > > +back to 115200 after the upload. > > > + > > > +Tested values for \fIbaudrate\fP for Armada 38x include: 115200, > > > +230400, 460800, 50, 576000, 921600, 100, 1152000, 150, > > > +200, 250,
Re: [PATCH u-boot-marvell 00/29] kwboot higher baudrate
On Friday 27 August 2021 14:45:07 Chris Packham wrote: > On Fri, Aug 27, 2021 at 1:39 PM Marek Behún wrote: > > > > On Fri, 27 Aug 2021 13:16:25 +1200 > > Chris Packham wrote: > > > > > On Thu, Aug 26, 2021 at 1:46 AM Marek Behún wrote: > > > > > > > > Hello Stefan and others, > > > > > > > > this series adds support for booting Marvell platforms via UART (those > > > > bootable with kwboot) at higher baudrates. > > > > > > > > Tested on Turris Omnia up to 5.15 MBd, which is 44x faster than > > > > 115200 Bd. > > > > > > > > The user can direct kwboot to use higher baudrate via the -B option. > > > > (BTW this option was there before but did not work with the -b option.) > > > > > > > > Only the payload part of the KWB image is uploaded at this higher > > > > baudrate. The header part is still uploaded at 115200 Bd, since the code > > > > that changes baudrate is injected into header as a binary extension. > > > > (The payload part makes up majority of the binary, though. On Turris > > > > Omnia the payload currently makes ~87%.) > > > > > > > > The series also contains various other fixes, refactors and improvements > > > > of the code, upon which the main change is done. > > > > > > > > Marek & Pali > > > > > > What tree/sha is this series based on. I've tried to apply them out of > > > patchwork and it fails at "tools: kwbimage: Simplify iteration over > > > version 1 optional headers" > > > > Applies to master and to u-boot-marvell, but you need the 6 > > additional patches for kwbimage/kwboot that are on patchwork > > but not yet applied to u-boot-marvell: > > https://patchwork.ozlabs.org/project/uboot/list/?series=257577 > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210817050320.11983-1-xypron.g...@gmx.de/ > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210817051158.13283-1-xypron.g...@gmx.de/ > > > > Also some more fixes were yet needed, which I will sent in v2. > > > > To make it simpler for you I pushed v2 into > > https://gitlab.nic.cz/turris/turris-omnia-uboot > > branch > > kwboot-baudrate-improvements > > > > Thanks. I took it for a spin on the x530. In terms of regression > testing the default behaviour is good. > > The higher speed settings weren't so good. I started with 3125000 and > that doesn't get onto the 2nd part of the download, same for 1152000 > and 400 (I stopped trying higher speeds at that point). Using > 230400 and 460800 it does make it through the 2nd part of the download > but when I go back on to the console it appears to be unresponsive. > > All of this could be down to the serial hardware in my system (the > x530 uses a real RS232 interface not a TTL) and I have had problems > with the MosChip USB-Serial adapter in my test PC in the past. I > wouldn't reject this series based on me not being able to get it > working, the important thing for me is the default behaviour at the > standard baudrate which is good. You need to choose speed which is supported by both armada board and your computer. Armada boards support speeds calculated by formula: speed = TCLK / ( 16 * d ) where d is 16-bit integer number. So for A385 board with 250 MHz TCLK you can set speeds from above formula +/- 30%. Tested were: 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 50, 576000, 921600, 100, 1152000, 150, 200, 250, 3125000, 400, 515. If you have a board with different TCLK you obviously need to use different baudrates. But it is possible that your computer does not support these speeds. E.g. more chinese USB TTL adapters have base clock 3 MHz and so they could not support 315 or 250 speeds. > One usability thing I'd like to see is retaining support for -t (I use > that quite a lot when recovering a system). Ideally we'd still be able > to drop into the console at 115200 once the download is complete. -t is fully supported, I'm using -t with -B 515 and it is working fine. After successful download, speed on both A38x and host computer is changed back to the value 115200.
Re: [PATCH u-boot-marvell 28/29] doc/kwboot.1: Update man page
On Friday 27 August 2021 13:37:54 Chris Packham wrote: > On Thu, Aug 26, 2021 at 1:46 AM Marek Behún wrote: > > > > Update man page for the kwboot utility. > > > > Signed-off-by: Marek Behún > > --- > > doc/kwboot.1 | 58 ++-- > > 1 file changed, 38 insertions(+), 20 deletions(-) > > > > diff --git a/doc/kwboot.1 b/doc/kwboot.1 > > index 1e9ca268f7..cf113b8b27 100644 > > --- a/doc/kwboot.1 > > +++ b/doc/kwboot.1 > > @@ -1,21 +1,22 @@ > > -.TH KWBOOT 1 "2012-05-19" > > +.TH KWBOOT 1 "2021-08-25" > > > > .SH NAME > > -kwboot \- Boot Marvell Kirkwood SoCs over a serial link. > > +kwboot \- Boot Marvell Kirkwood (and others 32-bit) SoCs over a serial > > link. > > .SH SYNOPSIS > > .B kwboot > > .RB [ "-b \fIimage\fP" ] > > -.RB [ "-p" ] > > .RB [ "-t" ] > > I notice there's no mention of -d might be good to add it while we're here. Option -d is broken and does not work. So not mentioning it here is a good idea. Maybe I could look at it and try to fix in future... > > .RB [ "-B \fIbaudrate\fP" ] > > .RB \fITTY\fP > > .SH "DESCRIPTION" > > > > -The \fBmkimage\fP program boots boards based on Marvell's Kirkwood > > -platform over their integrated UART. Boot image files will typically > > +The \fBkwboot\fP program boots boards based on Marvell's 32-bit > > +platforms including Orion, Kirkwood, Dove, Discovery, AXP, A37x, A38x > > +and A39x over their integrated UART. Boot image files will typically > > contain a second stage boot loader, such as U-Boot. The image file > > must conform to Marvell's BootROM firmware image format > > -(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP. > > +(\fIkwbimage v0\fP or \fIv1\fP), created using a tool such as > > +\fBmkimage\fP. > > > > Following power-up or a system reset, system BootROM code polls the > > UART for a brief period of time, sensing a handshake message which > > @@ -36,25 +37,23 @@ by the second-stage loader. > > Handshake; then upload file \fIimage\fP over \fITTY\fP. > > > > Note that for the encapsulated boot code to be executed, \fIimage\fP > > -must be of type "UART boot" (0x69). Boot images of different types, > > -such as backup images of vendor firmware downloaded from flash memory > > -(type 0x8B), will not work (or not as expected). See \fB-p\fP for a > > -workaround. > > +must be of type "UART boot" (0x69). The \fBkwboot\fP program changes > > +this type automatically, unless the \fIimage\fP is signed, in which > > +case it cannot be changed. > > > > This mode writes handshake status and upload progress indication to > > -stdout. > > +stdout. It is possible that \fIimage\fP contains an optional binary > > +code in it's header which may also print some output via UART (for > > +example U-Boot SPL does this). In such a case, this output is also > > +written to stdout after the header is sent. > > > > .TP > > .BI "\-p" > > -In combination with \fB-b\fP, patches the header in \fIimage\fP prior > > -to upload, to "UART boot" type. > > +Obsolete. Does nothing. > > > > -This option attempts on-the-fly conversion of some none-UART image > > -types, such as images which were originally formatted to be stored in > > -flash memory. > > - > > -Conversion is performed in memory. The contents of \fIimage\fP will > > -not be altered. > > +In the past, when this option was used, the program patched the header > > +in the image prior upload, to "UART boot" type. This is now done by > > +default. > > > > .TP > > .BI "\-t" > > @@ -69,7 +68,22 @@ after receiving 'ctrl-\\' followed by 'c' from console > > input. > > > > .TP > > .BI "\-B \fIbaudrate\fP" > > -Adjust the baud rate on \fITTY\fP. Default rate is 115200. > > +If used in combination with \fB-b\fP, inject into the image header > > +code that changes baud rate to \fIbaudrate\fP after uploading image > > +header, and code that changes the baud rate back to the default > > +(115200 Bd) before executing payload, and also adjust the baud rate > > +on \fITTY\fP correspondingly. This can make the upload significantly > > +faster. > > + > > +If used in combination with \fB-t\fP, adjust the baud rate to > > +\fIbaudrate\fP on \fITTY\fP before starting terminal. > > + > > +If both \fB-b\fP and \fB-t\fP are used, the baud rate is changed > > +back to 115200 after the upload. > > + > > +Tested values for \fIbaudrate\fP for Armada 38x include: 115200, > > +230400, 460800, 50, 576000, 921600, 100, 1152000, 150, > > +200, 250, 3125000, 400 and 515. > > > > .SH "SEE ALSO" > > .PP > > @@ -82,3 +96,7 @@ Daniel Stodden > > Luka Perkov > > .br > > David Purdy > > +.br > > +Pali Rohár > > +.br > > +Marek Behún > > -- > > 2.31.1 > >
Re: [PATCH] xilinx: zynqmp: Enable stack relocation to DDR
út 24. 8. 2021 v 15:25 odesílatel Michal Simek napsal: > > There is no space in OCM for SPL stack because the space in OCM is occupied > by TF-A. That's why move relocate stack to DDR to 0x1800 address > and also enable SPL_SIZE_LIMIT not to be more then 0xfffea000 which is > default address for TFA. > > It is good to summarize current DDR usage in SPL flow. > 0-0x8 is used for BSS > (CONFIG_SPL_BSS_START_ADDR, CONFIG_SPL_BSS_MAX_SIZE) > 0x10 is used for DTB passing address > (CONFIG_XILINX_OF_BOARD_DTB_ADDR) > 0x17fffe70 - CONFIG_SPL_STACK_R_ADDR - is used for GD > 0x1800 is used for SPL stack > (CONFIG_SPL_STACK_R_ADDR) > 0x2000-0x2100 is used for SPL malloc area > (CONFIG_SYS_SPL_MALLOC_START, CONFIG_SYS_SPL_MALLOC_SIZE) > > Signed-off-by: Michal Simek > --- > > configs/xilinx_zynqmp_virt_defconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/configs/xilinx_zynqmp_virt_defconfig > b/configs/xilinx_zynqmp_virt_defconfig > index 8d82fe918a60..00f7133d775a 100644 > --- a/configs/xilinx_zynqmp_virt_defconfig > +++ b/configs/xilinx_zynqmp_virt_defconfig > @@ -8,6 +8,9 @@ CONFIG_SYS_MEMTEST_END=0x1000 > CONFIG_SYS_SPI_U_BOOT_OFFS=0x10 > CONFIG_DM_GPIO=y > CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu100-revC" > +CONFIG_SPL_STACK_R_ADDR=0x1800 > +CONFIG_SPL_SIZE_LIMIT=0x2a000 > +CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x0 > CONFIG_SPL=y > CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI_SUPPORT=y > @@ -28,6 +31,7 @@ CONFIG_USE_PREBOOT=y > CONFIG_PREBOOT="run scsi_init;usb start" > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_BOARD_EARLY_INIT_R=y > +CONFIG_SPL_STACK_R=y > CONFIG_SPL_FPGA=y > CONFIG_SPL_OS_BOOT=y > CONFIG_SPL_RAM_SUPPORT=y > -- > 2.33.0 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] xilinx: zynqmp: Update descriptions for u-boot.its
po 23. 8. 2021 v 8:43 odesílatel Michal Simek napsal:
>
> Use TF-A instead of ATF in description. And update generic description with
> removing ATF because also configurations without it are supported.
>
> Signed-off-by: Michal Simek
> ---
>
> arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> index feb3a6260a34..72a8a3eb7714 100755
> --- a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> @@ -57,7 +57,7 @@ cat << __HEADER_EOF
> /dts-v1/;
>
> / {
> - description = "Configuration to load ATF before U-Boot";
> + description = "Configuration for Xilinx ZynqMP SoC";
>
> images {
> uboot {
> @@ -78,7 +78,7 @@ __HEADER_EOF
> if [ -f $BL31 ]; then
> cat << __ATF
> atf {
> - description = "ARM Trusted Firmware";
> + description = "Trusted Firmware-A";
> data = /incbin/("$BL31");
> type = "firmware";
> os = "arm-trusted-firmware";
> --
> 2.33.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 00/10] xilinx: Add support for DTB reselection
po 23. 8. 2021 v 9:37 odesílatel Michal Simek napsal: > > Hi, > > this series add support for board or board+cc runtime DT selection. EEPROM > memory is read and based on that decoded if this is legacy/fru based format > and proper DTB is used. There is a need to have all DTBs 64bit aligned. If > you don't have it you will end up in exception. But one patch in this > series is trying to detect it and panic before you reach it to let you know > what's wrong. > > Enforcing mkimage/dtb alignment is done based on CONFIG_PHYS_64BIT and > affects all 64bit systems but it is also not wrong for them to be properly > aligned. > > Thanks, > Michal > > Changes in v2: > - Update subject and commit message > - Enable 64bit alignment for all - reported by Andre > - Update subject and commit message > - Enable it for all (not just 64bit systems) > - Update if condition for MULTI_DTB > - call fru_capture in non DEBUG mode > - Show detected name as standard message to see what has been chosen > > Michal Simek (10): > xilinx: fru: Replace spaces with \0 in detected name > xilinx: Use variable for passing board_name > xilinx: common: Change board_info[] handling > xilinx: common: Free allocated structure > xilinx: Add support for generic board detection > xilinx: zynqmp: Check that DT is 64bit aligned > Makefile: Align fit-dtb.blob and u-boot.itb by 64bits > arm64: dts: Make sure that all DTBs are 64bit aligned > xilinx: zynqmp: Generate different u-boot.itb for MULTI_DTB_FIT > xilinx: common: Enabling generic function for DT reselection > > Makefile| 3 + > arch/arm/dts/Makefile | 2 +- > arch/arm/dts/zynqmp-sm-k26-revA.dts | 3 + > arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 47 +++ > board/xilinx/common/board.c | 158 +++- > board/xilinx/zynqmp/zynqmp.c| 3 + > 6 files changed, 186 insertions(+), 30 deletions(-) > > -- > 2.33.0 > This should have v2 in subject but it has changes in v2. Simon: Can we extend patman to capture this configuration where you have changes for newer revision then revision of the whole series? Anyway applied to my tree. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] efi_loader: Omit memory with "no-map" when returning memory map.
efi_reserve_memory() states that memory marked with "no-map" shall not
be accessed by the UEFI payload. Make sure efi_get_memory_map() honors
this.
This helps the case when booting vexpress_ca9x4 under QEMU. Because
the kernel wants to use an address in the lowest 128MiB of the range,
but this range is reserved with "no-map", the kernel complains that it
can not allocate the low memory it needs. In reality the actual usable
memory starts much higher, which is reflected correctly in the memory
map after this fix.
Signed-off-by: Kristian Amlie
---
lib/efi_loader/efi_memory.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index f4acbee4f9..7f8543143a 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -646,8 +646,16 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
provided_map_size = *memory_map_size;
- list_for_each(lhandle, _mem)
+ list_for_each(lhandle, _mem) {
+ struct efi_mem_list *lmem;
+
+ lmem = list_entry(lhandle, struct efi_mem_list, link);
+
+ if (lmem->desc.type == EFI_RESERVED_MEMORY_TYPE)
+ continue;
+
map_entries++;
+ }
map_size = map_entries * sizeof(struct efi_mem_desc);
@@ -672,6 +680,10 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
struct efi_mem_list *lmem;
lmem = list_entry(lhandle, struct efi_mem_list, link);
+
+ if (lmem->desc.type == EFI_RESERVED_MEMORY_TYPE)
+ continue;
+
*memory_map = lmem->desc;
memory_map--;
}
--
2.17.1
efi_loader: Omit memory with "no-map" when returning memory
Since I'm not very experienced with EFI internals, this is part patch submission, part question. Does it seem correct? At least according to comments I could find in the code, it should work like this. See patch. -- Kristian
[PATCH] Kconfig: Remove all default n/no options
default n/no doesn't need to be specified. It is default option anyway. Signed-off-by: Michal Simek --- Kconfig | 6 -- api/Kconfig | 1 - arch/arc/Kconfig | 5 - arch/arm/Kconfig | 4 arch/arm/cpu/armv8/Kconfig| 3 --- arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 1 - arch/arm/mach-at91/Kconfig| 1 - arch/arm/mach-imx/mx6/Kconfig | 1 - arch/arm/mach-mediatek/Kconfig| 1 - arch/arm/mach-mvebu/Kconfig | 3 --- arch/arm/mach-rmobile/Kconfig.32 | 1 - arch/arm/mach-stm32mp/Kconfig | 1 - arch/arm/mach-sunxi/Kconfig | 13 - arch/mips/Kconfig | 9 - arch/mips/mach-mtmips/mt7628/Kconfig | 1 - arch/nds32/Kconfig| 2 -- arch/riscv/Kconfig| 2 -- arch/x86/Kconfig | 7 --- arch/x86/cpu/ivybridge/Kconfig| 2 -- arch/xtensa/Kconfig | 2 -- board/beacon/imx8mn/Kconfig | 2 -- board/congatec/common/Kconfig | 3 --- board/freescale/common/Kconfig| 1 - board/freescale/imx8mn_evk/Kconfig| 1 - board/freescale/ls1028a/Kconfig | 2 -- board/freescale/ls1043ardb/Kconfig| 1 - board/freescale/t208xrdb/Kconfig | 1 - board/keymile/km_arm/Kconfig | 6 -- board/toradex/apalis_imx6/Kconfig | 1 - cmd/Kconfig | 9 - cmd/mvebu/Kconfig | 1 - common/Kconfig| 5 - common/Kconfig.boot | 11 --- common/spl/Kconfig| 7 --- drivers/block/Kconfig | 2 -- drivers/core/Kconfig | 4 drivers/dfu/Kconfig | 1 - drivers/dma/ti/Kconfig| 1 - drivers/fastboot/Kconfig | 1 - drivers/gpio/Kconfig | 10 -- drivers/i2c/Kconfig | 2 -- drivers/mmc/Kconfig | 5 - drivers/mtd/nand/raw/Kconfig | 3 --- drivers/mtd/spi/Kconfig | 2 -- drivers/mtd/ubi/Kconfig | 1 - drivers/net/Kconfig | 3 --- drivers/net/phy/Kconfig | 3 --- drivers/pci/Kconfig | 8 drivers/phy/marvell/Kconfig | 1 - drivers/power/Kconfig | 2 -- drivers/ram/aspeed/Kconfig| 3 --- drivers/ram/octeon/Kconfig| 2 -- drivers/ram/stm32mp1/Kconfig | 1 - drivers/reboot-mode/Kconfig | 3 --- drivers/rng/Kconfig | 3 --- drivers/serial/Kconfig| 2 -- drivers/usb/host/Kconfig | 4 drivers/usb/musb-new/Kconfig | 2 -- drivers/video/Kconfig | 13 - drivers/w1/Kconfig| 3 --- env/Kconfig | 3 --- lib/Kconfig | 3 --- lib/efi_loader/Kconfig| 10 -- lib/optee/Kconfig | 1 - net/Kconfig | 1 - 65 files changed, 220 deletions(-) diff --git a/Kconfig b/Kconfig index a6c42b902f7d..25465583a9d9 100644 --- a/Kconfig +++ b/Kconfig @@ -83,7 +83,6 @@ config CC_OPTIMIZE_FOR_SIZE config OPTIMIZE_INLINING bool "Allow compiler to uninline functions marked 'inline' in full U-Boot" - default n help This option determines if U-Boot forces gcc to inline the functions developers have marked 'inline'. Doing so takes away freedom from gcc to @@ -93,7 +92,6 @@ config OPTIMIZE_INLINING config SPL_OPTIMIZE_INLINING bool "Allow compiler to uninline functions marked 'inline' in SPL" depends on SPL - default n help This option determines if U-Boot forces gcc to inline the functions developers have marked 'inline'. Doing so takes away freedom from gcc to @@ -106,7 +104,6 @@ config ARCH_SUPPORTS_LTO config LTO bool "Enable Link Time Optimizations" depends on ARCH_SUPPORTS_LTO - default n help This option enables Link Time Optimization (LTO), a mechanism which allows the compiler to optimize between different compilation units. @@ -127,7 +124,6 @@ config LTO config TPL_OPTIMIZE_INLINING bool "Allow compiler to uninline functions marked 'inline' in TPL" depends on TPL - default n help This option determines if U-Boot forces gcc to inline the functions developers have marked
Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()
Hi Tom, On 17.08.21 14:35, Tom Rini wrote: Getting back to this to hopefully get this decided: It seems that we (most of us?) agree on this change, that wdt_stop_all() shall be changed to return an error code and the caller can decide what to do with it? If yes, then Rasmus, could you please re-spin this patchset accordingly and send v6? Yes, please and thanks. Tom, would you like me to push this patchset in at this stage (rc2), or better defer to the next merge window? Thanks, Stefan
