[PATCH 6/6] arm: a37xx: pci: Increase PCIe MEM size from 16 MiB to 128 MiB - 64 KiB
For some configurations with more PCIe cards and PCIe bridges 16 MiB of PCIe MEM space is not enough. Since TF-A already allocates a 128 MiB CPU window for PCIe and IO port space is only 64 KiB in total, use all the remaining space for PCIe MEM. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- arch/arm/dts/armada-37xx.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi index b7d325b40577..f85fe38ad11c 100644 --- a/arch/arm/dts/armada-37xx.dtsi +++ b/arch/arm/dts/armada-37xx.dtsi @@ -333,9 +333,9 @@ bus-range = <0 0xff>; ranges = <0x8200 0 0xe800 -0 0xe800 0 0x100 /* Port 0 MEM */ -0x8100 0 0xe900 -0 0xe900 0 0x1>; /* Port 0 IO*/ +0 0xe800 0 0xefff /* Port 0 MEM */ +0x8100 0 0xefff +0 0xefff 0 0x1>; /* Port 0 IO*/ }; }; }; -- 2.20.1
[PATCH 3/6] arm: a37xx: pci: Fix DT compatible string to Linux' DT compatible
Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
arch/arm/dts/armada-37xx.dtsi | 2 +-
drivers/pci/pci-aardvark.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index a1052add0cca..b7d325b40577 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -323,7 +323,7 @@
};
pcie0: pcie@d007 {
- compatible = "marvell,armada-37xx-pcie";
+ compatible = "marvell,armada-3700-pcie";
reg = <0 0xd007 0 0x2>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index ee81b2ea46d3..ae1a20551fed 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -717,7 +717,7 @@ static const struct dm_pci_ops pcie_advk_ops = {
};
static const struct udevice_id pcie_advk_ids[] = {
- { .compatible = "marvell,armada-37xx-pcie" },
+ { .compatible = "marvell,armada-3700-pcie" },
{ }
};
--
2.20.1
[PATCH 5/6] arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function
Current version of this function uses a lot of incorrect assumptions about
the `ranges` DT property:
* parent(#address-cells) == 2
* #size-cells == 2
* number of entries == 2
* address size of first entry == 0x100
* second child address entry == base + 0x100
Trying to increase PCIe MEM space to more than 16 MiB leads to an overlap
with PCIe IO space, and trying to define additional MEM space (as a third
entry in the `ranges` DT property) causes U-Boot to crash when booting the
kernel.
## Flattened Device Tree blob at 04f0
Booting using the fdt blob at 0x4f0
Loading Device Tree to 1fb01000, end 1fb08f12 ... OK
ERROR: board-specific fdt fixup failed:
- must RESET the board to recover.
Fix a3700_fdt_fix_pcie_regions() to properly parse and update all addresses
in the `ranges` property according to
https://elinux.org/Device_Tree_Usage#PCI_Address_Translation
Now it is possible to increase PCIe MEM space from 16MiB to maximal value
of 128MiB - 64KiB.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
Fixes: cb2ddb291ee6 ("arm64: mvebu: a37xx: add device-tree fixer for PCIe
regions")
---
arch/arm/mach-mvebu/armada3700/cpu.c | 74 ++--
1 file changed, 60 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
b/arch/arm/mach-mvebu/armada3700/cpu.c
index 1abac7c9a47a..9aec0ce9a430 100644
--- a/arch/arm/mach-mvebu/armada3700/cpu.c
+++ b/arch/arm/mach-mvebu/armada3700/cpu.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -280,36 +281,81 @@ static u32 find_pcie_window_base(void)
return -1;
}
+static int fdt_setprop_inplace_u32_partial(void *blob, int node,
+ const char *name,
+ u32 idx, u32 val)
+{
+ val = cpu_to_fdt32(val);
+
+ return fdt_setprop_inplace_namelen_partial(blob, node, name,
+ strlen(name),
+ idx * sizeof(u32),
+ &val, sizeof(u32));
+}
+
int a3700_fdt_fix_pcie_regions(void *blob)
{
- u32 new_ranges[14], base;
+ int acells, pacells, scells;
+ u32 base, fix_offset;
const u32 *ranges;
- int node, len;
+ int node, pnode;
+ int ret, i, len;
+
+ base = find_pcie_window_base();
+ if (base == -1)
+ return -ENOENT;
node = fdt_node_offset_by_compatible(blob, -1,
"marvell,armada-3700-pcie");
if (node < 0)
return node;
ranges = fdt_getprop(blob, node, "ranges", &len);
- if (!ranges)
+ if (!ranges || len % sizeof(u32))
return -ENOENT;
- if (len != sizeof(new_ranges))
- return -EINVAL;
-
- memcpy(new_ranges, ranges, len);
+ /*
+* The "ranges" property is an array of
+* {}
+*
+* All 3 elements can span a diffent number of cells. Fetch their sizes.
+*/
+ pnode = fdt_parent_offset(blob, node);
+ acells = fdt_address_cells(blob, node);
+ pacells = fdt_address_cells(blob, pnode);
+ scells = fdt_size_cells(blob, node);
- base = find_pcie_window_base();
- if (base == -1)
+ /* Child PCI addresses always use 3 cells */
+ if (acells != 3)
return -ENOENT;
- new_ranges[2] = cpu_to_fdt32(base);
- new_ranges[4] = new_ranges[2];
+ /* Calculate fixup offset from first child address (in last cell) */
+ fix_offset = base - fdt32_to_cpu(ranges[2]);
- new_ranges[9] = cpu_to_fdt32(base + 0x100);
- new_ranges[11] = new_ranges[9];
+ /*
+* Fix address (last cell) of each child address and each parent
+* address
+*/
+ for (i = 0; i < len / sizeof(u32); i += acells + pacells + scells) {
+ int idx;
+
+ /* fix child address */
+ idx = i + acells - 1;
+ ret = fdt_setprop_inplace_u32_partial(blob, node, "ranges", idx,
+ fdt32_to_cpu(ranges[idx])
+
+ fix_offset);
+ if (ret)
+ return ret;
+
+ /* fix parent address */
+ idx = i + acells + pacells - 1;
+ ret = fdt_setprop_inplace_u32_partial(blob, node, "ranges", idx,
+ fdt32_to_cpu(ranges[idx])
+
+ fix_offset);
+ if (ret)
+ return ret;
+ }
- return fdt_setprop_inplace(blob, node, "ranges", new_ranges, len);
+ return 0;
}
void reset_cpu(void)
--
2.20.1
[PATCH 4/6] arm: a37xx: pci: Find PCIe controller node by compatible instead of path
Find PCIe DT node by compatible string instead of retrieving it by using
hardcoded DT path.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
arch/arm/mach-mvebu/armada3700/cpu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
b/arch/arm/mach-mvebu/armada3700/cpu.c
index 0cf60d7cdd7d..1abac7c9a47a 100644
--- a/arch/arm/mach-mvebu/armada3700/cpu.c
+++ b/arch/arm/mach-mvebu/armada3700/cpu.c
@@ -53,8 +53,6 @@
#define A3700_PTE_BLOCK_DEVICE \
(PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_NON_SHARE)
-#define PCIE_PATH "/soc/pcie@d007"
-
DECLARE_GLOBAL_DATA_PTR;
static struct mm_region mvebu_mem_map[MAX_MEM_MAP_REGIONS] = {
@@ -288,7 +286,7 @@ int a3700_fdt_fix_pcie_regions(void *blob)
const u32 *ranges;
int node, len;
- node = fdt_path_offset(blob, PCIE_PATH);
+ node = fdt_node_offset_by_compatible(blob, -1,
"marvell,armada-3700-pcie");
if (node < 0)
return node;
--
2.20.1
[PATCH 1/6] arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe
During our debugging of the Aardvark driver in Linux we have discovered that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard PCIe Link Control Register for PCIe Root Bridge. This led us to discover that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding comment by this macro's usage is misleading; this bit in fact controls Retrain Link, which, according to PCIe base spec is defined as: A write of 1b to this bit initiates Link retraining by directing the Physical Layer LTSSM to the Recovery state. If the LTSSM is already in Recovery or Configuration, re-entering Recovery is permitted but not required. Entering Recovery state is normally done from LTSSM L0, L0s and L1 states. But since the pci-aardvark.c driver enables Link Training just a few lines above, the controller is not in L0 ready state yet. So setting aardvark bit PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this place. Moreover, trying to enter LTSSM Recovery state without other configuration is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since Recovery state is not entered, these issues are not triggered. Remove code which tries to enter LTSSM Recovery state completely. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- drivers/pci/pci-aardvark.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index c43d4f309b19..06c567e236f9 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -613,11 +613,6 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie) reg |= PIO_CTRL_ADDR_WIN_DISABLE; advk_writel(pcie, reg, PIO_CTRL); - /* Start link training */ - reg = advk_readl(pcie, PCIE_CORE_LINK_CTRL_STAT_REG); - reg |= PCIE_CORE_LINK_TRAINING; - advk_writel(pcie, reg, PCIE_CORE_LINK_CTRL_STAT_REG); - /* Wait for PCIe link up */ if (pcie_advk_wait_for_link(pcie)) return -ENXIO; -- 2.20.1
[PATCH 2/6] arm: a37xx: pci: Disable bus mastering when unloading driver
Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's remove method, which is called before booting Linux kernel. This ensures that PCIe device which was initialized and used by U-Boot cannot do new DMA transfers until Linux initializes PCI subsystem and loads appropriate drivers for the device. During initialization of PCI subsystem Linux in fact disables this bus mastering on Root Bridge (and later enables it when driver is loaded and configured), but there is a possibility of a small window after U-Boot boots Linux when bus mastering is enabled, which is not correct. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- drivers/pci/pci-aardvark.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index 06c567e236f9..ee81b2ea46d3 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -675,6 +675,12 @@ static int pcie_advk_remove(struct udevice *dev) struct pcie_advk *pcie = dev_get_priv(dev); u32 reg; + reg = advk_readl(pcie, PCIE_CORE_CMD_STATUS_REG); + reg &= ~(PCIE_CORE_CMD_MEM_ACCESS_EN | +PCIE_CORE_CMD_IO_ACCESS_EN | +PCIE_CORE_CMD_MEM_IO_REQ_EN); + advk_writel(pcie, reg, PCIE_CORE_CMD_STATUS_REG); + reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); reg &= ~LINK_TRAINING_EN; advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); -- 2.20.1
Re: [PATCH 1/1] xilinx: disable Unicode capitalization
On 5/16/21 11:17 AM, Heinrich Schuchardt wrote: > Save some KiB when building xilinx_versal_virt_defconfig by disabling > Unicode capitalization support. This avoids build failures when adding new > features for the UEFI sub-system. > > Signed-off-by: Heinrich Schuchardt > --- > It would be preferable to have a size check for the u-boot binary. > This would avoid seeing problems only during execution. > --- > configs/xilinx_versal_virt_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/xilinx_versal_virt_defconfig > b/configs/xilinx_versal_virt_defconfig > index 707693713a..8bc2ff4a4c 100644 > --- a/configs/xilinx_versal_virt_defconfig > +++ b/configs/xilinx_versal_virt_defconfig > @@ -111,3 +111,4 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x0300 > CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_USB_FUNCTION_THOR=y > CONFIG_OF_LIBFDT_OVERLAY=y > +# CONFIG_EFI_UNICODE_CAPITALIZATION is not set > -- > 2.30.2 > What's the build issue? Any log? U-Boot is getting bigger and bigger and we are enabling more and more features for our generic targets that's why fixing that problem is better than disabling some options. Thanks, Michal
Re: [PATCH v2 4/4] test: Don't unmount not (yet) mounted system
On Thu, May 13, 2021 at 2:32 PM Heinrich Schuchardt wrote: > On 2/11/21 3:40 PM, Andy Shevchenko wrote: > > When test suite tries to create a file for a new filesystem test case and > > fails, > > the clean up of the exception tries to unmount the image, that has not yet > > been > > mounted. When it happens, the fuse_mounted global variable is set to False > > and > > inconveniently the test case tries to use sudo, so without this change the > > admin of the machine gets an (annoying) email: > > > >Subject: *** SECURITY information for example.com *** > > > >example.com : Feb 5 19:43:47 : ... COMMAND=/bin/umount > > .../build-sandbox/persistent-data/mnt > > > > and second run of the test cases on uncleaned build folder will ask for sudo > > which is not what expected. > > > > Besides that there is a double unmount calls during successfully run test > > case. > > > > All of these due to over engineered Python try-except clause and people > > didn't > > get it properly at all. The rule of thumb is that don't use more keywords > > than > > try-except in the exception handling code. Nevertheless, here we adjust code > > to be less intrusive to the initial logic behind that complex and unclear > > constructions in the test case, although it adds a lot of lines of the code, > > i.e. splits one exception handler to three, so on each step we know what > > cleanup shall perform. > > > > Signed-off-by: Andy Shevchenko > > Dear Andy, > > with this merged patch the following tests are not executed anymore locally: > > test/py/tests/test_fs/test_basic.py > test/py/tests/test_fs/test_ext.py > > SKIPPED [13] test/py/tests/test_fs/conftest.py:350: Setup failed for > filesystem: ext4. Command 'guestmount -a > build-sandbox/persistent-data/3GB.ext4.img -m /dev/sda > build-sandbox/persistent-data/mnt' returned non-zero exit status 1. > > Please, revert the patch or fix it. Thanks for the report, let's investigate it. And for the consistency let's continue this under the revert thread, -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/1] test: revert Don't unmount not (yet) mounted system
On Thu, May 13, 2021 at 2:41 PM Heinrich Schuchardt wrote:
>
> Since commit 1ba21bb06b08 ("test: Don't unmount not (yet) mounted system")
> the following tests are skipped:
>
> test/py/tests/test_fs/test_basic.py
> test/py/tests/test_fs/test_ext.py
>
> SKIPPED [13] test/py/tests/test_fs/conftest.py:350: Setup failed for
> filesystem: ext4. Command 'guestmount -a
> build-sandbox/persistent-data/3GB.ext4.img -m /dev/sda
> build-sandbox/persistent-data/mnt' returned non-zero exit status 1.
>
> Let's revert the patch to get our tests back.
Probably we may understand first what is the root cause of this issue?
In my case I can't allow this to happen, because it will annoy system
administrators as I mentioned earlier in the commit message.
So, NAK from me and let's investigate.
Can you provide a command line that I may run on my environment w/o root access?
--
With Best Regards,
Andy Shevchenko
[PATCH 1/1] fs/squashfs: zero out unused fields in fs_dirent
When reading directories the UEFI sub-system must supply file attributes and timestamps. These fields will have to be added to struct fs_dirent. SquashFS should not fill these fields with random data. Ensure that they are zeroed out. Signed-off-by: Heinrich Schuchardt --- fs/squashfs/sqfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c index 29805c3c6f..997be2dcf4 100644 --- a/fs/squashfs/sqfs.c +++ b/fs/squashfs/sqfs.c @@ -876,7 +876,7 @@ int sqfs_opendir(const char *filename, struct fs_dir_stream **dirsp) char **token_list = NULL, *path = NULL; u32 *pos_list = NULL; - dirs = malloc(sizeof(*dirs)); + dirs = calloc(1, sizeof(*dirs)); if (!dirs) return -EINVAL; -- 2.30.2
Re: [PATCH] tee: optee: sync cache on pre-reloc OP-TEE invocation
On Wed, May 12, 2021 at 5:08 PM Etienne Carriere
wrote:
>
> This change ensures both U-Boot and OP-TEE see the same content
> from shared memory when OP-TEE is invoked prior U-Boot relocation.
>
> This change is required since U-Boot may execute with data cahce off
> while OP-TEE always enables cache on memory shared with U-Boot.
>
> Signed-off-by: Etienne Carriere
> ---
> drivers/tee/optee/core.c | 20 +++-
> drivers/tee/tee-uclass.c | 18 +-
> include/tee.h| 6 ++
> 3 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 73dbb22ba0..120d315813 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -1,9 +1,10 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright (c) 2018 Linaro Limited
> + * Copyright (c) 2018-2020 Linaro Limited
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -295,6 +296,15 @@ static u32 call_err_to_res(u32 call_err)
> }
> }
>
> +static void flush_shm_dcache(struct udevice *dev, struct optee_msg_arg *arg)
> +{
> + flush_dcache_range(rounddown((ulong)arg, CONFIG_SYS_CACHELINE_SIZE),
> + roundup((ulong)arg + sizeof(*arg),
> + CONFIG_SYS_CACHELINE_SIZE));
Please use the OPTEE_MSG_GET_ARG_SIZE() macro to calculate the size of
the argument struct.
Cheers,
Jens
> +
> + tee_flush_all_shm_dcache(dev);
> +}
> +
> static u32 do_call_with_arg(struct udevice *dev, struct optee_msg_arg *arg)
> {
> struct optee_pdata *pdata = dev_get_plat(dev);
> @@ -305,9 +315,17 @@ static u32 do_call_with_arg(struct udevice *dev, struct
> optee_msg_arg *arg)
> while (true) {
> struct arm_smccc_res res;
>
> + /* If cache are off from U-Boot, sync the cache shared with
> OP-TEE */
> + if (!dcache_status())
> + flush_shm_dcache(dev, arg);
> +
> pdata->invoke_fn(param.a0, param.a1, param.a2, param.a3,
> param.a4, param.a5, param.a6, param.a7,
> &res);
>
> + /* If cache are off from U-Boot, sync the cache shared with
> OP-TEE */
> + if (!dcache_status())
> + flush_shm_dcache(dev, arg);
> +
> free(page_list);
> page_list = NULL;
>
> diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> index 2cc6b6c407..81fcd4e801 100644
> --- a/drivers/tee/tee-uclass.c
> +++ b/drivers/tee/tee-uclass.c
> @@ -1,9 +1,10 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright (c) 2018 Linaro Limited
> + * Copyright (c) 2018-2020 Linaro Limited
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -233,3 +234,18 @@ void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
> d[7] = s->time_hi_and_version;
> memcpy(d + 8, s->clock_seq_and_node, sizeof(s->clock_seq_and_node));
> }
> +
> +void tee_flush_all_shm_dcache(struct udevice *dev)
> +{
> + struct tee_uclass_priv *priv = dev_get_uclass_priv(dev);
> + struct tee_shm *s;
> +
> + list_for_each_entry(s, &priv->list_shm, link) {
> + ulong start = rounddown((ulong)s->addr,
> + CONFIG_SYS_CACHELINE_SIZE);
> + ulong end = roundup((ulong)s->addr + s->size,
> + CONFIG_SYS_CACHELINE_SIZE);
> +
> + flush_dcache_range(start, end);
> + }
> +}
> diff --git a/include/tee.h b/include/tee.h
> index 99367b258e..2ef29bfc8f 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -377,4 +377,10 @@ void tee_optee_ta_uuid_from_octets(struct
> tee_optee_ta_uuid *d,
> void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
> const struct tee_optee_ta_uuid *s);
>
> +/**
> + * tee_flush_all_shm_dcache() - Flush data cache for all shared memories
> + * @dev: The TEE device
> + */
> +void tee_flush_all_shm_dcache(struct udevice *dev);
> +
> #endif /* __TEE_H */
> --
> 2.17.1
>
Re: [PATCH 2/2] tee: optee: support session login as REE kernel
On Wed, May 12, 2021 at 5:06 PM Etienne Carriere
wrote:
>
> OP-TEE supports an API extension to allow client to open a TEE session
> as REE kernel which OP-TEE uses to differentiate client application
> services from system services that only the REE OS kernel can access.
>
> This change allows U-Boot to invoke OP-TEE which such kernel identity
> and therefore access kernel client specific services.
>
> Signed-off-by: Etienne Carriere
> ---
> drivers/tee/optee/core.c | 24 +++-
> drivers/tee/optee/optee_msg.h | 2 ++
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 73dbb22ba0..526bf125a0 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -349,6 +349,28 @@ static int optee_close_session(struct udevice *dev, u32
> session)
> return 0;
> }
>
> +static uint32_t optee_login_id(enum tee_session_login login)
> +{
> + /* Treat invalid IDs as public login */
> + switch (login) {
> + case TEE_SESSION_LOGIN_USER:
> + return OPTEE_MSG_LOGIN_USER;
> + case TEE_SESSION_LOGIN_GROUP:
> + return OPTEE_MSG_LOGIN_GROUP;
> + case TEE_SESSION_LOGIN_APPLICATION:
> + return OPTEE_MSG_LOGIN_APPLICATION;
> + case TEE_SESSION_LOGIN_APPLICATION_USER:
> + return OPTEE_MSG_LOGIN_APPLICATION;
> + case TEE_SESSION_LOGIN_APPLICATION_GROUP:
> + return OPTEE_MSG_LOGIN_APPLICATION;
> + case TEE_SESSION_LOGIN_REE_KERNEL:
> + return OPTEE_MSG_LOGIN_REE_KERNEL;
> + case TEE_SESSION_LOGIN_PUBLIC:
> + default:
> + return OPTEE_MSG_LOGIN_PUBLIC;
> + }
> +}
> +
I don't see any point in this translation, we could just as well use
the correct values from the start.
Cheers,
Jens
> static int optee_open_session(struct udevice *dev,
> struct tee_open_session_arg *arg,
> uint num_params, struct tee_param *params)
> @@ -372,7 +394,7 @@ static int optee_open_session(struct udevice *dev,
> OPTEE_MSG_ATTR_META;
> memcpy(&msg_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid));
> memcpy(&msg_arg->params[1].u.value, arg->uuid,
> sizeof(arg->clnt_uuid));
> - msg_arg->params[1].u.value.c = arg->clnt_login;
> + msg_arg->params[1].u.value.c = optee_login_id(arg->clnt_login);
>
> rc = to_msg_param(msg_arg->params + 2, num_params, params);
> if (rc)
> diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
> index 8d40ce60c2..17e8d28e52 100644
> --- a/drivers/tee/optee/optee_msg.h
> +++ b/drivers/tee/optee/optee_msg.h
> @@ -95,6 +95,8 @@
> #define OPTEE_MSG_LOGIN_APPLICATION0x0004
> #define OPTEE_MSG_LOGIN_APPLICATION_USER 0x0005
> #define OPTEE_MSG_LOGIN_APPLICATION_GROUP 0x0006
> +/* OP-TEE extension: log as REE kernel */
> +#define OPTEE_MSG_LOGIN_REE_KERNEL 0x8000
>
> /*
> * Page size used in non-contiguous buffer entries
> --
> 2.17.1
>
Re: [PATCH 1/2] tee: define session login identifiers
On Wed, May 12, 2021 at 5:06 PM Etienne Carriere
wrote:
>
> TEE header file defines a clnt_login field in struct tee_open_session_arg
> but does not define the values expected. This change define identifiers
> for the field using a enumerated type. Back end TEE driver is expected to
> convert these IDs into IDs meaningful to the TEE.
>
> Signed-off-by: Etienne Carriere
> ---
> include/tee.h | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/include/tee.h b/include/tee.h
> index 99367b258e..b8297601b4 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -31,6 +31,19 @@
> #define TEE_PARAM_ATTR_MASK(TEE_PARAM_ATTR_TYPE_MASK | \
> TEE_PARAM_ATTR_META)
>
> +/*
> + * Value for tee_open_session_arg::clnt_login
> + */
> +enum tee_session_login {
> + TEE_SESSION_LOGIN_PUBLIC = 0,
> + TEE_SESSION_LOGIN_USER,
> + TEE_SESSION_LOGIN_GROUP,
> + TEE_SESSION_LOGIN_APPLICATION,
This is defined as 4 in the spec.
> + TEE_SESSION_LOGIN_APPLICATION_USER,
> + TEE_SESSION_LOGIN_APPLICATION_GROUP,
Please make these USER_APPLICATION and GROUP_APPLICATION since that's
the order used in the spec.
> + TEE_SESSION_LOGIN_REE_KERNEL,
The Linux kernel defines the REE kernel stuff as:
/*
* Disallow user-space to use GP implementation specific login
* method range (0x8000 - 0xBFFF). This range is rather
* being reserved for REE kernel clients or TEE implementation.
*/
#define TEE_IOCTL_LOGIN_REE_KERNEL_MIN 0x8000
#define TEE_IOCTL_LOGIN_REE_KERNEL_MAX 0xBFFF
/* Private login method for REE kernel clients */
#define TEE_IOCTL_LOGIN_REE_KERNEL 0x8000
We should at least try to be in the same implementation defined range.
> +};
I think that using a TEE_LOGIN_ prefix should be enough.
> +
> /*
> * Some Global Platform error codes which has a meaning if the
> * TEE_GEN_CAP_GP bit is returned by the driver in
> @@ -135,8 +148,8 @@ struct tee_param {
> /**
> * struct tee_open_session_arg - extra arguments for tee_open_session()
> * @uuid: [in] UUID of the Trusted Application
> - * @clnt_uuid: [in] Normally zeroes
> - * @clnt_login:[in] Normally 0
> + * @clnt_uuid: [in] UUID of client, zeroes for PUBLIC/REE_KERNEL
> + * @clnt_login:[in] Class of client TEE_SESSION_LOGIN_*
> * @session: [out] Session id
> * @ret: [out] return value
> * @ret_origin:[out] origin of the return value
> @@ -144,7 +157,7 @@ struct tee_param {
> struct tee_open_session_arg {
> u8 uuid[TEE_UUID_LEN];
> u8 clnt_uuid[TEE_UUID_LEN];
> - u32 clnt_login;
> + enum tee_session_login clnt_login;
Please keep this as an u32. It's part of the ABI.
Cheers,
Jens
> u32 session;
> u32 ret;
> u32 ret_origin;
> --
> 2.17.1
>
Please pull u-boot-marvell/master v2
please pull the next batch of Marvell Armada related patches. Here the
summary log:
- Add base support for Marvell OcteonTX2 CN9130 DB (mostly done
by Kostya)
- Sync Armada 8k MMU setup with Marvell version (misc Marvell
authors)
- spi: kirkwood: Some fixes especially for baudrate generation
(misc Marvell authors)
- mvebu: x530: Reduce SPL image size (Stefan)
- Rename "rx_training" to "mvebu_comphy_rx_training" (Stefan)
Here the Azure build without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=89&view=results
I've dropped the mvpp2 ethernet driver sync with the PHY header
extension as it introduces some issues on xilinx_versal_virt which
need to be investigated.
Thanks,
Stefan
The following changes since commit e644dfbb1786a4a3308b068e1f61cd9e2dfac237:
configs: Resync with savedefconfig (2021-05-15 08:10:13 -0400)
are available in the Git repository at:
g...@source.denx.de:u-boot/custodians/u-boot-marvell.git
for you to fetch changes up to e1c55dfc7b59e8e49fc400290b3bea8066b74de1:
arm: octeontx2: Add Octeon TX2 CN913x DB support (2021-05-16 06:48:45
+0200)
Grzegorz Jaszczyk (4):
spi: kirkwood: prevent limiting speed to 0
arm64: mvebu: do not map firmware RT service region
arm64: mvebu: a8k: move firmware related definitions to fw info
arm64: mvebu: extend the mmio region
Ken Ma (1):
spi: kirkwood: support extended baud rates
Konstantin Porotchkin (2):
arm: octeontx2: Add dtsi/dts files for Octeon TX2 CN913x DB
arm: octeontx2: Add Octeon TX2 CN913x DB support
Marcin Wojtas (2):
spi: kirkwood: prevent configuring speed exceeding max controller
freq
pcie: designware: mvebu: do not configure ATU for IO when not used
Stefan Roese (2):
mvebu: x530: Reduce SPL image size
cmd: mvebu: Rename rx_training to mvebu_comphy_rx_training
jinghua (1):
arm64: mvebu: a8k: align memory regions
arch/arm/dts/Makefile | 6 +
arch/arm/dts/cn9130-db-A.dts | 55
arch/arm/dts/cn9130-db-B.dts | 51
arch/arm/dts/cn9130-db-dev-info.dtsi | 44 +++
arch/arm/dts/cn9130-db.dtsi | 316
++
arch/arm/dts/cn9131-db-A.dts | 54
arch/arm/dts/cn9131-db-B.dts | 69 +
arch/arm/dts/cn9131-db.dtsi | 166
arch/arm/dts/cn9132-db-A.dts | 13 +
arch/arm/dts/cn9132-db-B.dts | 13 +
arch/arm/dts/cn9132-db.dtsi | 217 +++
arch/arm/mach-mvebu/armada8k/cpu.c| 70 ++---
arch/arm/mach-mvebu/include/mach/fw_info.h| 18 ++
board/Marvell/octeontx2_cn913x/MAINTAINERS| 1 +
board/Marvell/octeontx2_cn913x/README | 24 ++
cmd/mvebu/Kconfig | 9 +-
cmd/mvebu/Makefile| 2 +-
cmd/mvebu/{rx_training.c => comphy_rx_training.c} | 10 +-
configs/mvebu_db_cn9130_defconfig | 89 ++
configs/x530_defconfig| 2 +-
drivers/pci/pcie_dw_mvebu.c | 37 ++-
drivers/spi/kirkwood_spi.c| 67 -
22 files changed, 1250 insertions(+), 83 deletions(-)
create mode 100644 arch/arm/dts/cn9130-db-A.dts
create mode 100644 arch/arm/dts/cn9130-db-B.dts
create mode 100644 arch/arm/dts/cn9130-db-dev-info.dtsi
create mode 100644 arch/arm/dts/cn9130-db.dtsi
create mode 100644 arch/arm/dts/cn9131-db-A.dts
create mode 100644 arch/arm/dts/cn9131-db-B.dts
create mode 100644 arch/arm/dts/cn9131-db.dtsi
create mode 100644 arch/arm/dts/cn9132-db-A.dts
create mode 100644 arch/arm/dts/cn9132-db-B.dts
create mode 100644 arch/arm/dts/cn9132-db.dtsi
create mode 100644 arch/arm/mach-mvebu/include/mach/fw_info.h
create mode 100644 board/Marvell/octeontx2_cn913x/README
rename cmd/mvebu/{rx_training.c => comphy_rx_training.c} (74%)
create mode 100644 configs/mvebu_db_cn9130_defconfig
Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb
Hi Rick,
On Wed, May 12, 2021 at 11:25 AM Rick Chen wrote:
>
> HI Bin,
>
> >
> > > Hi Rick,
> > >
> > > On Tue, May 11, 2021 at 8:49 AM Rick Chen wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Mon, May 10, 2021 at 3:22 PM Rick Chen
> > > > > wrote:
> > > > > >
> > > > > > Hi Bin
> > > > > >
> > > > > > > Hi Bin,
> > > > > > >
> > > > > > > > From: Bin Meng
> > > > > > > > Sent: Monday, May 10, 2021 2:58 PM
> > > > > > > > To: Simon Glass ; Rick Jian-Zhi Chen(陳建志)
> > > > > > > > ; u-boot@lists.denx.de
> > > > > > > > Subject: [PATCH v4 00/13] riscv: Switch to use binman to
> > > > > > > > generate u-boot.itb
> > > > > > > >
> > > > > > > > This series updates binman to handle creation of u-boot.itb
> > > > > > > > image for RISC-V boards.
> > > > > > > >
> > > > > > > > Azure results: PASS
> > > > > > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363&view=results
> > > > > > > >
> > > > > > > > The following tests were performed:
> > > > > > > > * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> > > > > > > > * booting sifive_unleashed_defconfig on QEMU sifive_u
> > > > > > > >
> > > > > > > > AE350 SPL defconfigs are not tested. @Rick, could you please
> > > > > > > > test and report?
> > > > > > >
> > > > > > > OK. I will verify it on AE350.
> > > > > >
> > > > > > It fail as below messages:
> > > > > >
> > > > > > U-Boot SPL 2021.07-rc1-00218-g468b3b3 (May 10 2021 - 15:13:03 +0800)
> > > > > > Trying to boot from RAM
> > > > > > alloc space exhausted
> > > > >
> > > > > Looks it is running out of memory.
> > > > >
> > > > > > Could not get FIT buffer of 499076 bytes
> > > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > >
> > > > > Could you please try increasing CONFIG_SYS_SPL_MALLOC_SIZE?
> > > >
> > > > I increased CONFIG_SYS_SPL_MALLOC_SIZE, but it is useless.
> > > > But it boots successfully after increase CONFIG_SPL_SYS_MALLOC_F_LEN
> > > > larger.
> > >
> > > Thanks for testing. I am not sure why AE350 fails to boot because this
> > > series only changes the way to assemble the bits.
> > >
> > > Could you please confirm if without this patch series, AE350 can boot?
> >
> > OK.
>
>
> I have verified AE350 without your patch, it works as below:
>
> U-Boot SPL 2021.07-rc1-00194-g07b5310 (May 12 2021 - 10:59:48 +0800)
> Trying to boot from RAM
>
> U-Boot 2021.07-rc1-00194-g07b5310 (May 12 2021 - 10:59:48 +0800)
>
> DRAM: 1 GiB
> Flash: 64 MiB
> MMC: mmc@f0e0: 0
> Loading Environment from SPIFlash... SF: Detected mx25u1635e with page
> size 256 Bytes, erase size 4 KiB, total 2 MiB
> OK
> In:serial@f030
> Out: serial@f030
> Err: serial@f030
> Net: no alias for ethernet0
>
> Warning: mac@e010 (eth0) using random MAC address - 26:00:fa:12:76:ad
> eth0: mac@e010
> Hit any key to stop autoboot: 0
> RISC-V #
>
> =
> With your patch, it fail as below:
> =
>
> U-Boot SPL 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:09:11 +0800)
> Trying to boot from RAM
> alloc space exhausted
> Could not get FIT buffer of 499076 bytes
> check CONFIG_SYS_SPL_MALLOC_SIZE
> No device tree specified in SPL image
>
> ===
> After increase CONFIG_SPL_SYS_MALLOC_F_LEN, it works as below
> ===
> U-Boot SPL 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:11:00 +0800)
> Trying to boot from RAM
>
>
> U-Boot 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:11:00 +0800)
>
> DRAM: 1 GiB
> Flash: 64 MiB
> MMC: mmc@f0e0: 0
> Loading Environment from SPIFlash... SF: Detected mx25u1635e with page
> size 256 Bytes, erase size 4 KiB, total 2 MiB
> OK
> In:serial@f030
> Out: serial@f030
> Err: serial@f030
> Net: no alias for ethernet0
>
> Warning: mac@e010 (eth0) using random MAC address - e6:58:7e:7c:5f:49
> eth0: mac@e010
> Hit any key to stop autoboot: 0
> RISC-V #
>
>
> I found that it need larger heap size when spl try to get fit image
> with using binman to generate u-boot.itb instead of
> USE_SPL_FIT_GENERATOR.
> But it is OK. I will send a patch for AE350 later.
A patch for AE350 to increase CONFIG_SPL_SYS_MALLOC_F_LEN needs to be
applied before this series.
Would you please send the AE350 patch, and get this series applied?
Regards,
Bin
Re: [PATCH 1/2] riscv: Fix memmove and optimise memcpy when misalign
On Thu, May 13, 2021 at 4:46 PM Bin Meng wrote:
>
> At present U-Boot SPL fails to boot on SiFive Unleashed board, due
> to a load address misaligned exception happens when loading the FIT
> image in spl_load_simple_fit(). The exception happens in memmove()
> which is called by fdt_splice_().
>
> Commit 8f0dc4cfd106 introduces an assembly version of memmove but
> it does take misalignment into account (it checks if length is a
> multiple of machine word size but pointers need also be aligned).
> As a result it will generate misaligned load/store for the majority
> of cases and causes significant performance regression on hardware
> that traps misaligned load/store and emulate them using firmware.
>
> The current behaviour of memcpy is that it checks if both src and
> dest pointers are co-aligned (aka congruent modular SZ_REG). If
> aligned, it will copy data word-by-word after first aligning
> pointers to word boundary. If src and dst are not co-aligned,
> however, byte-wise copy will be performed.
>
> This patch was taken from the Linux kernel patch [1], which has not
> been applied at the time being. It fixes the memmove and optimises
> memcpy for misaligned cases. It will first align destination pointer
> to word-boundary regardless whether src and dest are co-aligned or
> not. If they indeed are, then wordwise copy is performed. If they
> are not co-aligned, then it will load two adjacent words from src
> and use shifts to assemble a full machine word. Some additional
> assembly level micro-optimisation is also performed to ensure more
> instructions can be compressed (e.g. prefer a0 to t6).
>
> With this patch, U-Boot boots again on SiFive Unleashed board.
>
> [1]
> https://patchwork.kernel.org/project/linux-riscv/patch/2021021622.4976-1-g...@garyguo.net/
>
> Fixes: 8f0dc4cfd106 ("riscv: assembler versions of memcpy, memmove, memset")
> Signed-off-by: Bin Meng
> ---
>
> arch/riscv/lib/memcpy.S | 223 ---
> arch/riscv/lib/memmove.S | 176 --
> 2 files changed, 257 insertions(+), 142 deletions(-)
>
Ping?
Re: [PATCH v2 1/2] of: addr: Translate 'dma-ranges' for parent nodes missing 'dma-ranges'
Hi Simon, On Fri, Apr 30, 2021 at 9:17 PM Bin Meng wrote: > > 'dma-ranges' frequently exists without parent nodes having 'dma-ranges'. > While this is an error for 'ranges', this is fine because DMA capable > devices always have a translatable DMA address. Also, with no > 'dma-ranges' at all, the assumption is that DMA addresses are 1:1 with > no restrictions unless perhaps the device itself has implicit > restrictions. > > This keeps in sync with Linux kernel commit: > > 81db12ee15cb: of/address: Translate 'dma-ranges' for parent nodes missing > 'dma-ranges' > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass > > --- > > Changes in v2: > - rebase on top of Dario's revert patch: > > http://patchwork.ozlabs.org/project/uboot/patch/20210425141746.19115-6-dario...@libero.it/ The above dependent patch is now in u-boot/master. Could you please apply this series? > - drop commit "of: addr: Abort address translation for parent nodes missing > 'ranges'", > as the revert patch restores the abort behavior > > drivers/core/of_addr.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Regards, Bin
Re: [PATCH v2 27/28] fs/squashfs: sqfs_read: fragmented files are not supported
Hello, Em ter., 11 de mai. de 2021 às 10:04, Richard Genoud < richard.gen...@posteo.net> escreveu: > Hi all, > > Le 08/05/2021 à 23:51, Simon Glass a écrit : > > Hi, > > > > On Thu, 4 Feb 2021 at 15:32, João Marcos Costa > wrote: > >> > >> Em qua., 27 de jan. de 2021 às 12:15, Simon Glass > escreveu: > >>> > >>> Hi Joao, > >> > >> Hello! > >>> > >>> This test works the first time I run it but fails the second time, > >>> since the directory already exists. This makes it necessary to disable > >>> the test for development. > >>> > >>> It also uses the wrong quoting style - we have settled on a single > >>> quote by default in U-Boot. > >>> > >>> Finally, the tests and some functions need comments about what they do > >>> and what the arguments are. > >>> > >>> Please can you take a look? > >> > >> Absolutely. Excuse me for such a late reply. > > > > Any word on this please? Have you been able to repeat this? > Yes, for me, reading fragmented files doesn't work. > The test "test_sqfs_load" is OK because it only tests the file length not > its content. > > I've written a patch to check if the file is corrupted or not, and it > fails : > ./test/py/test.py --bd sandbox --build -k test_sqfs_load -v > [...] > I finally could get back to SquashFS support today, and I fixed a few bugs concerning the fragmented files. However, I still need to run a few more tests before submitting the patches. Best regards, Joao Marcos www.linkedin.com/in/jmarcoscosta/ https://github.com/jmarcoscosta
Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
On 2021/5/13 5:47, ZHIZHIKIN Andrey wrote:
Hello Peng,
-Original Message-
From: U-Boot On Behalf Of Peng Fan (OSS)
Sent: Friday, March 19, 2021 8:57 AM
To: sba...@denx.de; feste...@gmail.com
Cc: u-boot@lists.denx.de; uboot-...@nxp.com; Ye Li
Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
From: Ye Li
Update PMIC to use PCA9540, the legacy board not supported by NXP
This commit seems rather a "nuclear" to me, as de-facto it drops the
initialization of ROMH PMIC in
favor of PCA one, leaving all the previous board revisions not to be properly
sourced.
I know that there might be no intention to provide a support for earlier
revisions of i.MX8M Mini
EVKs from NXP, but providing no backward compatibility to those boards which
are still in use by
a lot of people for development purposes is highly undesirable either.
TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and
apart from having some
error messages in SPL regarding the register writes - it does boots. What
worries me the most though
is that DTS changes some voltage settings, which I'm not sure how the SOC would
react on.
To my opinion, this patch should either be complemented with the mechanism to
provide a
level of backward compatibility (where the PMIC can be dynamically identified
and instantiated),
or the separate implementation should be presented which would make the old
board type not to
be bootable at all if it is considered not to be supported any longer. Or this
patch should be reverted
in an effort to come up with a solution which covers new revision without
"damaging" the currently
integrated one.
The old evk board was no longer supported by NXP, all new boards using
new PMIC. No damage, just some default voltage settings different.
It is ok to add back the old pmic, but it finally will retire and no one
will use it in production I think.
Regards,
Peng.
Fabio / Stefano,
Do you have any thoughts here on how this should be handled further,
considering the fact that the
backward compatibility of 2021.07 release is not kept for this board type
across multiple revisions?
I'd really like to get your opinion here as I do have those boards in
development and would need to
come up with the idea on what to do with them.
Also, this should be taken care of in the Yocto, since there is only one
definition of the i.MX8MM EVK
machine which does not make any distinction regarding the revision.
Thanks a lot!
Signed-off-by: Ye Li
---
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +-
arch/arm/dts/imx8mm-evk.dtsi| 127 +++-
board/freescale/imx8mm_evk/spl.c| 33
configs/imx8mm_evk_defconfig| 2 +-
4 files changed, 86 insertions(+), 80 deletions(-)
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-
u-boot.dtsi
index e843a5648e..7f48912b49 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -114,11 +114,11 @@
u-boot,dm-spl;
};
-&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+&{/soc@0/bus@3080/i2c@30a2/pca9450@25} {
u-boot,dm-spl;
};
-&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+&{/soc@0/bus@3080/i2c@30a2/pca9450@25/regulators} {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
index 6518f088b2..60179e006d 100644
--- a/arch/arm/dts/imx8mm-evk.dtsi
+++ b/arch/arm/dts/imx8mm-evk.dtsi
@@ -126,115 +126,120 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- pmic@4b {
- compatible = "rohm,bd71847";
- reg = <0x4b>;
- pinctrl-names = "default";
+ pmic: pca9450@25 {
+ reg = <0x25>;
+ compatible = "nxp,pca9450a";
+ /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */
pinctrl-0 = <&pinctrl_pmic>;
- interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
- rohm,reset-snvs-powered;
-
- #clock-cells = <0>;
- clocks = <&osc_32k 0>;
- clock-output-names = "clk-32k-out";
+ gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>;
regulators {
- buck1_reg: BUCK1 {
- regulator-name = "buck1";
- regulator-min-microvolt = <70>;
- regulator-max-microvolt = <130>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pca9450,pmic-buck2-uses-i2c-dvs;
+ /* Run/Standby voltage */
+ pca9450,pmic-buck2-dvs-voltage = <95>,
+ <85>;
+
+ buck1_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "buck1";
+ re
[PATCH 2/3] ARM: dts: imxrt1020-evk: move all u-boot, dm-spl to imxrt1020-evk-u-boot.dtsi file
At the moment a lot of u-boot,dm-spl properties are present in board .dts
file but this is not correct since u-boot,dm-spl property is u-boot
specific and must be listed into the separate imrt1020-evk-u-boot.dtsi
file. So let's move every u-boot,dm-spl property present in
imxrt1020-evk.dts to imxrt1020-evk-u-boot.dtsi file.
Signed-off-by: Giulio Benetti
---
arch/arm/dts/imxrt1020-evk-u-boot.dtsi | 34 ++
arch/arm/dts/imxrt1020.dtsi| 10
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm/dts/imxrt1020-evk-u-boot.dtsi
b/arch/arm/dts/imxrt1020-evk-u-boot.dtsi
index 34d19e06c5..121665a2d2 100644
--- a/arch/arm/dts/imxrt1020-evk-u-boot.dtsi
+++ b/arch/arm/dts/imxrt1020-evk-u-boot.dtsi
@@ -8,6 +8,38 @@
chosen {
u-boot,dm-spl;
};
+
+ clocks {
+ u-boot,dm-spl;
+ };
+
+ soc {
+ u-boot,dm-spl;
+ };
+};
+
+&osc {
+ u-boot,dm-spl;
+};
+
+&clks {
+ u-boot,dm-spl;
+};
+
+&gpio1 {
+ u-boot,dm-spl;
+};
+
+&gpio2 {
+ u-boot,dm-spl;
+};
+
+&gpio3 {
+ u-boot,dm-spl;
+};
+
+&gpio5 {
+ u-boot,dm-spl;
};
&gpt1 {
@@ -19,6 +51,8 @@
};
&semc {
+ u-boot,dm-spl;
+
bank1: bank@0 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imxrt1020.dtsi b/arch/arm/dts/imxrt1020.dtsi
index cab608c644..884d57f614 100644
--- a/arch/arm/dts/imxrt1020.dtsi
+++ b/arch/arm/dts/imxrt1020.dtsi
@@ -23,7 +23,6 @@
};
clocks {
- u-boot,dm-spl;
ckil {
compatible = "fsl,imx-ckil", "fixed-clock";
#clock-cells = <0>;
@@ -37,7 +36,6 @@
};
osc: osc {
- u-boot,dm-spl;
compatible = "fsl,imx-osc", "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2400>;
@@ -45,10 +43,7 @@
};
soc {
- u-boot,dm-spl;
-
semc: semc@402f {
- u-boot,dm-spl;
compatible = "fsl,imxrt-semc";
reg = <0x402f 0x4000>;
clocks = <&clks IMXRT1020_CLK_SEMC>;
@@ -73,7 +68,6 @@
};
clks: ccm@400fc000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt1020-ccm";
reg = <0x400fc000 0x4000>;
interrupts = ,
@@ -82,7 +76,6 @@
};
usdhc1: usdhc@402c {
- u-boot,dm-spl;
compatible = "fsl,imxrt-usdhc";
reg = <0x402c 0x1>;
interrupts = ;
@@ -95,7 +88,6 @@
};
gpio1: gpio@401b8000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401b8000 0x4000>;
interrupts = ,
@@ -107,7 +99,6 @@
};
gpio2: gpio@401bc000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401bc000 0x4000>;
interrupts = ,
@@ -119,7 +110,6 @@
};
gpio3: gpio@401c {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401c 0x4000>;
interrupts = ,
--
2.25.1
[PATCH 3/3] ARM: dts: imxrt1020: add gpio5 node to this SoC
i.MXRT1020 supports gpio5, so let's add a node for it.
Signed-off-by: Giulio Benetti
---
arch/arm/dts/imxrt1020.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/dts/imxrt1020.dtsi b/arch/arm/dts/imxrt1020.dtsi
index 884d57f614..5ba314f995 100644
--- a/arch/arm/dts/imxrt1020.dtsi
+++ b/arch/arm/dts/imxrt1020.dtsi
@@ -120,6 +120,17 @@
#interrupt-cells = <2>;
};
+ gpio5: gpio@400c {
+ compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
+ reg = <0x400c 0x4000>;
+ interrupts = ,
+ ;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
gpt1: gpt1@401ec000 {
compatible = "fsl,imxrt-gpt";
reg = <0x401ec000 0x4000>;
--
2.25.1
[PATCH 1/3] ARM: dts: imxrt1050-evk: move all u-boot, dm-spl to imxrt1050-evk-u-boot.dtsi file
At the moment a lot of u-boot,dm-spl properties are present in board .dts
file but this is not correct since u-boot,dm-spl property is u-boot
specific and must be listed into the separate imrt1050-evk-u-boot.dtsi
file. So let's move every u-boot,dm-spl property present in
imxrt1050-evk.dts to imxrt1050-evk-u-boot.dtsi file.
Signed-off-by: Giulio Benetti
---
arch/arm/dts/imxrt1050-evk-u-boot.dtsi | 38 ++
arch/arm/dts/imxrt1050.dtsi| 13 -
2 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/imxrt1050-evk-u-boot.dtsi
b/arch/arm/dts/imxrt1050-evk-u-boot.dtsi
index a4b50f0bb2..3168c2df2c 100644
--- a/arch/arm/dts/imxrt1050-evk-u-boot.dtsi
+++ b/arch/arm/dts/imxrt1050-evk-u-boot.dtsi
@@ -8,6 +8,42 @@
chosen {
u-boot,dm-spl;
};
+
+ clocks {
+ u-boot,dm-spl;
+ };
+
+ soc {
+ u-boot,dm-spl;
+ };
+};
+
+&osc {
+ u-boot,dm-spl;
+};
+
+&clks {
+ u-boot,dm-spl;
+};
+
+&gpio1 {
+ u-boot,dm-spl;
+};
+
+&gpio2 {
+ u-boot,dm-spl;
+};
+
+&gpio3 {
+ u-boot,dm-spl;
+};
+
+&gpio4 {
+ u-boot,dm-spl;
+};
+
+&gpio5 {
+ u-boot,dm-spl;
};
&gpt1 {
@@ -19,6 +55,8 @@
};
&semc {
+ u-boot,dm-spl;
+
bank1: bank@0 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imxrt1050.dtsi b/arch/arm/dts/imxrt1050.dtsi
index 5f5a98e19e..e21f92864f 100644
--- a/arch/arm/dts/imxrt1050.dtsi
+++ b/arch/arm/dts/imxrt1050.dtsi
@@ -27,10 +27,7 @@
};
clocks {
- u-boot,dm-spl;
-
osc: osc {
- u-boot,dm-spl;
compatible = "fsl,imx-osc", "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2400>;
@@ -38,10 +35,7 @@
};
soc {
- u-boot,dm-spl;
-
semc: semc@402f {
- u-boot,dm-spl;
compatible = "fsl,imxrt-semc";
reg = <0x402f 0x4000>;
clocks = <&clks IMXRT1050_CLK_SEMC>;
@@ -66,7 +60,6 @@
};
clks: ccm@400fc000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt1050-ccm";
reg = <0x400fc000 0x4000>;
interrupts = ,
@@ -75,7 +68,6 @@
};
usdhc1: usdhc@402c {
- u-boot,dm-spl;
compatible = "fsl,imxrt-usdhc";
reg = <0x402c 0x1>;
interrupts = ;
@@ -88,7 +80,6 @@
};
gpio1: gpio@401b8000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401b8000 0x4000>;
interrupts = ,
@@ -100,7 +91,6 @@
};
gpio2: gpio@401bc000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401bc000 0x4000>;
interrupts = ,
@@ -112,7 +102,6 @@
};
gpio3: gpio@401c {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401c 0x4000>;
interrupts = ,
@@ -124,7 +113,6 @@
};
gpio4: gpio@401c4000 {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x401c4000 0x4000>;
interrupts = ,
@@ -136,7 +124,6 @@
};
gpio5: gpio@400c {
- u-boot,dm-spl;
compatible = "fsl,imxrt-gpio", "fsl,imx35-gpio";
reg = <0x400c 0x4000>;
interrupts = ,
--
2.25.1
Re: [PATCH] sandbox: cros-ec: Add tests for the cros-ec-pwm driver
Am 16. Mai 2021 17:41:44 MESZ schrieb Alper Nebi Yasak
:
>This patch lets sandbox-cros-ec emulate a limited pwm device which has
>multiple channels but can only set a duty cycle for each, as the actual
>EC doesn't expose any functionality or information other than that.
>Mapping non-generic EC_PWM_TYPE_* values to these emulated pwm channels
>is not implemented as nothing in U-Boot uses these types.
This commit messages is full of of abbreviations which makes it unclear.
Please, use human readable terms.
I guess you might be talking about
Chromium OS
Embedded Controller
Pulse Width Modulation
But I am not sure.
Best regards
Heinrich
>
>This emulated pwm is then used to test the cros-ec-pwm driver in
>sandbox. Adding the cros-ec-pwm node to the sandbox test device-tree
>unfortunately makes it the first pwm device, so this also touches some
>other tests to make sure they still use the sandbox pwm.
>
>Signed-off-by: Alper Nebi Yasak
>---
>This depends on a small fix [1] for cros-ec-pwm which otherwise fails
>to
>build.
>
>[1]
>https://patchwork.ozlabs.org/project/uboot/patch/20210514134840.19380-1-alpernebiya...@gmail.com/
>
> arch/sandbox/dts/test.dts | 6 +++
> arch/sandbox/include/asm/test.h| 10 +
> configs/sandbox64_defconfig| 1 +
> configs/sandbox_defconfig | 1 +
> configs/sandbox_flattree_defconfig | 1 +
> configs/sandbox_noinst_defconfig | 1 +
> configs/sandbox_spl_defconfig | 1 +
> drivers/misc/cros_ec_sandbox.c | 47 +++
> test/cmd/pwm.c | 32 +++-
> test/dm/Makefile | 1 +
> test/dm/cros_ec_pwm.c | 60 ++
> test/dm/panel.c| 2 +-
> test/dm/pwm.c | 6 ++-
> 13 files changed, 164 insertions(+), 5 deletions(-)
> create mode 100644 test/dm/cros_ec_pwm.c
>
>diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
>index 5ca3bc502a43..c684ff0b6db8 100644
>--- a/arch/sandbox/dts/test.dts
>+++ b/arch/sandbox/dts/test.dts
>@@ -139,6 +139,12 @@
> size = <0x1>;
> };
> };
>+
>+ cros_ec_pwm: cros-ec-pwm {
>+ compatible = "google,cros-ec-pwm";
>+ #pwm-cells = <1>;
>+ };
>+
> };
>
> dsi_host: dsi_host {
>diff --git a/arch/sandbox/include/asm/test.h
>b/arch/sandbox/include/asm/test.h
>index 1cb960ac240d..dab1a4ea01b3 100644
>--- a/arch/sandbox/include/asm/test.h
>+++ b/arch/sandbox/include/asm/test.h
>@@ -275,4 +275,14 @@ void sandbox_set_enable_memio(bool enable);
> */
> void sandbox_cros_ec_set_test_flags(struct udevice *dev, uint flags);
>
>+/**
>+ * sandbox_cros_ec_get_pwm_duty() - Get EC PWM config for testing
>purposes
>+ *
>+ * @dev: Device to check
>+ * @index: PWM channel index
>+ * @duty: Current duty cycle in 0..EC_PWM_MAX_DUTY range.
>+ * @return 0 if OK, -ENOSPC if the PWM number is invalid
>+ */
>+int sandbox_cros_ec_get_pwm_duty(struct udevice *dev, uint index, uint
>*duty);
>+
> #endif
>diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
>index 9a373bab6fe3..188ce05cfbf1 100644
>--- a/configs/sandbox64_defconfig
>+++ b/configs/sandbox64_defconfig
>@@ -186,6 +186,7 @@ CONFIG_REGULATOR_S5M8767=y
> CONFIG_DM_REGULATOR_SANDBOX=y
> CONFIG_REGULATOR_TPS65090=y
> CONFIG_DM_PWM=y
>+CONFIG_PWM_CROS_EC=y
> CONFIG_PWM_SANDBOX=y
> CONFIG_RAM=y
> CONFIG_REMOTEPROC_SANDBOX=y
>diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
>index bdbf714e2bd9..6c7a2f02718b 100644
>--- a/configs/sandbox_defconfig
>+++ b/configs/sandbox_defconfig
>@@ -223,6 +223,7 @@ CONFIG_DM_REGULATOR_SANDBOX=y
> CONFIG_REGULATOR_TPS65090=y
> CONFIG_DM_REGULATOR_SCMI=y
> CONFIG_DM_PWM=y
>+CONFIG_PWM_CROS_EC=y
> CONFIG_PWM_SANDBOX=y
> CONFIG_RAM=y
> CONFIG_REMOTEPROC_SANDBOX=y
>diff --git a/configs/sandbox_flattree_defconfig
>b/configs/sandbox_flattree_defconfig
>index 853c9440ea02..0844d6ec23eb 100644
>--- a/configs/sandbox_flattree_defconfig
>+++ b/configs/sandbox_flattree_defconfig
>@@ -163,6 +163,7 @@ CONFIG_REGULATOR_S5M8767=y
> CONFIG_DM_REGULATOR_SANDBOX=y
> CONFIG_REGULATOR_TPS65090=y
> CONFIG_DM_PWM=y
>+CONFIG_PWM_CROS_EC=y
> CONFIG_PWM_SANDBOX=y
> CONFIG_RAM=y
> CONFIG_REMOTEPROC_SANDBOX=y
>diff --git a/configs/sandbox_noinst_defconfig
>b/configs/sandbox_noinst_defconfig
>index c7fc98b5569a..629bde1f7ed6 100644
>--- a/configs/sandbox_noinst_defconfig
>+++ b/configs/sandbox_noinst_defconfig
>@@ -181,6 +181,7 @@ CONFIG_REGULATOR_S5M8767=y
> CONFIG_DM_REGULATOR_SANDBOX=y
> CONFIG_REGULATOR_TPS65090=y
> CONFIG_DM_PWM=y
>+CONFIG_PWM_CROS_EC=y
> CONFIG_PWM_SANDBOX=y
> CONFIG_RAM=y
> CONFIG_REMOTEPROC_SANDBOX=y
>diff --git a/configs/sandbox_spl_defconfig
>b/configs/sandbox_spl_defconfig
>index 87223a54d873..aa629e231753 100644
>--- a/configs/sandbox_spl_defconfig
>+++ b/configs/sandbox_spl_defconfig
>@@ -183,6 +183,7 @@ CONFIG_REGULATOR_S5M87
[PULL] u-boot-usb/master
The following changes since commit e644dfbb1786a4a3308b068e1f61cd9e2dfac237: configs: Resync with savedefconfig (2021-05-15 08:10:13 -0400) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to a5f9be1ed5a5e3a89478edd2f544e667046cd5ea: usb: dwc3-generic: Disable host driver definition if gadget only (2021-05-16 19:01:45 +0200) Andre Przywara (1): usb: musb-new: Extend and move Allwinner quirk into Kconfig Kunihiko Hayashi (1): usb: dwc3-generic: Disable host driver definition if gadget only drivers/usb/dwc3/dwc3-generic.c | 3 ++- drivers/usb/musb-new/Kconfig | 10 ++ drivers/usb/musb-new/musb_regs.h | 3 +-- 3 files changed, 13 insertions(+), 3 deletions(-)
Re: [PATCH] env: Leave invalid env for nowhere location
On 5/12/21 4:09 PM, Kunihiko Hayashi wrote:
When CONFIG_ENV_IS_NOWHERE is enabled, env_nowhere_init() sets ENV_INVALID
to gd->env_valid, and sets default_environment before relocation to
gd->env_addr. After that, env_init() switches gd->env_valid to ENV_VALID
by the previous fix.
If gd->env_valid is ENV_INVALID, env_get_char() returns relocated
default_environment, however, env_get_char() returns gd->env_addr before
relocation since gd->env_valid is ENV_VALID, and access to gd->env_addr
will cause a fault.
This leaves gd->env_valid as ENV_INVALID for "nowhere" location.
Cc: Marek Vasut
Fixes: 5557eec01cbf ("env: Fix invalid env handling in env_init()")
Signed-off-by: Kunihiko Hayashi
---
env/env.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/env/env.c b/env/env.c
index e534008..3233172 100644
--- a/env/env.c
+++ b/env/env.c
@@ -336,7 +336,8 @@ int env_init(void)
debug("%s: Environment %s init done (ret=%d)\n", __func__,
drv->name, ret);
- if (gd->env_valid == ENV_INVALID)
+ if (gd->env_valid == ENV_INVALID
+ && drv->location != ENVL_NOWHERE)
ret = -ENOENT;
}
I'm CCing Tim, it would be good to get a TB from him.
[PATCH] sandbox: cros-ec: Add tests for the cros-ec-pwm driver
This patch lets sandbox-cros-ec emulate a limited pwm device which has
multiple channels but can only set a duty cycle for each, as the actual
EC doesn't expose any functionality or information other than that.
Mapping non-generic EC_PWM_TYPE_* values to these emulated pwm channels
is not implemented as nothing in U-Boot uses these types.
This emulated pwm is then used to test the cros-ec-pwm driver in
sandbox. Adding the cros-ec-pwm node to the sandbox test device-tree
unfortunately makes it the first pwm device, so this also touches some
other tests to make sure they still use the sandbox pwm.
Signed-off-by: Alper Nebi Yasak
---
This depends on a small fix [1] for cros-ec-pwm which otherwise fails to
build.
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210514134840.19380-1-alpernebiya...@gmail.com/
arch/sandbox/dts/test.dts | 6 +++
arch/sandbox/include/asm/test.h| 10 +
configs/sandbox64_defconfig| 1 +
configs/sandbox_defconfig | 1 +
configs/sandbox_flattree_defconfig | 1 +
configs/sandbox_noinst_defconfig | 1 +
configs/sandbox_spl_defconfig | 1 +
drivers/misc/cros_ec_sandbox.c | 47 +++
test/cmd/pwm.c | 32 +++-
test/dm/Makefile | 1 +
test/dm/cros_ec_pwm.c | 60 ++
test/dm/panel.c| 2 +-
test/dm/pwm.c | 6 ++-
13 files changed, 164 insertions(+), 5 deletions(-)
create mode 100644 test/dm/cros_ec_pwm.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5ca3bc502a43..c684ff0b6db8 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -139,6 +139,12 @@
size = <0x1>;
};
};
+
+ cros_ec_pwm: cros-ec-pwm {
+ compatible = "google,cros-ec-pwm";
+ #pwm-cells = <1>;
+ };
+
};
dsi_host: dsi_host {
diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
index 1cb960ac240d..dab1a4ea01b3 100644
--- a/arch/sandbox/include/asm/test.h
+++ b/arch/sandbox/include/asm/test.h
@@ -275,4 +275,14 @@ void sandbox_set_enable_memio(bool enable);
*/
void sandbox_cros_ec_set_test_flags(struct udevice *dev, uint flags);
+/**
+ * sandbox_cros_ec_get_pwm_duty() - Get EC PWM config for testing purposes
+ *
+ * @dev: Device to check
+ * @index: PWM channel index
+ * @duty: Current duty cycle in 0..EC_PWM_MAX_DUTY range.
+ * @return 0 if OK, -ENOSPC if the PWM number is invalid
+ */
+int sandbox_cros_ec_get_pwm_duty(struct udevice *dev, uint index, uint *duty);
+
#endif
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 9a373bab6fe3..188ce05cfbf1 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -186,6 +186,7 @@ CONFIG_REGULATOR_S5M8767=y
CONFIG_DM_REGULATOR_SANDBOX=y
CONFIG_REGULATOR_TPS65090=y
CONFIG_DM_PWM=y
+CONFIG_PWM_CROS_EC=y
CONFIG_PWM_SANDBOX=y
CONFIG_RAM=y
CONFIG_REMOTEPROC_SANDBOX=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index bdbf714e2bd9..6c7a2f02718b 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -223,6 +223,7 @@ CONFIG_DM_REGULATOR_SANDBOX=y
CONFIG_REGULATOR_TPS65090=y
CONFIG_DM_REGULATOR_SCMI=y
CONFIG_DM_PWM=y
+CONFIG_PWM_CROS_EC=y
CONFIG_PWM_SANDBOX=y
CONFIG_RAM=y
CONFIG_REMOTEPROC_SANDBOX=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index 853c9440ea02..0844d6ec23eb 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -163,6 +163,7 @@ CONFIG_REGULATOR_S5M8767=y
CONFIG_DM_REGULATOR_SANDBOX=y
CONFIG_REGULATOR_TPS65090=y
CONFIG_DM_PWM=y
+CONFIG_PWM_CROS_EC=y
CONFIG_PWM_SANDBOX=y
CONFIG_RAM=y
CONFIG_REMOTEPROC_SANDBOX=y
diff --git a/configs/sandbox_noinst_defconfig b/configs/sandbox_noinst_defconfig
index c7fc98b5569a..629bde1f7ed6 100644
--- a/configs/sandbox_noinst_defconfig
+++ b/configs/sandbox_noinst_defconfig
@@ -181,6 +181,7 @@ CONFIG_REGULATOR_S5M8767=y
CONFIG_DM_REGULATOR_SANDBOX=y
CONFIG_REGULATOR_TPS65090=y
CONFIG_DM_PWM=y
+CONFIG_PWM_CROS_EC=y
CONFIG_PWM_SANDBOX=y
CONFIG_RAM=y
CONFIG_REMOTEPROC_SANDBOX=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 87223a54d873..aa629e231753 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -183,6 +183,7 @@ CONFIG_REGULATOR_S5M8767=y
CONFIG_DM_REGULATOR_SANDBOX=y
CONFIG_REGULATOR_TPS65090=y
CONFIG_DM_PWM=y
+CONFIG_PWM_CROS_EC=y
CONFIG_PWM_SANDBOX=y
CONFIG_RAM=y
CONFIG_REMOTEPROC_SANDBOX=y
diff --git a/drivers/misc/cros_ec_sandbox.c b/drivers/misc/cros_ec_sandbox.c
index bc01df0904eb..db5e3b0f51a2 100644
--- a/drivers/misc/cros_ec_sandbox.c
+++ b/drivers/misc/cros_ec_sandbox.c
@@ -64,6 +64,7 @@ struct ec_keymatrix_entry {
enum {
RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
Hello Ricardo, > -Original Message- > From: Ricardo Salveti > Sent: Friday, May 14, 2021 5:29 PM > To: Fabio Estevam > Cc: ZHIZHIKIN Andrey ; Peng Fan > (OSS) ; sba...@denx.de; u-boot@lists.denx.de; uboot- > i...@nxp.com; Ye Li ; vanessa.maeg...@foundries.io; > igor.opan...@foundries.io > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > Hi Fabio, > > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam wrote: > > > > Hi Andrey, > > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > > wrote: > > > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > > > > > This commit seems rather a "nuclear" to me, as de-facto it drops the > initialization of ROMH PMIC in > > > favor of PCA one, leaving all the previous board revisions not to be > > > properly > sourced. > > > > > > I know that there might be no intention to provide a support for earlier > revisions of i.MX8M Mini > > > EVKs from NXP, but providing no backward compatibility to those boards > which are still in use by > > > a lot of people for development purposes is highly undesirable either. > > > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and > apart from having some > > > error messages in SPL regarding the register writes - it does boots. What > worries me the most though > > > is that DTS changes some voltage settings, which I'm not sure how the SOC > would react on. > > > > > > To my opinion, this patch should either be complemented with the > mechanism to provide a > > > level of backward compatibility (where the PMIC can be dynamically > identified and instantiated), > > > or the separate implementation should be presented which would make the > old board type not to > > > be bootable at all if it is considered not to be supported any longer. Or > > > this > patch should be reverted > > > in an effort to come up with a solution which covers new revision without > "damaging" the currently > > > integrated one. > > > > > > Fabio / Stefano, > > > Do you have any thoughts here on how this should be handled further, > considering the fact that the > > > backward compatibility of 2021.07 release is not kept for this board type > across multiple revisions? > > > > > > I'd really like to get your opinion here as I do have those boards in > development and would need to > > > come up with the idea on what to do with them. > > > > > > Also, this should be taken care of in the Yocto, since there is only one > definition of the i.MX8MM EVK > > > machine which does not make any distinction regarding the revision. > > > > You bring a good point. > > > > What about adding a new defconfig to support the old imx8mm-evk with > > the Rohm PMIC? > > > > Then we could have imx8mm_evk_defconfig for the new version and > > imx8mm_evk_rohm_defconfig for the old one. > > > > What do you think? > > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) > would work better? This might be solution given that there is an implementation in SPL which can be used to query I2C to determine the PMIC type and get it dynamically. I'm not aware if this functionality exist, I would need to search for the reference in the U-Boot tree for this. But still, as I previously replied to Fabio, it would still need to have 2 separate entries in DTS for both PMICs, and SPL power_init_board(void) code should be extended to request the PMIC based on the type detected. I guess this can be done in 2 steps: first make the PMIC selection based on the config option in SPL, and then - replace it with dynamic query (if possible). > > Different configs would imply different builds and binaries, which is > a problem when trying to support a single build for both the old EVK > and EVKB (and the main difference is the PMIC, nothing really major). This is especially true for Yocto builds, but there would be a way to define separate U-Boot config based on the type, so having 2 separate config files would not be technically impossible to achieve. However, I totally agree with you - one build for both revisions would be the best solution here. > > I also share Andrey's concerns, as we do have several EVKs in hands, > and having one single build would facilitate quite a bit. > > Cheers, > -- > Ricardo Salveti de Araujo -- andrey
RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
Hello Fabio, > -Original Message- > From: Fabio Estevam > Sent: Friday, May 14, 2021 2:31 PM > To: ZHIZHIKIN Andrey > Cc: Peng Fan (OSS) ; sba...@denx.de; u- > b...@lists.denx.de; uboot-...@nxp.com; Ye Li > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > Hi Andrey, > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey geosystems.com> wrote: > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > > > This commit seems rather a "nuclear" to me, as de-facto it drops the > > initialization of ROMH PMIC in favor of PCA one, leaving all the previous > > board > revisions not to be properly sourced. > > > > I know that there might be no intention to provide a support for > > earlier revisions of i.MX8M Mini EVKs from NXP, but providing no > > backward compatibility to those boards which are still in use by a lot of > > people > for development purposes is highly undesirable either. > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, > > and apart from having some error messages in SPL regarding the > > register writes - it does boots. What worries me the most though is that DTS > changes some voltage settings, which I'm not sure how the SOC would react on. > > > > To my opinion, this patch should either be complemented with the > > mechanism to provide a level of backward compatibility (where the PMIC > > can be dynamically identified and instantiated), or the separate > > implementation should be presented which would make the old board type > > not to be bootable at all if it is considered not to be supported any > > longer. Or this patch should be reverted in an effort to come up with a > > solution > which covers new revision without "damaging" the currently integrated one. > > > > Fabio / Stefano, > > Do you have any thoughts here on how this should be handled further, > > considering the fact that the backward compatibility of 2021.07 release is > > not > kept for this board type across multiple revisions? > > > > I'd really like to get your opinion here as I do have those boards in > > development and would need to come up with the idea on what to do with > them. > > > > Also, this should be taken care of in the Yocto, since there is only > > one definition of the i.MX8MM EVK machine which does not make any > distinction regarding the revision. > > You bring a good point. > > What about adding a new defconfig to support the old imx8mm-evk with the > Rohm PMIC? This would not be the only change that is necessary to provide support for both ROMH and PCA PMIC ICs. From the commit, it seems that also the "duplication" should be done in DTS and SPL PMIC code in power_init_board(void) should also be adapted to get PMIC based on the config option. I'm not saying it is not feasible - it is perfectly doable, but would require some verification afterwards. I can try to come up with the patch set for this but cannot commit to test the change since I do not own a updated EVK board. I guess an ideal situation would be that NXP can step in here to provide the better version of this patch where both revisions are supported, and they can verify the change on both EVK revisions. > > Then we could have imx8mm_evk_defconfig for the new version and > imx8mm_evk_rohm_defconfig for the old one. Yes, ultimately this would be possible provided that both DTS and SPL code are made in a way to provide implementation for both PMIC types. > > What do you think? > > Thanks -- andrey
[PATCH 1/1] xilinx: disable Unicode capitalization
Save some KiB when building xilinx_versal_virt_defconfig by disabling Unicode capitalization support. This avoids build failures when adding new features for the UEFI sub-system. Signed-off-by: Heinrich Schuchardt --- It would be preferable to have a size check for the u-boot binary. This would avoid seeing problems only during execution. --- configs/xilinx_versal_virt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 707693713a..8bc2ff4a4c 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -111,3 +111,4 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x0300 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_FUNCTION_THOR=y CONFIG_OF_LIBFDT_OVERLAY=y +# CONFIG_EFI_UNICODE_CAPITALIZATION is not set -- 2.30.2
