Re: [PATCH v3] rng: Add Turris Mox rTWM RNG driver
Hi Max,
On 2/7/24 16:00, Max Resch wrote:
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
from CZ.NIC in the secure processor.
Signed-off-by: Max Resch
---
Changes in v3:
- More meaningful variable names in accordance with review
Changes in v2:
- Removed ring buffer implementation
drivers/rng/turris_rwtm_rng.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rng/turris_rwtm_rng.c b/drivers/rng/turris_rwtm_rng.c
index 143fe0b47f..ec2cb0bca3 100644
--- a/drivers/rng/turris_rwtm_rng.c
+++ b/drivers/rng/turris_rwtm_rng.c
@@ -41,18 +41,19 @@ static int turris_rwtm_rng_fill_entropy(phys_addr_t
entropy, size_t size)
static int turris_rwtm_rng_random_read(struct udevice *dev, void *data, size_t count)
{
- phys_addr_t p;
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys;
You've now just sent the update v2->v3. As v2 is not applied yet
this is not the way to do it. Please squash this patch into the v2
one a send this as v3 or even better v4 now.
Thanks,
Stefan
size_t size;
int ret;
- p = ((struct turris_rwtm_rng_priv *)dev_get_priv(dev))->buffer;
+ phys = priv->buffer;
while (count) {
size = min_t(size_t, RNG_BUFFER_SIZE, count);
- ret = turris_rwtm_rng_fill_entropy(p, size);
+ ret = turris_rwtm_rng_fill_entropy(phys, size);
- memcpy(data, (void *)p, size);
+ memcpy(data, (void *)phys, size);
count -= size;
data = (u8 *)data + size;
}
@@ -62,7 +63,7 @@ static int turris_rwtm_rng_random_read(struct udevice *dev,
void *data, size_t c
static int turris_rwtm_rng_probe(struct udevice *dev)
{
- struct turris_rwtm_rng_priv *priv;
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
u32 args[] = { 0 };
int ret;
@@ -76,7 +77,6 @@ static int turris_rwtm_rng_probe(struct udevice *dev)
return ret;
/* entropy buffer */
- priv = (struct turris_rwtm_rng_priv *)dev_get_priv(dev);
priv->buffer = 0;
/* buffer address need to be aligned */
@@ -89,10 +89,10 @@ static int turris_rwtm_rng_probe(struct udevice *dev)
static int turris_rwtm_rng_remove(struct udevice *dev)
{
- phys_addr_t p;
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys = priv->buffer;
- p = ((struct turris_rwtm_rng_priv *)dev_get_priv(dev))->buffer;
- dma_free_coherent((void *)p);
+ dma_free_coherent((void *)phys);
return 0;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v4] misc: fs-loader: Use fw_storage_interface instead of storage_interface
Hi Sean, On 07/02/24 11:14 pm, Sean Anderson wrote: > On 1/30/24 01:26, MD Danish Anwar wrote: >> The fs-loader driver reads env storage_interface and uses it to load >> firmware file into memory using the medium set by env. Update the driver >> to use env fw_storage_interface as this variable is only used to load >> firmwares. The env storage_interface will act as fallback so that the >> existing implementations do not break. >> >> Also update the FS Loader documentation accordingly. > > So why do you want to do this? I don't see what the point of renaming the > variable is, since you are not e.g. adding any new functionality, and we > have to pay for the rename in code size. > I am upstreaming TI's ICSSG driver for u-boot and during code review Roger Quadros commented asking to rename this variable [1]. I think the motive here was to keep all variables used by fs-loader driver with 'fw_' prefix. All other variables had 'fw_' prefix except for storage_interface. [1] https://lore.kernel.org/all/4721f3b9-f823-47f3-b4f3-ed40002af...@kernel.org/ > --Sean -- Thanks and Regards, Danish
Re: [PATCH 13/15] rockchip: rk3328: Add support to build bootable SPI image
Hello Jonas,
On 2024-02-07 01:02, Jonas Karlman wrote:
Similar to RK35xx the BootRom in RK3328 can read all data and look for
idbloader at 0x8000, same as on SD and eMMC.
Use the rksd format and modify the mkimage offset to generate a
bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
Signed-off-by: Jonas Karlman
Could you, please, clarify a bit why the "rkspi" format isn't used
instead of "rksd"?
---
arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
arch/arm/mach-rockchip/rk3328/rk3328.c | 1 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
b/arch/arm/dts/rk3328-u-boot.dtsi
index b90d78878d77..2a5dca97dd4b 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -120,3 +120,14 @@
_otg {
hnp-srp-disable;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+ offset = <0x8000>;
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index b591d38fe412..b82b209de9e2 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -36,6 +36,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff19/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@ff50",
};
[PATCH] FWU: developerbox: read boot index from NOR flash
The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks).
On the Developerbox, SCP-firmware running on the SCB(Cortex-M3)
passes the value of the boot index on the NOR flash.
Add a function to read the boot index value from the NOR flash.
Signed-off-by: Masahisa Kojima
---
board/socionext/developerbox/fwu_plat.c | 31 +
include/configs/synquacer.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/board/socionext/developerbox/fwu_plat.c
b/board/socionext/developerbox/fwu_plat.c
index e724e702bd..26031795b0 100644
--- a/board/socionext/developerbox/fwu_plat.c
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -35,3 +35,34 @@ void set_dfu_alt_info(char *interface, char *devstr)
env_set("dfu_alt_info", buf);
}
+
+/**
+ * fwu_plat_get_bootidx() - Get the value of the boot index
+ * @boot_idx: Boot index value
+ *
+ * Get the value of the bank(partition) from which the platform
+ * has booted. This value is passed to U-Boot from the earlier
+ * stage bootloader which loads and boots all the relevant
+ * firmware images
+ */
+void fwu_plat_get_bootidx(uint *boot_idx)
+{
+ int ret;
+ u32 buf;
+ size_t readlen;
+ struct mtd_info *mtd;
+
+ *boot_idx = 0;
+
+ mtd_probe_devices();
+ mtd = get_mtd_device_nm("nor1");
+ if (IS_ERR_OR_NULL(mtd))
+ return;
+
+ ret = mtd_read(mtd, SCB_PLAT_METADATA_OFFSET, sizeof(buf),
+ , (u_char *));
+ if (ret < 0)
+ return;
+
+ *boot_idx = buf;
+}
diff --git a/include/configs/synquacer.h b/include/configs/synquacer.h
index e36e63e81e..f0867227ac 100644
--- a/include/configs/synquacer.h
+++ b/include/configs/synquacer.h
@@ -21,6 +21,7 @@
/*
* Boot info
*/
+#define SCB_PLAT_METADATA_OFFSET (0x51)
/*
* Hardware drivers support
--
2.34.1
Re: inconsistent wget behavior
Hi Paul, On Wed, Jan 10, 2024 at 9:20 AM Fabio Estevam wrote: > One colleague from you at Linaro was able to reproduce the bug: > > https://lore.kernel.org/u-boot/cadq0-x_cj1ecn67u3sefcz-jm4obsymzka+jazrca3ekq84...@mail.gmail.com/ > > It is not specific to i.MX. Have you had a chance to look into this wget problem?
Re: [PATCH v4] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 1/30/24 01:26, MD Danish Anwar wrote: The fs-loader driver reads env storage_interface and uses it to load firmware file into memory using the medium set by env. Update the driver to use env fw_storage_interface as this variable is only used to load firmwares. The env storage_interface will act as fallback so that the existing implementations do not break. Also update the FS Loader documentation accordingly. So why do you want to do this? I don't see what the point of renaming the variable is, since you are not e.g. adding any new functionality, and we have to pay for the rename in code size. --Sean
Re: [PATCH v1] cmd: hash: fix param count check
Hi Tom,
On Wed, Feb 7, 2024 at 1:01 AM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Add correct check for parameter count.
>
> This fixes this issue when `hash` cmd is invoked without params:
>
> => hash
> data abort
> pc : [] lr : []
> reloc pc : [<60019204>]lr : [<5afcffa8>]
> sp : ba6dd9c8 ip : bf7391f0 fp : bf74ec14
> r10: 0001 r9 : ba6dfea0 r8 : bf7ea030
> r7 : r6 : ba6effa8 r5 : r4 :
> r3 : bf7c257c r2 : 0001 r1 : r0 : bf7e6e34
> Flags: nZCv IRQs off FIQs on Mode SVC_32
> Code: e5934004 e1a0e003 e59f3050 e2444001 (e5f4c001)
> Resetting CPU ...
>
> resetting ...
>
> Signed-off-by: Igor Opaniuk
> ---
>
> cmd/hash.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/cmd/hash.c b/cmd/hash.c
> index e163cd67742..5534a735fa7 100644
> --- a/cmd/hash.c
> +++ b/cmd/hash.c
> @@ -14,15 +14,22 @@
> #include
> #include
>
> +#if IS_ENABLED(CONFIG_HASH_VERIFY)
> +#define HARGS 6
> +#else
> +#define HARGS 5
> +#endif
> +
> static int do_hash(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
> {
> char *s;
> int flags = HASH_FLAG_ENV;
>
> -#ifdef CONFIG_HASH_VERIFY
> - if (argc < 4)
> + if (argc < (HARGS - 1))
> return CMD_RET_USAGE;
> +
> +#if IS_ENABLED(CONFIG_HASH_VERIFY)
> if (!strcmp(argv[1], "-v")) {
> flags |= HASH_FLAG_VERIFY;
> argc--;
> @@ -37,18 +44,12 @@ static int do_hash(struct cmd_tbl *cmdtp, int flag, int
> argc,
> return hash_command(*argv, flags, cmdtp, flag, argc - 1, argv + 1);
> }
>
> -#ifdef CONFIG_HASH_VERIFY
> -#define HARGS 6
> -#else
> -#define HARGS 5
> -#endif
> -
> U_BOOT_CMD(
> hash, HARGS, 1, do_hash,
> "compute hash message digest",
> "algorithm address count [[*]hash_dest]\n"
> "- compute message digest [save to env var / *address]"
> -#ifdef CONFIG_HASH_VERIFY
> +#if IS_ENABLED(CONFIG_HASH_VERIFY)
> "\nhash -v algorithm address count [*]hash\n"
> "- verify message digest of memory area to immediate
> value, \n"
> " env var or *address"
> --
> 2.34.1
>
This is a fix, however I haven't added the "Fixes: " tag as I could not find
the commit which introduces this cmd (it seems it was added before
U-Boot moved to git).
For the next merge window I'll refactor all hash cmds as we discussed
in my previous email [1]
[1]
https://lore.kernel.org/u-boot/calede9mdjzjtmdhbg-vfis1e5uvfyn4wwd1hopgywxripfj...@mail.gmail.com/T/#t
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
http://ua.linkedin.com/in/iopaniuk
[PATCH v2 3/3] usb: ehci: Make usage of generic_{setup,shutdown}_phy_bulk() helpers
From: Yang Xiwen
Replace generic_setup_phy() and generic_shutdown_phy() by respectively
generic_setup_phy_bulk() and generic_shutdown_phy_bulk().
Signed-off-by: Yang Xiwen
---
drivers/usb/host/ehci-generic.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index 936e30438d..e109d84d73 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -25,7 +25,7 @@ struct generic_ehci {
struct ehci_ctrl ctrl;
struct clk_bulk clocks;
struct reset_ctl_bulk resets;
- struct phy phy;
+ struct phy_bulk phys;
struct udevice *vbus_supply;
};
@@ -95,7 +95,7 @@ static int ehci_usb_probe(struct udevice *dev)
if (err)
goto reset_err;
- err = generic_setup_phy(dev, >phy, 0);
+ err = generic_setup_phy_bulk(dev, >phys);
if (err)
goto regulator_err;
@@ -110,7 +110,7 @@ static int ehci_usb_probe(struct udevice *dev)
return 0;
phy_err:
- ret = generic_shutdown_phy(>phy);
+ ret = generic_shutdown_phy_bulk(>phys);
if (ret)
dev_err(dev, "failed to shutdown usb phy (ret=%d)\n", ret);
@@ -140,7 +140,7 @@ static int ehci_usb_remove(struct udevice *dev)
if (ret)
return ret;
- ret = generic_shutdown_phy(>phy);
+ ret = generic_shutdown_phy_bulk(>phys);
if (ret)
return ret;
--
2.43.0
[PATCH v2 0/3] usb: ehci-generic: setup a bulk of phy when possible
one USB controller can have multiple ports specified in dts, all of them
should be setup to make use of all possible ports.
Signed-off-by: Yang Xiwen
---
Changes in v2:
- Rewrite generic_phy_setup_bulk(): Actually v1 is doing things
completely wrong. This series should work and it's tested on a real
machine.
- Link to v1:
https://lore.kernel.org/r/20240201-ehci-v1-0-bb506cb0f...@outlook.com
---
Yang Xiwen (3):
phy: add generic_setup(shutdown)_phy_bulk()
test: phy: test generic_setup(shutdown)_phy_bulk()
usb: ehci: Make usage of generic_{setup,shutdown}_phy_bulk() helpers
drivers/phy/phy-uclass.c| 41 +
drivers/usb/host/ehci-generic.c | 8
include/generic-phy.h | 29 +
test/dm/phy.c | 4
4 files changed, 78 insertions(+), 4 deletions(-)
---
base-commit: b6d8969bcb94321dfed1399f2eaa8768ba42caaa
change-id: 20240201-ehci-6c3aa7d97932
Best regards,
--
Yang Xiwen
[PATCH v2 2/3] test: phy: test generic_setup(shutdown)_phy_bulk()
From: Yang Xiwen add unittests for the newly introduced helper functions. Signed-off-by: Yang Xiwen --- test/dm/phy.c | 4 1 file changed, 4 insertions(+) diff --git a/test/dm/phy.c b/test/dm/phy.c index 0cf3689fde..cb16844a0a 100644 --- a/test/dm/phy.c +++ b/test/dm/phy.c @@ -159,6 +159,8 @@ static int dm_test_phy_bulk(struct unit_test_state *uts) ut_asserteq(0, generic_phy_power_on_bulk()); ut_asserteq(0, generic_phy_power_off_bulk()); ut_asserteq(0, generic_phy_exit_bulk()); + ut_asserteq(0, generic_setup_phy_bulk(parent, )); + ut_asserteq(0, generic_shutdown_phy_bulk()); /* has a known problem phy */ ut_assertok(uclass_get_device_by_name(UCLASS_SIMPLE_BUS, @@ -171,6 +173,8 @@ static int dm_test_phy_bulk(struct unit_test_state *uts) ut_asserteq(-EIO, generic_phy_power_on_bulk()); ut_asserteq(-EIO, generic_phy_power_off_bulk()); ut_asserteq(0, generic_phy_exit_bulk()); + ut_asserteq(-EIO, generic_setup_phy_bulk(parent, )); + ut_asserteq(-EIO, generic_shutdown_phy_bulk()); return 0; } -- 2.43.0
[PATCH v2 1/3] phy: add generic_setup(shutdown)_phy_bulk()
From: Yang Xiwen
They are the bulk version of generic_setup(shutdown)_phy().
Signed-off-by: Yang Xiwen
---
drivers/phy/phy-uclass.c | 41 +
include/generic-phy.h| 29 +
2 files changed, 70 insertions(+)
diff --git a/drivers/phy/phy-uclass.c b/drivers/phy/phy-uclass.c
index 0dcfe258bc..1a6bb54290 100644
--- a/drivers/phy/phy-uclass.c
+++ b/drivers/phy/phy-uclass.c
@@ -528,6 +528,36 @@ int generic_setup_phy(struct udevice *dev, struct phy
*phy, int index)
return ret;
}
+int generic_setup_phy_bulk(struct udevice *dev, struct phy_bulk *bulk)
+{
+ int ret;
+
+ ret = generic_phy_get_bulk(dev, bulk);
+ if (ret) {
+ pr_err("Can't get PHY bulk: %d\n", ret);
+ goto phys_get_err;
+ }
+
+ ret = generic_phy_init_bulk(bulk);
+ if (ret) {
+ pr_err("Can't init PHY bulk: %d\n", ret);
+ goto phys_get_err;
+ }
+
+ ret = generic_phy_power_on_bulk(bulk);
+ if (ret) {
+ generic_phy_exit_bulk(bulk);
+ goto phys_setup_err;
+ }
+
+ return 0;
+
+phys_setup_err:
+ generic_phy_exit_bulk(bulk);
+phys_get_err:
+ return ret;
+}
+
int generic_shutdown_phy(struct phy *phy)
{
int ret;
@@ -542,6 +572,17 @@ int generic_shutdown_phy(struct phy *phy)
return generic_phy_exit(phy);
}
+int generic_shutdown_phy_bulk(struct phy_bulk *bulk)
+{
+ struct phy *phys = bulk->phys;
+ int i, ret = 0;
+
+ for (i = 0; i < bulk->count; i++)
+ ret |= generic_shutdown_phy([i]);
+
+ return ret;
+}
+
UCLASS_DRIVER(phy) = {
.id = UCLASS_PHY,
.name = "phy",
diff --git a/include/generic-phy.h b/include/generic-phy.h
index eaab749166..2d1bf7c1ea 100644
--- a/include/generic-phy.h
+++ b/include/generic-phy.h
@@ -420,6 +420,16 @@ int generic_phy_power_off_bulk(struct phy_bulk *bulk);
*/
int generic_setup_phy(struct udevice *dev, struct phy *phy, int index);
+/**
+ * generic_setup_phy() - Get, initialize and power on all phys in a phy bulk.
+ *
+ * @dev: The consumer device.
+ * @bulk: A pointer to the PHY bulk
+ *
+ * Return: 0 if OK, or negative error code.
+ */
+int generic_setup_phy_bulk(struct udevice *dev, struct phy_bulk *bulk);
+
/**
* generic_shutdown_phy() - Power off and de-initialize phy.
*
@@ -429,6 +439,15 @@ int generic_setup_phy(struct udevice *dev, struct phy
*phy, int index);
*/
int generic_shutdown_phy(struct phy *phy);
+/**
+ * generic_shutdown_phy_bulk() - Power off and de-initialize all phys in a phy
bulk.
+ *
+ * @bulk: A pointer to the PHY bulk.
+ *
+ * Return: 0 if OK, or negative error code.
+ */
+int generic_shutdown_phy_bulk(struct phy_bulk *bulk);
+
#else /* CONFIG_PHY */
static inline int generic_phy_init(struct phy *phy)
@@ -514,11 +533,21 @@ static inline int generic_setup_phy(struct udevice *dev,
struct phy *phy, int in
return 0;
}
+static inline int generic_setup_phy_bulk(struct udevice *dev, struct phy_bulk
*bulk)
+{
+ return 0;
+}
+
static inline int generic_shutdown_phy(struct phy *phy)
{
return 0;
}
+static inline int generic_shutdown_phy_bulk(struct phy_bulk *bulk)
+{
+ return 0;
+}
+
#endif /* CONFIG_PHY */
/**
--
2.43.0
Re: imx93-var-som: ahab: U-boot is hanging
Hello, I performed a bisection and was able to fix that issue by reverting three commits on v2024.04-rc1: 0585c28fda1007e4a90dea5f70723cff0b63dd98 eed8294b75a5908a486945ff6655d4dc9aae5fed ee23d7466c77d01ee63efb76db2c5fd3b7cdd6f7 It is still unclear to me how those FEAT_HAFDBS related commits can be linked to my issue. Possibly my issue is a race condition and the timing shifts introduced by those three commits are enough to make the issue go away. To be continued... Thanks, Mathieu
Re: [PATCH] stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD
On Wed, Feb 7, 2024 at 2:12 PM Patrick Delaunay wrote: > > This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated > in defconfig, with undefined reference to run_usb_dnl_gadget and to > g_dnl_set_product. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > index 8f91db4b46b9..589276282e44 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > @@ -17,6 +17,7 @@ config CMD_STM32PROG > config CMD_STM32PROG_USB > bool "support stm32prog over USB" > depends on CMD_STM32PROG > + depends on USB_GADGET_DOWNLOAD > default y > help > activate the command "stm32prog usb" for STM32MP soc family > -- > 2.25.1 > Reviewed-by: Igor Opaniuk -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk Senior Software Engineer, Embedded & Security E: igor.opan...@foundries.io W: www.foundries.io
Re: REGRESSION: [PATCH 5/9] toradex: Use checkboard() instead of show_board_info()
On Wed, Feb 07, 2024 at 03:23:10PM +, Marcel Ziswiler wrote: > Gentle ping on this. Any opinion on that matter much appreciated. Thanks! Perhaps you need to RFC some sysinfo driver that ends up providing what you expect? -- Tom signature.asc Description: PGP signature
Re: [PATCH] blk: host_dev: Fix error code in host_sb_attach_file()
On Wed, Jan 31, 2024 at 10:09:52AM +0300, Dan Carpenter wrote:
> This error path should return -EINVAL instead of success.
>
> Fixes: e261fbf34785 ("blk: host_dev: Sanity check on the size of host backing
> file")
> Signed-off-by: Dan Carpenter
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH V5 2/2] firmware: ti_sci: Add comment explaining the is_secure code
On Tue, Jan 30, 2024 at 08:30:00PM +0530, Dhruva Gole wrote: > Add a comment to explain the code under is_secure condition of > ti_sci_do_xfer. This will help avoid confusion amongst people who may in > future touch upon this code. > > Reviewed-by: Nishanth Menon > Signed-off-by: Dhruva Gole Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V5 1/2] firmware: ti_sci: fix the secure_hdr in do_xfer
On Tue, Jan 30, 2024 at 08:29:59PM +0530, Dhruva Gole wrote:
> The ti_sci driver in U-Boot has support for secure_msg as part of it's
> do_xfer function. This let's U-boot send secure messages during boot up.
>
> The protocol to send such secure messages is described as part of the
> struct ti_sci_secure_msg_hdr. As part of this, there are 2 fields for
> checksum and reserved that occupy the first 4 bytes of any secure
> message. This is called as the secure_hdr.
>
> As of now, the secure_hdr needs to be 0 init-ed before sending secure
> messages. However the existing code was never putting the zero-inited vars
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make secure_hdr members 0, it automatically ensures
> the first 4 bytes of secure_buf are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Reviewed-by: Nishanth Menon
> Signed-off-by: Dhruva Gole
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [RESEND PATCH v2] arm: mach-k3: j721s2_init: Support less than max DDR controllers
On Tue, Jan 30, 2024 at 03:53:56PM +0530, Neha Malcom Francis wrote: > The number of DDR controllers to be initialised and used should depend > on the device tree with the constraint of the maximum number of > controllers the device supports. Since J721S2 has multiple (2) > controllers, instead of hardcoding the number of probes, move to > depending on the device tree UCLASS_RAM nodes present. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Manorit Chawdhry Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4] dma: ti: k3-udma: Use ring_idx to pair k3 nav rings
On Tue, Jan 30, 2024 at 11:48:04AM +0530, MD Danish Anwar wrote: > Use ring_idx to pair rings. ring_idx will be same as tx flow_id for all > non-negative flow_ids. For negative flow_ids, ring_idx will be tchan->id > added with bchan_cnt. > > Link: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/ti/k3-udma.c?h=v6.8-rc2#n1686 > Signed-off-by: MD Danish Anwar > Reviewed-by: Ravi Gunasekaran Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] common: event: check event_type_name() argument
On Sun, Jan 28, 2024 at 08:58:55AM +0100, Heinrich Schuchardt wrote: > In event_type_name() we should avoid possible buffer overruns by checking > the type argument. > > Addresses-Coverity-ID: 478862 Out-of-bounds access > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] vexpress_ca9x4: Enable DM_SERIAL
On Fri, Jan 26, 2024 at 01:47:50PM +0100, Ole P. Orhagen wrote: > This commit enables support for DM_SERIAL in the vexpress_ca9x4 boards. > > When running the board with the DM_SERIAL driver, the board ran out of > memory in SPL when initialising the DM serial driver. > > Thus this required an increase in the pre-allocated SRAM memory. I did > increase it to 0x800, and it now works graciously. > > It could probably be set lower, but I do not see any reason not to use the > available SRAM at this point. > > Also adds stdout-path to the 'chosen' node in the device tree. > > Signed-off-by: Ole P. Orhagen > Reviewed-by: Linus Walleij Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] arm: dts: nuvoton: modify npcm8xx reset property
On Wed, Jan 24, 2024 at 09:54:51AM +0800, Jim Liu wrote: > Change reset method from generic to reset driver > > Signed-off-by: Jim Liu Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/gen_compile_commands: update to Linux v6.7
On Mon, Jan 22, 2024 at 06:45:50PM +, Brandon Maier wrote:
> Adds support for assembly files and updates the LINE_PATTERN so it
> supports both "cmd" and "savedcmd", which allows reverting the U-Boot
> modification in commit 97fbb2eb016b ("scripts/gen_compile_commands.py:
> adapt _LINE_PATTERN").
>
> Upstream commits:
>
> - 880946158b011 gen_compile_commands.py: fix path resolve with symlinks in it
> - 9e56d3be4bfd2 gen_compile_commands: Sort output compile commands by file
> name
> - 52c15e7e79285 gen_compile_commands: Allow the line prefix to still be cmd_
> - 1c67921444bf6 gen_compile_commands: add assembly files to compilation
> database
>
> Signed-off-by: Brandon Maier
> Cc: Joao Marcos Costa
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: Pull request: u-boot-rockchip-20240207
On Wed, Feb 07, 2024 at 04:02:55PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the updates for rockchip platform: > - Add board: rv1126 Sonoff iHost board > - rv1126 ddr4 support; > - Enable BOOTSTD_FULL for RK3399 and RK3588; > - rk3036 spl stack addr fix; > - dts sync from linux v6.8-rc1 for rk356x, rk3588, rv1126; > - Enable eMMC HS200 mode by default for rk3568 and rk3588; > > CI: > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/19556 > > Thanks, > - Kever > > The following changes since commit 819abd0a1eaff9a921f5b917e152b85dab302e33: > > Merge tag 'smbios-2024-04-rc2' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2024-02-03 09:11:25 > -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20240207 > > for you to fetch changes up to b8f1f60c23c9b3edb70159c4e2b1be232a008ee3: > > arm: dts: rockpro64: Add RockPro64 smbios (2024-02-07 10:49:13 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: REGRESSION: [PATCH 5/9] toradex: Use checkboard() instead of show_board_info()
Gentle ping on this. Any opinion on that matter much appreciated. Thanks! On Wed, 2024-01-24 at 18:16 +0100, Marcel Ziswiler wrote: > Hi Simon > > Sorry, I missed this one, also due to a longer Xmas/New Year and later skiing > vacation. > > On Sun, 2023-11-12 at 19:58 -0700, Simon Glass wrote: > > Boards can use a sysinfo driver if a particular model name is needed. > > Okay, but so far we did print more than just a model name: > > On Apalis/Colibri: > > Model: Toradex 0028 Apalis iMX6Q 2GB IT V1.1D > Serial#: 10867499 > > On Verdin: > > Model: Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.1A > Serial#: 14772913 > Carrier: Toradex Dahlia V1.1A, Serial# 10870316 > > Optionally there would even be display adapters with potentially more model > (serial) information. > > Now with your change we get the following: > > On Apalis/Colibri: > > Model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board > Model: Toradex Apalis iMX6 Quad 2GB IT > Model: Toradex 0028 Apalis iMX6Q 2GB IT V1.1D > Serial#: 11211073 > > The first line gets printed from the information in the device tree, the > second Line from the fall-back in > our > board file (which so far was only used for the case when we failed reading > the ConfigBlock) and the third and > fourth lines are the previous information. Ugly, but so far so good. > > On Verdin: > > Model: Toradex Verdin iMX8M Plus WB on Verdin Development Board > > Here only the device tree information gets printed and the ConfigBlock is not > even read at all which > subsequently fails detecting the variant (e.g. Wi-Fi vs. non-Wi-Fi) and later > Ethernet fails due to an > invalid > MAC address. This does not look good... > > Anyway, I don't propose to just revert your work but instead looked into > converting our previous > show_board_info (now tdx_checkboard) to a proper sysinfo driver. The basics > actually worked quite smoothly > but > we would need more than just SYSINFO_ID_BOARD_MODEL, just like you do with > CONFIG_SYSINFO_EXTRA. Of course, I > could just do a CONFIG_SYSINFO_TORADEX, with e.g. SYSINFO_ID_BOARD_SERIAL and > optionally > SYSINFO_ID_BOARD_CARRIER or something but maybe a more generic way of > extending sysinfo would make more > sense. > > What do you think? > > > Update this board to use checkboard() directly, rather than having a > > weak function laid on top of a weak function. > > Unfortunately, as mentioned above, this does not quite lead to any desired > behaviour. > > > Make all the checkboard() functions call the new tdx_checkboard() so > > that the same information is displayed. > > Not quite. > > > Signed-off-by: Simon Glass > > --- > > > > board/toradex/apalis-imx8/apalis-imx8.c | 2 +- > > board/toradex/apalis-tk1/apalis-tk1.c | 2 +- > > board/toradex/apalis_imx6/apalis_imx6.c | 3 ++- > > board/toradex/apalis_t30/apalis_t30.c | 2 +- > > board/toradex/colibri-imx6ull/colibri-imx6ull.c | 2 +- > > board/toradex/colibri-imx8x/colibri-imx8x.c | 2 +- > > board/toradex/colibri_imx6/colibri_imx6.c | 3 ++- > > board/toradex/colibri_imx7/colibri_imx7.c | 2 +- > > board/toradex/colibri_t20/colibri_t20.c | 2 +- > > board/toradex/colibri_t30/colibri_t30.c | 2 +- > > board/toradex/colibri_vf/colibri_vf.c | 2 +- > > board/toradex/common/tdx-common.c | 2 +- > > board/toradex/common/tdx-common.h | 1 + > > 13 files changed, 15 insertions(+), 12 deletions(-) > > [snip] > > > Cheers > > Marcel
[PATCH v3] rng: Add Turris Mox rTWM RNG driver
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
from CZ.NIC in the secure processor.
Signed-off-by: Max Resch
---
Changes in v3:
- More meaningful variable names in accordance with review
Changes in v2:
- Removed ring buffer implementation
drivers/rng/turris_rwtm_rng.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rng/turris_rwtm_rng.c b/drivers/rng/turris_rwtm_rng.c
index 143fe0b47f..ec2cb0bca3 100644
--- a/drivers/rng/turris_rwtm_rng.c
+++ b/drivers/rng/turris_rwtm_rng.c
@@ -41,18 +41,19 @@ static int turris_rwtm_rng_fill_entropy(phys_addr_t
entropy, size_t size)
static int turris_rwtm_rng_random_read(struct udevice *dev, void *data, size_t
count)
{
- phys_addr_t p;
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys;
size_t size;
int ret;
- p = ((struct turris_rwtm_rng_priv *)dev_get_priv(dev))->buffer;
+ phys = priv->buffer;
while (count) {
size = min_t(size_t, RNG_BUFFER_SIZE, count);
- ret = turris_rwtm_rng_fill_entropy(p, size);
+ ret = turris_rwtm_rng_fill_entropy(phys, size);
- memcpy(data, (void *)p, size);
+ memcpy(data, (void *)phys, size);
count -= size;
data = (u8 *)data + size;
}
@@ -62,7 +63,7 @@ static int turris_rwtm_rng_random_read(struct udevice *dev,
void *data, size_t c
static int turris_rwtm_rng_probe(struct udevice *dev)
{
- struct turris_rwtm_rng_priv *priv;
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
u32 args[] = { 0 };
int ret;
@@ -76,7 +77,6 @@ static int turris_rwtm_rng_probe(struct udevice *dev)
return ret;
/* entropy buffer */
- priv = (struct turris_rwtm_rng_priv *)dev_get_priv(dev);
priv->buffer = 0;
/* buffer address need to be aligned */
@@ -89,10 +89,10 @@ static int turris_rwtm_rng_probe(struct udevice *dev)
static int turris_rwtm_rng_remove(struct udevice *dev)
{
- phys_addr_t p;
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys = priv->buffer;
- p = ((struct turris_rwtm_rng_priv *)dev_get_priv(dev))->buffer;
- dma_free_coherent((void *)p);
+ dma_free_coherent((void *)phys);
return 0;
}
--
2.43.0
Re: [RFC] Drop md5sum, crc32 and sha1 cmds in favor of hash cmd
On Wed, 7 Feb 2024 at 13:48, Tom Rini wrote: > > On Wed, Feb 07, 2024 at 02:00:16PM +0100, Igor Opaniuk wrote: > > Hello, > > > > I was playing a bit with different hash functions recently, and > > it turned out that md5sum, crc32, sha1 cmds just duplicate > > what is already covered by generic `hash` cmd. > > > > => sha1 0x6000 0x200 > > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 > > => hash sha1 0x6000 0x200 > > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 > > > > => crc32 0x6000 0x200 > > crc32 for 6000 ... 61ff ==> 6fe352e8 > > => hash crc32 0x6000 0x200 > > crc32 for 6000 ... 61ff ==> 6fe352e8 > > > > => md5sum 0x6000 0x200 > > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > > => hash md5 0x6000 0x200 > > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > > > > Considering that most of them (besides md5sum) are using the same > > int hash_command() function under the hood, but have a lot of duplicated > > code for handling params, does it make sense to do some cleanup and > > drop all them in favour `hash`? > > > > I also plan to extend usage info for `hash` by adding a list > > compiled-in algos based on hash related compiled flags > > (CONFIG_SHA1, CONFIG_CRC32 etc), so it's clear what algos > > are available for hash calculation. > > > > Comments/objections are welcome! > > It would be good, implementation wise, if each of those commands was > just a redirect to hash ..., similar to how "load " will call the > right filesystem calls. Does that make sense? Thanks. Yes, I actually have that one my todo list to basically alias the individual commands to the hash command to remove those commands. My intention there was a first step to allow us to eventually minimise or even remove the use of obsolete hashes etc.
Re: [RFC] Drop md5sum, crc32 and sha1 cmds in favor of hash cmd
On Wed, Feb 07, 2024 at 03:10:01PM +0100, Igor Opaniuk wrote:
> Hi Tom,
>
> On Wed, Feb 7, 2024 at 2:48 PM Tom Rini wrote:
> >
> > On Wed, Feb 07, 2024 at 02:00:16PM +0100, Igor Opaniuk wrote:
> > > Hello,
> > >
> > > I was playing a bit with different hash functions recently, and
> > > it turned out that md5sum, crc32, sha1 cmds just duplicate
> > > what is already covered by generic `hash` cmd.
> > >
> > > => sha1 0x6000 0x200
> > > sha1 for 6000 ... 61ff ==>
> > > 4ff5ffc91d00a95155518b920f46e2483d0e1437
> > > => hash sha1 0x6000 0x200
> > > sha1 for 6000 ... 61ff ==>
> > > 4ff5ffc91d00a95155518b920f46e2483d0e1437
> > >
> > > => crc32 0x6000 0x200
> > > crc32 for 6000 ... 61ff ==> 6fe352e8
> > > => hash crc32 0x6000 0x200
> > > crc32 for 6000 ... 61ff ==> 6fe352e8
> > >
> > > => md5sum 0x6000 0x200
> > > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050
> > > => hash md5 0x6000 0x200
> > > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050
> > >
> > > Considering that most of them (besides md5sum) are using the same
> > > int hash_command() function under the hood, but have a lot of duplicated
> > > code for handling params, does it make sense to do some cleanup and
> > > drop all them in favour `hash`?
> > >
> > > I also plan to extend usage info for `hash` by adding a list
> > > compiled-in algos based on hash related compiled flags
> > > (CONFIG_SHA1, CONFIG_CRC32 etc), so it's clear what algos
> > > are available for hash calculation.
> > >
> > > Comments/objections are welcome!
> >
> > It would be good, implementation wise, if each of those commands was
> > just a redirect to hash ..., similar to how "load " will call the
> > right filesystem calls. Does that make sense? Thanks.
>
> Sure. You mean something like this?:
>
> /* cmd/crc32.c */
> int do_crc32(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> {
> return do_hash(cmdtp, flag, argc, argv);
> }
>
> /* cmd/hash.c */
> static int do_hash(struct cmd_tbl *cmdtp, int flag, int argc,
> char *const argv[]) {
> ...
> /* if not true, we are called from crc32/sha1/etc alias */
> if (!strcmp(argv[0], "hash")) {
> /*
> * Hash cmd is used directly,
> * Move forward to 'algorithm' parameter
> */
> argc--;
> argv++;
> }
> ...
> }
So right, sorry, I didn't quite follow what you said before. If there's
further cleanup we can do with how hash_command is abstracting things,
yes, lets.
--
Tom
signature.asc
Description: PGP signature
Re: [RFC] Drop md5sum, crc32 and sha1 cmds in favor of hash cmd
Hi Tom,
On Wed, Feb 7, 2024 at 2:48 PM Tom Rini wrote:
>
> On Wed, Feb 07, 2024 at 02:00:16PM +0100, Igor Opaniuk wrote:
> > Hello,
> >
> > I was playing a bit with different hash functions recently, and
> > it turned out that md5sum, crc32, sha1 cmds just duplicate
> > what is already covered by generic `hash` cmd.
> >
> > => sha1 0x6000 0x200
> > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437
> > => hash sha1 0x6000 0x200
> > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437
> >
> > => crc32 0x6000 0x200
> > crc32 for 6000 ... 61ff ==> 6fe352e8
> > => hash crc32 0x6000 0x200
> > crc32 for 6000 ... 61ff ==> 6fe352e8
> >
> > => md5sum 0x6000 0x200
> > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050
> > => hash md5 0x6000 0x200
> > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050
> >
> > Considering that most of them (besides md5sum) are using the same
> > int hash_command() function under the hood, but have a lot of duplicated
> > code for handling params, does it make sense to do some cleanup and
> > drop all them in favour `hash`?
> >
> > I also plan to extend usage info for `hash` by adding a list
> > compiled-in algos based on hash related compiled flags
> > (CONFIG_SHA1, CONFIG_CRC32 etc), so it's clear what algos
> > are available for hash calculation.
> >
> > Comments/objections are welcome!
>
> It would be good, implementation wise, if each of those commands was
> just a redirect to hash ..., similar to how "load " will call the
> right filesystem calls. Does that make sense? Thanks.
Sure. You mean something like this?:
/* cmd/crc32.c */
int do_crc32(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
return do_hash(cmdtp, flag, argc, argv);
}
/* cmd/hash.c */
static int do_hash(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[]) {
...
/* if not true, we are called from crc32/sha1/etc alias */
if (!strcmp(argv[0], "hash")) {
/*
* Hash cmd is used directly,
* Move forward to 'algorithm' parameter
*/
argc--;
argv++;
}
...
}
>
> --
> Tom
Regards,
Igor
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
http://ua.linkedin.com/in/iopaniuk
Re: [RFC] Drop md5sum, crc32 and sha1 cmds in favor of hash cmd
On Wed, Feb 07, 2024 at 02:00:16PM +0100, Igor Opaniuk wrote: > Hello, > > I was playing a bit with different hash functions recently, and > it turned out that md5sum, crc32, sha1 cmds just duplicate > what is already covered by generic `hash` cmd. > > => sha1 0x6000 0x200 > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 > => hash sha1 0x6000 0x200 > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 > > => crc32 0x6000 0x200 > crc32 for 6000 ... 61ff ==> 6fe352e8 > => hash crc32 0x6000 0x200 > crc32 for 6000 ... 61ff ==> 6fe352e8 > > => md5sum 0x6000 0x200 > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > => hash md5 0x6000 0x200 > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > > Considering that most of them (besides md5sum) are using the same > int hash_command() function under the hood, but have a lot of duplicated > code for handling params, does it make sense to do some cleanup and > drop all them in favour `hash`? > > I also plan to extend usage info for `hash` by adding a list > compiled-in algos based on hash related compiled flags > (CONFIG_SHA1, CONFIG_CRC32 etc), so it's clear what algos > are available for hash calculation. > > Comments/objections are welcome! It would be good, implementation wise, if each of those commands was just a redirect to hash ..., similar to how "load " will call the right filesystem calls. Does that make sense? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/10] Add AVS support for J721S2
On Wed, Feb 07, 2024 at 03:35:51PM +0530, Manorit Chawdhry wrote: > Hi Tom, > > On 08:45-20240206, Tom Rini wrote: > > On Tue, Feb 06, 2024 at 05:51:07PM +0530, Manorit Chawdhry wrote: > > > > > This series does the DT sync with Linux 6.8-rc1 as that has the pmic > > > nodes required for AVS support and then adds AVS Support for J721S2. > > > > > > AVS Test for J721S2: > > > https://gist.github.com/manorit2001/d7690ded6ef685aa8ffa5b16746cc529 > > > Boot Test results: > > > https://gist.github.com/manorit2001/6775d721b3df5a690497d94d012b93c4 > > > > > > Signed-off-by: Manorit Chawdhry > > > --- > > > Manorit Chawdhry (10): > > > arm: dts: k3-j721s2*: Sync with 6.8-rc1 > > > arm: dts: k3-am68*: Sync with 6.8-rc1 > > > > The starting point for this series should be to build on top of Sumit's > > OF_UPSTREAM series. > > > > I see that series is still under discussion and not yet merged ( hoping > am on the correct thread [0]). Do I have to rebase my commits on top of > that and try or do you think that series is gonna take time? > > [0]: https://lore.kernel.org/u-boot/20240206130040.GO1152441@bill-the-cat/ Yes, you need to rebase on top of that series, just like how the am62p support was posted. Thanks. -- Tom signature.asc Description: PGP signature
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On 2024-02-07 14:14, Dragan Simic wrote:
Hello Shantur,
Please see my notes below.
On 2024-02-07 11:23, Shantur Rathore wrote:
USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.
Resetting only when hub is USB 3.0 fixes it.
Tested-by: Andre Przywara
Signed-off-by: Shantur Rathore
Please, add the "Fixes" line available below, reformat the patch
description to the usual 78-character width, and remove unnecessary
"FIX " from the patch subject prefix.
Fixes: 33e06dcbe57a ("common: usb-hub: Reset hub port before scanning")
As a side note, such tags can be produced very easily by running
"git log --max-count=1 --pretty=fixes ". I have an alias
like that defined in my ~/.gitconfig.
With these changes applied, please feel free to also add:
Reviewed-by: Dragan Simic
Oops, sorry for the typo... s/anjaro/manjaro/
---
common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
usb_hub_device *hub)
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1, dev->status);
+ if (usb_hub_is_superspeed(dev)) {
+ usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
+ debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ }
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug("PowerOn : port %d returns %lX\n", i + 1, dev->status);
}
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
Hello Shantur,
Please see my notes below.
On 2024-02-07 11:23, Shantur Rathore wrote:
USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.
Resetting only when hub is USB 3.0 fixes it.
Tested-by: Andre Przywara
Signed-off-by: Shantur Rathore
Please, add the "Fixes" line available below, reformat the patch
description to the usual 78-character width, and remove unnecessary
"FIX " from the patch subject prefix.
Fixes: 33e06dcbe57a ("common: usb-hub: Reset hub port before scanning")
As a side note, such tags can be produced very easily by running
"git log --max-count=1 --pretty=fixes ". I have an alias
like that defined in my ~/.gitconfig.
With these changes applied, please feel free to also add:
Reviewed-by: Dragan Simic
---
common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct usb_hub_device
*hub)
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1, dev->status);
+ if (usb_hub_is_superspeed(dev)) {
+ usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
+ debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ }
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug("PowerOn : port %d returns %lX\n", i + 1, dev->status);
}
[PATCH] stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD
This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated in defconfig, with undefined reference to run_usb_dnl_gadget and to g_dnl_set_product. Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig index 8f91db4b46b9..589276282e44 100644 --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig @@ -17,6 +17,7 @@ config CMD_STM32PROG config CMD_STM32PROG_USB bool "support stm32prog over USB" depends on CMD_STM32PROG + depends on USB_GADGET_DOWNLOAD default y help activate the command "stm32prog usb" for STM32MP soc family -- 2.25.1
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On 2/7/24 11:23, Shantur Rathore wrote:
USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.
Resetting only when hub is USB 3.0 fixes it.
It would be good to include as many details about the faulty hardware in
the commit message as possible, so that when someone else runs into
this, they would have all that information available.
Tested-by: Andre Przywara
Signed-off-by: Shantur Rathore
---
common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1, dev->status);
+ if (usb_hub_is_superspeed(dev)) {
Should this condition be "all which are lower than superspeed" instead ,
so when the next generation of USB comes, this problem won't trigger ?
What does Linux do btw ?
[RFC] Drop md5sum, crc32 and sha1 cmds in favor of hash cmd
Hello, I was playing a bit with different hash functions recently, and it turned out that md5sum, crc32, sha1 cmds just duplicate what is already covered by generic `hash` cmd. => sha1 0x6000 0x200 sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 => hash sha1 0x6000 0x200 sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 => crc32 0x6000 0x200 crc32 for 6000 ... 61ff ==> 6fe352e8 => hash crc32 0x6000 0x200 crc32 for 6000 ... 61ff ==> 6fe352e8 => md5sum 0x6000 0x200 md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 => hash md5 0x6000 0x200 md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 Considering that most of them (besides md5sum) are using the same int hash_command() function under the hood, but have a lot of duplicated code for handling params, does it make sense to do some cleanup and drop all them in favour `hash`? I also plan to extend usage info for `hash` by adding a list compiled-in algos based on hash related compiled flags (CONFIG_SHA1, CONFIG_CRC32 etc), so it's clear what algos are available for hash calculation. Comments/objections are welcome! Regards, Igor -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +48 666 108 041 http://ua.linkedin.com/in/iopaniuk
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 2/7/2024 6:05 PM, Roger Quadros wrote:
>
>
> On 07/02/2024 09:15, MD Danish Anwar wrote:
>> Hi Roger
>>
>> On 06/02/24 7:11 pm, Roger Quadros wrote:
>>>
>>>
>>> On 06/02/2024 07:31, MD Danish Anwar wrote:
On 05/02/24 6:07 pm, Roger Quadros wrote:
>
>
> On 05/02/2024 12:20, MD Danish Anwar wrote:
>>
>>
>> On 05/02/24 3:36 pm, Roger Quadros wrote:
>>>
>>>
>>> On 02/02/2024 18:40, Anwar, Md Danish wrote:
Hi Roger,
On 2/2/2024 4:49 PM, Roger Quadros wrote:
>
>
> On 30/01/2024 08:33, MD Danish Anwar wrote:
>> Add APIs to set a firmware_name to a rproc and boot the rproc with
>> the
>> same firmware.
>>
> How does caller know what firmware size to set to?
> This should already be private to the rproc as it knows
> how large is its program memory.
>
Caller is trying to boot the rproc with a firmware binary. Caller
should
know the size of binary that it wants to load to rproc core. Caller
will
specify the binary size to rproc_boot(). Based on the size provided by
caller, rproc_boot() will then allocate that much memory and call
request_firmware_into_buf() with the size and allocated buffer. If the
caller doesn't provide minimum size rproc_load() will fail.
>>>
>>> Caller only knows the filename. It need not know more details.
>>
>> Caller is trying to load a file of it's choice to a rproc. Caller should
>> know the size of file it is trying to load or atleast the max size that
>> the firmware file could be of.
>>
>>
>>> Also see my comment below about rproc_boot() API.
>>>
rproc_load() calls respective driver ops, for example: pru_load().
pru_load() [1] API checks the required size of firmware to load by
casting the buffer into Elf32_Ehdr and Elf32_Phdr and returns error if
size provided by caller is less than this.
if (offset + filesz > size) {
dev_dbg(dev, "truncated fw: need 0x%x avail 0x%zx\n",
offset + filesz, size);
ret = -EINVAL;
break;
}
>> + *
>> + * Boot a remote processor (i.e. load its firmware, power it on,
>> ...).
>> + *
>> + * This function first loads the firmware set in the uclass pdata
>> of Remote
>> + * processor to a buffer and then loads firmware to the remote
>> processor
>> + * using rproc_load().
>> + *
>> + * Return: 0 on success, and an appropriate error value otherwise
>> + */
>> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size);
>
> Was wondering if you need separate API for rproc_set_firmware or we
> can just
> pass firmware name as argument to rproc_boot()?
>
Technically we can. But when we discussed this approach first in v1,
you
had asked to keep the APIs similar to upstream linux. Upstream linux
has
these two APIs so I kept it that way. If you want I can drop the first
API. Please let me know.
>>>
>>> Sure you can keep it as it is in Linux, but there, rproc_boot doesn't
>>> take fw_size argument. So wondering why you should have it in u-boot.
>>>
>>
>> For loading firmware to a rproc core in u-boot, it's first neccassry to
>> load the firmware into buffer and then load that buffer into rproc core
>> using rproc_load() API. Now to load the firmware to a buffer ther is an
>> API request_firmware_into_buf(). This API takes size of firmware as one
>> of it's argument. So in order to call this API from rproc_boot() we need
>> to pass fw_size to rproc_boot()
>>
>> Other u-boot drivers using request_firmware_into_buf() are also passing
>> size of firmware from their driver.
>
> But in your driver you didn't use size of firmware but some 64K
> https://lore.kernel.org/all/20240124064930.1787929-8-danishan...@ti.com/
>
Yes, in driver I am hardcoding the size to 64K. That's because I know
the size of ICSSG firmwares are less than 64K. Instead of hardcoding I
>>>
>>> What if you enable debugging symbols in the firmware file. Won't it exceed
>>> 64KB?
>>> It is not a good idea to assume any firmware file size as it will eventually
>>> break sometime in the future and will be a pain to debug.
>>>
can also define macro or provide a config option where we set the size
and the driver will read the size from the config and call rproc_boot()
with size.
For example, fm.c driver reads the size from config option
CONFIG_SYS_QE_FMAN_FW_LENGTH [1]
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 07/02/2024 09:15, MD Danish Anwar wrote:
> Hi Roger
>
> On 06/02/24 7:11 pm, Roger Quadros wrote:
>>
>>
>> On 06/02/2024 07:31, MD Danish Anwar wrote:
>>>
>>>
>>> On 05/02/24 6:07 pm, Roger Quadros wrote:
On 05/02/2024 12:20, MD Danish Anwar wrote:
>
>
> On 05/02/24 3:36 pm, Roger Quadros wrote:
>>
>>
>> On 02/02/2024 18:40, Anwar, Md Danish wrote:
>>> Hi Roger,
>>>
>>> On 2/2/2024 4:49 PM, Roger Quadros wrote:
On 30/01/2024 08:33, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
>
>>>
>>>
>>>
>>>
How does caller know what firmware size to set to?
This should already be private to the rproc as it knows
how large is its program memory.
>>>
>>> Caller is trying to boot the rproc with a firmware binary. Caller should
>>> know the size of binary that it wants to load to rproc core. Caller will
>>> specify the binary size to rproc_boot(). Based on the size provided by
>>> caller, rproc_boot() will then allocate that much memory and call
>>> request_firmware_into_buf() with the size and allocated buffer. If the
>>> caller doesn't provide minimum size rproc_load() will fail.
>>
>> Caller only knows the filename. It need not know more details.
>
> Caller is trying to load a file of it's choice to a rproc. Caller should
> know the size of file it is trying to load or atleast the max size that
> the firmware file could be of.
>
>
>> Also see my comment below about rproc_boot() API.
>>
>>>
>>> rproc_load() calls respective driver ops, for example: pru_load().
>>> pru_load() [1] API checks the required size of firmware to load by
>>> casting the buffer into Elf32_Ehdr and Elf32_Phdr and returns error if
>>> size provided by caller is less than this.
>>>
>>>
>>> if (offset + filesz > size) {
>>> dev_dbg(dev, "truncated fw: need 0x%x avail 0x%zx\n",
>>> offset + filesz, size);
>>> ret = -EINVAL;
>>> break;
>>> }
>>>
> + *
> + * Boot a remote processor (i.e. load its firmware, power it on,
> ...).
> + *
> + * This function first loads the firmware set in the uclass pdata of
> Remote
> + * processor to a buffer and then loads firmware to the remote
> processor
> + * using rproc_load().
> + *
> + * Return: 0 on success, and an appropriate error value otherwise
> + */
> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size);
Was wondering if you need separate API for rproc_set_firmware or we
can just
pass firmware name as argument to rproc_boot()?
>>>
>>> Technically we can. But when we discussed this approach first in v1, you
>>> had asked to keep the APIs similar to upstream linux. Upstream linux has
>>> these two APIs so I kept it that way. If you want I can drop the first
>>> API. Please let me know.
>>
>> Sure you can keep it as it is in Linux, but there, rproc_boot doesn't
>> take fw_size argument. So wondering why you should have it in u-boot.
>>
>
> For loading firmware to a rproc core in u-boot, it's first neccassry to
> load the firmware into buffer and then load that buffer into rproc core
> using rproc_load() API. Now to load the firmware to a buffer ther is an
> API request_firmware_into_buf(). This API takes size of firmware as one
> of it's argument. So in order to call this API from rproc_boot() we need
> to pass fw_size to rproc_boot()
>
> Other u-boot drivers using request_firmware_into_buf() are also passing
> size of firmware from their driver.
But in your driver you didn't use size of firmware but some 64K
https://lore.kernel.org/all/20240124064930.1787929-8-danishan...@ti.com/
>>>
>>> Yes, in driver I am hardcoding the size to 64K. That's because I know
>>> the size of ICSSG firmwares are less than 64K. Instead of hardcoding I
>>
>> What if you enable debugging symbols in the firmware file. Won't it exceed
>> 64KB?
>> It is not a good idea to assume any firmware file size as it will eventually
>> break sometime in the future and will be a pain to debug.
>>
>>> can also define macro or provide a config option where we set the size
>>> and the driver will read the size from the config and call rproc_boot()
>>> with size.
>>>
>>> For example, fm.c driver reads the size from config option
>>> CONFIG_SYS_QE_FMAN_FW_LENGTH [1] and calls request_firmware_into_buf()
>>>
>>> [1]
>>> https://elixir.bootlin.com/u-boot/latest/source/drivers/net/fm/fm.c#L458
>>>
So neither does the caller have a clue of firmware size?
>
> If
Re: [PATCH 04/15] rockchip: rk3328-roc-cc: Update defconfig
On Wed, Feb 7, 2024 at 8:04 AM Jonas Karlman wrote: > > Update defconfig for rk3328-roc-cc with new defaults. > > Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL. > > Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash > of FIT images. This help indicate if there is an issue loading any of > the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep > support for scripts. > > Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and > eth1addr is set based on cpuid read from eFUSE. I wonder if it would make sense to enable ROCKCHIP_EFUSE or ROCKCHIP_OTP for the respective SoCs by default, either with "imply" under the SoC Kconfig options, or "default if XXX" under the driver Kconfig options? Not sure which is preferred. Same goes for CONFIG_MISC_INIT_R for actually generating the serial number and MAC addresses from the efuse/OTP. At least for RK3566 and RK3588 we are implying these options. ChenYu > Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL. > > Add DM_ETH_PHY=y, PHY_MOTORCOMM=y and PHY_REALTEK=y to support common > ethernet PHYs. > > Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random > generator. > > Also add missing device tree file to MAINTAINERS and add myself as a > reviewer for this board. > > Signed-off-by: Jonas Karlman > --- > board/rockchip/evb_rk3328/MAINTAINERS | 2 ++ > configs/roc-cc-rk3328_defconfig | 9 +++-- > doc/board/rockchip/rockchip.rst | 2 +- > 3 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/board/rockchip/evb_rk3328/MAINTAINERS > b/board/rockchip/evb_rk3328/MAINTAINERS > index 419bc8ded375..09488eaf083f 100644 > --- a/board/rockchip/evb_rk3328/MAINTAINERS > +++ b/board/rockchip/evb_rk3328/MAINTAINERS > @@ -41,8 +41,10 @@ F: > arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi > ROC-RK3328-CC > M: Loic Devulder > M: Chen-Yu Tsai > +R: Jonas Karlman > S: Maintained > F: configs/roc-cc-rk3328_defconfig > +F: arch/arm/dts/rk3328-roc-cc.dts > F: arch/arm/dts/rk3328-roc-cc-u-boot.dtsi > > ROCK64-RK3328 > diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig > index 4ac3c9403b02..7d81a715ef25 100644 > --- a/configs/roc-cc-rk3328_defconfig > +++ b/configs/roc-cc-rk3328_defconfig > @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y > CONFIG_TPL_LIBCOMMON_SUPPORT=y > CONFIG_TPL_LIBGENERIC_SUPPORT=y > -CONFIG_SPL_DRIVERS_MISC=y > CONFIG_SPL_STACK_R_ADDR=0x60 > CONFIG_SPL_STACK=0x40 > CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 > @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y > # CONFIG_ANDROID_BOOT_IMAGE is not set > CONFIG_FIT=y > CONFIG_FIT_VERBOSE=y > +CONFIG_SPL_FIT_SIGNATURE=y > CONFIG_SPL_LOAD_FIT=y > +CONFIG_LEGACY_IMAGE_FORMAT=y > CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-roc-cc.dtb" > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > @@ -58,8 +59,8 @@ CONFIG_TPL_OF_PLATDATA=y > CONFIG_ENV_IS_IN_MMC=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_SYS_MMC_ENV_DEV=1 > -CONFIG_NET_RANDOM_ETHADDR=y > CONFIG_TPL_DM=y > +CONFIG_SPL_DM_SEQ_ALIAS=y > CONFIG_REGMAP=y > CONFIG_SPL_REGMAP=y > CONFIG_TPL_REGMAP=y > @@ -73,9 +74,11 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > CONFIG_ROCKCHIP_GPIO=y > CONFIG_SYS_I2C_ROCKCHIP=y > CONFIG_MISC=y > +CONFIG_ROCKCHIP_EFUSE=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_PHY_REALTEK=y > +CONFIG_DM_ETH_PHY=y > CONFIG_PHY_GIGE=y > CONFIG_ETH_DESIGNWARE=y > CONFIG_GMAC_ROCKCHIP=y > @@ -95,6 +98,8 @@ CONFIG_PWM_ROCKCHIP=y > CONFIG_RAM=y > CONFIG_SPL_RAM=y > CONFIG_TPL_RAM=y > +CONFIG_DM_RNG=y > +CONFIG_RNG_ROCKCHIP=y > CONFIG_BAUDRATE=150 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYS_NS16550_MEM32=y > diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst > index de2195deadca..99f48b6d6fa5 100644 > --- a/doc/board/rockchip/rockchip.rst > +++ b/doc/board/rockchip/rockchip.rst > @@ -60,8 +60,8 @@ List of mainline supported Rockchip boards: > - ODROID-GO Advance (odroid-go2) > * rk3328 > - Rockchip Evb-RK3328 (evb-rk3328) > + - Firefly ROC-RK3328-CC (roc-cc-rk3328) > - Pine64 Rock64 (rock64-rk3328) > - - Firefly-RK3328 (roc-cc-rk3328) > - Radxa Rockpi E (rock-pi-e-rk3328) > * rk3368 > - GeekBox (geekbox) > -- > 2.43.0 >
Re: [PATCH] xilinx: zynqmp: Add the missing function prototype
On 2/7/24 09:33, Venkatesh Yadav Abbarapu wrote: Add missing prototype to fix the below sparse warning warning: no previous prototype for 'spl_spi_get_uboot_offs' [-Wmissing-prototypes] Signed-off-by: Venkatesh Yadav Abbarapu --- board/xilinx/zynqmp/zynqmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index 9f50090720..ba49eb7be2 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include good. Please send it to upstream. M
[FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.
Resetting only when hub is USB 3.0 fixes it.
Tested-by: Andre Przywara
Signed-off-by: Shantur Rathore
---
common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1, dev->status);
+ if (usb_hub_is_superspeed(dev)) {
+ usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
+ debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ }
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug("PowerOn : port %d returns %lX\n", i + 1, dev->status);
}
--
2.40.1
Re: [PATCH 2/6] arm: mach-k3: Move disable_linefill_optimization() into R5 directory
Hi Andrew,
On Fri, Feb 2, 2024 at 1:26 AM Andrew Davis wrote:
>
> The disable_linefill_optimization() function is only ever loaded by the
> R5 core, move the code into the R5 directory.
>
> Signed-off-by: Andrew Davis
> ---
> arch/arm/mach-k3/common.c| 25 -
> arch/arm/mach-k3/r5/Makefile | 1 +
> arch/arm/mach-k3/r5/common.c | 35 +++
> 3 files changed, 36 insertions(+), 25 deletions(-)
> create mode 100644 arch/arm/mach-k3/r5/common.c
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index f411366778f..5d53efed85b 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -453,31 +453,6 @@ void board_prep_linux(struct bootm_headers *images)
> }
> #endif
>
> -#ifdef CONFIG_CPU_V7R
> -void disable_linefill_optimization(void)
> -{
> - u32 actlr;
> -
> - /*
> -* On K3 devices there are 2 conditions where R5F can deadlock:
> -* 1.When software is performing series of store operations to
> -* cacheable write back/write allocate memory region and later
> -* on software execute barrier operation (DSB or DMB). R5F may
> -* hang at the barrier instruction.
> -* 2.When software is performing a mix of load and store operations
> -* within a tight loop and store operations are all writing to
> -* cacheable write back/write allocates memory regions, R5F may
> -* hang at one of the load instruction.
> -*
> -* To avoid the above two conditions disable linefill optimization
> -* inside Cortex R5F.
> -*/
> - asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
> - actlr |= (1 << 13); /* Set DLFO bit */
> - asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
> -}
> -#endif
> -
> static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
>enum k3_firewall_region_type fwl_type)
> {
> diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile
> index b99199d3374..8ad86eb2798 100644
> --- a/arch/arm/mach-k3/r5/Makefile
> +++ b/arch/arm/mach-k3/r5/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
> obj-$(CONFIG_SOC_K3_AM625) += am62x/
> obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
>
> +obj-y += common.o
> obj-y += lowlevel_init.o
> obj-y += r5_mpu.o
>
> diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
> new file mode 100644
> index 000..ef81f50c6c7
> --- /dev/null
> +++ b/arch/arm/mach-k3/r5/common.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: R5 Common Architecture initialization
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "../common.h"
> +
> +void disable_linefill_optimization(void)
> +{
> + u32 actlr;
> +
> + /*
> +* On K3 devices there are 2 conditions where R5F can deadlock:
> +* 1.When software is performing series of store operations to
> +* cacheable write back/write allocate memory region and later
> +* on software execute barrier operation (DSB or DMB). R5F may
> +* hang at the barrier instruction.
> +* 2.When software is performing a mix of load and store operations
> +* within a tight loop and store operations are all writing to
> +* cacheable write back/write allocates memory regions, R5F may
> +* hang at one of the load instruction.
> +*
> +* To avoid the above two conditions disable linefill optimization
> +* inside Cortex R5F.
> +*/
> + asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
> + actlr |= (1 << 13); /* Set DLFO bit */
> + asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
> +}
> --
> 2.39.2
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Senior Software Engineer, Embedded & Security
E: igor.opan...@foundries.io
W: www.foundries.io
Re: [PATCH 09/10] DONOTMERGE: arm: dts: j721s2: Fix Power domain for VTM node.
Hi Udit, On 19:37-20240206, Kumar, Udit wrote: > > On 2/6/2024 5:51 PM, Manorit Chawdhry wrote: > > Patch is sent to upstream linux [0]. > > > > [0]: > > https://lore.kernel.org/all/20240201-b4-upstream-j721s2-fix-vtm-devid-v2-0-85fd568b7...@ti.com/ > > > > Signed-off-by: Manorit Chawdhry > > --- > > arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi > > b/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi > > index 80aa33c58a45..a47cb557dd95 100644 > > --- a/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi > > +++ b/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi > > @@ -663,7 +663,7 @@ > > compatible = "ti,j7200-vtm"; > > reg = <0x00 0x4204 0x0 0x350>, > > <0x00 0x4205 0x0 0x350>; > > - power-domains = <_pds 154 TI_SCI_PD_SHARED>; > > + power-domains = <_pds 180 TI_SCI_PD_SHARED>; > > I kind of disagree with this patch as Do not Merge, I understand you want to > do this change as part of next sync. > > But we got already node in u-boot for VTM with incorrect power-domain. > > I am not sure, with incorrect power-domain, how AVS will be behave. > > Here are my 2 cents > > Either mark this patch part of series or Hold AVS till next sync > Can mark the series for AVS as RFC till then ig, will see what to be done for DT Sync. Regards, Manorit > > > #thermal-sensor-cells = <1>; > > }; > >
Re: [PATCH 02/10] arm: dts: k3-am68*: Sync with 6.8-rc1
Hi Andrew,
On 11:38-20240206, Andrew Davis wrote:
> On 2/6/24 6:21 AM, Manorit Chawdhry wrote:
> > Syncs the DT from Linux v6.8-rc1.
> >
> > Remove udmap overrides and handle location change of chipid node.
>
> Message doesn't match the patch. This patch should just be squashed
> into the previous one anyway.
>
Ah yeah, oversight. Would see what should be done about it after Tom's
reply for OF_UPSTREAM, would change accordingly.
Regards,
Manorit
> Andrew
>
> >
> > Signed-off-by: Manorit Chawdhry
> > ---
> > arch/arm/dts/k3-am68-sk-base-board.dts | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/dts/k3-am68-sk-base-board.dts
> > b/arch/arm/dts/k3-am68-sk-base-board.dts
> > index 1e1a82f9d2b8..d0cfdeac21fb 100644
> > --- a/arch/arm/dts/k3-am68-sk-base-board.dts
> > +++ b/arch/arm/dts/k3-am68-sk-base-board.dts
> > @@ -31,6 +31,7 @@
> > can1 = _mcan1;
> > can2 = _mcan6;
> > can3 = _mcan7;
> > + ethernet0 = _port1;
> > };
> > vusb_main: regulator-vusb-main5v0 {
> >
Re: [PATCH 00/10] Add AVS support for J721S2
Hi Tom, On 08:45-20240206, Tom Rini wrote: > On Tue, Feb 06, 2024 at 05:51:07PM +0530, Manorit Chawdhry wrote: > > > This series does the DT sync with Linux 6.8-rc1 as that has the pmic > > nodes required for AVS support and then adds AVS Support for J721S2. > > > > AVS Test for J721S2: > > https://gist.github.com/manorit2001/d7690ded6ef685aa8ffa5b16746cc529 > > Boot Test results: > > https://gist.github.com/manorit2001/6775d721b3df5a690497d94d012b93c4 > > > > Signed-off-by: Manorit Chawdhry > > --- > > Manorit Chawdhry (10): > > arm: dts: k3-j721s2*: Sync with 6.8-rc1 > > arm: dts: k3-am68*: Sync with 6.8-rc1 > > The starting point for this series should be to build on top of Sumit's > OF_UPSTREAM series. > I see that series is still under discussion and not yet merged ( hoping am on the correct thread [0]). Do I have to rebase my commits on top of that and try or do you think that series is gonna take time? [0]: https://lore.kernel.org/u-boot/20240206130040.GO1152441@bill-the-cat/ > > DONOTMERGE: arm: dts: j721s2: Fix Power domain for VTM node. > > And please make sure to mark the series as RFC if there's DONOTMERGE > parts in it, thanks. Sure, would convert it to an RFC series. Regards, Manorit > > -- > Tom
Re: [PATCH 1/6] arm: mach-k3: Move SYS_K3_SPL_ATF definition into R5 Kconfig
Hi Andrew, On Fri, Feb 2, 2024 at 1:25 AM Andrew Davis wrote: > > Loading ATF is only supported from the R5, move the Kconfig symbol > definition to match. > > Signed-off-by: Andrew Davis > --- > arch/arm/mach-k3/Kconfig| 7 --- > arch/arm/mach-k3/r5/Kconfig | 6 ++ > 2 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > index 03898424c95..45cf740bb1f 100644 > --- a/arch/arm/mach-k3/Kconfig > +++ b/arch/arm/mach-k3/Kconfig > @@ -114,13 +114,6 @@ config K3_EARLY_CONS_IDX > Use this option to set the index of the serial device to be used > for the early console during SPL execution. > > -config SYS_K3_SPL_ATF > - bool "Start Cortex-A from SPL" > - depends on CPU_V7R > - help > - Enabling this will try to start Cortex-A (typically with ATF) > - after SPL from R5. > - > config K3_ATF_LOAD_ADDR > hex "Load address of ATF image" > default 0x7000 > diff --git a/arch/arm/mach-k3/r5/Kconfig b/arch/arm/mach-k3/r5/Kconfig > index ae79f8ff6cd..317a6c4b67e 100644 > --- a/arch/arm/mach-k3/r5/Kconfig > +++ b/arch/arm/mach-k3/r5/Kconfig > @@ -43,3 +43,9 @@ config K3_SYSFW_IMAGE_SPI_OFFS > help > Offset of the combined System Firmware and configuration image tree > blob to be loaded when booting from a SPI flash memory. > + > +config SYS_K3_SPL_ATF > + bool "Start Cortex-A from SPL" > + help > + Enabling this will try to start Cortex-A (typically with ATF) > + after SPL from R5. > -- > 2.39.2 > Reviewed-by: Igor Opaniuk -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk Senior Software Engineer, Embedded & Security E: igor.opan...@foundries.io W: www.foundries.io
Re: [PATCH 07/15] rockchip: rk3328-orangepi-r1-plus: Update defconfig
Hi Jonas,
On Wed, Feb 7, 2024 at 9:06 AM Jonas Karlman wrote:
>
> Update defconfig for rk3328-orangepi-r1-plus boards with new defaults.
>
> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL.
>
> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash
> of FIT images. This help indicate if there is an issue loading any of
> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep
> support for scripts.
>
> Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and
> eth1addr is set based on cpuid read from eFUSE.
>
> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL.
>
> Add DM_ETH_PHY=y, PHY_MOTORCOMM=y, PHY_REALTEK=y and remove to
> support reset of onboard ethernet PHYs.
>
> Add PHY_ROCKCHIP_INNO_USB2=y option to support the onboard USB PHY.
>
> Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random
> generator.
>
> Also add missing device tree files to MAINTAINERS file.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Tianling Shen
Best regards,
Tianling.
> ---
> arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi | 6 --
> arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi | 6 --
> board/rockchip/evb_rk3328/MAINTAINERS| 2 ++
> configs/orangepi-r1-plus-lts-rk3328_defconfig| 12 ++--
> configs/orangepi-r1-plus-rk3328_defconfig| 12 ++--
> doc/board/rockchip/rockchip.rst | 2 ++
> 6 files changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> index 5aaa5ccb15c1..8a4189c6f1cc 100644
> --- a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> @@ -28,12 +28,6 @@
> bootph-pre-ram;
> };
>
> - {
> - snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 1 5>;
> -};
> -
> {
> spi_flash: spiflash@0 {
> bootph-all;
> diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> index 6d3db86dce6a..2e3b6a77a268 100644
> --- a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> @@ -28,12 +28,6 @@
> bootph-pre-ram;
> };
>
> - {
> - snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 1 5>;
> -};
> -
> {
> spi_flash: spiflash@0 {
> bootph-all;
> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS
> b/board/rockchip/evb_rk3328/MAINTAINERS
> index b88727acad26..675b72dd060c 100644
> --- a/board/rockchip/evb_rk3328/MAINTAINERS
> +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> @@ -32,12 +32,14 @@ ORANGEPI-R1-PLUS-RK3328
> M: Tianling Shen
> S: Maintained
> F: configs/orangepi-r1-plus-rk3328_defconfig
> +F: arch/arm/dts/rk3328-orangepi-r1-plus.dts
> F: arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
>
> ORANGEPI-R1-PLUS-LTS-RK3328
> M: Tianling Shen
> S: Maintained
> F: configs/orangepi-r1-plus-lts-rk3328_defconfig
> +F: arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts
> F: arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
>
> ROC-RK3328-CC
> diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig
> b/configs/orangepi-r1-plus-lts-rk3328_defconfig
> index d3d9417509e9..937ef003d85b 100644
> --- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
> +++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y
> CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> CONFIG_TPL_LIBCOMMON_SUPPORT=y
> CONFIG_TPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SPL_DRIVERS_MISC=y
> CONFIG_SPL_STACK_R_ADDR=0x60
> CONFIG_SPL_STACK=0x40
> CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y
> # CONFIG_ANDROID_BOOT_IMAGE is not set
> CONFIG_FIT=y
> CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
> CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
> CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus-lts.dtb"
> # CONFIG_DISPLAY_CPUINFO is not set
> CONFIG_DISPLAY_BOARDINFO_LATE=y
> @@ -57,8 +58,8 @@ CONFIG_TPL_OF_PLATDATA=y
> CONFIG_ENV_IS_IN_MMC=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_SYS_MMC_ENV_DEV=1
> -CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_TPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> CONFIG_REGMAP=y
> CONFIG_SPL_REGMAP=y
> CONFIG_TPL_REGMAP=y
> @@ -72,11 +73,16 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
> CONFIG_ROCKCHIP_GPIO=y
> CONFIG_SYS_I2C_ROCKCHIP=y
> CONFIG_MISC=y
> +CONFIG_ROCKCHIP_EFUSE=y
> CONFIG_MMC_DW=y
> CONFIG_MMC_DW_ROCKCHIP=y
> CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_PHY_MOTORCOMM=y
> +CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH_PHY=y
> CONFIG_ETH_DESIGNWARE=y
> CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>
Re: [PATCH 15/15] rockchip: rk3328-orangepi-r1-plus: Enable boot from SPI NOR flash
Hi Jonas, On Wed, Feb 7, 2024 at 8:14 AM Jonas Karlman wrote: > > Add Kconfig options to enable support for booting from SPI NOR flash on > Orange Pi R1 Plus boards. > > The generated bootable u-boot-rockchip-spi.bin that can be written to > 0x0 of SPI NOR flash. The FIT image is loaded from 0x6, same as on > RK35xx boards. > > Signed-off-by: Jonas Karlman Thanks for your great work! Reviewed-by: Tianling Shen Best regards, Tianling. > --- > configs/orangepi-r1-plus-lts-rk3328_defconfig | 8 > configs/orangepi-r1-plus-rk3328_defconfig | 8 > 2 files changed, 16 insertions(+) > > diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig > b/configs/orangepi-r1-plus-lts-rk3328_defconfig > index 937ef003d85b..968110c8cd6f 100644 > --- a/configs/orangepi-r1-plus-lts-rk3328_defconfig > +++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig > @@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3328-orangepi-r1-plus-lts" > CONFIG_DM_RESET=y > CONFIG_ROCKCHIP_RK3328=y > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y > +CONFIG_ROCKCHIP_SPI_IMAGE=y > CONFIG_TPL_LIBCOMMON_SUPPORT=y > CONFIG_TPL_LIBGENERIC_SUPPORT=y > CONFIG_SPL_STACK_R_ADDR=0x60 > @@ -20,6 +21,8 @@ CONFIG_SPL_STACK=0x40 > CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 > CONFIG_DEBUG_UART_BASE=0xFF13 > CONFIG_DEBUG_UART_CLOCK=2400 > +CONFIG_SPL_SPI_FLASH_SUPPORT=y > +CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_DEBUG_UART=y > # CONFIG_ANDROID_BOOT_IMAGE is not set > @@ -42,6 +45,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 > CONFIG_SPL_STACK_R=y > CONFIG_SPL_I2C=y > CONFIG_SPL_POWER=y > +CONFIG_SPL_SPI_LOAD=y > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 > CONFIG_SPL_ATF=y > CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > CONFIG_TPL_SYS_MALLOC_SIMPLE=y > @@ -76,7 +81,10 @@ CONFIG_MISC=y > CONFIG_ROCKCHIP_EFUSE=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > +CONFIG_SPI_FLASH_SFDP_SUPPORT=y > CONFIG_SPI_FLASH_GIGADEVICE=y > +CONFIG_SPI_FLASH_MACRONIX=y > +CONFIG_SPI_FLASH_WINBOND=y > CONFIG_PHY_MOTORCOMM=y > CONFIG_PHY_REALTEK=y > CONFIG_DM_ETH_PHY=y > diff --git a/configs/orangepi-r1-plus-rk3328_defconfig > b/configs/orangepi-r1-plus-rk3328_defconfig > index 563a1ac6ecd4..7038f09f202c 100644 > --- a/configs/orangepi-r1-plus-rk3328_defconfig > +++ b/configs/orangepi-r1-plus-rk3328_defconfig > @@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3328-orangepi-r1-plus" > CONFIG_DM_RESET=y > CONFIG_ROCKCHIP_RK3328=y > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y > +CONFIG_ROCKCHIP_SPI_IMAGE=y > CONFIG_TPL_LIBCOMMON_SUPPORT=y > CONFIG_TPL_LIBGENERIC_SUPPORT=y > CONFIG_SPL_STACK_R_ADDR=0x60 > @@ -20,6 +21,8 @@ CONFIG_SPL_STACK=0x40 > CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 > CONFIG_DEBUG_UART_BASE=0xFF13 > CONFIG_DEBUG_UART_CLOCK=2400 > +CONFIG_SPL_SPI_FLASH_SUPPORT=y > +CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_DEBUG_UART=y > # CONFIG_ANDROID_BOOT_IMAGE is not set > @@ -42,6 +45,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 > CONFIG_SPL_STACK_R=y > CONFIG_SPL_I2C=y > CONFIG_SPL_POWER=y > +CONFIG_SPL_SPI_LOAD=y > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 > CONFIG_SPL_ATF=y > CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > CONFIG_TPL_SYS_MALLOC_SIMPLE=y > @@ -76,7 +81,10 @@ CONFIG_MISC=y > CONFIG_ROCKCHIP_EFUSE=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > +CONFIG_SPI_FLASH_SFDP_SUPPORT=y > CONFIG_SPI_FLASH_GIGADEVICE=y > +CONFIG_SPI_FLASH_MACRONIX=y > +CONFIG_SPI_FLASH_WINBOND=y > CONFIG_PHY_MOTORCOMM=y > CONFIG_PHY_REALTEK=y > CONFIG_DM_ETH_PHY=y > -- > 2.43.0 >
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On Wed, Feb 7, 2024 at 9:22 AM Shantur Rathore wrote: > > Hi Dragan and Andre, > > On Sat, Feb 3, 2024 at 10:39 AM Dragan Simic wrote: > > > > Hello Andre and Shantur, > > > > On 2024-02-02 12:28, Andre Przywara wrote: > > > On Fri, 02 Feb 2024 03:35:24 +0100 Dragan Simic > > > wrote: > > >> On 2024-02-02 01:12, Andre Przywara wrote: > > >> > On Thu, 1 Feb 2024 18:35:28 + Shantur Rathore > > >> > wrote: > > >> >> On Thu, Feb 1, 2024 at 4:46 PM Andre Przywara > > >> >> wrote: > > >> >> > On Thu, 1 Feb 2024 09:39:54 + Shantur Rathore > > >> >> > wrote: > > >> >> > > Which USB disk are you using? Is it a USB 2.0 disk ? > > >> >> > > Can you try with any other USB disk to confirm? > > >> >> > > > >> >> > Yes, this was some USB 2.0 memory stick, on an USB 2.0 port. > > >> >> > Most sunxi boards only have USB 2.0, but there is one SoC with USB > > >> >> > 3.0, I > > >> >> > will try some combinations later tonight. > > >> >> > > >> >> That would be awesome. > > >> >> We need to test > > >> >> > > >> >> USB 3.0 and 2.0 ports with USB 3.0 and 2.0 drives. > > >> > > > >> > So I had some mixed and apparently inconsistent results: > > >> > - On the Pine-H64 (H6 SoC with USB 3.0 + USB 2.0) it worked with > > >> > mainline, but only after I applied some pending sunxi USB PHY > > >> > regulator patches. This is an unrelated issue, those patches > > >> > are needed to enable USB 3.0 support on that board (shared regulator > > >> > conflict). > > >> > I tested a USB 2.0 and a USB 3.0 drive in both kind of slots, with > > >> > and without the patch. > > >> > - On the OrangePi Zero 3 (H616 SoC with USB 2.0 only), the USB 3.0 > > >> > drive would not work with mainline. A USB 2.0 drive was fine. > > >> > Applying your patch below fixed that problem, now both drives worked. > > >> > > >> Let me interject, please... > > >> > > >> Huh, this (mih)behavior with the tested OrangePi Zero 3 is really > > >> strange. As we know, a USB 3.0 drive plugged into a USB 2.0 port > > >> should behave just like a USB 2.0 drive, using the separate set > > >> of pins inside the connector. > > > > > > Yes, I found this odd as well, hence saying inconsistent above. > > > > > >> If possible, performing some additional testing with another USB > > >> 3.0 drive would be quite interesting. Could it be that something > > >> is wrong with the USB 2.0 receptacle on your OrangePi Zero 3, > > >> mechanically or electrically? > > > > > > The receptacle on the OPi Zero3 is a standard USB 2.0 Type-A socket, > > > with clearly only 4 pins. The USB 3.0 stick in question has all 9 pins. > > > So indeed there should be little difference to a USB 2.0 stick. > > > > Ah, sorry, I wasn't clear enough... I actually had some possible > > damage to the Zero 3's USB 2.0 receptacle in mind, or some results > > of the regular wear and tear, which could've possibly caused some > > intermittent issues. > > > > > And I just tested the same board with some other (cheap) USB 2.0 stick: > > > it's the same situation as with the USB 3.0 drive: it does not work > > > with > > > mainline, but works with the patch below. So the USB 3.0 device here > > > might > > > be a red herring, and it's actually more up to an individual device? > > > Or maybe it's like: *Some* USB devices (in Hi-Speed mode?) do not like > > > it > > > when their port is reset before it's powered on? And the root hub > > > implementation also plays a role, which is why we only got reports > > > about > > > Allwinner boards? > > > > Hmm, we've got quite a few unknowns there. Thank you for > > performing the additional testing! > > > > > Also I think Marek said that Linux does the reset only when using > > > SuperSpeed (hence the patch below), so maybe it's something in the USB > > > 3.0 > > > spec that changed the requirements? > > > > I just spent about an hour and a half going through the USB 2.0 > > and USB 3.0 specifications. From what I understood, resetting > > a USB 3.0 port should be required when a USB device transitions > > between different states, such as when it resumes from suspend, > > but maybe not necessarily upon the initial device attachment. > > > > Though, the Linux kernel USB driver seems to be doing additional > > USB 3.0 port resets upon the initial USB device attachment, > > presumably to ensure proper state of the USB 3.0 hub port and > > proper USB mode negotiation. > > > > Here are the links to a couple of screenshots from the USB 3.0 > > specification, for future reference: https://i.imgur.com/cMaBdq2.png > > and https://i.imgur.com/PDciRjP.png . > > > > Moreover, such USB port resets don't seem to exist for USB 2.0 > > hubs, or at least I didn't see them in the USB 2.0 specification. > > The resets seem to be added to the USB 3.0 specification as part > > of the port and device mode negotiation. > > > > Thus, the additional fix that Shantur sent, available below, looks > > to be the right way to handle it. Thus, Shantur, AFAICT it's fine > > to
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
Hi Dragan and Andre, On Sat, Feb 3, 2024 at 10:39 AM Dragan Simic wrote: > > Hello Andre and Shantur, > > On 2024-02-02 12:28, Andre Przywara wrote: > > On Fri, 02 Feb 2024 03:35:24 +0100 Dragan Simic > > wrote: > >> On 2024-02-02 01:12, Andre Przywara wrote: > >> > On Thu, 1 Feb 2024 18:35:28 + Shantur Rathore > >> > wrote: > >> >> On Thu, Feb 1, 2024 at 4:46 PM Andre Przywara > >> >> wrote: > >> >> > On Thu, 1 Feb 2024 09:39:54 + Shantur Rathore > >> >> > wrote: > >> >> > > Which USB disk are you using? Is it a USB 2.0 disk ? > >> >> > > Can you try with any other USB disk to confirm? > >> >> > > >> >> > Yes, this was some USB 2.0 memory stick, on an USB 2.0 port. > >> >> > Most sunxi boards only have USB 2.0, but there is one SoC with USB > >> >> > 3.0, I > >> >> > will try some combinations later tonight. > >> >> > >> >> That would be awesome. > >> >> We need to test > >> >> > >> >> USB 3.0 and 2.0 ports with USB 3.0 and 2.0 drives. > >> > > >> > So I had some mixed and apparently inconsistent results: > >> > - On the Pine-H64 (H6 SoC with USB 3.0 + USB 2.0) it worked with > >> > mainline, but only after I applied some pending sunxi USB PHY > >> > regulator patches. This is an unrelated issue, those patches > >> > are needed to enable USB 3.0 support on that board (shared regulator > >> > conflict). > >> > I tested a USB 2.0 and a USB 3.0 drive in both kind of slots, with > >> > and without the patch. > >> > - On the OrangePi Zero 3 (H616 SoC with USB 2.0 only), the USB 3.0 > >> > drive would not work with mainline. A USB 2.0 drive was fine. > >> > Applying your patch below fixed that problem, now both drives worked. > >> > >> Let me interject, please... > >> > >> Huh, this (mih)behavior with the tested OrangePi Zero 3 is really > >> strange. As we know, a USB 3.0 drive plugged into a USB 2.0 port > >> should behave just like a USB 2.0 drive, using the separate set > >> of pins inside the connector. > > > > Yes, I found this odd as well, hence saying inconsistent above. > > > >> If possible, performing some additional testing with another USB > >> 3.0 drive would be quite interesting. Could it be that something > >> is wrong with the USB 2.0 receptacle on your OrangePi Zero 3, > >> mechanically or electrically? > > > > The receptacle on the OPi Zero3 is a standard USB 2.0 Type-A socket, > > with clearly only 4 pins. The USB 3.0 stick in question has all 9 pins. > > So indeed there should be little difference to a USB 2.0 stick. > > Ah, sorry, I wasn't clear enough... I actually had some possible > damage to the Zero 3's USB 2.0 receptacle in mind, or some results > of the regular wear and tear, which could've possibly caused some > intermittent issues. > > > And I just tested the same board with some other (cheap) USB 2.0 stick: > > it's the same situation as with the USB 3.0 drive: it does not work > > with > > mainline, but works with the patch below. So the USB 3.0 device here > > might > > be a red herring, and it's actually more up to an individual device? > > Or maybe it's like: *Some* USB devices (in Hi-Speed mode?) do not like > > it > > when their port is reset before it's powered on? And the root hub > > implementation also plays a role, which is why we only got reports > > about > > Allwinner boards? > > Hmm, we've got quite a few unknowns there. Thank you for > performing the additional testing! > > > Also I think Marek said that Linux does the reset only when using > > SuperSpeed (hence the patch below), so maybe it's something in the USB > > 3.0 > > spec that changed the requirements? > > I just spent about an hour and a half going through the USB 2.0 > and USB 3.0 specifications. From what I understood, resetting > a USB 3.0 port should be required when a USB device transitions > between different states, such as when it resumes from suspend, > but maybe not necessarily upon the initial device attachment. > > Though, the Linux kernel USB driver seems to be doing additional > USB 3.0 port resets upon the initial USB device attachment, > presumably to ensure proper state of the USB 3.0 hub port and > proper USB mode negotiation. > > Here are the links to a couple of screenshots from the USB 3.0 > specification, for future reference: https://i.imgur.com/cMaBdq2.png > and https://i.imgur.com/PDciRjP.png . > > Moreover, such USB port resets don't seem to exist for USB 2.0 > hubs, or at least I didn't see them in the USB 2.0 specification. > The resets seem to be added to the USB 3.0 specification as part > of the port and device mode negotiation. > > Thus, the additional fix that Shantur sent, available below, looks > to be the right way to handle it. Thus, Shantur, AFAICT it's fine > to submit this fix as a separate "Fixes" patch. > Thanks for confirmation. I will submit a patch soon. > >> > - On the OrangePi Zero (H3 with USB 2.0 only), it worked with and > >> > without the patch below, with both the USB 2.0 and USB 3.0 drive. > >> > - On the
Re: [PATCH 03/15] rockchip: rk3328-rock64: Update defconfig
On 2024-02-07 08:53, Matwey V. Kornilov wrote:
> ср, 7 февр. 2024 г. в 03:14, Jonas Karlman :
>>
>> Update defconfig for rk3328-rock64 with new defaults.
>>
>> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL.
>
> What is abould rockchip-efuse?
The efuse driver is only used in U-Boot proper to read cpuid for serial#
and ethaddr use, there is nothing trying to access efuse in TPL or SPL.
Beside the initialization of efuse block done after commit 5708e8eeae53
("rockchip: rk3328: Set efuse auto mode and timing control"). But that
happens outside the efuse driver, in arch_cpu_init() at SPL.
So it is safe to skip DRIVERS_MISC for TPL/SPL and current intended use
of efuse still continues to work.
Regards,
Jonas
>
>>
>> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash
>> of FIT images. This help indicate if there is an issue loading any of
>> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep
>> support for scripts.
>>
>> Remove the NET_RANDOM_ETHADDR=y option, ethaddr and eth1addr is set
>> based on cpuid read from eFUSE.
>>
>> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL.
>>
>> Add DM_ETH_PHY=y and PHY_REALTEK=y to support onboard ethernet PHY.
>>
>> Also add missing device tree file to MAINTAINERS and add myself as a
>> reviewer for this board.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> board/rockchip/evb_rk3328/MAINTAINERS | 2 ++
>> configs/rock64-rk3328_defconfig | 7 +--
>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS
>> b/board/rockchip/evb_rk3328/MAINTAINERS
>> index dc750bd69426..419bc8ded375 100644
>> --- a/board/rockchip/evb_rk3328/MAINTAINERS
>> +++ b/board/rockchip/evb_rk3328/MAINTAINERS
>> @@ -47,8 +47,10 @@ F: arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
>>
>> ROCK64-RK3328
>> M: Matwey V. Kornilov
>> +R: Jonas Karlman
>> S: Maintained
>> F: configs/rock64-rk3328_defconfig
>> +F: arch/arm/dts/rk3328-rock64.dts
>> F: arch/arm/dts/rk3328-rock64-u-boot.dtsi
>>
>> ROCKPIE-RK3328
>> diff --git a/configs/rock64-rk3328_defconfig
>> b/configs/rock64-rk3328_defconfig
>> index 0297d098761e..0157a1efe374 100644
>> --- a/configs/rock64-rk3328_defconfig
>> +++ b/configs/rock64-rk3328_defconfig
>> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y
>> CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
>> CONFIG_TPL_LIBCOMMON_SUPPORT=y
>> CONFIG_TPL_LIBGENERIC_SUPPORT=y
>> -CONFIG_SPL_DRIVERS_MISC=y
>> CONFIG_SPL_STACK_R_ADDR=0x60
>> CONFIG_SPL_STACK=0x40
>> CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
>> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y
>> # CONFIG_ANDROID_BOOT_IMAGE is not set
>> CONFIG_FIT=y
>> CONFIG_FIT_VERBOSE=y
>> +CONFIG_SPL_FIT_SIGNATURE=y
>> CONFIG_SPL_LOAD_FIT=y
>> +CONFIG_LEGACY_IMAGE_FORMAT=y
>> CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock64.dtb"
>> # CONFIG_DISPLAY_CPUINFO is not set
>> CONFIG_DISPLAY_BOARDINFO_LATE=y
>> @@ -57,8 +58,8 @@ CONFIG_TPL_OF_PLATDATA=y
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>> CONFIG_SYS_MMC_ENV_DEV=1
>> -CONFIG_NET_RANDOM_ETHADDR=y
>> CONFIG_TPL_DM=y
>> +CONFIG_SPL_DM_SEQ_ALIAS=y
>> CONFIG_REGMAP=y
>> CONFIG_SPL_REGMAP=y
>> CONFIG_TPL_REGMAP=y
>> @@ -76,6 +77,8 @@ CONFIG_ROCKCHIP_EFUSE=y
>> CONFIG_MMC_DW=y
>> CONFIG_MMC_DW_ROCKCHIP=y
>> CONFIG_SPI_FLASH_GIGADEVICE=y
>> +CONFIG_PHY_REALTEK=y
>> +CONFIG_DM_ETH_PHY=y
>> CONFIG_ETH_DESIGNWARE=y
>> CONFIG_GMAC_ROCKCHIP=y
>> CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>> --
>> 2.43.0
>>
>
>
[PATCH] xilinx: zynqmp: Add the missing function prototype
Add missing prototype to fix the below sparse warning warning: no previous prototype for 'spl_spi_get_uboot_offs' [-Wmissing-prototypes] Signed-off-by: Venkatesh Yadav Abbarapu --- board/xilinx/zynqmp/zynqmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index 9f50090720..ba49eb7be2 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include -- 2.25.1
Re: [PATCH 10/15] rng: rockchip: Use same compatible as linux
On 2024-02-07 08:12, Heinrich Schuchardt wrote:
> On 2/7/24 01:02, Jonas Karlman wrote:
>> Replace the rockchip,cryptov1-rng compatible with compatibles used in
>> the linux device tree for RK3288, RK3328 and RK3399 to ease sync of SoC
>> device tree from linux.
>>
>> Signed-off-by: Jonas Karlman
>
> It is strange that U-Boot only uses the random number generation while
> Linux only seems to use the crypto algorithm acceleration.
>
> U-Boot has some crypto accelerator drivers in drivers/crypto/. But here
> we only make use of modular exponentiation (see struct mod_exp_ops). We
> could improve on crypto acceleration.
I believe kaslrseed was the main intended use case of this driver in
U-Boot, and the TRNG feature of crypto hw block can serve that purpose.
Regards,
Jonas
>
> The current change looks good to me.
>
> Reviewed-by: Heinrich Schuchardt
>
>> ---
>> arch/arm/dts/rk3328-u-boot.dtsi | 2 +-
>> arch/arm/dts/rk3399-u-boot.dtsi | 2 +-
>> drivers/rng/rockchip_rng.c | 10 +-
>> 3 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
>> b/arch/arm/dts/rk3328-u-boot.dtsi
>> index e087b02893c1..d805c2f394f8 100644
>> --- a/arch/arm/dts/rk3328-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3328-u-boot.dtsi
>> @@ -28,7 +28,7 @@
>> };
>>
>> rng: rng@ff06 {
>> -compatible = "rockchip,cryptov1-rng";
>> +compatible = "rockchip,rk3328-crypto";
>> reg = <0x0 0xff06 0x0 0x4000>;
>> status = "okay";
>> };
>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi
>> b/arch/arm/dts/rk3399-u-boot.dtsi
>> index 3423b882c437..87b173e59579 100644
>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
>> @@ -30,7 +30,7 @@
>> };
>>
>> rng: rng@ff8b8000 {
>> -compatible = "rockchip,cryptov1-rng";
>> +compatible = "rockchip,rk3399-crypto";
>> reg = <0x0 0xff8b8000 0x0 0x1000>;
>> status = "okay";
>> };
>> diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
>> index 705b424cf3dd..e82b5572fec5 100644
>> --- a/drivers/rng/rockchip_rng.c
>> +++ b/drivers/rng/rockchip_rng.c
>> @@ -302,7 +302,15 @@ static const struct dm_rng_ops rockchip_rng_ops = {
>>
>> static const struct udevice_id rockchip_rng_match[] = {
>> {
>> -.compatible = "rockchip,cryptov1-rng",
>> +.compatible = "rockchip,rk3288-crypto",
>> +.data = (ulong)_cryptov1_soc_data,
>> +},
>> +{
>> +.compatible = "rockchip,rk3328-crypto",
>> +.data = (ulong)_cryptov1_soc_data,
>> +},
>> +{
>> +.compatible = "rockchip,rk3399-crypto",
>> .data = (ulong)_cryptov1_soc_data,
>> },
>> {
>
Re: [PATCH 04/15] rockchip: rk3328-roc-cc: Update defconfig
On 2024-02-07 06:52, Chen-Yu Tsai wrote: > On Wed, Feb 7, 2024 at 8:04 AM Jonas Karlman wrote: >> >> Update defconfig for rk3328-roc-cc with new defaults. >> >> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL. >> >> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash >> of FIT images. This help indicate if there is an issue loading any of >> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep >> support for scripts. >> >> Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and >> eth1addr is set based on cpuid read from eFUSE. > > I wonder if it would make sense to enable ROCKCHIP_EFUSE or ROCKCHIP_OTP > for the respective SoCs by default, either with "imply" under the SoC > Kconfig options, or "default if XXX" under the driver Kconfig options? > Not sure which is preferred. > > Same goes for CONFIG_MISC_INIT_R for actually generating the serial number > and MAC addresses from the efuse/OTP. > > At least for RK3566 and RK3588 we are implying these options. I agree that these and lots of other Kconfig options could and should be implied, either at soc or arch level. Maybe something for a follow up series? Regards, Jonas > > > ChenYu > >> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL. >> >> Add DM_ETH_PHY=y, PHY_MOTORCOMM=y and PHY_REALTEK=y to support common >> ethernet PHYs. >> >> Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random >> generator. >> >> Also add missing device tree file to MAINTAINERS and add myself as a >> reviewer for this board. >> >> Signed-off-by: Jonas Karlman >> --- >> board/rockchip/evb_rk3328/MAINTAINERS | 2 ++ >> configs/roc-cc-rk3328_defconfig | 9 +++-- >> doc/board/rockchip/rockchip.rst | 2 +- >> 3 files changed, 10 insertions(+), 3 deletions(-) >> >> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS >> b/board/rockchip/evb_rk3328/MAINTAINERS >> index 419bc8ded375..09488eaf083f 100644 >> --- a/board/rockchip/evb_rk3328/MAINTAINERS >> +++ b/board/rockchip/evb_rk3328/MAINTAINERS >> @@ -41,8 +41,10 @@ F: >> arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi >> ROC-RK3328-CC >> M: Loic Devulder >> M: Chen-Yu Tsai >> +R: Jonas Karlman >> S: Maintained >> F: configs/roc-cc-rk3328_defconfig >> +F: arch/arm/dts/rk3328-roc-cc.dts >> F: arch/arm/dts/rk3328-roc-cc-u-boot.dtsi >> >> ROCK64-RK3328 >> diff --git a/configs/roc-cc-rk3328_defconfig >> b/configs/roc-cc-rk3328_defconfig >> index 4ac3c9403b02..7d81a715ef25 100644 >> --- a/configs/roc-cc-rk3328_defconfig >> +++ b/configs/roc-cc-rk3328_defconfig >> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y >> CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y >> CONFIG_TPL_LIBCOMMON_SUPPORT=y >> CONFIG_TPL_LIBGENERIC_SUPPORT=y >> -CONFIG_SPL_DRIVERS_MISC=y >> CONFIG_SPL_STACK_R_ADDR=0x60 >> CONFIG_SPL_STACK=0x40 >> CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 >> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y >> # CONFIG_ANDROID_BOOT_IMAGE is not set >> CONFIG_FIT=y >> CONFIG_FIT_VERBOSE=y >> +CONFIG_SPL_FIT_SIGNATURE=y >> CONFIG_SPL_LOAD_FIT=y >> +CONFIG_LEGACY_IMAGE_FORMAT=y >> CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-roc-cc.dtb" >> # CONFIG_DISPLAY_CPUINFO is not set >> CONFIG_DISPLAY_BOARDINFO_LATE=y >> @@ -58,8 +59,8 @@ CONFIG_TPL_OF_PLATDATA=y >> CONFIG_ENV_IS_IN_MMC=y >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> CONFIG_SYS_MMC_ENV_DEV=1 >> -CONFIG_NET_RANDOM_ETHADDR=y >> CONFIG_TPL_DM=y >> +CONFIG_SPL_DM_SEQ_ALIAS=y >> CONFIG_REGMAP=y >> CONFIG_SPL_REGMAP=y >> CONFIG_TPL_REGMAP=y >> @@ -73,9 +74,11 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y >> CONFIG_ROCKCHIP_GPIO=y >> CONFIG_SYS_I2C_ROCKCHIP=y >> CONFIG_MISC=y >> +CONFIG_ROCKCHIP_EFUSE=y >> CONFIG_MMC_DW=y >> CONFIG_MMC_DW_ROCKCHIP=y >> CONFIG_PHY_REALTEK=y >> +CONFIG_DM_ETH_PHY=y >> CONFIG_PHY_GIGE=y >> CONFIG_ETH_DESIGNWARE=y >> CONFIG_GMAC_ROCKCHIP=y >> @@ -95,6 +98,8 @@ CONFIG_PWM_ROCKCHIP=y >> CONFIG_RAM=y >> CONFIG_SPL_RAM=y >> CONFIG_TPL_RAM=y >> +CONFIG_DM_RNG=y >> +CONFIG_RNG_ROCKCHIP=y >> CONFIG_BAUDRATE=150 >> CONFIG_DEBUG_UART_SHIFT=2 >> CONFIG_SYS_NS16550_MEM32=y >> diff --git a/doc/board/rockchip/rockchip.rst >> b/doc/board/rockchip/rockchip.rst >> index de2195deadca..99f48b6d6fa5 100644 >> --- a/doc/board/rockchip/rockchip.rst >> +++ b/doc/board/rockchip/rockchip.rst >> @@ -60,8 +60,8 @@ List of mainline supported Rockchip boards: >> - ODROID-GO Advance (odroid-go2) >> * rk3328 >> - Rockchip Evb-RK3328 (evb-rk3328) >> + - Firefly ROC-RK3328-CC (roc-cc-rk3328) >> - Pine64 Rock64 (rock64-rk3328) >> - - Firefly-RK3328 (roc-cc-rk3328) >> - Radxa Rockpi E (rock-pi-e-rk3328) >> * rk3368 >> - GeekBox (geekbox) >> -- >> 2.43.0 >>
Pull request: u-boot-rockchip-20240207
Hi Tom, Please pull the updates for rockchip platform: - Add board: rv1126 Sonoff iHost board - rv1126 ddr4 support; - Enable BOOTSTD_FULL for RK3399 and RK3588; - rk3036 spl stack addr fix; - dts sync from linux v6.8-rc1 for rk356x, rk3588, rv1126; - Enable eMMC HS200 mode by default for rk3568 and rk3588; CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/19556 Thanks, - Kever The following changes since commit 819abd0a1eaff9a921f5b917e152b85dab302e33: Merge tag 'smbios-2024-04-rc2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2024-02-03 09:11:25 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20240207 for you to fetch changes up to b8f1f60c23c9b3edb70159c4e2b1be232a008ee3: arm: dts: rockpro64: Add RockPro64 smbios (2024-02-07 10:49:13 +0800) Andy Yan (1): rockchip: rk3588-evb: Enable USB support Jonas Karlman (15): net: designware: Reset eth phy before phy connect rockchip: rk3328-rock-pi-e: Enable DM_ETH_PHY and PHY_REALTEK rockchip: rk356x: Sync device tree from linux v6.7 rockchip: rk356x: Sync device tree from linux v6.8-rc1 rockchip: rk356x: Move common uart2 props to rk356x-u-boot.dtsi rockchip: rk3588: Sync device tree with linux v6.7 rockchip: rk3588: Sync device tree from linux v6.8-rc1 rockchip: rk3588: Add default u-boot,spl-boot-order prop rockchip: rk35xx: Remove unnecessary status props rockchip: rk3588: Enable eMMC HS200 mode rockchip: rk3588-quartzpro64: Enable AHCI, PCI and USB rockchip: rk35xx: Remove use of eMMC DDR52 mode rockchip: rk35xx: Enable eMMC HS200 mode by default mmc: rockchip_sdhci: Fix HS400 mode write on RK3568 rockchip: rk3568-generic: Enable eMMC HS200 mode Kever Yang (2): spl: Make SPL_STACK available for ROCKCHIP_RK3036 without spl framework configs: rockchip: rk3036: Fix CONFIG_SPL_STACK define Shantur Rathore (2): arch: arm: mach-rockchip: Kconfig: Enable BOOTSTD_FULL for RK3399 and RK3588 arm: dts: rockpro64: Add RockPro64 smbios Tim Lunn (6): arm: dts: rockchip: Sync rv1126 dts from linux 6.8-rc1 ram: rockchip: Add rv1126 ddr4 support rockchip: Convert rv1126 to standard boot board: rockchip: Add Sonoff iHost board rockchip: rv1126: select SPL_OPTEE_IMAGE rockchip: rv1126: Move RAM disk address YouMin Chen (1): rockchip: sdram: fix LPDDR5 bank info for sys_reg version 3 arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 22 ++ arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi | 7 - arch/arm/dts/rk3566-anbernic-rgxx3.dtsi| 42 ++- arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 13 - arch/arm/dts/rk3566-quartz64-a.dts | 7 +- arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 13 - arch/arm/dts/rk3566-quartz64-b.dts | 2 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 13 - arch/arm/dts/rk3566-radxa-cm3-io.dts | 5 +- arch/arm/dts/rk3566-soquartz-blade.dts | 4 + arch/arm/dts/rk3566-soquartz-cm4.dts | 4 + arch/arm/dts/rk3566-soquartz-model-a.dts | 4 + arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 13 - arch/arm/dts/rk3566-soquartz.dtsi | 4 - arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi | 13 - arch/arm/dts/rk3568-evb-u-boot.dtsi| 17 - arch/arm/dts/rk3568-evb.dts| 3 - arch/arm/dts/rk3568-generic-u-boot.dtsi| 11 - arch/arm/dts/rk3568-generic.dts| 12 +- arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 13 - arch/arm/dts/rk3568-lubancat-2.dts | 3 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 13 - arch/arm/dts/rk3568-nanopi-r5s.dtsi| 3 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 13 - arch/arm/dts/rk3568-odroid-m1.dts | 3 - arch/arm/dts/rk3568-radxa-cm3i.dtsi| 3 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 13 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi| 13 - arch/arm/dts/rk3568-rock-3a.dts| 7 +- arch/arm/dts/rk356x-u-boot.dtsi| 12 +- arch/arm/dts/rk356x.dtsi | 20 +- arch/arm/dts/rk3588-edgeble-neu6a-io.dts | 4 - arch/arm/dts/rk3588-edgeble-neu6b-io.dts | 6 +- arch/arm/dts/rk3588-evb1-v10.dts | 99 - arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi | 6 - arch/arm/dts/rk3588-nanopc-t6.dts | 10 +- arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi| 6 - arch/arm/dts/rk3588-orangepi-5-plus.dts| 1 - arch/arm/dts/rk3588
