Re: [PATCH v4 0/2] k3-am625-beagleplay: Add symlinks for tiboot3 and tispl
On Fri, Jun 28, 2024 at 8:12 AM Nishanth Menon wrote: > > On 10:19-20240618, Dhruva Gole wrote: > > Add symlinks for both tiboot3.bin and tispl.bin because a user has to > > anyway rename these files to get the platform to boot up. > > Also update the documentation to reflect above change. > > > > Changes in v4: > > * Add the docs patch. > > > > Cc: Nishant Menon > > Cc: Robert Nelson > > > > Dhruva Gole (2): > > arm: dts: k3-am625-beagleplay: Add symlinks for tiboot3 and tispl > > doc: beagle: am62x_beagleplay: Rename the boot bins > > > > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 1 + > > arch/arm/dts/k3-am625-r5-beagleplay.dts | 1 + > > doc/board/beagle/am62x_beagleplay.rst| 7 +++ > > 3 files changed, 5 insertions(+), 4 deletions(-) > > > Robert/Jason: > > Can you folks confirm that we will ONLY have GP version of BeaglePlay > for even a new update of the board? If that is confirmed, then this > series is good. > > Any thoughts? Yeap pretty sure the BeaglePlay will ONLY ever use the GP version. I know there is a list of wants for BeaglePlay2, cc33xx WiFi, the newer ITE HDMI encoder (oh wait, BeagleY-AI)... Regards, -- Robert Nelson https://rcn-ee.com/
[PATCH v4 3/3] drivers: bootcount: Fix typo in documentation
The bootcount documentation was using "unattended" while it probably intending to say "unintended" Signed-off-by: Vasileios Amoiridis --- doc/api/bootcount.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/api/bootcount.rst b/doc/api/bootcount.rst index 9435a7ef15..968c679c3c 100644 --- a/doc/api/bootcount.rst +++ b/doc/api/bootcount.rst @@ -49,7 +49,7 @@ The format of the file is: * - u8 - upgrade_available -To prevent unattended usage of ``altbootcmd``, the ``upgrade_available`` +To prevent unintended usage of ``altbootcmd``, the ``upgrade_available`` variable is used. If ``upgrade_available`` is 0, ``bootcount`` is not saved. If ``upgrade_available`` is 1, ``bootcount`` is saved. -- 2.25.1
[PATCH v4 2/3] doc: api: bootcount: Convert to rST documentation
Move to the new documentation style with rST formatting. Signed-off-by: Vasileios Amoiridis --- doc/README.bootcount | 53 --- doc/api/bootcount.rst | 58 +++ doc/api/index.rst | 1 + 3 files changed, 59 insertions(+), 53 deletions(-) delete mode 100644 doc/README.bootcount create mode 100644 doc/api/bootcount.rst diff --git a/doc/README.bootcount b/doc/README.bootcount deleted file mode 100644 index 0f4ffb6828..00 --- a/doc/README.bootcount +++ /dev/null @@ -1,53 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -Boot Count Limit - - -This is enabled by CONFIG_BOOTCOUNT_LIMIT. - -This allows to detect multiple failed attempts to boot Linux. - -After a power-on reset, the "bootcount" variable will be initialized to 1, and -each reboot will increment the value by 1. - -If, after a reboot, the new value of "bootcount" exceeds the value of -"bootlimit", then instead of the standard boot action (executing the contents of -"bootcmd"), an alternate boot action will be performed, and the contents of -"altbootcmd" will be executed. - -If the variable "bootlimit" is not defined in the environment, the Boot Count -Limit feature is disabled. If it is enabled, but "altbootcmd" is not defined, -then U-Boot will drop into interactive mode and remain there. - -It is the responsibility of some application code (typically a Linux -application) to reset the variable "bootcount" to 0 when the system booted -successfully, thus allowing for more boot cycles. - -CONFIG_BOOTCOUNT_FS - - -This adds support for maintaining boot count in a file on a filesystem. -Supported filesystems are FAT and EXT. The file to use is defined by: - -CONFIG_SYS_BOOTCOUNT_FS_INTERFACE -CONFIG_SYS_BOOTCOUNT_FS_DEVPART -CONFIG_SYS_BOOTCOUNT_FS_NAME - -The format of the file is: - - = -type entry - = -u8 magic -u8 version -u8 bootcount -u8 upgrade_available - = - -To prevent unattended usage of "altbootcmd", the "upgrade_available" variable is -used. -If "upgrade_available" is 0, "bootcount" is not saved. -If "upgrade_available" is 1, "bootcount" is saved. -So a userspace application should take care of setting the "upgrade_available" -and "bootcount" variables to 0, if the system boots successfully. -This also avoids writing the "bootcount" information on all reboots. diff --git a/doc/api/bootcount.rst b/doc/api/bootcount.rst new file mode 100644 index 00..9435a7ef15 --- /dev/null +++ b/doc/api/bootcount.rst @@ -0,0 +1,58 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Boot Count Limit + + +This is enabled by CONFIG_BOOTCOUNT_LIMIT. + +This allows to detect multiple failed attempts to boot Linux. + +After a power-on reset, the ``bootcount`` variable will be initialized to 1, and +each reboot will increment the value by 1. + +If, after a reboot, the new value of ``bootcount`` exceeds the value of +``bootlimit``, then instead of the standard boot action (executing the contents +of ``bootcmd``), an alternate boot action will be performed, and the contents of +``altbootcmd`` will be executed. + +If the variable ``bootlimit`` is not defined in the environment, the Boot Count +Limit feature is disabled. If it is enabled, but ``altbootcmd`` is not defined, +then U-Boot will drop into interactive mode and remain there. + +It is the responsibility of some application code (typically a Linux +application) to reset the variable ``bootcount`` to 0 when the system booted +successfully, thus allowing for more boot cycles. + +CONFIG_BOOTCOUNT_FS + + +This adds support for maintaining boot count in a file on a filesystem. +Tested filesystems are FAT and EXT. The file to use is defined by: + +CONFIG_SYS_BOOTCOUNT_FS_INTERFACE +CONFIG_SYS_BOOTCOUNT_FS_DEVPART +CONFIG_SYS_BOOTCOUNT_FS_NAME + +The format of the file is: + +.. list-table:: + :header-rows: 1 + + * - type + - entry + * - u8 + - magic + * - u8 + - version + * - u8 + - bootcount + * - u8 + - upgrade_available + +To prevent unattended usage of ``altbootcmd``, the ``upgrade_available`` +variable is used. +If ``upgrade_available`` is 0, ``bootcount`` is not saved. +If ``upgrade_available`` is 1, ``bootcount`` is saved. +So a userspace application should take care of setting the ``upgrade_available`` +and ``bootcount`` variables to 0, if the system boots successfully. +This also avoids writing the ``bootcount`` information on all reboots. diff --git a/doc/api/index.rst b/doc/api/index.rst index 51b2013af3..ec0b8adb2c 100644 --- a/doc/api/index.rst +++ b/doc/api/index.rst @@ -6,6 +6,7 @@ U-Boot API documentation .. toctree:: :maxdepth: 2 + bootcount clk dfu dm -- 2.25.1
[PATCH v4 1/3] drivers: bootcount: Add support for ANY filesystem
Add support to save boot count variable in ANY filesystem. Tested with
FAT and EXT.
Reviewed-by: Tom Rini
Reviewed-by: Heiko Schocher
Reviewed-by: Philip Oberfichtner
Signed-off-by: Vasileios Amoiridis
---
doc/README.bootcount | 12 +++
drivers/bootcount/Kconfig | 36 +--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 +++
4 files changed, 31 insertions(+), 31 deletions(-)
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
diff --git a/doc/README.bootcount b/doc/README.bootcount
index f6c5f82f98..0f4ffb6828 100644
--- a/doc/README.bootcount
+++ b/doc/README.bootcount
@@ -23,15 +23,15 @@ It is the responsibility of some application code
(typically a Linux
application) to reset the variable "bootcount" to 0 when the system booted
successfully, thus allowing for more boot cycles.
-CONFIG_BOOTCOUNT_EXT
+CONFIG_BOOTCOUNT_FS
-This adds support for maintaining boot count in a file on an EXT filesystem.
-The file to use is defined by:
+This adds support for maintaining boot count in a file on a filesystem.
+Supported filesystems are FAT and EXT. The file to use is defined by:
-CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE
-CONFIG_SYS_BOOTCOUNT_EXT_DEVPART
-CONFIG_SYS_BOOTCOUNT_EXT_NAME
+CONFIG_SYS_BOOTCOUNT_FS_INTERFACE
+CONFIG_SYS_BOOTCOUNT_FS_DEVPART
+CONFIG_SYS_BOOTCOUNT_FS_NAME
The format of the file is:
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 3c56253b1e..fbf3c56b41 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -25,13 +25,13 @@ config BOOTCOUNT_GENERIC
Set to the address where the bootcount and bootcount magic
will be stored.
-config BOOTCOUNT_EXT
- bool "Boot counter on EXT filesystem"
- depends on FS_EXT4
- select EXT4_WRITE
+config BOOTCOUNT_FS
+ bool "Boot counter on a filesystem"
help
- Add support for maintaining boot count in a file on an EXT
- filesystem.
+ Add support for maintaining boot count in a file on a filesystem.
+ This requires that you have enabled write support for the filesystem
+ that you will be used by the partition that you configure this feature
+ for.
config BOOTCOUNT_AM33XX
bool "Boot counter in AM33XX RTC IP block"
@@ -184,26 +184,26 @@ config SYS_BOOTCOUNT_SINGLEWORD
This option enables packing boot count magic value and boot count
into single word (32 bits).
-config SYS_BOOTCOUNT_EXT_INTERFACE
- string "Interface on which to find boot counter EXT filesystem"
+config SYS_BOOTCOUNT_FS_INTERFACE
+ string "Interface on which to find boot counter filesystem"
default "mmc"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the interface to use when locating the filesystem to use for the
boot counter.
-config SYS_BOOTCOUNT_EXT_DEVPART
- string "Partition of the boot counter EXT filesystem"
+config SYS_BOOTCOUNT_FS_DEVPART
+ string "Partition of the boot counter filesystem"
default "0:1"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the partition to use when locating the filesystem to use for the
boot counter.
-config SYS_BOOTCOUNT_EXT_NAME
- string "Path and filename of the EXT filesystem based boot counter"
+config SYS_BOOTCOUNT_FS_NAME
+ string "Path and filename of the FS filesystem based boot counter"
default "/boot/failures"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the filename and path of the file used to store the boot counter.
@@ -211,18 +211,18 @@ config SYS_BOOTCOUNT_ADDR
hex "RAM address used for reading and writing the boot counter"
default 0x44E3E000 if BOOTCOUNT_AM33XX || BOOTCOUNT_AM33XX_NVMEM
default 0xE0115FF8 if ARCH_LS1043A || ARCH_LS1021A
- depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX_NVMEM
help
Set the address used for reading and writing the boot counter.
config SYS_BOOTCOUNT_MAGIC
hex "Magic value for the boot counter"
- default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
BOOTCOUNT_RAM || BOOTCOUNT_AT91 || DM_BOOTCOUNT
default 0xB0 if BOOTCOUNT_AM33XX_NVMEM
- depends on BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ depends on BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
BOOTCOUNT_RAM || BOOTCOUNT_AT91 ||
[PATCH v4 0/3] drivers: bootcount: Add support for ANY filesystem
Changes in v4:
- Add bootcount.rst in doc/api/index.rst
- Fix typo in documentation
Changes in v3:
- Remove specific CONFIGs for filesystems
- Add message to prompt user to enable required write function
- Use tags from previous rounds
- Move documentation to rST
v2:
https://lore.kernel.org/u-boot/20240610185116.353604-1-vassilisa...@gmail.com
Changes in v2:
- Use generic code by utilizing FS_TYPE_ANY
- Change filename from bootcount_ext.c to bootcount_fs.c
v1:
https://lore.kernel.org/u-boot/20240605181041.68317-1-vassilisa...@gmail.com/
This patch adds support to save the bootcount variable in a file located in
FAT filesystem. Up to now, there was support only for EXT filesystem.
The reason I put this as RFC is because the file "bootcount_ext.c" will no
longer represent the implementation for the EXT filesystem, but also for the
FAT filesystem. Should it be renamed? If not, wouldn't it be inconsistent?
Cheers,
Vasilis
Vasileios Amoiridis (3):
drivers: bootcount: Add support for ANY filesystem
doc: api: bootcount: Convert to rST documentation
drivers: bootcount: Fix typo in documentation
doc/README.bootcount | 53 -
doc/api/bootcount.rst | 58 +++
doc/api/index.rst | 1 +
drivers/bootcount/Kconfig | 36 ++--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 ++--
6 files changed, 84 insertions(+), 78 deletions(-)
delete mode 100644 doc/README.bootcount
create mode 100644 doc/api/bootcount.rst
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
base-commit: c53b344475734d0d29f522b7b1d80c5b8204442d
--
2.25.1
[PATCH 1/1] efi_loader: print device-tree in dtbdump.efi
The dtbdump.efi binary can be used for testing the EFI_DT_FIXUP_PROTOCOL.
It provides a command to load a file and have it fixed up and a
command to save the resulting file.
Add a command 'dump' for displaying the device-tree.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/dtbdump.c | 228 +++
1 file changed, 228 insertions(+)
diff --git a/lib/efi_loader/dtbdump.c b/lib/efi_loader/dtbdump.c
index 5f39cf22da7..8dbd69a56ef 100644
--- a/lib/efi_loader/dtbdump.c
+++ b/lib/efi_loader/dtbdump.c
@@ -40,6 +40,53 @@ static void print(u16 *string)
cout->output_string(cout, string);
}
+/**
+ * print_char() - print character
+ *
+ * 0x00 is replaced by '", "'.
+ *
+ * @c: - character
+ */
+static void print_char(unsigned char c)
+{
+ u16 out[2] = u"?";
+
+ if (!c) {
+ print(u"\", \"");
+ return;
+ }
+
+ if (c > 0x1f && c < 0x80)
+ out[0] = c;
+
+ print(out);
+}
+
+/**
+ * print_hex_digit() - print hexadecimal digit
+ *
+ * @digit: digit to print
+ */
+static void print_hex_digit(unsigned char digit)
+{
+ if (digit < 10)
+ digit += '0';
+ else
+ digit += 'a' - 10;
+ print_char(digit);
+}
+
+/**
+ * printx() - print hexadecimal byte
+ *
+ * @val: value to print
+ */
+static void printx(unsigned char val)
+{
+ print_hex_digit(val >> 4);
+ print_hex_digit(val & 0xf);
+}
+
/**
* error() - print error string
*
@@ -227,6 +274,7 @@ bool starts_with(u16 *string, u16 *keyword)
*/
void do_help(void)
{
+ error(u"dump - print device-tree\r\n");
error(u"load - load device-tree from file\r\n");
error(u"save - save device-tree to file\r\n");
error(u"exit - exit the shell\r\n");
@@ -489,6 +537,184 @@ efi_status_t do_save(u16 *filename)
return ret;
}
+/**
+ * indent() - print a number of tabstops
+ *
+ * @level: indentation level
+ */
+static void indent(u32 level)
+{
+ for (; level; --level)
+ print(u"\t");
+}
+
+/**
+ * is_string_value() - determine if property is a string
+ *
+ * If a property is a string, an x-string, or a u32 cannot be deducted
+ * from the device-tree. Therefore a heuristic is used.
+ *
+ * @str: pointer to device-tree property
+ * @len: length of the device-tree property
+ * Return: 1 for string, 0 otherwise
+ */
+static int is_string_value(const unsigned char *str, u32 len)
+{
+ int nonzero_flag = 0;
+
+ /* Zero length or not ending with 0x00 */
+ if (!len || str[len - 1])
+ return 0;
+
+ for (u32 i = 0; i < len; ++i) {
+ if (!str[i]) {
+ /* Zero length string or two consecutive 0x00 */
+ if (!nonzero_flag)
+ return 0;
+
+ nonzero_flag = 0;
+
+ continue;
+ }
+ /* Space or non-printable */
+ if (str[i] <= ' ' || str[i] >= 0x80)
+ return 0;
+
+ nonzero_flag = 1;
+ }
+
+ return 1;
+}
+
+/**
+ * print_property() - print device-tree property
+ *
+ * If a property is a string, an x-string, or a u32 cannot be deducted
+ * from the device-tree. Therefore a heuristic is used.
+ *
+ * @str: property value
+ * @len: length of property value
+ */
+static void print_property(const unsigned char *val, u32 len)
+{
+ if (is_string_value(val, len)) {
+ print(u"\"");
+ for (int i = 0; i < len - 1; ++i)
+ print_char(val[i]);
+ print(u"\"");
+ } else if (len & 0x3) {
+ print(u"<0x");
+ for (int i = 0; i < len; ++i)
+ printx(val[i]);
+ print(u">\"");
+ } else {
+ print(u"<");
+ for (u32 i = 0; i < len; ++i) {
+ if ((i & 0x3) == 0) {
+ if (i > 0)
+ print(u" ");
+ print(u"0x");
+ }
+ printx(val[i]);
+ }
+ print(u">");
+ }
+}
+
+/**
+ * do_dump() - print device-tree
+ */
+static efi_status_t do_dump(void)
+{
+ const char *fdt;
+ struct fdt_header *header;
+ const u32 *end;
+ const u32 *pos;
+ const char *strings;
+ u32 level = 0;
+
+ fdt = get_dtb(systable);
+ if (!fdt) {
+ error(u"DTB not found\r\n");
+ return EFI_NOT_FOUND;
+ }
+
+ header = (struct fdt_header *)fdt;
+ if (f2h(header->magic) != FDT_MAGIC) {
+ error(u"Wrong device tree magic\r\n");
+ error(u"Not a device-tree\r\n");
+ return EFI_LOAD_ERROR;
+ }
+
+ pos = (u32 *)(fdt +
Re: [PATCH v6 0/8] Bug-fixes for a few boards (reduced series)
On Thu, 27 Jun 2024 09:29:41 +0100, Simon Glass wrote: > This series includes fixes to get some rockchip and nvidia boards > working again. It also drops the broken Beaglebone Black config and > provides a devicetree fix for coral (x86). > > Note that since this series fixes bugs, it is targeted at -master > > Note that this series does not include: > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH] omap3: igep0x00: Switch to the I2C driver model
From: Javier Martinez Canillas
When building with the igep00x0_defconfig, the following warning is shown:
$ make -j $(nproc)
...
LD spl/u-boot-spl
OBJCOPY spl/u-boot-spl-nodtb.bin
SYM spl/u-boot-spl.sym
CAT spl/u-boot-spl-dtb.bin
COPYspl/u-boot-spl.bin
MKIMAGE MLO
= WARNING ==
This board does not use CONFIG_DM_I2C (Driver Model
for I2C drivers). Please update the board to use
CONFIG_DM_I2C before the v2022.04 release. Failure to
update by the deadline may result in board removal.
See doc/develop/driver-model/migration.rst for more info.
The only reason why I2C is enabled for the IGEP boards is that the TWL4030
driver requires it.
But both the TWL4034 and the OMAP I2C controller drivers were converted to
the driver model by commits daa69ffe3d4d ("drivers: i2c: omap24xx_i2c:
adopt omap_i2c driver to driver model") and fb1b7712ad3f power: make most
tps drivers and the twl4030 driver compatible with DM_I2C") respectively.
So there's no reason anymore to keep using the I2C legacy API and instead
the DM_I2C option could just be enabled.
Signed-off-by: Javier Martinez Canillas
---
configs/igep00x0_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index 87fd2797eace..473891607b0f 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -68,8 +68,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_VERSION_VARIABLE=y
# CONFIG_NET is not set
CONFIG_SPL_DM=y
-CONFIG_SYS_I2C_LEGACY=y
-CONFIG_SPL_SYS_I2C_LEGACY=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
CONFIG_MMC_OMAP_HS=y
CONFIG_MTD=y
CONFIG_SYS_MTDPARTS_RUNTIME=y
--
2.45.2
Re: [PATCH v2] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board
Hi Phil,
On Fri, Jun 28, 2024 at 3:04 PM Tony Dinh wrote:
>
> Hi Phil,
>
> On Wed, Jun 26, 2024 at 3:31 AM Phil Sutter wrote:
> >
> > Hi Tony,
> >
> > On Sat, Jun 15, 2024 at 03:06:54PM -0700, Tony Dinh wrote:
> > [...]
> > > diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
> > > index abe6f9eb5e..f0b55fa095 100644
> > > --- a/board/Synology/ds414/ds414.c
> > > +++ b/board/Synology/ds414/ds414.c
> > > @@ -181,18 +181,9 @@ int board_init(void)
> > > return 0;
> > > }
> > >
> > > -int misc_init_r(void)
> > > +int board_late_init(void)
> > > {
> > > - if (!env_get("ethaddr")) {
> > > - puts("Incomplete environment, populating from SPI flash\n");
> > > - do_syno_populate(0, NULL);
> > > - }
> > > - return 0;
> > > -}
> >
> > Could you please leave misc_init_r() in place (along with MISC_INIT_R in
> > defconfig)? A closer look at doc/README.enetaddr suggests that
> > implementing this board-specific function which acts if the environment
> > does not have ethaddr defined already is exactly the right thing to do.
> > Also, it doesn't conflict with NET_RANDOM_ETHADDR: If do_syno_populate()
> > succeeds, no random MAC addresses are generated. If I manually remove
> > the call, random MACs come into play. So having this option enabled
> > serves as a fallback for boxes which lack the data in flash.
>
> Sure I will do that. I was mistaken in assuming that network random
> addresses were already generated before misc_init_r(). Thanks!
>
> >
> > > -int checkboard(void)
> > > -{
> > > - puts("Board: DS414\n");
> > > -
> > > + /* Do late init to ensure successful enumeration of XHCI devices */
> > > + pci_init();
> > > return 0;
> > > }
> >
> > FWIW, booting from rear USB port worked fine for me!
>
> Cool! That was the main thing I was interested in for sending in this
> patch. One thing led to another... :)
>
> >
> > > diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
> > > index ecf9501ba5..501ed51129 100644
> > > --- a/configs/ds414_defconfig
> > > +++ b/configs/ds414_defconfig
> > [...]
> > > @@ -25,44 +26,40 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000
> > > CONFIG_SPL=y
> > > CONFIG_DEBUG_UART_BASE=0xf1012000
> > > CONFIG_DEBUG_UART_CLOCK=25000
> > > +CONFIG_IDENT_STRING="\nSynology DS214+/DS414 2/4-Bay Diskstation"
> > > CONFIG_SYS_LOAD_ADDR=0x80
> > > CONFIG_PCI=y
> > > CONFIG_DEBUG_UART=y
> > > +CONFIG_BOOTSTD_FULL=y
> > > CONFIG_BOOTDELAY=3
> > > CONFIG_USE_BOOTARGS=y
> > > -CONFIG_BOOTARGS="console=ttyS0,115200 ip=off initrd=0x840,8M
> > > root=/dev/md0 rw syno_hw_version=DS414r1 ihd_num=4 netif_num=2
> > > flash_size=8 SataLedSpecial=1 HddHotplug=1"
> > > -CONFIG_USE_BOOTCOMMAND=y
> > > -CONFIG_BOOTCOMMAND="sf probe; sf read ${loadaddr} 0xd 0x2d; sf
> > > read ${ramdisk_addr_r} 0x3a 0x43; bootm ${loadaddr}
> > > ${ramdisk_addr_r}"
> >
> > So these should not be necessary anymore with BOOTSTD. I wonder if it is
> > possible to provide a static bootmeth (or bootflow?) with low priority
> > which boots the legacy OS from flash. It could hold all the details
> > instead of the *_legacy env vars introduced below.
>
> I recall from bootstd documentation that it is possible to have a
> bootflow on flash. But it seems a bit too much for this patch. I think
> we'll have to repartition or find some space on the flash to store
> that bootflow script.
>
Sorry I've misread your comment "it is possible to provide a static
bootmeth (or bootflow?) ". I think by "static bootflow" you must have
meant we would define it in the board code, and convince bootstd to
use it as the last boot method (without hunting for it on flash). I'm
not sure. Perhaps "global bootflow" is something that can be defined
and used here. I'll have to dig into bootstd documentation a bit more.
All the best,
Tony
> >
> > A pending issue for me is inability to 'saveenv' - the flash seems
> > read-only in that spot. Does it work for you?
>
> Yes it does work for me. With the latest u-boot SPI flash driver, as I
> recall, the entire flash is automatically unprotected at
> initialization. But we need to be careful using saveenv running stock
> FW, because it could overwrite the rootfs on flash. It is common for
> Synology NAS that the envs location is at the same place as the stock
> rootfs. Since I don't care about stock FW, I saved the envs and used
> the location for u-boot envs in Linux /etc/fw_env.config. I'm not sure
> if my DS214+ box can boot stock FW anymore :)
>
> >
> > > # CONFIG_DISPLAY_BOARDINFO is not set
> > > CONFIG_DISPLAY_BOARDINFO_LATE=y
> > > -CONFIG_MISC_INIT_R=y
> > > +CONFIG_BOARD_LATE_INIT=y
> > > CONFIG_SPL_MAX_SIZE=0x1bfd0
> > > CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > > CONFIG_SPL_I2C=y
> > > +CONFIG_SYS_PROMPT="DS414> "
> >
> > Can we detect whether it is 414 or 214, BTW? bootargs_legacy contains
> > 414-specific info as well.
>
> It's a bit hard
Re: [PATCH v2] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board
Hi Phil,
On Wed, Jun 26, 2024 at 3:31 AM Phil Sutter wrote:
>
> Hi Tony,
>
> On Sat, Jun 15, 2024 at 03:06:54PM -0700, Tony Dinh wrote:
> [...]
> > diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
> > index abe6f9eb5e..f0b55fa095 100644
> > --- a/board/Synology/ds414/ds414.c
> > +++ b/board/Synology/ds414/ds414.c
> > @@ -181,18 +181,9 @@ int board_init(void)
> > return 0;
> > }
> >
> > -int misc_init_r(void)
> > +int board_late_init(void)
> > {
> > - if (!env_get("ethaddr")) {
> > - puts("Incomplete environment, populating from SPI flash\n");
> > - do_syno_populate(0, NULL);
> > - }
> > - return 0;
> > -}
>
> Could you please leave misc_init_r() in place (along with MISC_INIT_R in
> defconfig)? A closer look at doc/README.enetaddr suggests that
> implementing this board-specific function which acts if the environment
> does not have ethaddr defined already is exactly the right thing to do.
> Also, it doesn't conflict with NET_RANDOM_ETHADDR: If do_syno_populate()
> succeeds, no random MAC addresses are generated. If I manually remove
> the call, random MACs come into play. So having this option enabled
> serves as a fallback for boxes which lack the data in flash.
Sure I will do that. I was mistaken in assuming that network random
addresses were already generated before misc_init_r(). Thanks!
>
> > -int checkboard(void)
> > -{
> > - puts("Board: DS414\n");
> > -
> > + /* Do late init to ensure successful enumeration of XHCI devices */
> > + pci_init();
> > return 0;
> > }
>
> FWIW, booting from rear USB port worked fine for me!
Cool! That was the main thing I was interested in for sending in this
patch. One thing led to another... :)
>
> > diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
> > index ecf9501ba5..501ed51129 100644
> > --- a/configs/ds414_defconfig
> > +++ b/configs/ds414_defconfig
> [...]
> > @@ -25,44 +26,40 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000
> > CONFIG_SPL=y
> > CONFIG_DEBUG_UART_BASE=0xf1012000
> > CONFIG_DEBUG_UART_CLOCK=25000
> > +CONFIG_IDENT_STRING="\nSynology DS214+/DS414 2/4-Bay Diskstation"
> > CONFIG_SYS_LOAD_ADDR=0x80
> > CONFIG_PCI=y
> > CONFIG_DEBUG_UART=y
> > +CONFIG_BOOTSTD_FULL=y
> > CONFIG_BOOTDELAY=3
> > CONFIG_USE_BOOTARGS=y
> > -CONFIG_BOOTARGS="console=ttyS0,115200 ip=off initrd=0x840,8M
> > root=/dev/md0 rw syno_hw_version=DS414r1 ihd_num=4 netif_num=2 flash_size=8
> > SataLedSpecial=1 HddHotplug=1"
> > -CONFIG_USE_BOOTCOMMAND=y
> > -CONFIG_BOOTCOMMAND="sf probe; sf read ${loadaddr} 0xd 0x2d; sf
> > read ${ramdisk_addr_r} 0x3a 0x43; bootm ${loadaddr}
> > ${ramdisk_addr_r}"
>
> So these should not be necessary anymore with BOOTSTD. I wonder if it is
> possible to provide a static bootmeth (or bootflow?) with low priority
> which boots the legacy OS from flash. It could hold all the details
> instead of the *_legacy env vars introduced below.
I recall from bootstd documentation that it is possible to have a
bootflow on flash. But it seems a bit too much for this patch. I think
we'll have to repartition or find some space on the flash to store
that bootflow script.
>
> A pending issue for me is inability to 'saveenv' - the flash seems
> read-only in that spot. Does it work for you?
Yes it does work for me. With the latest u-boot SPI flash driver, as I
recall, the entire flash is automatically unprotected at
initialization. But we need to be careful using saveenv running stock
FW, because it could overwrite the rootfs on flash. It is common for
Synology NAS that the envs location is at the same place as the stock
rootfs. Since I don't care about stock FW, I saved the envs and used
the location for u-boot envs in Linux /etc/fw_env.config. I'm not sure
if my DS214+ box can boot stock FW anymore :)
>
> > # CONFIG_DISPLAY_BOARDINFO is not set
> > CONFIG_DISPLAY_BOARDINFO_LATE=y
> > -CONFIG_MISC_INIT_R=y
> > +CONFIG_BOARD_LATE_INIT=y
> > CONFIG_SPL_MAX_SIZE=0x1bfd0
> > CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > CONFIG_SPL_I2C=y
> > +CONFIG_SYS_PROMPT="DS414> "
>
> Can we detect whether it is 414 or 214, BTW? bootargs_legacy contains
> 414-specific info as well.
It's a bit hard to do without creating another defconfig. AFAICT, the
only difference between DS414 and DS214+ is the number of SATA bays.
But currently u-boot SATA does not work for this box. U-Boot sata_mv
driver is a subset of Linux sata_mv, and we don't have support for the
right PCIe SATA chip in u-boot sata_mv.
>
> [...]
> > diff --git a/include/configs/ds414.h b/include/configs/ds414.h
> > index 9446acba79..89e55bf0d4 100644
> > --- a/include/configs/ds414.h
> > +++ b/include/configs/ds414.h
> [...]
> > @@ -16,14 +17,9 @@
> > * U-Boot into it.
> > */
> >
> > -/* I2C */
> > #define CFG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE
> >
> > -/*
> > - * mv-common.h should be defined after CMD configs since it used them
> > -
Re: [PATCH] arm: mediatek: fix ram init for mt7622 (decrease to 1G)
On Sat, 15 Jun 2024 11:34:56 +0200, Frank Wunderlich wrote: > RAM init on mt7622 based bananapi R64 is broken since v2023.10. > > Increasing the mem-map does not help here, so i reduced the maximum > available ram in get_ram_size call from 2G to 1G (board has only 1G). > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] board: mpfs_icicle: change maintainer to Conor
On Sat, 22 Jun 2024 21:18:31 +0100, Conor Dooley wrote: > Padmarao is leaving Microchip soon, and suggested that I should take > over maintaining the Icicle in U-Boot in his stead. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] cmd: gpt: Fix freeing gpt_pte in gpt_verify()
On Wed, 19 Jun 2024 16:23:30 -0500, Sam Protsenko wrote: > In case when either gpt_verify_headers() or gpt_verify_partitions() > fails, the memory allocated for gpt_pte will be freed in those functions > internally, but gpt_pte will still contain non-NULL dangling pointer. > The attempt to free it in those cases in gpt_verify() leads to "use > after free" error, which leads to a "Synchronous abort" exception. > > This issue was found by running the next command on the device with > incorrect partition table: > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [v2] cmd: Make use of U_BOOT_LONGHELP when missing
On Wed, 19 Jun 2024 10:09:44 -0600, Tom Rini wrote: > After adding the U_BOOT_LONGHELP macro some new commands came in still > that were not making use if it. Switch these cases over and in a few > places add missing newlines as well. > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] scripts/Makefile.lib: remove bootph-some-ram property from VPL/TPL/SPL
On Wed, 19 Jun 2024 13:33:28 +0200, Quentin Schulz wrote: > The property isn't useful in VPL/SPL/TPL as it is only for U-Boot proper > pre-reloc, which has its own DTB. > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] arm: davinci: remove unused watchdog functions
On Wed, 19 Jun 2024 10:57:49 +, Emil Kronborg wrote:
> The davinci_hw_watchdog_ functions are defined but never called from
> anywhere. Commit 881ae794b93b ("calimain: remove board") eliminated the
> last call to these functions.
>
>
Applied to u-boot/next, thanks!
--
Tom
Re: [PATCH v2] fs: btrfs: fix out of bounds write
On Wed, 19 Jun 2024 00:41:38 +0300, Alex Shumsky wrote: > Fix btrfs_read/read_and_truncate_page write out of bounds of destination > buffer. Old behavior break bootstd malloc'd buffers of exact file size. > Previously this OOB write have not been noticed because distroboot usually > read files into huge static memory areas. > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v4 0/2] k3-am625-beagleplay: Add symlinks for tiboot3 and tispl
On Tue, 18 Jun 2024 10:19:44 +0530, Dhruva Gole wrote: > Add symlinks for both tiboot3.bin and tispl.bin because a user has to > anyway rename these files to get the platform to boot up. > Also update the documentation to reflect above change. > > Changes in v4: > * Add the docs patch. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v2] board: beagleplay: Fix the bootpart to pick from root partition
On Tue, 18 Jun 2024 10:23:18 +0530, Dhruva Gole wrote: > The Kernel Image and DTB files are supposed to be picked from the rootfs > of the SD Card, this fails in legacy boot flow because bootpart is set > to 1:1. Fix it. > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v1] arm: mach-k3: j784s4: Fix MCU_CLKOUT0 parent clock mux
On Mon, 17 Jun 2024 11:22:01 +0200, Emanuele Ghidoli wrote: > MCU_CLKOUT0 output can be driven by two different clock inputs: > one at 25 MHz and another at 50 MHz. Currently, the 25 MHz input > clock is not selectable due to a duplication of the 50 MHz clock input > in the mux configuration. This commit corrects the parent clock mux > configuration, making the 25 MHz input clock selectable. > > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH 1/5] Azure: Correct comment about the strategy in the world matrix build
On Tue, 18 Jun 2024 08:18:47 -0600, Tom Rini wrote: > At this point noting that we have a split in our job similar to TravisCI > (which we have not used in years) isn't helpful, and is also not true > anymore either. Instead, explain that we split the world up in to 10 > jobs as that's the maximum we can have going in parallel on the free > tier of Azure. > > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH 12/12] clk: mediatek: add support for APMIXED parent in infra MUX
Add support for APMIXED parent in infra MUX. This is the case for mt7622
that reference APMIXED parents for the MUX1_SEL clock.
We assume the second level parent is always APMIXED.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index c1d171624b9..66683aeb2d7 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -488,6 +488,10 @@ static ulong mtk_find_parent_rate(struct mtk_clk_priv
*priv, struct clk *clk,
switch (flags & CLK_PARENT_MASK) {
case CLK_PARENT_XTAL:
return priv->tree->xtal_rate;
+ /* Assume the second level parent is always APMIXED */
+ case CLK_PARENT_APMIXED:
+ priv = dev_get_priv(priv->parent);
+ fallthrough;
case CLK_PARENT_TOPCKGEN:
return mtk_clk_find_parent_rate(clk, parent, priv->parent);
default:
--
2.45.1
[PATCH 11/12] clk: mediatek: add support for GATEs for APMIXED OPs
Add support for GATEs for APMIXED OPs. It's possible that some APMIXED
have also gates on top of PLL. This is the case for mt7622. Add support
for this.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 144 +++--
1 file changed, 84 insertions(+), 60 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 096f593fc5c..c1d171624b9 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -47,6 +47,56 @@ static int mtk_clk_get_id(struct clk *clk)
return id;
}
+static int mtk_gate_enable(void __iomem *base, const struct mtk_gate *gate)
+{
+ u32 bit = BIT(gate->shift);
+
+ switch (gate->flags & CLK_GATE_MASK) {
+ case CLK_GATE_SETCLR:
+ writel(bit, base + gate->regs->clr_ofs);
+ break;
+ case CLK_GATE_SETCLR_INV:
+ writel(bit, base + gate->regs->set_ofs);
+ break;
+ case CLK_GATE_NO_SETCLR:
+ clrsetbits_le32(base + gate->regs->sta_ofs, bit, 0);
+ break;
+ case CLK_GATE_NO_SETCLR_INV:
+ clrsetbits_le32(base + gate->regs->sta_ofs, bit, bit);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int mtk_gate_disable(void __iomem *base, const struct mtk_gate *gate)
+{
+ u32 bit = BIT(gate->shift);
+
+ switch (gate->flags & CLK_GATE_MASK) {
+ case CLK_GATE_SETCLR:
+ writel(bit, base + gate->regs->set_ofs);
+ break;
+ case CLK_GATE_SETCLR_INV:
+ writel(bit, base + gate->regs->clr_ofs);
+ break;
+ case CLK_GATE_NO_SETCLR:
+ clrsetbits_le32(base + gate->regs->sta_ofs, bit, bit);
+ break;
+ case CLK_GATE_NO_SETCLR_INV:
+ clrsetbits_le32(base + gate->regs->sta_ofs, bit, 0);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/*
* In case the rate change propagation to parent clocks is undesirable,
* this function is recursively called to find the parent to calculate
@@ -143,11 +193,10 @@ static unsigned long __mtk_pll_recalc_rate(const struct
mtk_pll_data *pll,
* for the integer part and the remaining bits (if present) for the
* fractional part. Also they have a 3 bit power-of-two post divider.
*/
-static void mtk_pll_set_rate_regs(struct clk *clk, u32 pcw, int postdiv)
+static void mtk_pll_set_rate_regs(struct mtk_clk_priv *priv, u32 id,
+ u32 pcw, int postdiv)
{
- struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_pll_data *pll;
- int id = mtk_clk_get_id(clk);
u32 val, chg;
pll = >tree->plls[id];
@@ -182,17 +231,16 @@ static void mtk_pll_set_rate_regs(struct clk *clk, u32
pcw, int postdiv)
/**
* mtk_pll_calc_values - calculate good values for a given input frequency.
- * @clk: The clk
+ * @priv: The mtk priv struct
+ * @id:The clk id
* @pcw: The pcw value (output)
* @postdiv: The post divider (output)
* @freq: The desired target frequency
*/
-static void mtk_pll_calc_values(struct clk *clk, u32 *pcw, u32 *postdiv,
- u32 freq)
+static void mtk_pll_calc_values(struct mtk_clk_priv *priv, u32 id,
+ u32 *pcw, u32 *postdiv, u32 freq)
{
- struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_pll_data *pll;
- int id = mtk_clk_get_id(clk);
unsigned long fmin;
u64 _pcw;
int ibits;
@@ -220,11 +268,16 @@ static void mtk_pll_calc_values(struct clk *clk, u32
*pcw, u32 *postdiv,
static ulong mtk_apmixedsys_set_rate(struct clk *clk, ulong rate)
{
+ struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
+ int id = mtk_clk_get_id(clk);
u32 pcw = 0;
u32 postdiv;
- mtk_pll_calc_values(clk, , , rate);
- mtk_pll_set_rate_regs(clk, pcw, postdiv);
+ if (priv->tree->gates && id >= priv->tree->gates_offs)
+ return -EINVAL;
+
+ mtk_pll_calc_values(priv, id, , , rate);
+ mtk_pll_set_rate_regs(priv, id, pcw, postdiv);
return 0;
}
@@ -234,9 +287,16 @@ static ulong mtk_apmixedsys_get_rate(struct clk *clk)
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_pll_data *pll;
int id = mtk_clk_get_id(clk);
+ const struct mtk_gate *gate;
u32 postdiv;
u32 pcw;
+ /* GATE handling */
+ if (priv->tree->gates && id >= priv->tree->gates_offs) {
+ gate = >tree->gates[id - priv->tree->gates_offs];
+ return mtk_clk_find_parent_rate(clk, gate->parent, NULL);
+ }
+
pll = >tree->plls[id];
postdiv = (readl(priv->base + pll->pd_reg) >> pll->pd_shift) &
@@ -255,8 +315,15 @@ static
[PATCH 09/12] clk: mediatek: add support for remapping clock ID
Upstream kernel linux might have a different clock ID order in their
-clk.h header. This is the case of some clock ID for mt7623 that
upstream use the shared header clk-mt7601.h
This header doesn't have a well distincted order and have factor or mux
in the middle of the CLK ID list. This is problematic with the mtk clock
driver that expect everything well organized in block and apply offset
to reference the clk in the different array.
To solve this problem, implement in the mtk_clk_tree an additional
option .id_offs_map, an array where each CLK ID can be remapped to what
the driver expect permitting to reorganize the clock following the
expected logic of fixed, factor, mux and gates.
Each clock function is updated to tranparently handle this by first
converting the clk ID to the remapped one.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 107 ++---
drivers/clk/mediatek/clk-mtk.h | 8 +++
2 files changed, 80 insertions(+), 35 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 8a7a61d6740..096f593fc5c 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -35,6 +35,18 @@
/* shared functions */
+static int mtk_clk_get_id(struct clk *clk)
+{
+ struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
+ int id = clk->id;
+
+ /* Remap the clk ID to the one expected by driver */
+ if (priv->tree->id_offs_map)
+ id = priv->tree->id_offs_map[id];
+
+ return id;
+}
+
/*
* In case the rate change propagation to parent clocks is undesirable,
* this function is recursively called to find the parent to calculate
@@ -134,9 +146,12 @@ static unsigned long __mtk_pll_recalc_rate(const struct
mtk_pll_data *pll,
static void mtk_pll_set_rate_regs(struct clk *clk, u32 pcw, int postdiv)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_pll_data *pll = >tree->plls[clk->id];
+ const struct mtk_pll_data *pll;
+ int id = mtk_clk_get_id(clk);
u32 val, chg;
+ pll = >tree->plls[id];
+
/* set postdiv */
val = readl(priv->base + pll->pd_reg);
val &= ~(POSTDIV_MASK << pll->pd_shift);
@@ -176,12 +191,16 @@ static void mtk_pll_calc_values(struct clk *clk, u32
*pcw, u32 *postdiv,
u32 freq)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_pll_data *pll = >tree->plls[clk->id];
- unsigned long fmin = pll->fmin ? pll->fmin : 1000 * MHZ;
+ const struct mtk_pll_data *pll;
+ int id = mtk_clk_get_id(clk);
+ unsigned long fmin;
u64 _pcw;
int ibits;
u32 val;
+ pll = >tree->plls[id];
+ fmin = pll->fmin ? pll->fmin : 1000 * MHZ;
+
if (freq > pll->fmax)
freq = pll->fmax;
@@ -213,10 +232,13 @@ static ulong mtk_apmixedsys_set_rate(struct clk *clk,
ulong rate)
static ulong mtk_apmixedsys_get_rate(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_pll_data *pll = >tree->plls[clk->id];
+ const struct mtk_pll_data *pll;
+ int id = mtk_clk_get_id(clk);
u32 postdiv;
u32 pcw;
+ pll = >tree->plls[id];
+
postdiv = (readl(priv->base + pll->pd_reg) >> pll->pd_shift) &
POSTDIV_MASK;
postdiv = 1 << postdiv;
@@ -231,9 +253,12 @@ static ulong mtk_apmixedsys_get_rate(struct clk *clk)
static int mtk_apmixedsys_enable(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_pll_data *pll = >tree->plls[clk->id];
+ const struct mtk_pll_data *pll;
+ int id = mtk_clk_get_id(clk);
u32 r;
+ pll = >tree->plls[id];
+
r = readl(priv->base + pll->pwr_reg) | CON0_PWR_ON;
writel(r, priv->base + pll->pwr_reg);
udelay(1);
@@ -260,9 +285,12 @@ static int mtk_apmixedsys_enable(struct clk *clk)
static int mtk_apmixedsys_disable(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_pll_data *pll = >tree->plls[clk->id];
+ const struct mtk_pll_data *pll;
+ int id = mtk_clk_get_id(clk);
u32 r;
+ pll = >tree->plls[id];
+
if (pll->flags & HAVE_RST_BAR) {
r = readl(priv->base + pll->reg + REG_CON0);
r &= ~pll->rst_bar_mask;
@@ -423,38 +451,39 @@ static ulong mtk_infrasys_get_mux_rate(struct clk *clk,
u32 off)
static ulong mtk_topckgen_get_rate(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
+ int id = mtk_clk_get_id(clk);
- if (clk->id < priv->tree->fdivs_offs)
- return priv->tree->fclks[clk->id].rate;
- else if (clk->id < priv->tree->muxes_offs)
- return mtk_topckgen_get_factor_rate(clk, clk->id -
+ if (id < priv->tree->fdivs_offs)
+
[PATCH 10/12] clk: mediatek: implement MUX_FLAGS and MUX_MIXED_FLAGS macro
Some simple MUX might require flags to specify the parent source.
Implement MUX_FLAGS as a variant of the MUX macro that takes custom
flags as last arg.
Also implement MUX_MIXED_FLAGS for PARENT_MIXED implementation and
MUX_MIXED with no additional flags.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index c448ed024aa..c1d9901c10b 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -179,7 +179,20 @@ struct mtk_composite {
#define MUX_GATE(_id, _parents, _reg, _shift, _width, _gate) \
MUX_GATE_FLAGS(_id, _parents, _reg, _shift, _width, _gate, 0)
-#define MUX(_id, _parents, _reg, _shift, _width) { \
+#define MUX_MIXED_FLAGS(_id, _parents, _reg, _shift, _width, _flags) { \
+ .id = _id, \
+ .mux_reg = _reg,\
+ .mux_shift = _shift,\
+ .mux_mask = BIT(_width) - 1,\
+ .gate_shift = -1, \
+ .parent_flags = _parents, \
+ .num_parents = ARRAY_SIZE(_parents),\
+ .flags = CLK_PARENT_MIXED | (_flags), \
+ }
+#define MUX_MIXED(_id, _parents, _reg, _shift, _width) \
+ MUX_MIXED_FLAGS(_id, _parents, _reg, _shift, _width, 0)
+
+#define MUX_FLAGS(_id, _parents, _reg, _shift, _width, _flags) { \
.id = _id, \
.mux_reg = _reg,\
.mux_shift = _shift,\
@@ -187,8 +200,10 @@ struct mtk_composite {
.gate_shift = -1, \
.parent = _parents, \
.num_parents = ARRAY_SIZE(_parents),\
- .flags = 0, \
+ .flags = _flags,\
}
+#define MUX(_id, _parents, _reg, _shift, _width) \
+ MUX_FLAGS(_id, _parents, _reg, _shift, _width, 0)
#define MUX_CLR_SET_UPD_FLAGS(_id, _parents, _mux_ofs, _mux_set_ofs,\
_mux_clr_ofs, _shift, _width, _gate,\
--
2.45.1
[PATCH 08/12] clk: mediatek: provide common clk init function for infrasys
Provide common clk init function for infrasys that defaults to topckgen
driver if clock-parent is not defined. This is the case for upstream
DTSI that doesn't provide this entry.
This is needed for infracfg driver that will make use of the unified
gates + muxes implementation.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 22 ++
drivers/clk/mediatek/clk-mtk.h | 2 ++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 4a057059407..8a7a61d6740 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -707,8 +707,9 @@ const struct clk_ops mtk_clk_gate_ops = {
.get_rate = mtk_clk_gate_get_rate,
};
-int mtk_common_clk_init(struct udevice *dev,
- const struct mtk_clk_tree *tree)
+static int mtk_common_clk_init_drv(struct udevice *dev,
+ const struct mtk_clk_tree *tree,
+ const struct driver *drv)
{
struct mtk_clk_priv *priv = dev_get_priv(dev);
struct udevice *parent;
@@ -720,8 +721,7 @@ int mtk_common_clk_init(struct udevice *dev,
ret = uclass_get_device_by_phandle(UCLASS_CLK, dev, "clock-parent",
);
if (ret || !parent) {
- ret = uclass_get_device_by_driver(UCLASS_CLK,
- DM_DRIVER_GET(mtk_clk_apmixedsys), );
+ ret = uclass_get_device_by_driver(UCLASS_CLK, drv, );
if (ret || !parent)
return -ENOENT;
}
@@ -732,6 +732,20 @@ int mtk_common_clk_init(struct udevice *dev,
return 0;
}
+int mtk_common_clk_init(struct udevice *dev,
+ const struct mtk_clk_tree *tree)
+{
+ return mtk_common_clk_init_drv(dev, tree,
+ DM_DRIVER_GET(mtk_clk_apmixedsys));
+}
+
+int mtk_common_clk_infrasys_init(struct udevice *dev,
+const struct mtk_clk_tree *tree)
+{
+ return mtk_common_clk_init_drv(dev, tree,
+ DM_DRIVER_GET(mtk_clk_topckgen));
+}
+
int mtk_common_clk_gate_init(struct udevice *dev,
const struct mtk_clk_tree *tree,
const struct mtk_gate *gates)
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 4423689803a..e9c8a52ce8f 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -266,6 +266,8 @@ extern const struct clk_ops mtk_clk_gate_ops;
int mtk_common_clk_init(struct udevice *dev,
const struct mtk_clk_tree *tree);
+int mtk_common_clk_infrasys_init(struct udevice *dev,
+const struct mtk_clk_tree *tree);
int mtk_common_clk_gate_init(struct udevice *dev,
const struct mtk_clk_tree *tree,
const struct mtk_gate *gates);
--
2.45.1
[PATCH 07/12] clk: mediatek: add support for gate clock to reference topckgen clock
Add support for gate clock get_rate to reference topckgen clock for
infracfg-ao implementation.
In infracfg-ao implementation topckgen is on second level of parent with
infracfg in the middle.
To correctly detect this, check the driver of the dev parent and use the
second level parent if it's not mtk_clk_topckgen.
Due to all the dependency, parent tree must be filled before a gate is
used, hence is safe to assume it will be there.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 790b92eaf86..4a057059407 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -651,20 +651,33 @@ static int mtk_clk_infrasys_disable(struct clk *clk)
static ulong mtk_clk_gate_get_rate(struct clk *clk)
{
struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
+ struct udevice *parent = priv->parent;
const struct mtk_gate *gate;
if (clk->id < priv->tree->gates_offs)
return -EINVAL;
gate = >gates[clk->id - priv->tree->gates_offs];
+ /*
+* With requesting a TOPCKGEN parent, make sure the dev parent
+* is actually topckgen. This might not be the case for an
+* infracfg-ao implementation where:
+* parent = infracfg
+* parent->parent = topckgen
+*/
+ if (gate->flags & CLK_PARENT_TOPCKGEN &&
+ parent->driver != DM_DRIVER_GET(mtk_clk_topckgen)) {
+ priv = dev_get_priv(parent);
+ parent = priv->parent;
/*
* Assume xtal_rate to be declared if some gates have
* XTAL as parent
*/
- if (gate->flags & CLK_PARENT_XTAL)
+ } else if (gate->flags & CLK_PARENT_XTAL) {
return priv->tree->xtal_rate;
+ }
- return mtk_clk_find_parent_rate(clk, gate->parent, priv->parent);
+ return mtk_clk_find_parent_rate(clk, gate->parent, parent);
}
const struct clk_ops mtk_clk_apmixedsys_ops = {
--
2.45.1
[PATCH 06/12] clk: mediatek: add support for parent mux from different source for topckgen
As done for infracfg, also add support for parent mux from different
source for topckgen. This is needed as upstream linux doesn't use 1/1
factor and use directly the APMIXED clocks.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 42 ++
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 4b8a904aa5e..790b92eaf86 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -338,6 +338,19 @@ static ulong mtk_infrasys_get_factor_rate(struct clk *clk,
u32 off)
return mtk_factor_recalc_rate(fdiv, rate);
}
+static ulong mtk_topckgen_find_parent_rate(struct mtk_clk_priv *priv, struct
clk *clk,
+ const int parent, u16 flags)
+{
+ switch (flags & CLK_PARENT_MASK) {
+ case CLK_PARENT_XTAL:
+ return priv->tree->xtal_rate;
+ case CLK_PARENT_APMIXED:
+ return mtk_clk_find_parent_rate(clk, parent, priv->parent);
+ default:
+ return mtk_clk_find_parent_rate(clk, parent, NULL);
+ }
+}
+
static ulong mtk_topckgen_get_mux_rate(struct clk *clk, u32 off)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
@@ -348,22 +361,23 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
u32 off)
index &= mux->mux_mask << mux->mux_shift;
index = index >> mux->mux_shift;
- if (mux->parent[index] > 0 ||
- (mux->parent[index] == CLK_XTAL &&
-priv->tree->flags & CLK_BYPASS_XTAL)) {
- switch (mux->flags & CLK_PARENT_MASK) {
- case CLK_PARENT_APMIXED:
- return mtk_clk_find_parent_rate(clk, mux->parent[index],
- priv->parent);
- break;
- default:
- return mtk_clk_find_parent_rate(clk, mux->parent[index],
- NULL);
- break;
- }
+ /*
+* Parents can be either from APMIXED or TOPCKGEN,
+* inspect the mtk_parent struct to check the source
+*/
+ if (mux->flags & CLK_PARENT_MIXED) {
+ const struct mtk_parent *parent = >parent_flags[index];
+
+ return mtk_topckgen_find_parent_rate(priv, clk, parent->id,
+parent->flags);
}
- return priv->tree->xtal_rate;
+ if (mux->parent[index] == CLK_XTAL &&
+ !(priv->tree->flags & CLK_BYPASS_XTAL))
+ return priv->tree->xtal_rate;
+
+ return mtk_topckgen_find_parent_rate(priv, clk, mux->parent[index],
+mux->flags);
}
static ulong mtk_find_parent_rate(struct mtk_clk_priv *priv, struct clk *clk,
--
2.45.1
[PATCH 05/12] clk: mediatek: add support for parent mux from different source
There is a current limitation where parents for a mux can be all declared
as they are from a common source. This is not true as there are some MUX
that can have parent from both infracfg or from topckgen.
To handle this, implement a new flag for the mux, CLK_PARENT_MIXED, and
a new entry for the mux parent_flags.
To use this, CLK_PARENT_MIXED must be used and parent_flags will be used
instead of the parent variable.
Entry in parent_flags are just a struct of ID and flags where it will be
defined where that parent comes from with the usage of
CLK_PARENT_INFRASYS or CLK_PARENT_TOPCKGEN.
This permits to have MUX with parents from infracfg or topckgen.
Notice that with CLK_PARENT_MIXED applied the CLK_BYPASS_XTAL is
ignored.
With CLK_PARENT_MIXED declare CLK_PARENT_XTAL for the relevant parent
instead.
Also alias for the CLK_PARENT macro are provided to better clear their
usage. CLK_PARENT_MIXED require these alias that describe the clk type
to be defined in the clk_tree flags to prevent clk ID clash from
different subsystem that may have equal clk ID.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 69 +-
drivers/clk/mediatek/clk-mtk.h | 43 +++--
2 files changed, 91 insertions(+), 21 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 79230fc26e0..4b8a904aa5e 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -54,13 +54,27 @@ static ulong mtk_clk_find_parent_rate(struct clk *clk, int
id,
}
static int mtk_clk_mux_set_parent(void __iomem *base, u32 parent,
+ u32 parent_type,
const struct mtk_composite *mux)
{
u32 val, index = 0;
- while (mux->parent[index] != parent)
- if (++index == mux->num_parents)
- return -EINVAL;
+ if (mux->flags & CLK_PARENT_MIXED) {
+ /*
+* Assume parent_type in clk_tree to be always set with
+* CLK_PARENT_MIXED implementation. If it's not, assume
+* not parent clk ID clash is possible.
+*/
+ while (mux->parent_flags[index].id != parent ||
+ (parent_type && (mux->parent_flags[index].flags &
CLK_PARENT_MASK) !=
+ parent_type))
+ if (++index == mux->num_parents)
+ return -EINVAL;
+ } else {
+ while (mux->parent[index] != parent)
+ if (++index == mux->num_parents)
+ return -EINVAL;
+ }
if (mux->flags & CLK_MUX_SETCLR_UPD) {
val = (mux->mux_mask << mux->mux_shift);
@@ -352,6 +366,19 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
u32 off)
return priv->tree->xtal_rate;
}
+static ulong mtk_find_parent_rate(struct mtk_clk_priv *priv, struct clk *clk,
+ const int parent, u16 flags)
+{
+ switch (flags & CLK_PARENT_MASK) {
+ case CLK_PARENT_XTAL:
+ return priv->tree->xtal_rate;
+ case CLK_PARENT_TOPCKGEN:
+ return mtk_clk_find_parent_rate(clk, parent, priv->parent);
+ default:
+ return mtk_clk_find_parent_rate(clk, parent, NULL);
+ }
+}
+
static ulong mtk_infrasys_get_mux_rate(struct clk *clk, u32 off)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
@@ -362,21 +389,21 @@ static ulong mtk_infrasys_get_mux_rate(struct clk *clk,
u32 off)
index &= mux->mux_mask << mux->mux_shift;
index = index >> mux->mux_shift;
- if (mux->parent[index] > 0 ||
- (mux->parent[index] == CLK_XTAL &&
-priv->tree->flags & CLK_BYPASS_XTAL)) {
- switch (mux->flags & CLK_PARENT_MASK) {
- case CLK_PARENT_TOPCKGEN:
- return mtk_clk_find_parent_rate(clk, mux->parent[index],
- priv->parent);
- break;
- default:
- return mtk_clk_find_parent_rate(clk, mux->parent[index],
- NULL);
- break;
- }
+ /*
+* Parents can be either from TOPCKGEN or INFRACFG,
+* inspect the mtk_parent struct to check the source
+*/
+ if (mux->flags & CLK_PARENT_MIXED) {
+ const struct mtk_parent *parent = >parent_flags[index];
+
+ return mtk_find_parent_rate(priv, clk, parent->id,
parent->flags);
}
- return priv->tree->xtal_rate;
+
+ if (mux->parent[index] == CLK_XTAL &&
+ !(priv->tree->flags & CLK_BYPASS_XTAL))
+ return priv->tree->xtal_rate;
+
+ return mtk_find_parent_rate(priv, clk, mux->parent[index], mux->flags);
}
static ulong
[PATCH 04/12] clk: mediatek: add support for gate ID at offset
Add support to clk_gate ops to reference the clk ID at an offset by
using the just introduced gates_offs value from the unified muxes +
gates implementation.
Gate clock that doesn't have gates_offs set won't be affected as the
offset will simply be 0 and won't be offset of any value.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index c3c50f4c14b..79230fc26e0 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -529,8 +529,12 @@ static int mtk_gate_enable(void __iomem *base, const
struct mtk_gate *gate)
static int mtk_clk_gate_enable(struct clk *clk)
{
struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_gate *gate = >gates[clk->id];
+ const struct mtk_gate *gate;
+
+ if (clk->id < priv->tree->gates_offs)
+ return -EINVAL;
+ gate = >gates[clk->id - priv->tree->gates_offs];
return mtk_gate_enable(priv->base, gate);
}
@@ -575,8 +579,12 @@ static int mtk_gate_disable(void __iomem *base, const
struct mtk_gate *gate)
static int mtk_clk_gate_disable(struct clk *clk)
{
struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_gate *gate = >gates[clk->id];
+ const struct mtk_gate *gate;
+ if (clk->id < priv->tree->gates_offs)
+ return -EINVAL;
+
+ gate = >gates[clk->id - priv->tree->gates_offs];
return mtk_gate_disable(priv->base, gate);
}
@@ -596,8 +604,12 @@ static int mtk_clk_infrasys_disable(struct clk *clk)
static ulong mtk_clk_gate_get_rate(struct clk *clk)
{
struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_gate *gate = >gates[clk->id];
+ const struct mtk_gate *gate;
+
+ if (clk->id < priv->tree->gates_offs)
+ return -EINVAL;
+ gate = >gates[clk->id - priv->tree->gates_offs];
/*
* Assume xtal_rate to be declared if some gates have
* XTAL as parent
--
2.45.1
[PATCH 03/12] clk: mediatek: add support for gates in clk_tree for infrasys
Add support for gates in clk_tree for infrasys ops.
Infracfg clks can have a sum of gates and muxes, and current solution
handle this by duplicating the driver and split clks for mux and clks
for gates. Upstream linux kernel handle this differently and doesn't
have this distinction.
To be closer to the upstream kernel clock definition, implement
additional logic to have gates defined in the clk_tree and implement
variant for the infrasys ops to handle gates defined in the tree.
Similar to how it's done with factor and mux, we introduce gates_offs.
Upstream kernel follow the similar logic with all the ID defined as
FDIVS, MUXES and finally GATES.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mtk.c | 85 --
drivers/clk/mediatek/clk-mtk.h | 2 +
2 files changed, 72 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 555e2220748..c3c50f4c14b 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -404,9 +404,26 @@ static ulong mtk_infrasys_get_rate(struct clk *clk)
} else if (clk->id < priv->tree->muxes_offs) {
rate = mtk_infrasys_get_factor_rate(clk, clk->id -
priv->tree->fdivs_offs);
- } else {
+ /* No gates defined or ID is a MUX */
+ } else if (!priv->tree->gates || clk->id < priv->tree->gates_offs) {
rate = mtk_infrasys_get_mux_rate(clk, clk->id -
priv->tree->muxes_offs);
+ /* Only valid with muxes + gates implementation */
+ } else {
+ struct udevice *parent = NULL;
+ const struct mtk_gate *gate;
+
+ gate = >tree->gates[clk->id - priv->tree->gates_offs];
+ if (gate->flags & CLK_PARENT_TOPCKGEN)
+ parent = priv->parent;
+ /*
+* Assume xtal_rate to be declared if some gates have
+* XTAL as parent
+*/
+ else if (gate->flags & CLK_PARENT_XTAL)
+ return priv->tree->xtal_rate;
+
+ rate = mtk_clk_find_parent_rate(clk, gate->parent, parent);
}
return rate;
@@ -484,24 +501,22 @@ static int mtk_common_clk_set_parent(struct clk *clk,
struct clk *parent)
/* CG functions */
-static int mtk_clk_gate_enable(struct clk *clk)
+static int mtk_gate_enable(void __iomem *base, const struct mtk_gate *gate)
{
- struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
- const struct mtk_gate *gate = >gates[clk->id];
u32 bit = BIT(gate->shift);
switch (gate->flags & CLK_GATE_MASK) {
case CLK_GATE_SETCLR:
- writel(bit, priv->base + gate->regs->clr_ofs);
+ writel(bit, base + gate->regs->clr_ofs);
break;
case CLK_GATE_SETCLR_INV:
- writel(bit, priv->base + gate->regs->set_ofs);
+ writel(bit, base + gate->regs->set_ofs);
break;
case CLK_GATE_NO_SETCLR:
- clrsetbits_le32(priv->base + gate->regs->sta_ofs, bit, 0);
+ clrsetbits_le32(base + gate->regs->sta_ofs, bit, 0);
break;
case CLK_GATE_NO_SETCLR_INV:
- clrsetbits_le32(priv->base + gate->regs->sta_ofs, bit, bit);
+ clrsetbits_le32(base + gate->regs->sta_ofs, bit, bit);
break;
default:
@@ -511,24 +526,43 @@ static int mtk_clk_gate_enable(struct clk *clk)
return 0;
}
-static int mtk_clk_gate_disable(struct clk *clk)
+static int mtk_clk_gate_enable(struct clk *clk)
{
struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
const struct mtk_gate *gate = >gates[clk->id];
+
+ return mtk_gate_enable(priv->base, gate);
+}
+
+static int mtk_clk_infrasys_enable(struct clk *clk)
+{
+ struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
+ const struct mtk_gate *gate;
+
+ /* MUX handling */
+ if (!priv->tree->gates || clk->id < priv->tree->gates_offs)
+ return mtk_clk_mux_enable(clk);
+
+ gate = >tree->gates[clk->id - priv->tree->gates_offs];
+ return mtk_gate_enable(priv->base, gate);
+}
+
+static int mtk_gate_disable(void __iomem *base, const struct mtk_gate *gate)
+{
u32 bit = BIT(gate->shift);
switch (gate->flags & CLK_GATE_MASK) {
case CLK_GATE_SETCLR:
- writel(bit, priv->base + gate->regs->set_ofs);
+ writel(bit, base + gate->regs->set_ofs);
break;
case CLK_GATE_SETCLR_INV:
- writel(bit, priv->base + gate->regs->clr_ofs);
+ writel(bit, base + gate->regs->clr_ofs);
break;
case CLK_GATE_NO_SETCLR:
- clrsetbits_le32(priv->base + gate->regs->sta_ofs, bit, bit);
+ clrsetbits_le32(base +
[PATCH 02/12] clk: mediatek: return XTAL rate for infrasys get_mux_rate
We currently return 0 if XTAL rate is requested in get_mux_rate. This deviates from what is done in get_factor_rate and is totally wrong as it can cause unwanted results (division by 0 crash) For infrasys that makes use of CLK_XTAL, assume xtal_rate to be defined in clk_tree and return the rate when BYPASS_XTAL is not enabled with clk ID 0 index parents. Signed-off-by: Christian Marangi --- drivers/clk/mediatek/clk-mtk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c index e68beccc060..555e2220748 100644 --- a/drivers/clk/mediatek/clk-mtk.c +++ b/drivers/clk/mediatek/clk-mtk.c @@ -376,7 +376,7 @@ static ulong mtk_infrasys_get_mux_rate(struct clk *clk, u32 off) break; } } - return 0; + return priv->tree->xtal_rate; } static ulong mtk_topckgen_get_rate(struct clk *clk) -- 2.45.1
[PATCH 01/12] clk: mediatek: return XTAL rate directly for gates with XTAL parent
There is currently a massive bug that makes any gate clk that have CLK_XTAL as parent to return the wrong clock. Following the code, with CLK_XTAL defined as TOPCKGEN parent, the topckgen get_rate is called. The clk ID (0) is parsed and only in some corner case (scenario where fixed clock are not defined) the correct XTAL rate will be returned as get_factor or get_mux is called (that have correct handling for CLK_XTAL). With fixed clock defined, the rate that will be returned will always be the FIRST ELEMENT of the fixed clock table instead of the hardcoded XTAL rate. To handle this, add additional logic and if the flag is set to PARENT_XTAL for the gate, return the XTAL rate directly. We assume the clk_tree to have xtal_rate defined with clk gates that have XTAL as parents. Signed-off-by: Christian Marangi --- drivers/clk/mediatek/clk-mtk.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c index d2c45be30de..e68beccc060 100644 --- a/drivers/clk/mediatek/clk-mtk.c +++ b/drivers/clk/mediatek/clk-mtk.c @@ -543,6 +543,13 @@ static ulong mtk_clk_gate_get_rate(struct clk *clk) struct mtk_cg_priv *priv = dev_get_priv(clk->dev); const struct mtk_gate *gate = >gates[clk->id]; + /* +* Assume xtal_rate to be declared if some gates have +* XTAL as parent +*/ + if (gate->flags & CLK_PARENT_XTAL) + return priv->tree->xtal_rate; + return mtk_clk_find_parent_rate(clk, gate->parent, priv->parent); } -- 2.45.1
[PATCH 00/12] clk: mediatek: add OPs to support OF_UPSTREAM
This series doesn't currently change anything and it does add all the additional OPs to make support of OF_UPSTREAM. While converting the mt7681/7686/7688/7623/7622 it was notice lots of discrepancy between the downstream dtsi and the upstream one and the clock ID between downstream clock ID and upstream clock ID. Upstream reference clock by names and clock are handled by the CCF (Common Clock Framework). The same can't be used here as we would quickly reach the max space allocated before relocation. The current mediatek clock driver reference all the parents and clocks with offset from the clk ID related to the different tables. Discrepancy between clock ID and the order in the clocks table cause one clock referenced for another or even crash for trying to access a clock at an offset that doesn't exist. To handle this and permit use of OF_UPSTREAM, various measure and changes are done to the mediatek clock driver to support it. This series have all the generic clock changes. Once this is merged, series for each SoC will came that will just change files in their dedicated clock driver. This is to prevent massive patch and to permit to split series, one for each SoC. As said at the start, these changes doesn't cause regression and are just expansion to the current API. Current behaviour is saved in every possible way (aside from the first 2 patch that fixes latent bugs) World compile tested in Azure Pipeline test Christian Marangi (12): clk: mediatek: return XTAL rate directly for gates with XTAL parent clk: mediatek: return XTAL rate for infrasys get_mux_rate clk: mediatek: add support for gates in clk_tree for infrasys clk: mediatek: add support for gate ID at offset clk: mediatek: add support for parent mux from different source clk: mediatek: add support for parent mux from different source for topckgen clk: mediatek: add support for gate clock to reference topckgen clock clk: mediatek: provide common clk init function for infrasys clk: mediatek: add support for remapping clock ID clk: mediatek: implement MUX_FLAGS and MUX_MIXED_FLAGS macro clk: mediatek: add support for GATEs for APMIXED OPs clk: mediatek: add support for APMIXED parent in infra MUX drivers/clk/mediatek/clk-mtk.c | 433 - drivers/clk/mediatek/clk-mtk.h | 74 +- 2 files changed, 392 insertions(+), 115 deletions(-) -- 2.45.1
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 19:39-20240628, Sebin Francis wrote: > > On 28/06/24 18:33, Nishanth Menon wrote: > > On 15:02-20240628, Dhruva Gole wrote: > > > This series includes the binman related changes required to package tIFS > > > Stub to support Low Power Modes on BeaglePlay. > > > Also, based on comments from previous patch [0] documentation has been > > > added to describe small addition in boot flow as well as tispl image > > > format. > > > > > > I am aware that the new boot flow image will need to be updated in > > > other places like am62a, am62p and even other boards that use am62x. > > > However, I would like to keep this series beagleplay TIFSStub specific > > > and so I will be sending a follow up series to update other places > > > seperately if that's ok. [...] > > > > Maybe you can help clarify a bit. I understand from [1] > > that you are betting on timing to keep tifs stub safe. But then, why > > not plug in this firmware blob along with DM itself? that allows DM > > to manage itself the way it wants to and control it's own memory map? > > DM initialization itself takes a few ms, just because TFA is not > > touching any part of DDR does not mean that we can assume system is > > interference free, no? What if DM architecture changes such that PLL > > initialization or some other long pole item is performed prior to > > loading the tifs stub? > > In Linux DT the address space in which FS stub is copied is part of DM > firmware carve-out in DDR, > so if fs stub can get corrupted then DM also can get corrupted. OK - so the memory map we are copying to is already reserved in device tree? See this thread[1] - we are arguing here that the reserved region is meant for bootloader to fill up and keep protected. DT itself from kernel is shared between u-boot and kernel OF_UPSTREAM. Now, the consumer of the binary is DM, the load area is already part of carveout for DM, it sounds like it should have been packaged with DM itself instead of making the packaging problem the problem that everyone image creation system has to solve - not to mention signing etc.. Why not merge this with DM? [1] https://lore.kernel.org/all/59c391a7-c6fe-4b04-891a-c6905ef29...@ti.com/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 28/06/24 18:33, Nishanth Menon wrote: On 15:02-20240628, Dhruva Gole wrote: This series includes the binman related changes required to package tIFS Stub to support Low Power Modes on BeaglePlay. Also, based on comments from previous patch [0] documentation has been added to describe small addition in boot flow as well as tispl image format. I am aware that the new boot flow image will need to be updated in other places like am62a, am62p and even other boards that use am62x. However, I would like to keep this series beagleplay TIFSStub specific and so I will be sending a follow up series to update other places seperately if that's ok. Changelog: * Add new image format for TISPL * Add new changes in boot flow for am62 family of devices. [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-g...@ti.com/ Dhruva Gole (4): arm: dts: k3-am625-beagleplay: Package TIFS Stub doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub doc: beagle: am62x_beagleplay: Add TIFS Stub in image format doc: ti: k3: Add TIFS Stub documentation arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++- doc/board/beagle/am62x_beagleplay.rst| 4 +-- doc/board/ti/img/boot_diagram_am62.svg | 4 +++ doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 +++ doc/board/ti/k3.rst | 5 +++ 5 files changed, 47 insertions(+), 3 deletions(-) create mode 100644 doc/board/ti/img/boot_diagram_am62.svg create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg Maybe you can help clarify a bit. I understand from [1] that you are betting on timing to keep tifs stub safe. But then, why not plug in this firmware blob along with DM itself? that allows DM to manage itself the way it wants to and control it's own memory map? DM initialization itself takes a few ms, just because TFA is not touching any part of DDR does not mean that we can assume system is interference free, no? What if DM architecture changes such that PLL initialization or some other long pole item is performed prior to loading the tifs stub? In Linux DT the address space in which FS stub is copied is part of DM firmware carve-out in DDR, so if fs stub can get corrupted then DM also can get corrupted. Regards Sebin [1] https://lore.kernel.org/u-boot/20240621054337.qqjftv72ofiinlhv@dhruva/
Re: [PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on
On 6/28/24 9:32 AM, Simon Glass wrote: Hi Marek, Hi, [...] @@ -473,8 +483,6 @@ static int regulator_pre_probe(struct udevice *dev) -ENODATA); uc_pdata->max_uA = dev_read_u32_default(dev, "regulator-max-microamp", -ENODATA); - uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on"); - uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on"); uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay", 0); uc_pdata->force_off = dev_read_bool(dev, "regulator-force-boot-off"); -- 2.43.0 This is reading a lot of DT stuff very early, which may be slow. It is also reading from the DT in the bind() step which we sometimes have to do, but try to avoid. Actually, it is reading only the bare minimum very early in bind, the always-on and boot-on, the rest is in pre_probe, i.e. later. Yes, I see that. Also it is inevitable that these properties need to be read before probe(), since they control whether to probe(). Also this seems to happen in SPL and again pre-reloc and again in U-Boot post-reloc? What does, the uclass post_bind ? I mean that this code will be called in SPL (if the regulators are in the DT there), U-Boot pre-reloc and post-reloc, each time turning on the regulators. We need a way to control that, don't we? I would assume that if those regulators are turned on once in the earliest stage , turning them on again in the follow up stage would be a noop ? This is the point of regulator-*-on, to keep the regulators on. Should we have a step in the init sequence where we set up the regulators, by calling regulators_enable_boot_on() ? Let's not do this , the entire point of this series is to get rid of those functions and do the regulator configuration the same way LED subsystem does it -- by probing always-on/boot-on regulators and configuring them correctly on probe. To me regulators_enable_boot_on() and the like was always an inconsistently applied workaround for missing DM_FLAG_PROBE_AFTER_BIND , which is now implemented, so such workarounds can be removed. That patch seemed to slip under the radar, sent and applied on the same day! We really need to add a test for it, BTW. Which patch ? My recollection of DM_FLAG_PROBE_AFTER_BIND was that it took a while to get in. My concern is that this might cause us ordering problems. We perhaps want the regulators to be done first. If drivers are probed which use regulators, then presumably they will enable them. Consider this: - LED driver auto-probes - probes I2C bus 2 - probes LDO1 which is autoset so turns on - LDO1 probes, but is already running - LDO2 probes, which is autoset so turns on So long as it is OK to enable the regulators in any order, then this seems fine. But is it? How do we handle the case where are particular sequence is needed? Did we finally arrive at the point where we need -EPROBE_DEFER alike mechanism ?
Re: [PATCH v2 2/2] usb: musb-new: sunxi: make compatible with UDC/DM gadget model
Hi, On Fri, Jun 28, 2024 at 04:17:27PM +0100, Andre Przywara wrote: > > I do not know if this patch is still a > > necessity; though if John is nudging about it, it probably is. > > Yes apparently he needs it, though I am not entirely sure why. > USB gadget has worked for ages in sunxi, without DM_USB_GADGET support, > that's why I was a bit puzzled why this patch seems so important. > > And secondly I was put off by John's initial reply that it would trigger > many USB errors for him. He later rectified it, but I must have missed > that message. This patch is necessary for gadget to work on the T113 board I have. Without it I get this error during fastboot: Controller uninitialized g_dnl_register: failed!, error: -6 John.
Re: [PATCH 1/3] net: give a different name to rtl8169 interfaces
Hello, On 2024-06-28 08:51, Etienne Dublé wrote: Le 27/06/2024 à 14:27, Quentin Schulz a écrit : On 6/25/24 1:42 PM, Etienne Dublé wrote: Le 25/06/2024 à 12:25, Dragan Simic a écrit : Another option may be to name them "rtl8169@", with "" reflecting the PCI region address (so it is unique and stable). What do you think? I guess that's one way, I'm also wondering how systemd renames those to be unique but stable on the same machine, maybe we could take some inspiration from them for that? Systemd also allows renaming of network interfaces using some rules predefined by the user, so there's also the possibility to rename the interfaces in U-Boot to ethernet0 and ethernet1, using fixed rules that would be based on the PCI region address. OK but the renaming occurs in the rtl8169 driver, that is used by several boards, whereas the PCI region addresses come from the device-tree, so they differ from board to board. I'm of the opinion that we only care about stability for the same product, not for different products with the same Ethernet PHY on different SoCs/products. I agree, but my comment was more about how u-boot code is structured (network interface naming is done in the driver, and the driver code should probably not include board-specific code, so we are quite limited). In theory we could just name the interfaces ethernet0, ethernet1, etc., by using the PCI region address as the sort key, and maybe this is what Dragan was suggesting. But in practice when driver->bind() is called we don't know if more interfaces will be discovered next; and renaming the 1st interface when the 2nd one is discovered with a lower address is probably not the kind of code u-boot code experts would like... Good point, we don't know how many Ethernet interfaces will be there in total. I'll see to go through the source code, to see what options are available for stable interface naming.
Re: [PATCH v4 00/14] Introduce the lwIP network stack
On Fri, Jun 28, 2024 at 2:50 AM Jerome Forissier wrote: > > Hi Tim, > > On 6/26/24 18:00, Tim Harvey wrote: > > On Tue, Jun 25, 2024 at 1:02 AM Jerome Forissier > > wrote: > >> > >> On 6/25/24 00:28, Tim Harvey wrote: > >>> On Sat, Jun 22, 2024 at 1:09 AM Maxim Uvarov wrote: > > пт, 21 июн. 2024 г. в 21:42, Fabio Estevam : > > > > Hi Tim and Jerome, > > > > On Fri, Jun 21, 2024 at 1:08 PM Tim Harvey > > wrote: > > > >> I tried your to-upstream/v5-wip branch > >> (042bea36eb9731079a3d7afffe3774d79e06ac5d) and it behaves the same. Do > >> you have something else to try/test? > > > > Yes, when I tested older versions from Maxim I could never get lwIP to > > work with i.MX. > > > > Jerome, > > > > Please try to run the lwIP series on any i.MX board, if possible. > > > > Thanks > > Packet not for us means that incoming packet DST MAC does not match to > the MAC address inside lwip. I.e. to MAC address set into lwip when > lwip_init was done. Original U-Boot network stack does not compare > MACs but lwip does. There is something specific on this board, in > general lwip with debug should print out > MAC used during initialization. This MAC should match to the MAC from > the incoming packet. > > >>> > >>> It seems 'packet not for us' can mean a lot of things. > >> > >> Yeah :-/ in this case I believe the traces are caused by unrelated traffic > >> (UDP port 138 is used by NetBIOS). > >> > >> > >>> I added a bit of debugging around 'DHCP packet accepted' and found I'm > >>> not receiving any packets from my DHCP server. So I connected directly > >>> to another board (isolated network) where I ran my own server and > >>> tcpdump and I don't see packets coming from lwip: > >> > >> Ha! That's interesting. > >> > >>> without lwip my server shows: > >>> # tcpdump -i eth1 > >>> tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot > >>> length 262144 bytes > >>> tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot > >>> length 262144 bytes > >>> 22:18:01.043992 IP (tos 0x0, ttl 255, id 23, offset 0, flags [DF], > >>> proto UDP (17), length 328) > >>> 22:18:01.044391 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], > >>> proto UDP (17), length 328) > >>> 22:18:01.044454 IP (tos 0x0, ttl 255, id 24, offset 0, flags [DF], > >>> proto UDP (17), length 328) > >>> 22:18:01.044752 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], > >>> proto UDP (17), length 328) > >>> > >>> # tcpdump -i eth1 > >>> tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot > >>> length 262144 bytes > >>> 22:22:41.602178 [|llc] > >>> 22:22:41.709978 [|llc] > >>> 22:22:41.867947 [|llc] > >>> 22:22:42.105202 [|llc] > >>> 22:22:42.502091 [|llc] > >>> 22:22:43.219079 [|llc] > >>> 22:22:44.497979 [|llc] > >>> 22:22:45.776884 [|llc] > >>> 22:22:47.054773 [|llc] > >>> 22:22:48.333667 [|llc] > >>> 22:22:49.611559 [|llc] > >>> 22:22:50.890469 [|llc] > >>> > >>> What actual hardware has this been tested with? I think Tom mentioned > >>> he tested with an rpi of some sort. > >> > >> Yes, I believe he tested on RPi 3B and me too. Ilias has tested on NVIDIA > >> Jetson Nano. > >> > >>> I don't know what the meaning of the llc msg is above but you can see > >>> there is no DHCP request. > >> > >> Some more tracing is needed. Can you try enabling all traces in > >> lib/lwip/u-boot/lwipopts.h? i.e., replace all LWIP_DBG_OFF with > >> LWIP_DBG_ON in the #if defined(CONFIG_LWIP_DEBUG) section. And of course > >> enabled CONFIG_LWIP_DEBUG. > > > > Here's what I see with all those enabled on an imx8mm-venice-gw73xx-0x: > > Net: eth0: ethernet@30be [PRIME] > > GSC : boot watchdog disabled > > Thermal protection:enabled at 96C > > Hit any key to stop autoboot: 0 > > u-boot=> dhcp || echo fail > > netif: added interface et IP addr 0.0.0.0 netmask 0.0.0.0 gw 0.0.0.0 > > netif: setting default interface et > > dhcp_start(netif=fdf23bb0) et0 > > dhcp_start(): mallocing new DHCP client > > dhcp_start(): allocated dhcp > > dhcp_start(): starting DHCP configuration > > udp_bind(ipaddr = 0.0.0.0, port = 68) > > udp_bind: bound to 0.0.0.0, port 68) > > udp_connect: connected to 0.0.0.0, port 67) > > dhcp_discover() > > pbuf_alloc(length=308) > > pbuf_alloc(length=308) == fdf23d10 > > transaction id xid(42021) > > dhcp_discover: making request > > dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, > > LWIP_IANA_PORT_DHCP_SERVER) > > pbuf_add_header: old fdf23d5e new fdf23d56 (8) > > udp_send: added header in given pbuf fdf23d10 > > udp_send: sending datagram of length 316 > > udp_send: UDP packet length 316 > > inet_chksum_pseudo(): checksumming pbuf fdf23d10 (has next > > ) > > inet_chksum_pseudo(): pbuf chain lwip_chksum()=807 > > udp_send: UDP checksum 0xf7f8 > > udp_send: ip_output_if (0x11,) > >
Re: [PATCH 2/3] soc: qcom: rpmh and cmd-db drivers
Hi Caleb,
On 17/06/2024 10:32, Caleb Connolly wrote:
Introduce two Qualcomm SoC drivers, the RPMh and cmd-db. RPMh is a the
name for the second generation Resource Power Management hub on Qualcomm
SoCs. Most core regulators have to be controlled via this hub.
The cmd-db is a region of memory which contains offsets and data about
how to communicate with the RPMh.
Signed-off-by: Caleb Connolly
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/qcom/Kconfig | 25 ++
drivers/soc/qcom/Makefile| 4 +
drivers/soc/qcom/cmd-db.c| 246
drivers/soc/qcom/rpmh-internal.h | 141 +
drivers/soc/qcom/rpmh-rsc.c | 619 +++
drivers/soc/qcom/rpmh.c | 110 +++
include/soc/qcom/cmd-db.h| 42 +++
include/soc/qcom/rpmh.h | 29 ++
include/soc/qcom/tcs.h | 78 +
11 files changed, 1296 insertions(+)
+
+static int cmd_db_get_header(const char *id, const struct entry_header **eh,
+const struct rsc_hdr **rh)
+{
+ const struct rsc_hdr *rsc_hdr;
+ const struct entry_header *ent;
+ int i, j;
+ u8 query[sizeof(ent->id)] __nonstring;
+
+ /*
+* Pad out query string to same length as in DB. NOTE: the output
+* query string is not necessarily '\0' terminated if it bumps up
+* against the max size. That's OK and expected.
+*/
+ strncpy(query, id, sizeof(query));
+
+ for (i = 0; i < MAX_SLV_ID; i++) {
+ rsc_hdr = _db_header->header[i];
+ if (!rsc_hdr->slv_id)
+ break;
+
+ ent = rsc_to_entry_header(rsc_hdr);
+ for (j = 0; j < le16_to_cpu(rsc_hdr->cnt); j++, ent++) {
+ if (memcmp(ent->id, query, sizeof(ent->id)) == 0) {
I had to change to:
if (strncmp(ent->id, query, sizeof(ent->id)) == 0) {
otherwise I get:
Failed to read RPMh address for bobb1
...
on SM8550 and SM8650.
Linux uses memcmp, but it pads the buffer with strtomem_pad(), strncpy doesn't
seem to do the padding.
Neil
+ if (eh)
+ *eh = ent;
+ if (rh)
+ *rh = rsc_hdr;
+ return 0;
+ }
+ }
+ }
+
+ return -ENODEV;
+}
Re: [PATCH v2 2/2] usb: musb-new: sunxi: make compatible with UDC/DM gadget model
On Thu, 27 Jun 2024 17:25:57 -0600
Sam Edwards wrote:
Hi Sam,
thanks for coming back so quickly!
> On 6/27/24 09:06, Andre Przywara wrote:
> > On Thu, 8 Jun 2023 13:56:31 -0600
> > Sam Edwards wrote:
> >
> > Hi,
> >
> > John asked me have a look at this.
>
> Hi Andre, it's good to hear from you again,
>
> I'd first like to make sure you're aware that the date on this patch is
> June *2023,* not June 2024. It's possible things have changed
> substantially in the past year.
Not in the Allwinner MUSB driver, but indeed the gadget support in U-Boot
has changed since then.
> I do not know if this patch is still a
> necessity; though if John is nudging about it, it probably is.
Yes apparently he needs it, though I am not entirely sure why.
USB gadget has worked for ages in sunxi, without DM_USB_GADGET support,
that's why I was a bit puzzled why this patch seems so important.
And secondly I was put off by John's initial reply that it would trigger
many USB errors for him. He later rectified it, but I must have missed
that message.
> >> Since many sunxi boards do not implement a `board_usb_init`, it's
> >
> > I am confused, what has this have to do with gadget support? *No* sunxi
> > board build provides board_usb_init(), but apparently this works fine for
> > now.
> > I am all for this converting to DM part, but the rationale seems a bit
> > off.
>
> For context, board_usb_init() is (was?) the non-DM entry point for USB
> functionality;
I think board_usb_init() comes from the old days, to provide hooks in case
certain boards need something special to enable USB, like an extra
regulator, power domain or clock to toggle. These days this should all be
covered by DT properties, so we should not (and do not!) need it.
And there is an empty fallback implementation in common/usb.c.
> it is (was?) *the* implementation of
> usb_gadget_initialize() when !DM_USB_GADGET.
Mmh, was that so? None of them seemed to call usb_gadget_initialize(),
though? I checked older releases, but usb_gadget_initialize() seemed to
have always been called by the respective gadget code (fastboot, ums,
ethernet)?
> > Also can you give some reason for this patch? What does this fix or
> > improve? "it's better" is a bit thin, "complying with DM" would already be
> > sufficient, but maybe there is more?
>
> Eh, yeah, "better" is something of a question-begging word isn't it? :)
>
> The main point is to be compatible with DM's view of UDC, which as you
> said is a worthy goal in itself. It's "better" because this allows using
> DM's all-purpose implementation of usb_gadget_initialize(), which is
> (was?) necessary for those targets lacking board_usb_init().
That's what triggered my confusion: there is no sunxi board as such that
implements board_usb_init(), and with our USB PHY code being DT driven, we
should not need it anyway.
There are empty fallback implementations in common/usb.c and
drivers/usb/gadget/g_dnl.c, and we pick up one of them, given the right
Kconfig symbols defined.
I just tried it: enabling the "ums" command, and it worked:
$ make orangepi_zero3_defconfig
$ scripts/config --enable CONFIG_CMD_USB_MASS_STORAGE
$ make olddefconfig
$ make
then, on the U-Boot prompt:
=> ums 0 mmc 0
and the SD card block device popped up on my host.
(That the ums command is useful enough to be enabled by default is a
separate story).
Gadget Ethernet and fastboot are even enabled by default, so whenever you
have a defconfig with CONFIG_USB_MUSB_GADGET=y, you should get this
functionality.
So can anyone tell why this patch is needed so desperately?
> >> better if we just make the sunxi USB driver compatible with the
> >> DM gadget model, as many other musb-new variants already are.
> >>
> >> This change has been verified working on a T113s.
> >>
> >> Signed-off-by: Sam Edwards
> >> ---
> >> drivers/usb/musb-new/sunxi.c | 50 +++-
> >> 1 file changed, 32 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> >> index 510b254f7d..6658cd995d 100644
> >> --- a/drivers/usb/musb-new/sunxi.c
> >> +++ b/drivers/usb/musb-new/sunxi.c
> >> @@ -444,6 +444,16 @@ static struct musb_hdrc_config musb_config_h3 = {
> >>.ram_bits = SUNXI_MUSB_RAM_BITS,
> >> };
> >>
> >> +#if CONFIG_IS_ENABLED(DM_USB_GADGET)
> >
> > Please no more #ifdef's. Is there any reason to *not* force
> > DM_USB_GADGET now, for all sunxi boards, in Kconfig?
> > Either by "select"ing it in the USB Kconfig, or in arch/arm/Kconfig, like
> > other platforms do.
> > Then you don't need to care about the !DM_USB_GADGET definition of this
> > function and can drop the #ifdef.
>
> I wouldn't be the one to ask. I can't think of any such reason myself.
> But to me it sounds like since *no sunxi board provides
> board_usb_init()* the only way USB gadgets *could* work is with
> DM_USB_GADGET? That'd be reason enough to force it.
See above.
So I
Re: [PATCH v4 0/2] k3-am625-beagleplay: Add symlinks for tiboot3 and tispl
On 10:19-20240618, Dhruva Gole wrote: > Add symlinks for both tiboot3.bin and tispl.bin because a user has to > anyway rename these files to get the platform to boot up. > Also update the documentation to reflect above change. > > Changes in v4: > * Add the docs patch. > > Cc: Nishant Menon > Cc: Robert Nelson > > Dhruva Gole (2): > arm: dts: k3-am625-beagleplay: Add symlinks for tiboot3 and tispl > doc: beagle: am62x_beagleplay: Rename the boot bins > > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 1 + > arch/arm/dts/k3-am625-r5-beagleplay.dts | 1 + > doc/board/beagle/am62x_beagleplay.rst| 7 +++ > 3 files changed, 5 insertions(+), 4 deletions(-) Robert/Jason: Can you folks confirm that we will ONLY have GP version of BeaglePlay for even a new update of the board? If that is confirmed, then this series is good. Any thoughts? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/3] Fix findfdt for j722s and am62p
On 13:53-20240628, Manorit Chawdhry wrote: > findfdt wasn't being populated in these boards, add the code in evm.c > for the same. why not just drop findfdt? I am ok with #2,3 more or less, but keeping findfdt alive is just a bad direction when we are moving to stdboot flow. > > Signed-off-by: Manorit Chawdhry > --- > Manorit Chawdhry (3): > include: env: ti: mmc: Change name_fdt usage to fdtfile > board: ti: am62p|j722s: Add ti_set_fdt_env for findfdt > configs: am62p|j722s_a53: Add CONFIG_BOARD_LATE_INIT > > board/ti/am62px/evm.c| 9 + > board/ti/j722s/evm.c | 9 + > configs/am62px_evm_a53_defconfig | 1 + > configs/j722s_evm_a53_defconfig | 1 + > include/env/ti/mmc.env | 2 +- > 5 files changed, 21 insertions(+), 1 deletion(-) > --- > base-commit: 899b088674b6905710ce546f0a8848662904852a > change-id: 20240628-b4-upstream-streamline-platform-f0d7453637b2 > > Best regards, > -- > Manorit Chawdhry > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 1/3] include: env: ti: mmc: Change name_fdt usage to fdtfile
On 13:53-20240628, Manorit Chawdhry wrote:
> name_fdt is kept for backward compatibility but it depends on EEPROM
> detection logic and some of the platforms like J7AHP/AM69 don't have
> that anymore which causes boot failure.
>
> Replacing name_fdt usage to fdtfile as fdtfile is populated based on
> CONFIG_DEFAULT_DEVICE_TREE.
>
> Signed-off-by: Manorit Chawdhry
> ---
> include/env/ti/mmc.env | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/env/ti/mmc.env b/include/env/ti/mmc.env
> index 0256a2d2aaca..037a09010ce4 100644
> --- a/include/env/ti/mmc.env
> +++ b/include/env/ti/mmc.env
> @@ -16,7 +16,7 @@ importbootenv=echo Importing environment from mmc${mmcdev}
> ...;
> loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
> loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
> loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
> -get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${name_fdt}
> +get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
Did you check the other users of mmc.env file? How about legacy boards like k2g?
> envboot=if mmc dev ${mmcdev}; then
> if mmc rescan; then
> echo SD/MMC found on device ${mmcdev};
>
> --
> 2.45.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 15:02-20240628, Dhruva Gole wrote: > This series includes the binman related changes required to package tIFS > Stub to support Low Power Modes on BeaglePlay. > Also, based on comments from previous patch [0] documentation has been > added to describe small addition in boot flow as well as tispl image > format. > > I am aware that the new boot flow image will need to be updated in > other places like am62a, am62p and even other boards that use am62x. > However, I would like to keep this series beagleplay TIFSStub specific > and so I will be sending a follow up series to update other places > seperately if that's ok. > > Changelog: > * Add new image format for TISPL > * Add new changes in boot flow for am62 family of devices. > > [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-g...@ti.com/ > > Dhruva Gole (4): > arm: dts: k3-am625-beagleplay: Package TIFS Stub > doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub > doc: beagle: am62x_beagleplay: Add TIFS Stub in image format > doc: ti: k3: Add TIFS Stub documentation > > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++- > doc/board/beagle/am62x_beagleplay.rst| 4 +-- > doc/board/ti/img/boot_diagram_am62.svg | 4 +++ > doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 +++ > doc/board/ti/k3.rst | 5 +++ > 5 files changed, 47 insertions(+), 3 deletions(-) > create mode 100644 doc/board/ti/img/boot_diagram_am62.svg > create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg Maybe you can help clarify a bit. I understand from [1] that you are betting on timing to keep tifs stub safe. But then, why not plug in this firmware blob along with DM itself? that allows DM to manage itself the way it wants to and control it's own memory map? DM initialization itself takes a few ms, just because TFA is not touching any part of DDR does not mean that we can assume system is interference free, no? What if DM architecture changes such that PLL initialization or some other long pole item is performed prior to loading the tifs stub? [1] https://lore.kernel.org/u-boot/20240621054337.qqjftv72ofiinlhv@dhruva/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on
Hi Simon, This is reading a lot of DT stuff very early, which may be slow. It is also reading from the DT in the bind() step which we sometimes have to do, but try to avoid. Could we set up the livetree pre-bind? What about MMU? On armv8 at least this would have a huge impact on performance. I've done some measurements and there is at least 1 order of magnitude difference between parsing FDT with no caches vs parsing livetree with, it's huge. That seems like a great idea to me, in general. The fact that SPL sets up the MMU on armv8 makes it more practical. Well, on qcom we don't use SPL (yet?), we did have a cyclical dependency since we rely on DTB for the memory layout, although I have some patches to do all the memory parsing in board_fdt_blob_setup() since that's needed for multi-dtb FIT. So I guess we could enable caches at the same time. Yes...it seems that enabling cache in SPL has become common on armv8. As to the memory layout, I'm not sure what is happening there, but it seems that the DT does not describe it in general (at least not until U-Boot adds the nodes). I suppose this depends on the platform. On Qualcomm we use DT as the source of truth as it lets us support many platforms (with totally different memory maps) with a single U-Boot binary, at least for development this is quite nice. But for this series I believe we are going to have to define what happens in what phase. We have power_init_board() which is the old way of doing this...but perhaps we could use that as a way to start up regulators which are needed. As to my question about whether this happens in SPL / pre-reloc / proper, I forgot that we have the bootph tags for that, so it should be fine. The main issue is that in U-Boot proper we will re-init the regulators even though that has already been done. Probably that can be handled by Kconfig or a flag in SPL handoff. Ensuring that it isn't done multiple times sounds like the right approach to me. OK...I wonder how we can solve this. Needs some though. Also this seems to happen in SPL and again pre-reloc and again in U-Boot post-reloc? Should we have a step in the init sequence where we set up the regulators, by calling regulators_enable_boot_on() ? Regards, Simon -- // Caleb (they/them)
Re: [PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on
Hi Marek,
On Thu, 27 Jun 2024 at 17:05, Marek Vasut wrote:
>
> On 6/27/24 10:37 AM, Simon Glass wrote:
> > Hi Marek,
>
> Hi,
>
> [...]
>
> >> ---
> >> drivers/power/regulator/regulator-uclass.c | 22 +++---
> >> 1 file changed, 15 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/power/regulator/regulator-uclass.c
> >> b/drivers/power/regulator/regulator-uclass.c
> >> index 66fd531da04..ccc4ef33d83 100644
> >> --- a/drivers/power/regulator/regulator-uclass.c
> >> +++ b/drivers/power/regulator/regulator-uclass.c
> >> @@ -433,6 +433,8 @@ static int regulator_post_bind(struct udevice *dev)
> >> const char *property = "regulator-name";
> >>
> >> uc_pdata = dev_get_uclass_plat(dev);
> >> + uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
> >> + uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
> >>
> >> /* Regulator's mandatory constraint */
> >> uc_pdata->name = dev_read_string(dev, property);
> >> @@ -444,13 +446,21 @@ static int regulator_post_bind(struct udevice *dev)
> >> return -EINVAL;
> >> }
> >>
> >> - if (regulator_name_is_unique(dev, uc_pdata->name))
> >> - return 0;
> >> + if (!regulator_name_is_unique(dev, uc_pdata->name)) {
> >> + debug("'%s' of dev: '%s', has nonunique value: '%s\n",
> >> + property, dev->name, uc_pdata->name);
> >> + return -EINVAL;
> >> + }
> >>
> >> - debug("'%s' of dev: '%s', has nonunique value: '%s\n",
> >> - property, dev->name, uc_pdata->name);
> >> + /*
> >> +* In case the regulator has regulator-always-on or
> >> +* regulator-boot-on DT property, trigger probe() to
> >> +* configure its default state during startup.
> >> +*/
> >> + if (uc_pdata->always_on && uc_pdata->boot_on)
> >> + dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
> >>
> >> - return -EINVAL;
> >> + return 0;
> >> }
> >>
> >> static int regulator_pre_probe(struct udevice *dev)
> >> @@ -473,8 +483,6 @@ static int regulator_pre_probe(struct udevice *dev)
> >> -ENODATA);
> >> uc_pdata->max_uA = dev_read_u32_default(dev,
> >> "regulator-max-microamp",
> >> -ENODATA);
> >> - uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
> >> - uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
> >> uc_pdata->ramp_delay = dev_read_u32_default(dev,
> >> "regulator-ramp-delay",
> >> 0);
> >> uc_pdata->force_off = dev_read_bool(dev,
> >> "regulator-force-boot-off");
> >> --
> >> 2.43.0
> >>
> >
> > This is reading a lot of DT stuff very early, which may be slow. It is
> > also reading from the DT in the bind() step which we sometimes have to
> > do, but try to avoid.
>
> Actually, it is reading only the bare minimum very early in bind, the
> always-on and boot-on, the rest is in pre_probe, i.e. later.
Yes, I see that. Also it is inevitable that these properties need to
be read before probe(), since they control whether to probe().
>
> > Also this seems to happen in SPL and again pre-reloc and again in
> > U-Boot post-reloc?
>
> What does, the uclass post_bind ?
I mean that this code will be called in SPL (if the regulators are in
the DT there), U-Boot pre-reloc and post-reloc, each time turning on
the regulators. We need a way to control that, don't we?
>
> > Should we have a step in the init sequence where we set up the
> > regulators, by calling regulators_enable_boot_on() ?
>
> Let's not do this , the entire point of this series is to get rid of
> those functions and do the regulator configuration the same way LED
> subsystem does it -- by probing always-on/boot-on regulators and
> configuring them correctly on probe.
>
> To me regulators_enable_boot_on() and the like was always an
> inconsistently applied workaround for missing DM_FLAG_PROBE_AFTER_BIND ,
> which is now implemented, so such workarounds can be removed.
That patch seemed to slip under the radar, sent and applied on the
same day! We really need to add a test for it, BTW.
My concern is that this might cause us ordering problems. We perhaps
want the regulators to be done first. If drivers are probed which use
regulators, then presumably they will enable them. Consider this:
- LED driver auto-probes
- probes I2C bus 2
- probes LDO1 which is autoset so turns on
- LDO1 probes, but is already running
- LDO2 probes, which is autoset so turns on
So long as it is OK to enable the regulators in any order, then this
seems fine. But is it? How do we handle the case where are particular
sequence is needed?
Regards,
Simon
[PATCH] net: ftgmac100: Modify desc. size to cache line
The TX/RX descriptor size is 16 byte.
When the cache line size is larger than 16 bytes, descriptors
flushed to RAM will flush more than one descriptor.
It is possible that it may mistakenly flush to other descriptor
that has been updated by MAC in RAM.
To avoid this issue, align the descriptors to cache line size.
Only one desc will be flushed or invalidated at a time.
Signed-off-by: Jacky Chou
---
drivers/net/ftgmac100.c | 13 -
drivers/net/ftgmac100.h | 5 +++--
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 256a519020..9fb8c12838 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -322,7 +322,7 @@ static int ftgmac100_start(struct udevice *dev)
struct ftgmac100_data *priv = dev_get_priv(dev);
struct ftgmac100 *ftgmac100 = priv->iobase;
struct phy_device *phydev = priv->phydev;
- unsigned int maccr;
+ unsigned int maccr, dblac, desc_size;
ulong start, end;
int ret;
int i;
@@ -367,6 +367,17 @@ static int ftgmac100_start(struct udevice *dev)
/* receive ring */
writel((u32)priv->rxdes, >rxr_badr);
+ /* Configure TX/RX decsriptor size
+* This size is calculated based on cache line.
+*/
+ desc_size = ARCH_DMA_MINALIGN / FTGMAC100_DESC_UNIT;
+ /* The descriptor size is at least 2 descriptor units. */
+ if (desc_size < 2)
+ desc_size = 2;
+ dblac = readl(>dblac) & ~GENMASK(19, 12);
+ dblac |= FTGMAC100_DBLAC_RXDES_SIZE(desc_size) |
FTGMAC100_DBLAC_TXDES_SIZE(desc_size);
+ writel(dblac, >dblac);
+
/* poll receive descriptor automatically */
writel(FTGMAC100_APTC_RXPOLL_CNT(1), >aptc);
diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
index f7874ae68b..37c029aded 100644
--- a/drivers/net/ftgmac100.h
+++ b/drivers/net/ftgmac100.h
@@ -111,6 +111,7 @@ struct ftgmac100 {
#define FTGMAC100_DBLAC_TXBURST_SIZE(x)(((x) & 0x3) << 10)
#define FTGMAC100_DBLAC_RXDES_SIZE(x) (((x) & 0xf) << 12)
#define FTGMAC100_DBLAC_TXDES_SIZE(x) (((x) & 0xf) << 16)
+#define FTGMAC100_DESC_UNIT8
#define FTGMAC100_DBLAC_IFG_CNT(x) (((x) & 0x7) << 20)
#define FTGMAC100_DBLAC_IFG_INCBIT(23)
@@ -183,7 +184,7 @@ struct ftgmac100_txdes {
unsigned inttxdes1;
unsigned inttxdes2; /* not used by HW */
unsigned inttxdes3; /* TXBUF_BADR */
-} __aligned(16);
+} __aligned(ARCH_DMA_MINALIGN);
#define FTGMAC100_TXDES0_TXBUF_SIZE(x) ((x) & 0x3fff)
#define FTGMAC100_TXDES0_EDOTR BIT(15)
@@ -209,7 +210,7 @@ struct ftgmac100_rxdes {
unsigned intrxdes1;
unsigned intrxdes2; /* not used by HW */
unsigned intrxdes3; /* RXBUF_BADR */
-} __aligned(16);
+} __aligned(ARCH_DMA_MINALIGN);
#define FTGMAC100_RXDES0_VDBC(x) ((x) & 0x3fff)
#define FTGMAC100_RXDES0_EDORR BIT(15)
--
2.25.1
Re: [PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on
Hi Caleb,
On Fri, 28 Jun 2024 at 01:09, Caleb Connolly wrote:
>
>
>
> On 27/06/2024 11:26, Simon Glass wrote:
> > Hi Caleb,
> >
> > On Thu, 27 Jun 2024 at 09:48, Caleb Connolly
> > wrote:
> >>
> >>
> >>
> >> On 27/06/2024 10:37, Simon Glass wrote:
> >>> Hi Marek,
> >>>
> >>> On Thu, 27 Jun 2024 at 00:57, Marek Vasut wrote:
>
> In case a regulator DT node contains regulator-always-on or
> regulator-boot-on
> property, make sure the regulator gets correctly configured by U-Boot on
> start
> up. Unconditionally probe such regulator drivers. This is a preparatory
> patch
> for introduction of .regulator_post_probe() which would trigger the
> regulator
> configuration.
>
> Parsing of regulator-always-on and regulator-boot-on DT property has been
> moved to regulator_post_bind() as the information is required early, the
> rest of the DT parsing has been kept in regulator_pre_probe() to avoid
> slowing down the boot process.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Ben Wolsieffer
> Cc: Caleb Connolly
> Cc: Chris Morgan
> Cc: Dragan Simic
> Cc: Eugen Hristev
> Cc: Francesco Dolcini
> Cc: Heinrich Schuchardt
> Cc: Jaehoon Chung
> Cc: Jagan Teki
> Cc: Jonas Karlman
> Cc: Kever Yang
> Cc: Kostya Porotchkin
> Cc: Matteo Lisi
> Cc: Mattijs Korpershoek
> Cc: Max Krummenacher
> Cc: Neil Armstrong
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Philipp Tomsich
> Cc: Quentin Schulz
> Cc: Sam Day
> Cc: Simon Glass
> Cc: Sumit Garg
> Cc: Svyatoslav Ryhel
> Cc: Thierry Reding
> Cc: Tom Rini
> Cc: Volodymyr Babchuk
> Cc: u-boot-amlo...@groups.io
> Cc: u-boot-q...@groups.io
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> drivers/power/regulator/regulator-uclass.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/power/regulator/regulator-uclass.c
> b/drivers/power/regulator/regulator-uclass.c
> index 66fd531da04..ccc4ef33d83 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@ -433,6 +433,8 @@ static int regulator_post_bind(struct udevice *dev)
> const char *property = "regulator-name";
>
> uc_pdata = dev_get_uclass_plat(dev);
> + uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
> + uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
>
> /* Regulator's mandatory constraint */
> uc_pdata->name = dev_read_string(dev, property);
> @@ -444,13 +446,21 @@ static int regulator_post_bind(struct udevice *dev)
> return -EINVAL;
> }
>
> - if (regulator_name_is_unique(dev, uc_pdata->name))
> - return 0;
> + if (!regulator_name_is_unique(dev, uc_pdata->name)) {
> + debug("'%s' of dev: '%s', has nonunique value: '%s\n",
> + property, dev->name, uc_pdata->name);
> + return -EINVAL;
> + }
>
> - debug("'%s' of dev: '%s', has nonunique value: '%s\n",
> - property, dev->name, uc_pdata->name);
> + /*
> +* In case the regulator has regulator-always-on or
> +* regulator-boot-on DT property, trigger probe() to
> +* configure its default state during startup.
> +*/
> + if (uc_pdata->always_on && uc_pdata->boot_on)
> + dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>
> - return -EINVAL;
> + return 0;
> }
>
> static int regulator_pre_probe(struct udevice *dev)
> @@ -473,8 +483,6 @@ static int regulator_pre_probe(struct udevice *dev)
> -ENODATA);
> uc_pdata->max_uA = dev_read_u32_default(dev,
> "regulator-max-microamp",
> -ENODATA);
> - uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
> - uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
> uc_pdata->ramp_delay = dev_read_u32_default(dev,
> "regulator-ramp-delay",
> 0);
> uc_pdata->force_off = dev_read_bool(dev,
> "regulator-force-boot-off");
> --
> 2.43.0
>
> >>>
> >>> This is reading a lot of DT stuff very early, which may be slow. It is
> >>> also reading from the DT in the bind() step which we sometimes have to
> >>> do, but try to
[PATCH] net: ftgmac100: Fixed NC-SI PHY device cannot get
The NC-SI interface does not need the MDIO bus and the NC-SI PHY device cannot get from dm_eth_phy_connect. Therefore, use phy_connect directly here. Signed-off-by: Jacky Chou --- drivers/net/ftgmac100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c index 9b536fd5ab..256a519020 100644 --- a/drivers/net/ftgmac100.c +++ b/drivers/net/ftgmac100.c @@ -223,7 +223,7 @@ static int ftgmac100_phy_init(struct udevice *dev) struct phy_device *phydev; int ret; - if (IS_ENABLED(CONFIG_DM_MDIO)) + if (IS_ENABLED(CONFIG_DM_MDIO) && priv->phy_mode != PHY_INTERFACE_MODE_NCSI) phydev = dm_eth_phy_connect(dev); else phydev = phy_connect(priv->bus, priv->phy_addr, dev, priv->phy_mode); -- 2.25.1
Re: [PATCH V3 2/4] doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub
On 15:02-20240628, Dhruva Gole wrote: > Add the AM62x boot flow to show at which point the TIFS Stub actually > gets loaded. > > Signed-off-by: Dhruva Gole > --- > doc/board/beagle/am62x_beagleplay.rst | 2 +- > doc/board/ti/img/boot_diagram_am62.svg | 4 > 2 files changed, 5 insertions(+), 1 deletion(-) > create mode 100644 doc/board/ti/img/boot_diagram_am62.svg > > diff --git a/doc/board/beagle/am62x_beagleplay.rst > b/doc/board/beagle/am62x_beagleplay.rst > index 7784e62b0b71..be42e4d9c2ed 100644 > --- a/doc/board/beagle/am62x_beagleplay.rst > +++ b/doc/board/beagle/am62x_beagleplay.rst > @@ -23,7 +23,7 @@ Boot Flow: > -- > Below is the pictorial representation of boot flow: > > -.. image:: ../ti/img/boot_diagram_k3_current.svg > +.. image:: ../ti/img/boot_diagram_am62.svg >:alt: Boot flow diagram > > - On this platform, 'TI Foundational Security' (TIFS) functions as the > diff --git a/doc/board/ti/img/boot_diagram_am62.svg > b/doc/board/ti/img/boot_diagram_am62.svg > new file mode 100644 > index ..10b7eff6ce63 > --- /dev/null > +++ b/doc/board/ti/img/boot_diagram_am62.svg > @@ -0,0 +1,4 @@ > + > + > + "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;> Same set of issues as previously noted in response to patch #2. > +http://www.w3.org/2000/svg; style="background-color: rgb(255, > 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink; version="1.1" > width="706px" height="951px" viewBox="-0.5 -0.5 706 951" content="mxfile > host=confluence.itg.ti.com > modified=2024-06-28T08:45:50.931Z agent=Mozilla/5.0 (X11; > Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0 > etag=ufQvR89fuflntMrs8rcJ version=22.0.8 > type=atlasdiagram id=2E521vy4SbTbFAe6AtXR > name=Page-17V1bc+K4Ev41VJ19gLLl+2MCye5WJbWpkDmzc94MCPCMsVkjkrC//ki2fFMLsAEbkpCHBAlZtvvrbvVNSkfrL95/j9zl/DGcYL+DlMl7Rxt0EFJ1Tad/WM8m6bFUK+mYRd6ED8o7ht6/mHcqvHftTfCqNJCEoU+8ZblzHAYBHpNSnxtF4Vt52DT0y3ddujN+RyXvGI5dH4Nh370JmSe9tlEY/Qf2ZvP0zqrCv1m46WDesZq7k/Ct0KXddbR+FIYk+bR472OfES+lS3Ld/ZZvsweLcECqXPD4/eUNPYz+N34e/vvwuvn7+z9409XtZJpX11/zN+ZPSzYpCeZk4dNPake7XYZeQGKKGrcdY8B6cOQtMMER7QwjMg9nYeD6T3nvbRSugwlmD6HQVkYF1hiHC2/MP/vuCPu37vjXLL6gH/ohmzMIA8wuI1H4K0OAPco0DMi9u/B8xlj/xdHEDVzezblIpSS+dX1vFtDGmFIpfhxINk7JVxwR/F7o4mT8HYf0VaINHcK/NRQjuYTztKnyKd5yDkn5d15gDov3uZwnZ9nMOWz0A0euBooqALEfspfpPgMwKf2X7ON64T94U+x7MXmLKPq8u4jh29wjeLh0x+zSNyrptK/AFlT4iEsvibK277vLlTeK78rQjfB4Ha28V/yMVwk6rDdcE3anfia7Solf1E/CL8iwe2WOsRXIMLreswzINLbTFNegq+jvlKbK+JpaD5XxVVUJwBKNoGpNgasBcJ//egT40hckZVFOqJ1C0EHaxHJGCkNp6vl+oX86xeZ4LCMzI5xHV9Ab/sXCm0zYDaVapMwijSFk9ESAoMq21J5E/hpDSL+K34nA1UXxQ4ZRSfxQupCfHFxjx4qsDJ8eDpFEG40004SSODGwPdE/iiSaPRErU4KV0aoomgCth9CdsDsF8e81fTDqd3gjaqxrvZEXAPjKRssec6mM7ARP3bVPBFy59DUFgwWXLB0uWY5EZvSmQLC2gbDarAhedJAZE2kU0U8zklidU2/GfEuXuJ8BEUEwVFQJEA01BAh0DQcDpr76nO4fneC6SHAbaqJWCe5skwDirZb+59A7ItE11T4v0VO7oED1IXEjEjN6vGTffEKqO9WUfXNUhyGLlOoD6KZ8eHrrqXF/Nnpfnf3TeRsCtrJgjsxwUk9gOVne+3CIR99etSfn24+fP3/0jYHE1wfY4skMD3kzh+8u7xXgy8c8hOGSQ/ETE7LhRKc2cViWu3oEX4XraIx3jeNvRbXCDJMdb89flr3hTvwi7LvEey3H9WVYxJfeRJG7KQzgEpHP/MQ6crZQUwnjXGGI0fh64+mH5Alyrshe5QgtADllgF89igNSHmcR4JoKTqljWporcUqxSt1S66M6pboNAwgth4dUGB/aa5fgYHLDcl6M3L67WjGlW0TvGGrulS9Oy67S0x29RM2uCg1rQ6Ih0756kgpEyxQ9KV0xy3MkyodftkNIqXGI9s2V6Kcdc6UDw+l0hUtjTibWMH5xWazRDu5IF6O8pqmeDHgw1xbgTwYqjId8TVBF3Wzq6DBQLcAeesuQVki2f0lILd05EaRWWtDQFqQwZvM1IYVAnE71grkaBhXBkNAVVNZji8H/ynIqmmR225DCeNMV0hgIdKDqlcipLYavTgfqLs8fxstf/rwf0j9Dsh6xOQLW1T+o+uFzureGBkNWLbu3xsltIUq0aPM3a/SctPkjbiJDTTsG78XRg02xVQhmfmQJB2CLBWQ1lLbu5D+2s3vapjU4lPatcZBrkWP7RY66qZQXA0lUXDVlOsZqrC4WVYiMf8msRyZM1eEVwmBmtaRHc9BWKJ9rxKBL73Mh+l7AxVCFirbK5pym6LtnatqThiVz7QK6NyOVBikuFHlT75mHxrk1Rds7WcP46zCS8tdT9+XuDnDBBy2VPFrnGsbZrXYEhTSva71/hDV6ffOdftG33q822gXYaKZyqI3mKI2xVIXk1de00Yy68BrlFdyuaKNpdlPQwhTWzZpqAmVKp3s7RK9fYjjmAJxMASd0dr0OozFJDO1+8DjsX3X3BehutYLuViTS3eD+wQq5r6+pue264AqWXsWKQvUUFYXy3YMwA/aJtg/WxweV4YH6WubnNbe3s0Iy6yp4hwgeSv3gPZJn2lZT2CKAbVr2l6zIR4VEshxJlhBJMiRsO2xzGZIUlholhKZmCjWEcJtIk1kUVF5sVVuwkatGVgxj9zwXUD2owSC5lNMqKPuRbeiGTNnbY/xxlH05FJbtET6btpcUAjND2CPsme8CKvavrID7lp0kg0x3wUgVjFbsz1MUjvFqRXHYZsIHIdlG7iLSXDnrEsgI2x8AkV3Rybxg9hLvHuiaZ15Tjre/7bIkSzLo2WEOJbZoaoe5BkNxCQcorAiCQsBUmBiOu/LDyfgBCQuUlCH0NhkCBtIe3bj2pf/07Yr3sXiL+W0Z3jL/uzm8pdE1z/dcNvlV8hvjBDGKfn5OOHkt1cRdzbPoGWs8uYSCGXASKrGXtpWUJ96KB4xqTTDODcH0qmqcZxdum6jhlKcGA2h/JJFxZYj/6Wg39MMzjs1+JfJXEFNK5wcmI3FslEqmm8dKC9CmAunjKZFI7SgkJFxUN6hTbuMnLvJ7djKXqbogpaVzldnhuPOWYEzrZv/BLhfmX9ffjGco5WxDV3I0WYOetJZekrpTop9UXViFUA1yeo6t5D+okuy26VnrME73jH3srnAu2Eex21b+KG6aPtWmTlsvM5LTJhupQs5MTatR67KRuHggMbF9CXwDY4DCUUjK7rOPaiqtd48kddMKMng7UVsO1fVJO9darLEpNCrrrL31Vag2TyLDFncaoza5MkvUZIfZaIcqN1OYqNr2mFa5EsYJd0am2zu0pbYFr2lqdtZqqgckxRKtntCiwzAfF3p2IM6WkomLpnE5jqpL3KR2CQwDZqPI
Re: [PATCH V3 3/4] doc: beagle: am62x_beagleplay: Add TIFS Stub in image format
On 15:02-20240628, Dhruva Gole wrote: > Mention the TIFS Stub in the TISP image format > > Signed-off-by: Dhruva Gole > --- > doc/board/beagle/am62x_beagleplay.rst | 2 +- > doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 > 2 files changed, 5 insertions(+), 1 deletion(-) > create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg > > diff --git a/doc/board/beagle/am62x_beagleplay.rst > b/doc/board/beagle/am62x_beagleplay.rst > index be42e4d9c2ed..a70727adb621 100644 > --- a/doc/board/beagle/am62x_beagleplay.rst > +++ b/doc/board/beagle/am62x_beagleplay.rst > @@ -87,7 +87,7 @@ Image formats > > - tispl.bin > > -.. image:: ../ti/img/dm_tispl.bin.svg > +.. image:: ../ti/img/tifsstub_dm_tispl.bin.svg >:alt: tispl.bin image format > > Additional hardware for U-Boot development > diff --git a/doc/board/ti/img/tifsstub_dm_tispl.bin.svg > b/doc/board/ti/img/tifsstub_dm_tispl.bin.svg > new file mode 100644 > index ..04e4f15da21f > --- /dev/null > +++ b/doc/board/ti/img/tifsstub_dm_tispl.bin.svg > @@ -0,0 +1,4 @@ > + License is missing among other formatting issues. I usually pass it through inkscape to ensure the formatting issues are cleared up. > + Drop this. > + "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;> > +http://www.w3.org/2000/svg; style="background-color: rgb(255, > 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink; version="1.1" > width="231px" height="351px" viewBox="-0.5 -0.5 231 351" content="mxfile > host=confluence.itg.ti.com > modified=2024-06-28T06:00:12.998Z agent=Mozilla/5.0 (X11; > Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0 > etag=tyHDTMUXFR0F8l2WlmTa version=22.0.8 > type=atlasdiagram id=prx1HvI4_W0GNTyXR3Yw > name=Page-11Zfvj5owGMf/GpLthReggOzlieCZ7TZ3mJjszaXSCs0KNbVOvb9+rRSF1W3eMnPhDbTf5+mP5/MtjVogKvcTDtfFI0OYWq6N9hYYW67reMCTL6UcamXoDGsh5wTppLOQkhesRVurW4LwppMoGKOCrLtixqoKZ6KjQc7Zrpu2YrS76hrmekX7LKQZpNhIWxAkiloN/Vb2AyZ50azs2DpSwiZZC5sCIrZrSSC2QMQZE3Wr3EeYKngNl3pc8pvoaWMcV+KaAeGsmIJkST6uv0L/efE8fsm/DfQsPyDd6oL1ZsWhIcDZtkJYTeJYYLQriMDpGmYqupOeS60QJdXhFaE0YpTx41iAfBwiT+obwdl33IqE7hIEgYyYZTR7wlzgfUvSZU0wK7HgB5mioyDQiPUZc5v+7uyYC7RWtNwCjY1Qn5L8NPcZpGxolq/g6hpck+lcCg8YIsz/wNh+HeOKVfj/QPTsXyB+MCE6wQWIwa0YAoPhfJqkUknFdmm5AZUbGC0lzCBXrXeTmeVGinE6UGm6mcbv+4Dbc6/EfbMj65m4k8G9wU7WJ7qAut82wiu4PVpzARykJK9kN5Pg5GcARgoYkbftvQ6UBCG10kVTurbdwITTffA3E8CtTPANE77MBvM47sMRBuGV9Lxb0QsMek8SqD1+lI9k0QeG3vCtGQ4NhhFT1airwE5nn/pA0XfemmJoUDyis8dzWa/t3N197gXHa+/Df+Aou+ffvsdY6x8EiH8C/diagram/mxfile"> x="0" y="0" width="230" height="350" rx="34.5" ry="34.5" fill="#d5e8d4" > stroke="#82b366" pointer-events="all"/> height="60" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/> transform="translate(-0.5 -0.5)"> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility;> xmlns="http://www.w3.org/1999/xhtml; style="display: flex; align-items: > unsafe center; justify-content: unsafe center; width: 158px; height: 1px; > padding-top: 60px; margin-left: 41px;">FIT > HeaderFIT > Header fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/> transform="translate(-0.5 -0.5)"> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility;> xmlns="http://www.w3.org/1999/xhtml; style="display: flex; align-items: > unsafe center; justify-content: unsafe center; width: 158px; height: 1px; > padding-top: 185px; margin-left: 41px;">TIFS Stub(GP, HS-FS, > HS-SE)TIFS > Stub... fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/> transform="translate(-0.5 -0.5)"> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility;> xmlns="http://www.w3.org/1999/xhtml; style="display: flex; align-items: > unsafe center; justify-content: unsafe center; width: 158px; height: 1px; > padding-top: 105px; margin-left: 41px;">TF-A x="120" y="109" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" > text-anchor="middle">TF-A height="40" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/> transform="translate(-0.5 -0.5)"> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility;> xmlns="http://www.w3.org/1999/xhtml; style="display: flex; align-items: > unsafe center; justify-content: unsafe center; width: 158px; height: 1px; > padding-top: 140px; margin-left: 41px;">OP-TEE x="120" y="144" fill="r
Re: [PATCH v2 0/2] clk: add a stub clock driver
On Mon, 27 May 2024 at 20:12, Caleb Connolly wrote: > > As U-Boot works to align itself with upstream devicetrees, there are > some common issues we start to run into, that of hardware blocks which > might be important for an OS like Linux, but which aren't useful in > U-Boot. > > For example, the Resource Power Manager found on Qualcomm platforms > includes clock controllers and power domains which are only useful for > managing power consumption and enabling low power states. > > As this is not at all relevant for U-Boot, we can safely ignore these > devices, but we don't have a good way to communicate that to U-Boot. > > As an initial step, implement a "stub" clock driver which can be bound > to these devices so that drivers will work as expected. Make the > Qualcomm SM6115 RPMCC the first user of this, and enable the driver for > Qualcomm platforms. > > To: Tom Rini > To: Lukasz Majewski > To: Sean Anderson > To: Caleb Connolly > To: Neil Armstrong > To: Sumit Garg > Cc: Heinrich Schuchardt > Cc: Ilias Apalodimas > Cc: u-boot@lists.denx.de > Cc: u-boot-q...@groups.io > > Changes in v2: > - Take the other discussed approach of just implementing a stub driver. > - Link to v1: > https://lore.kernel.org/r/20240410-b4-stub-drivers-v1-0-6935bd2c0...@linaro.org > > --- > Caleb Connolly (2): > clk: add stub clock driver > qcom_defconfig: enable stub clock > > configs/qcom_defconfig | 1 + > drivers/clk/Kconfig| 7 ++ > drivers/clk/Makefile | 1 + > drivers/clk/clk-stub.c | 63 > ++ > 4 files changed, 72 insertions(+) > --- > change-id: 20240527-b4-clk-stub-9698797a65ef > base-commit: 7e52d6ccfb76e2afc2d183b357abe2a2e2f948cf > > // Caleb (they/them) > Acked-by: Ilias Apalodimas
Re: [PATCH v2 1/2] clk: add stub clock driver
On 27/05/2024 19:12, Caleb Connolly wrote:
Add a stub clock driver which can be used to bind clock controllers
which aren't required for the platform to boot, but which are needed for
U-Boot drivers to work.
In addition, add a NOP parent driver to allow for binding the parent
nodes of the clock.
Initially this driver supports a Qualcomm platform where the MMC driver
tries to fetch the RPM clock controller, which is not actually required
for the device to work.
Signed-off-by: Caleb Connolly
---
drivers/clk/Kconfig| 7 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-stub.c | 63 ++
3 files changed, 71 insertions(+)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9acbc47fe8ed..965bc4959403 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -95,8 +95,15 @@ config SPL_CLK_GPIO
help
Enable this option to add GPIO-controlled clock gate driver
in U-Boot SPL.
+config CLK_STUB
+ bool "Stub clock driver"
+ depends on CLK
+ help
+ Enable this to provide a stub clock driver for non-essential clock
+ controllers.
+
config CLK_BCM6345
bool "Clock controller driver for BCM6345"
depends on CLK && ARCH_BMIPS
default y
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 847b9b291100..b2cea41419b7 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -10,8 +10,9 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o clk-gate.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o
obj-$(CONFIG_$(SPL_TPL_)CLK_GPIO) += clk-gpio.o
+obj-$(CONFIG_CLK_STUB) += clk-stub.o
obj-y += adi/
obj-y += analogbits/
obj-y += imx/
diff --git a/drivers/clk/clk-stub.c b/drivers/clk/clk-stub.c
new file mode 100644
index ..3f9c758ef115
--- /dev/null
+++ b/drivers/clk/clk-stub.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Stub clk driver for non-essential clocks.
+ *
+ * This driver should be used for clock controllers
+ * which are described as dependencies in DT but aren't
+ * actually necessary for hardware functionality.
+ */
+
+#include
+#include
+
+/* NOP parent nodes to stub clocks */
+static const struct udevice_id nop_parent_ids[] = {
+ { .compatible = "qcom,rpm-proc" },
+ { .compatible = "qcom,glink-rpm" },
+ { .compatible = "qcom,rpm-sm6115" },
+ { }
+};
+
+U_BOOT_DRIVER(nop_parent) = {
+ .name = "nop_parent",
+ .id = UCLASS_NOP,
+ .of_match = nop_parent_ids,
+ .bind = dm_scan_fdt_dev,
+ .flags = DM_FLAG_DEFAULT_PD_CTRL_OFF,
+};
+
+static ulong stub_clk_set_rate(struct clk *clk, ulong rate)
+{
+ return (clk->rate = rate);
+}
+
+static ulong stub_clk_get_rate(struct clk *clk)
+{
+ return clk->rate;
+}
+
+static int stub_clk_nop(struct clk *clk)
+{
+ return 0;
+}
+
+static struct clk_ops stub_clk_ops = {
+ .set_rate = stub_clk_set_rate,
+ .get_rate = stub_clk_get_rate,
+ .enable = stub_clk_nop,
+ .disable = stub_clk_nop,
+};
+
+static const struct udevice_id stub_clk_ids[] = {
+ { .compatible = "qcom,rpmcc" },
If you resend, please add:
- qcom,sm8550-rpmh-clk
- qcom,sm8650-rpmh-clk
Thanks,
Neil
+ { }
+};
+
+U_BOOT_DRIVER(clk_stub) = {
+ .name = "clk_stub",
+ .id = UCLASS_CLK,
+ .ops = _clk_ops,
+ .of_match = stub_clk_ids,
+ .flags = DM_FLAG_DEFAULT_PD_CTRL_OFF,
+};
+
Re: [PATCH v2 0/2] clk: add a stub clock driver
On 27/05/2024 19:12, Caleb Connolly wrote: As U-Boot works to align itself with upstream devicetrees, there are some common issues we start to run into, that of hardware blocks which might be important for an OS like Linux, but which aren't useful in U-Boot. For example, the Resource Power Manager found on Qualcomm platforms includes clock controllers and power domains which are only useful for managing power consumption and enabling low power states. As this is not at all relevant for U-Boot, we can safely ignore these devices, but we don't have a good way to communicate that to U-Boot. As an initial step, implement a "stub" clock driver which can be bound to these devices so that drivers will work as expected. Make the Qualcomm SM6115 RPMCC the first user of this, and enable the driver for Qualcomm platforms. To: Tom Rini To: Lukasz Majewski To: Sean Anderson To: Caleb Connolly To: Neil Armstrong To: Sumit Garg Cc: Heinrich Schuchardt Cc: Ilias Apalodimas Cc: u-boot@lists.denx.de Cc: u-boot-q...@groups.io Changes in v2: - Take the other discussed approach of just implementing a stub driver. - Link to v1: https://lore.kernel.org/r/20240410-b4-stub-drivers-v1-0-6935bd2c0...@linaro.org --- Caleb Connolly (2): clk: add stub clock driver qcom_defconfig: enable stub clock configs/qcom_defconfig | 1 + drivers/clk/Kconfig| 7 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-stub.c | 63 ++ 4 files changed, 72 insertions(+) --- change-id: 20240527-b4-clk-stub-9698797a65ef base-commit: 7e52d6ccfb76e2afc2d183b357abe2a2e2f948cf // Caleb (they/them) LGTM Reviewed-by: Neil Armstrong
[PATCH] firmware: psci: register PSCI power domains to stub driver
On some SoCs, like Qualcomm SoCs, the PSCI cluster power domain
is used by system-wide firmware interfaces to make sure none
of the CPUs are suspended before submitting requests.
While on U-boot we only use the first core and we never
suspend it, the Device Tree still references it and blocks
those nodes to be probed.
Simply bind the PSCI power-domain subnoded to a stub power
domain driver in order to solve the runtime dependencies.
Signed-off-by: Neil Armstrong
---
drivers/firmware/psci.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 03544d76ed4..fc72bc17274 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#define DRIVER_NAME "psci"
@@ -172,6 +173,10 @@ static int bind_smccc_features(struct udevice *dev, int
psci_method)
static int psci_bind(struct udevice *dev)
{
+#if IS_ENABLED(CONFIG_POWER_DOMAIN)
+ ofnode node;
+#endif
+
/* No SYSTEM_RESET support for PSCI 0.1 */
if (device_is_compatible(dev, "arm,psci-0.2") ||
device_is_compatible(dev, "arm,psci-1.0")) {
@@ -188,6 +193,16 @@ static int psci_bind(struct udevice *dev)
if (IS_ENABLED(CONFIG_ARM_SMCCC_FEATURES) && device_is_compatible(dev,
"arm,psci-1.0"))
dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
+ /* Bind power-domain subnodes */
+#if IS_ENABLED(CONFIG_POWER_DOMAIN)
+ dev_for_each_subnode(node, dev) {
+ if (device_bind_driver_to_node(dev, "psci_power_domain",
+ ofnode_get_name(node),
+ node, NULL))
+ pr_warn("failed to bind %s\n", ofnode_get_name(node));
+ }
+#endif
+
return 0;
}
@@ -324,3 +339,29 @@ U_BOOT_DRIVER(psci) = {
#endif
.flags = DM_FLAG_PRE_RELOC,
};
+
+#if IS_ENABLED(CONFIG_POWER_DOMAIN)
+/* Accept #power-domain-cells == 0 */
+static int psci_power_domain_xlate(struct power_domain *power_domain,
+ struct ofnode_phandle_args *args)
+{
+ return args->args_count == 0 ? 0 : -EINVAL;
+}
+
+static const struct power_domain_ops psci_power_ops = {
+ .of_xlate = psci_power_domain_xlate,
+};
+
+static int psci_power_domain_probe(struct udevice *dev)
+{
+ return 0;
+}
+
+U_BOOT_DRIVER(psci_power_domain) = {
+ .name = "psci_power_domain",
+ .id = UCLASS_POWER_DOMAIN,
+ .ops = _power_ops,
+ .probe = psci_power_domain_probe,
+ .flags = DM_FLAG_PRE_RELOC,
+};
+#endif
---
base-commit: 9e9f78f7aa0124ef0e622532043acf87e84008dc
change-id: 20240628-topic-sm8x50-psci-power-domain-27dd90a7f298
Best regards,
--
Neil Armstrong
Re: [PATCH v4 00/14] Introduce the lwIP network stack
Hi Tim, On 6/26/24 18:00, Tim Harvey wrote: > On Tue, Jun 25, 2024 at 1:02 AM Jerome Forissier > wrote: >> >> On 6/25/24 00:28, Tim Harvey wrote: >>> On Sat, Jun 22, 2024 at 1:09 AM Maxim Uvarov wrote: пт, 21 июн. 2024 г. в 21:42, Fabio Estevam : > > Hi Tim and Jerome, > > On Fri, Jun 21, 2024 at 1:08 PM Tim Harvey wrote: > >> I tried your to-upstream/v5-wip branch >> (042bea36eb9731079a3d7afffe3774d79e06ac5d) and it behaves the same. Do >> you have something else to try/test? > > Yes, when I tested older versions from Maxim I could never get lwIP to > work with i.MX. > > Jerome, > > Please try to run the lwIP series on any i.MX board, if possible. > > Thanks Packet not for us means that incoming packet DST MAC does not match to the MAC address inside lwip. I.e. to MAC address set into lwip when lwip_init was done. Original U-Boot network stack does not compare MACs but lwip does. There is something specific on this board, in general lwip with debug should print out MAC used during initialization. This MAC should match to the MAC from the incoming packet. >>> >>> It seems 'packet not for us' can mean a lot of things. >> >> Yeah :-/ in this case I believe the traces are caused by unrelated traffic >> (UDP port 138 is used by NetBIOS). >> >> >>> I added a bit of debugging around 'DHCP packet accepted' and found I'm >>> not receiving any packets from my DHCP server. So I connected directly >>> to another board (isolated network) where I ran my own server and >>> tcpdump and I don't see packets coming from lwip: >> >> Ha! That's interesting. >> >>> without lwip my server shows: >>> # tcpdump -i eth1 >>> tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot >>> length 262144 bytes >>> tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot >>> length 262144 bytes >>> 22:18:01.043992 IP (tos 0x0, ttl 255, id 23, offset 0, flags [DF], >>> proto UDP (17), length 328) >>> 22:18:01.044391 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], >>> proto UDP (17), length 328) >>> 22:18:01.044454 IP (tos 0x0, ttl 255, id 24, offset 0, flags [DF], >>> proto UDP (17), length 328) >>> 22:18:01.044752 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], >>> proto UDP (17), length 328) >>> >>> # tcpdump -i eth1 >>> tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot >>> length 262144 bytes >>> 22:22:41.602178 [|llc] >>> 22:22:41.709978 [|llc] >>> 22:22:41.867947 [|llc] >>> 22:22:42.105202 [|llc] >>> 22:22:42.502091 [|llc] >>> 22:22:43.219079 [|llc] >>> 22:22:44.497979 [|llc] >>> 22:22:45.776884 [|llc] >>> 22:22:47.054773 [|llc] >>> 22:22:48.333667 [|llc] >>> 22:22:49.611559 [|llc] >>> 22:22:50.890469 [|llc] >>> >>> What actual hardware has this been tested with? I think Tom mentioned >>> he tested with an rpi of some sort. >> >> Yes, I believe he tested on RPi 3B and me too. Ilias has tested on NVIDIA >> Jetson Nano. >> >>> I don't know what the meaning of the llc msg is above but you can see >>> there is no DHCP request. >> >> Some more tracing is needed. Can you try enabling all traces in >> lib/lwip/u-boot/lwipopts.h? i.e., replace all LWIP_DBG_OFF with >> LWIP_DBG_ON in the #if defined(CONFIG_LWIP_DEBUG) section. And of course >> enabled CONFIG_LWIP_DEBUG. > > Here's what I see with all those enabled on an imx8mm-venice-gw73xx-0x: > Net: eth0: ethernet@30be [PRIME] > GSC : boot watchdog disabled > Thermal protection:enabled at 96C > Hit any key to stop autoboot: 0 > u-boot=> dhcp || echo fail > netif: added interface et IP addr 0.0.0.0 netmask 0.0.0.0 gw 0.0.0.0 > netif: setting default interface et > dhcp_start(netif=fdf23bb0) et0 > dhcp_start(): mallocing new DHCP client > dhcp_start(): allocated dhcp > dhcp_start(): starting DHCP configuration > udp_bind(ipaddr = 0.0.0.0, port = 68) > udp_bind: bound to 0.0.0.0, port 68) > udp_connect: connected to 0.0.0.0, port 67) > dhcp_discover() > pbuf_alloc(length=308) > pbuf_alloc(length=308) == fdf23d10 > transaction id xid(42021) > dhcp_discover: making request > dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, LWIP_IANA_PORT_DHCP_SERVER) > pbuf_add_header: old fdf23d5e new fdf23d56 (8) > udp_send: added header in given pbuf fdf23d10 > udp_send: sending datagram of length 316 > udp_send: UDP packet length 316 > inet_chksum_pseudo(): checksumming pbuf fdf23d10 (has next > ) > inet_chksum_pseudo(): pbuf chain lwip_chksum()=807 > udp_send: UDP checksum 0xf7f8 > udp_send: ip_output_if (0x11,) > pbuf_add_header: old fdf23d56 new fdf23d42 (20) > ip4_output_if: et0 > IP header: > +---+ > | 4 | 5 | 0x00 | 336 | (v, hl, tos, len) > +---+ > |0 |000| 0 | (id, flags, offset) > +---+ > | 255 | 17 |
[PATCH] doc: ti: am62*: Add in TIFS Stub boot flow and img fmts
Since AM62x, AM62P and AM62A all use similar boot flows and their low power mode s/w ARCH is also similar in the way that they make use of the TIFS Stub, update their documentation to show where TIFS Stub is. Signed-off-by: Dhruva Gole --- This series depends on TIFS Stub BeaglePlay series sent previously: https://lore.kernel.org/u-boot/20240628093252.1864609-1-d-g...@ti.com/ doc/board/ti/am62ax_sk.rst | 4 ++-- doc/board/ti/am62px_sk.rst | 4 ++-- doc/board/ti/am62x_sk.rst | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/board/ti/am62ax_sk.rst b/doc/board/ti/am62ax_sk.rst index 60726b6652ce..92da6f65f9d5 100644 --- a/doc/board/ti/am62ax_sk.rst +++ b/doc/board/ti/am62ax_sk.rst @@ -47,7 +47,7 @@ Boot Flow: -- Below is the pictorial representation of boot flow: -.. image:: img/boot_diagram_k3_current.svg +.. image:: img/boot_diagram_am62.svg :alt: Boot flow diagram - Here TIFS acts as master and provides all the critical services. R5/A53 @@ -144,7 +144,7 @@ Image formats: - tispl.bin -.. image:: img/dm_tispl.bin.svg +.. image:: img/tifsstub_dm_tispl.bin.svg :alt: tispl.bin image format Switch Setting for Boot Mode diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst index 1f2982c36f9e..2c4af97967d3 100644 --- a/doc/board/ti/am62px_sk.rst +++ b/doc/board/ti/am62px_sk.rst @@ -55,7 +55,7 @@ Boot Flow: The bootflow is exactly the same as all SoCs in the am62xxx extended SoC family. Below is the pictorial representation: -.. image:: img/boot_diagram_k3_current.svg +.. image:: img/boot_diagram_am62.svg :alt: Boot flow diagram - Here TIFS acts as master and provides all the critical services. R5/A53 @@ -153,7 +153,7 @@ Image formats: - tispl.bin -.. image:: img/dm_tispl.bin.svg +.. image:: img/tifsstub_dm_tispl.bin.svg :alt: tispl.bin image format A53 SPL DDR Memory Layout diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index b12dc85f06b5..649c8232d76b 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -46,7 +46,7 @@ Boot Flow: -- Below is the pictorial representation of boot flow: -.. image:: img/boot_diagram_k3_current.svg +.. image:: img/boot_diagram_am62.svg :alt: Boot flow diagram - Here TIFS acts as master and provides all the critical services. R5/A53 @@ -147,7 +147,7 @@ Image formats: - tispl.bin -.. image:: img/dm_tispl.bin.svg +.. image:: img/tifsstub_dm_tispl.bin.svg :alt: tispl.bin image format A53 SPL DDR Memory Layout base-commit: c27d592304604559276d939a7ef676952062b4ae -- 2.34.1
[PATCH V3 4/4] doc: ti: k3: Add TIFS Stub documentation
Add documentation to briefly explain the role of TIFS Stub in relevant K3 SoC's. Signed-off-by: Dhruva Gole --- doc/board/ti/k3.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index 88821a15e4c6..f45a285db21b 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -192,6 +192,11 @@ online device resources such as power, clock, interrupts, dma etc. This firmware runs on a dedicated or multi-use microcontroller outside the security enclave. + * **TIFS Stub** - A small piece of code that helps restore the remaining +context and resume the TIFS firmware when resuming from Low Power Modes +like Suspend-to-RAM/ Deep Sleep. It is loaded into the ATCM (Tightly +Coupled Memory 'A' of the DM R5) during DM startup. This applies only +to AM62x, AM62A and AM62P based devices. OR -- 2.34.1
[PATCH V3 3/4] doc: beagle: am62x_beagleplay: Add TIFS Stub in image format
Mention the TIFS Stub in the TISP image format Signed-off-by: Dhruva Gole --- doc/board/beagle/am62x_beagleplay.rst | 2 +- doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg diff --git a/doc/board/beagle/am62x_beagleplay.rst b/doc/board/beagle/am62x_beagleplay.rst index be42e4d9c2ed..a70727adb621 100644 --- a/doc/board/beagle/am62x_beagleplay.rst +++ b/doc/board/beagle/am62x_beagleplay.rst @@ -87,7 +87,7 @@ Image formats - tispl.bin -.. image:: ../ti/img/dm_tispl.bin.svg +.. image:: ../ti/img/tifsstub_dm_tispl.bin.svg :alt: tispl.bin image format Additional hardware for U-Boot development diff --git a/doc/board/ti/img/tifsstub_dm_tispl.bin.svg b/doc/board/ti/img/tifsstub_dm_tispl.bin.svg new file mode 100644 index ..04e4f15da21f --- /dev/null +++ b/doc/board/ti/img/tifsstub_dm_tispl.bin.svg @@ -0,0 +1,4 @@ + + +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;> +http://www.w3.org/2000/svg; style="background-color: rgb(255, 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink; version="1.1" width="231px" height="351px" viewBox="-0.5 -0.5 231 351" content="mxfile host=confluence.itg.ti.com modified=2024-06-28T06:00:12.998Z agent=Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0 etag=tyHDTMUXFR0F8l2WlmTa version=22.0.8 type=atlasdiagram id=prx1HvI4_W0GNTyXR3Yw name=Page-11Zfvj5owGMf/GpLthReggOzlieCZ7TZ3mJjszaXSCs0KNbVOvb9+rRSF1W3eMnPhDbTf5+mP5/MtjVogKvcTDtfFI0OYWq6N9hYYW67reMCTL6UcamXoDGsh5wTppLOQkhesRVurW4LwppMoGKOCrLtixqoKZ6KjQc7Zrpu2YrS76hrmekX7LKQZpNhIWxAkiloN/Vb2AyZ50azs2DpSwiZZC5sCIrZrSSC2QMQZE3Wr3EeYKngNl3pc8pvoaWMcV+KaAeGsmIJkST6uv0L/efE8fsm/DfQsPyDd6oL1ZsWhIcDZtkJYTeJYYLQriMDpGmYqupOeS60QJdXhFaE0YpTx41iAfBwiT+obwdl33IqE7hIEgYyYZTR7wlzgfUvSZU0wK7HgB5mioyDQiPUZc5v+7uyYC7RWtNwCjY1Qn5L8NPcZpGxolq/g6hpck+lcCg8YIsz/wNh+HeOKVfj/QPTsXyB+MCE6wQWIwa0YAoPhfJqkUknFdmm5AZUbGC0lzCBXrXeTmeVGinE6UGm6mcbv+4Dbc6/EfbMj65m4k8G9wU7WJ7qAut82wiu4PVpzARykJK9kN5Pg5GcARgoYkbftvQ6UBCG10kVTurbdwITTffA3E8CtTPANE77MBvM47sMRBuGV9Lxb0QsMek8SqD1+lI9k0QeG3vCtGQ4NhhFT1airwE5nn/pA0XfemmJoUDyis8dzWa/t3N197gXHa+/Df+Aou+ffvsdY6x8EiH8C/diagram/mxfile">http://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 60px; margin-left: 41px;">FIT HeaderFIT Headerhttp://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 185px; margin-left: 41px;">TIFS Stub(GP, HS-FS, HS-SE)TIFS Stub...http://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 105px; margin-left: 41px;">TF-ATF-Ahttp://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 140px; margin-left: 41px;">OP-TEEOP-TEEhttp://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 230px; margin-left: 41px;">R5 DM FWR5 DM FWhttp://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 270px; margin-left: 41px;">Cortex-A SPLCortex-A SPLhttp://www.w3.org/TR/SVG11/feature#Extensibility;>http://www.w3.org/1999/xhtml; style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 310px; margin-left: 41px;">SPL DTB 1..NSPL DTB 1..Nhttp://www.w3.org/TR/SVG11/feature#Extensibility"/>https://www.drawio.com/doc/faq/svg-export-text-problems; target="_blank">Text is not SVG - cannot display \ No newline at end of file -- 2.34.1
[PATCH V3 2/4] doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub
Add the AM62x boot flow to show at which point the TIFS Stub actually gets loaded. Signed-off-by: Dhruva Gole --- doc/board/beagle/am62x_beagleplay.rst | 2 +- doc/board/ti/img/boot_diagram_am62.svg | 4 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 doc/board/ti/img/boot_diagram_am62.svg diff --git a/doc/board/beagle/am62x_beagleplay.rst b/doc/board/beagle/am62x_beagleplay.rst index 7784e62b0b71..be42e4d9c2ed 100644 --- a/doc/board/beagle/am62x_beagleplay.rst +++ b/doc/board/beagle/am62x_beagleplay.rst @@ -23,7 +23,7 @@ Boot Flow: -- Below is the pictorial representation of boot flow: -.. image:: ../ti/img/boot_diagram_k3_current.svg +.. image:: ../ti/img/boot_diagram_am62.svg :alt: Boot flow diagram - On this platform, 'TI Foundational Security' (TIFS) functions as the diff --git a/doc/board/ti/img/boot_diagram_am62.svg b/doc/board/ti/img/boot_diagram_am62.svg new file mode 100644 index ..10b7eff6ce63 --- /dev/null +++ b/doc/board/ti/img/boot_diagram_am62.svg @@ -0,0 +1,4 @@ + + +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;> +http://www.w3.org/2000/svg; style="background-color: rgb(255, 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink; version="1.1" width="706px" height="951px" viewBox="-0.5 -0.5 706 951" content="mxfile host=confluence.itg.ti.com modified=2024-06-28T08:45:50.931Z agent=Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0 etag=ufQvR89fuflntMrs8rcJ version=22.0.8 type=atlasdiagram id=2E521vy4SbTbFAe6AtXR
[PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
This series includes the binman related changes required to package tIFS Stub to support Low Power Modes on BeaglePlay. Also, based on comments from previous patch [0] documentation has been added to describe small addition in boot flow as well as tispl image format. I am aware that the new boot flow image will need to be updated in other places like am62a, am62p and even other boards that use am62x. However, I would like to keep this series beagleplay TIFSStub specific and so I will be sending a follow up series to update other places seperately if that's ok. Changelog: * Add new image format for TISPL * Add new changes in boot flow for am62 family of devices. [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-g...@ti.com/ Dhruva Gole (4): arm: dts: k3-am625-beagleplay: Package TIFS Stub doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub doc: beagle: am62x_beagleplay: Add TIFS Stub in image format doc: ti: k3: Add TIFS Stub documentation arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++- doc/board/beagle/am62x_beagleplay.rst| 4 +-- doc/board/ti/img/boot_diagram_am62.svg | 4 +++ doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 +++ doc/board/ti/k3.rst | 5 +++ 5 files changed, 47 insertions(+), 3 deletions(-) create mode 100644 doc/board/ti/img/boot_diagram_am62.svg create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg base-commit: c53b344475734d0d29f522b7b1d80c5b8204442d -- 2.34.1
[PATCH V3 1/4] arm: dts: k3-am625-beagleplay: Package TIFS Stub
Add support for packaging the TIFS Stub as it's required for basic Low
Power Modes like Deep Sleep.
Acked-by: Neha Malcom Francis
Signed-off-by: Dhruva Gole
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index fb2032068d1c..5e2248a4a668 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -69,6 +69,23 @@
};
};
+ tifsstub-gp {
+ filename = "tifsstub.bin_gp";
+ ti-secure-rom {
+ content = <_gp>;
+ core = "secure";
+ load = <0x6>;
+ sw-rev = ;
+ keyfile = "ti-degenerate-key.pem";
+ tifsstub;
+ };
+ tifsstub_gp: tifsstub-gp.bin {
+ filename = "ti-sysfw/ti-fs-stub-firmware-am62x-gp.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+
ti-spl_unsigned {
filename = "tispl.bin_unsigned";
pad-byte = <0xff>;
@@ -105,6 +122,19 @@
};
};
+ tifsstub-gp {
+ description = "tifsstub";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-gp";
+ load = <0x9dc0>;
+ entry = <0x9dc0>;
+ blob-ext {
+ filename = "tifsstub.bin_gp";
+ };
+ };
+
dm {
description = "DM binary";
type = "firmware";
@@ -148,7 +178,8 @@
conf-0 {
description = "k3-am625-beagleplay";
firmware = "atf";
- loadables = "tee", "dm", "spl";
+ loadables = "tee", "dm", "spl",
+ "tifsstub-gp";
fdt = "fdt-0";
};
};
base-commit: c53b344475734d0d29f522b7b1d80c5b8204442d
--
2.34.1
[PATCH] cmd: add resize for FDT in bootelf
In some FDTs, there is not enough free memory to add nodes, so this
operation fails.
Signed-off-by: Maxim Moskalets
---
cmd/elf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd/elf.c b/cmd/elf.c
index 32b7462f92..673c6c3051 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -68,6 +68,8 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
log_debug("Setting up FDT at 0x%08lx ...\n", fdt_addr);
flush();
+ fdt_set_totalsize((void *)fdt_addr,
+ fdt_totalsize(fdt_addr) + CONFIG_SYS_FDT_PAD);
if (image_setup_libfdt(, (void *)fdt_addr, NULL))
return 1;
}
--
2.39.2
Re: [PATCH] spl: fit: List DTOs applied by SPL in U-Boot control DT
Hi Marek,
On 6/28/24 4:42 AM, Marek Vasut wrote:
On 6/27/24 2:42 PM, Quentin Schulz wrote:
Hi Marek,
Hi,
On 6/27/24 1:58 AM, Marek Vasut wrote:
Insert /u-boot, = property into the U-Boot control DT
during SPL DTO application process. This can be used by user to inspect
which DTOs got applied by the SPL and in which order from running
U-Boot.
Example:
```
u-boot=> fdt addr $fdtcontroladdr && fdt list /
Working FDT set to aee9aeb0
/ {
u-boot,fdt-dto-imx8mp-dhcom-pdk3-overlay-rev100 = <0x0005>;
u-boot,fdt-dto-imx8mp-dhcom-som-overlay-rev100 = <0x0004>;
u-boot,fdt-dto-imx8mp-dhcom-pdk-overlay-eth2xfast =
<0x0003>;
u-boot,fdt-dto-imx8mp-dhcom-som-overlay-eth2xfast =
<0x0002>;
...
```
Shouldn't this rather be in /config node?
This is what I had there originally, but then I realized that some DTs
might not have the /config node in them (or am I mistaken?), so I moved
the new properties into the root node, which surely exists.
It also keeps the code simpler, as it doesn't have to fiddle with
creation of the /config node if it doesn't exist.
I don't think we should pollute the root node with this. If we want to
be able to expose this in a proper binding to the upstream DT binding
repo, I'm not sure this is going to fly :/
Also, I am highly suggesting to have an additional prefix aside from
u-boot to avoid unfortunate name clashes between DTO and existing
properties.
OK, fixed in V2.
Or could be in its own child node of /config ?
Please see above.
In any case, can you please add or edit a file somewhere to define
this new dt-binding.
Done in V2
Additional question, what is this index for?
To indicate in which order the DTOs were applied by the SPL. It matches
the order in which the the DTOs are stored in the fitImage and the order
in which SPL iterates over them. In case the SPL skips a DTO using
board_spl_fit_append_fdt_skip(), the integer sequence might have gaps.
I am wondering if we cannot simply have a string array with overlays
applied left-to-right or right-to-left instead? Or u-boot,fdt-dto-N =
"imx8mp-dhcom-pdk3-overlay-rev100";
We can, but that is much harder to test for presence of specific DTO on
U-Boot command line. It is easy to test for presence of boolean or
integer DT property using 'fdt' command.
Not sure dt-bindings people would love to hear that we adapt the fdt to
be easier to work with from the U-Boot CLI :)
In any case, another few thoughts that popped up overnight:
1- do we want to have this for SPL DTB modified by TPL? If so, I'm sure
we want it different from the one passed from SPL to U-Boot proper IFF
we start from a clean sheet (new DTB) and/or add the DTBO we applied on
top the DTBOs already applied by the TPL to the SPL DTB before passing
it to proper
2- Add info about which DTBOs were applied to the kernel DTB?
Cheers,
Quentin
[PATCH 3/3] configs: am62p|j722s_a53: Add CONFIG_BOARD_LATE_INIT
This is called to set findfdt after the board is initialized. Signed-off-by: Manorit Chawdhry --- configs/am62px_evm_a53_defconfig | 1 + configs/j722s_evm_a53_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig index e1c9c8535e43..87005d03dee3 100644 --- a/configs/am62px_evm_a53_defconfig +++ b/configs/am62px_evm_a53_defconfig @@ -33,6 +33,7 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 CONFIG_BOOTSTD_FULL=y CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" +CONFIG_BOARD_LATE_INIT=y CONFIG_SPL_MAX_SIZE=0x58000 CONFIG_SPL_PAD_TO=0x0 CONFIG_SPL_SYS_MALLOC_SIMPLE=y diff --git a/configs/j722s_evm_a53_defconfig b/configs/j722s_evm_a53_defconfig index da0e9f4d524d..1675cedb25ef 100644 --- a/configs/j722s_evm_a53_defconfig +++ b/configs/j722s_evm_a53_defconfig @@ -33,6 +33,7 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 CONFIG_BOOTSTD_FULL=y CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" +CONFIG_BOARD_LATE_INIT=y CONFIG_SPL_MAX_SIZE=0x58000 CONFIG_SPL_PAD_TO=0x0 CONFIG_SPL_SYS_MALLOC_SIMPLE=y -- 2.45.1
[PATCH 2/3] board: ti: am62p|j722s: Add ti_set_fdt_env for findfdt
stdboot and legacy boot now depend on findfdt and findfdt is populated
based on evm code now. Populate findfdt by calling ti_set_fdt_env in
board files.
Signed-off-by: Manorit Chawdhry
---
board/ti/am62px/evm.c | 9 +
board/ti/j722s/evm.c | 9 +
2 files changed, 18 insertions(+)
diff --git a/board/ti/am62px/evm.c b/board/ti/am62px/evm.c
index 1a2c46c462b4..7362fa4520a3 100644
--- a/board/ti/am62px/evm.c
+++ b/board/ti/am62px/evm.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include "../common/fdt_ops.h"
struct efi_fw_image fw_images[] = {
{
@@ -61,3 +62,11 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#if IS_ENABLED(CONFIG_BOARD_LATE_INIT)
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
diff --git a/board/ti/j722s/evm.c b/board/ti/j722s/evm.c
index 515aaa818783..29e06a5442fe 100644
--- a/board/ti/j722s/evm.c
+++ b/board/ti/j722s/evm.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include "../common/fdt_ops.h"
int board_init(void)
{
@@ -27,3 +28,11 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#if IS_ENABLED(CONFIG_BOARD_LATE_INIT)
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
--
2.45.1
[PATCH 1/3] include: env: ti: mmc: Change name_fdt usage to fdtfile
name_fdt is kept for backward compatibility but it depends on EEPROM
detection logic and some of the platforms like J7AHP/AM69 don't have
that anymore which causes boot failure.
Replacing name_fdt usage to fdtfile as fdtfile is populated based on
CONFIG_DEFAULT_DEVICE_TREE.
Signed-off-by: Manorit Chawdhry
---
include/env/ti/mmc.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/env/ti/mmc.env b/include/env/ti/mmc.env
index 0256a2d2aaca..037a09010ce4 100644
--- a/include/env/ti/mmc.env
+++ b/include/env/ti/mmc.env
@@ -16,7 +16,7 @@ importbootenv=echo Importing environment from mmc${mmcdev}
...;
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${name_fdt}
+get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
envboot=if mmc dev ${mmcdev}; then
if mmc rescan; then
echo SD/MMC found on device ${mmcdev};
--
2.45.1
[PATCH 0/3] Fix findfdt for j722s and am62p
findfdt wasn't being populated in these boards, add the code in evm.c for the same. Signed-off-by: Manorit Chawdhry --- Manorit Chawdhry (3): include: env: ti: mmc: Change name_fdt usage to fdtfile board: ti: am62p|j722s: Add ti_set_fdt_env for findfdt configs: am62p|j722s_a53: Add CONFIG_BOARD_LATE_INIT board/ti/am62px/evm.c| 9 + board/ti/j722s/evm.c | 9 + configs/am62px_evm_a53_defconfig | 1 + configs/j722s_evm_a53_defconfig | 1 + include/env/ti/mmc.env | 2 +- 5 files changed, 21 insertions(+), 1 deletion(-) --- base-commit: 899b088674b6905710ce546f0a8848662904852a change-id: 20240628-b4-upstream-streamline-platform-f0d7453637b2 Best regards, -- Manorit Chawdhry
Re: [PATCH 1/3] fit_dtb: relocate whole fit dtb image instead of selected dtb only
Hi Mikhail, On Thu, 27 Jun 2024 at 12:35, Mikhail Kshevetskiy wrote: > > U-Boot with linked fit dtb image may be loaded by a bootloader to > a low memory. On a later stage U-Boot will relocate itself and used > dtb. > > There is no problem until we decide to reselect dtb on a later stage. > In this case dtb placed in the low memory address may be selected. > But this data can be overwritted by flash reading or network file > transfer. Thus we will use damaged dtb. > > To fix it move the whole fit dtb image instead of just used dtb. > > Signed-off-by: Mikhail Kshevetskiy > --- > boot/boot_fit.c| 48 ++ > common/board_f.c | 34 > include/boot_fit.h | 8 > 3 files changed, 86 insertions(+), 4 deletions(-) > The current mechanism is in reloc_fdt() but it only happens during relocation. What is the later stage you refer to? Is it after relocation, or before? Regards, Simon
Re: [PATCH 13/14] Update u-boot.cfg to include CFG also
Hi Tom,
On Thu, 27 Jun 2024 at 15:42, Tom Rini wrote:
>
> On Thu, Jun 27, 2024 at 09:37:15AM +0100, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 26 Jun 2024 at 15:07, Tom Rini wrote:
> > >
> > > On Wed, Jun 26, 2024 at 09:00:41AM +0100, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 25 Jun 2024 at 15:14, Tom Rini wrote:
> > > > >
> > > > > On Tue, Jun 25, 2024 at 01:38:04PM +0100, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 24 Jun 2024 at 19:29, Tom Rini wrote:
> > > > > > >
> > > > > > > On Sun, Jun 23, 2024 at 02:30:32PM -0600, Simon Glass wrote:
> > > > > > >
> > > > > > > > Some configuration is now in variables with a CFG_ prefix. Add
> > > > > > > > these to
> > > > > > > > the .cfg file so that we can see everything in one place. Sort
> > > > > > > > the
> > > > > > > > options so they are easier to find and compare.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Changes in v2:
> > > > > > > > - Add new patch to update u-boot.cfg with CFG_... options
> > > > > > > >
> > > > > > > > scripts/Makefile.autoconf | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/scripts/Makefile.autoconf
> > > > > > > > b/scripts/Makefile.autoconf
> > > > > > > > index b42f9b525fe..65ff11ea508 100644
> > > > > > > > --- a/scripts/Makefile.autoconf
> > > > > > > > +++ b/scripts/Makefile.autoconf
> > > > > > > > @@ -71,7 +71,7 @@ quiet_cmd_autoconf = GEN $@
> > > > > > > > quiet_cmd_u_boot_cfg = CFG $@
> > > > > > > >cmd_u_boot_cfg = \
> > > > > > > > $(CPP) $(c_flags) $2 -DDO_DEPS_ONLY -dM include/config.h
> > > > > > > > > $@.tmp && { \
> > > > > > > > - grep 'define CONFIG_' $@.tmp | \
> > > > > > > > + egrep 'define (CONFIG_|CFG_)' $@.tmp | sort | \
> > > > > > > > sed '/define CONFIG_IS_ENABLED(/d;/define
> > > > > > > > CONFIG_IF_ENABLED_INT(/d;/define CONFIG_VAL(/d;' > $@; \
> > > > > > > > rm $@.tmp;
> > > > > > > > \
> > > > > > > > } || {
> > > > > > > > \
> > > > > > >
> > > > > > > I don't like this because whereas "CONFIG_" is enforced to be set
> > > > > > > only
> > > > > > > by Kconfig and so always all reliably set and found via a single
> > > > > > > header,
> > > > > > > CFG_ stuff is not.
> > > > > >
> > > > > > OK, so how are CFG_ options found? I hit this when trying to find
> > > > > > the
> > > > > > SDRAM size on rockchip 3399 and I could not find any way of figuring
> > > > > > it out.
> > > > >
> > > > > It's just another define, there's no uniformity to it. For some of the
> > > > > SDRAM values really we need some build time way to grab some
> > > > > information
> > > > > out of the default device tree.
> > > >
> > > > Can you give an example of a board that could use this? I looked at
> > > > the devicetree for chromebook_kevin and don't see a memory range in
> > > > ther.
> > >
> > > OK, wow, I didn't realize /memory was optional now. But indeed, I don't
> > > see it in the dtb file. That removes that option then, sadly.
> >
> > Well, we can still require it, so long as an error is produced if the
> > property is needed but does not exist.
>
> "We" who? I don't feel like we'll have a lot of traction with linux
> kernel folks in requiring /memory to be added to the dts files on
> however many platforms don't have it today because I'm going to guess
> it's added at run time, possibly by us, with the correct size and we'd
> be asking for statically adding things half-wrong like a lot of
> platforms used to do (and in turn rely on U-Boot to correct the size).
Hmm yes of course, the firmware is supposed to add these
properties...that's how it gets in there. So we need to stick with CFG
(and perhaps the RAM-size prober) for now.
Regards,
Simon
Re: [PATCH v2] spl: fit: List DTOs applied by SPL in U-Boot control DT
Hi Marek,
On Fri, 28 Jun 2024 at 03:48, Marek Vasut wrote:
>
> Insert /u-boot,spl-applied-dto- = property into the
> U-Boot control DT during SPL DTO application process. This can be used
> by user to inspect which DTOs got applied by the SPL and in which order
> from running U-Boot.
>
> Example:
> ```
> u-boot=> fdt addr $fdtcontroladdr && fdt list /
> Working FDT set to aee9aeb0
> / {
> u-boot,spl-applied-dto-fdt-dto-imx8mp-dhcom-pdk3-overlay-rev100 =
> <0x0005>;
> u-boot,spl-applied-dto-fdt-dto-imx8mp-dhcom-som-overlay-rev100 =
> <0x0004>;
> u-boot,spl-applied-dto-fdt-dto-imx8mp-dhcom-pdk-overlay-eth2xfast =
> <0x0003>;
> u-boot,spl-applied-dto-fdt-dto-imx8mp-dhcom-som-overlay-eth2xfast =
> <0x0002>;
> ...
> ```
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Manoj Sai
> Cc: Sean Anderson
> Cc: Simon Glass
> Cc: Suniel Mahesh
> Cc: Tom Rini
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> ---
> V2: - Expand the DT by one more byte to cater for trailing NUL byte
> - Update comment related to the expansion of DT
> - Flip the !ret conditional, which was incorrect and missed
> - Expand prefix to u-boot,spl-applied-dto-
> - Document the binding
> ---
> common/spl/spl_fit.c| 29 +++--
> doc/device-tree-bindings/config.txt | 11 +++
> 2 files changed, 38 insertions(+), 2 deletions(-)
Once this is figured out, can you extend test/image/spl_load_os.c to
test this code?
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 988125be008..0a6b5ea8212 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -363,6 +363,7 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> {
> struct spl_image_info image_info;
> int node, ret = 0, index = 0;
> + char dtoname[256];
>
> /*
> * Use the address following the image as target address for the
> @@ -448,9 +449,13 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
> if (ret < 0)
> break;
>
> - /* Make room in FDT for changes from the overlay */
> + /*
> +* Make room in FDT for changes from the overlay,
> +* the overlay name and the trailing NUL byte in
> +* that name.
> +*/
> ret = fdt_increase_size(spl_image->fdt_addr,
> - image_info.size);
> + image_info.size + strlen(str)
> + 1);
Oh and I missed the room for the property, sorry. It needs something like this:
ALIGN(strlen(str) + 1, 4) + 12 + 4
the first bit is the string-table size increase
12 is sizeof(struct fdt_property)
4 is the u32 size
Alos, is there any way to check that there is actually enough space to
increase the size?
> if (ret < 0)
> break;
>
> @@ -464,6 +469,26 @@ static int spl_fit_append_fdt(struct spl_image_info
> *spl_image,
>
> debug("%s: DT overlay %s applied\n", __func__,
> fit_get_name(ctx->fit, node, NULL));
> +
> + /*
> +* Insert /u-boot, = property into
> +* the U-Boot control DT. This can be used by user
> +* to inspect which DTOs got applied by the SPL from
> +* a running U-Boot.
> +*/
> + snprintf(dtoname, sizeof(dtoname),
> "u-boot,spl-applied-dto-%s", str);
> + ret = fdt_setprop_u32(spl_image->fdt_addr, 0, dtoname,
> + index);
> + if (ret) {
> + /*
> +* The DTO itself was applied, do not treat
> the
> +* insertion of /u-boot, as an error
> +* so the system can possibly boot somehow.
> +*/
> + debug("%s: DT overlay %s name not inserted
> into / node (%d)\n",
> + __func__,
> + fit_get_name(ctx->fit, node, NULL),
> ret);
> + }
> }
> free(tmpbuffer);
> if (ret)
> diff --git a/doc/device-tree-bindings/config.txt
> b/doc/device-tree-bindings/config.txt
> index f50c68bbdc3..7aa6d9a72c6 100644
> --- a/doc/device-tree-bindings/config.txt
> +++ b/doc/device-tree-bindings/config.txt
> @@ -95,6 +95,17 @@ rootdisk-offset (int)
> silent-console (int)
> If present and non-zero, the console is silenced by default on boot.
>
> +u-boot,spl-applied-dto-* (int)
> +
Re: [PATCH 3/3] dm: mmc: fix driver rebinding in the case of dtb reloading
Hi Mikhail,
On Thu, 27 Jun 2024 at 12:35, Mikhail Kshevetskiy
wrote:
>
> Rebinding of the mmc driver causes reregistration of block device.
> Thus second mmc device appears and the first becomes broken.
>
> Fix an issue by using already registered block device instead of
> registering a new one.
>
> Signed-off-by: Mikhail Kshevetskiy
> ---
> drivers/mmc/mmc-uclass.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 24170c59ecc..403d20dad53 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -420,11 +420,17 @@ int mmc_bind(struct udevice *dev, struct mmc *mmc,
> const struct mmc_config *cfg)
> /* Use the fixed index with aliases node's index */
> debug("%s: alias devnum=%d\n", __func__, dev_seq(dev));
>
> - ret = blk_create_devicef(dev, "mmc_blk", "blk", UCLASS_MMC,
> -dev_seq(dev), DEFAULT_BLKSZ, 0, );
> - if (ret) {
> - debug("Cannot create block device\n");
> - return ret;
> +#if CONFIG_IS_ENABLED(MULTI_DTB_FIT_RESCAN)
> + device_find_first_child_by_uclass(dev, UCLASS_BLK, );
> + if (!bdev)
> +#endif
> + {
> + ret = blk_create_devicef(dev, "mmc_blk", "blk", UCLASS_MMC,
> +dev_seq(dev), DEFAULT_BLKSZ, 0,
> );
> + if (ret) {
> + debug("Cannot create block device\n");
> + return ret;
> + }
> }
> bdesc = dev_get_uclass_plat(bdev);
> mmc->cfg = cfg;
> --
> 2.43.0
>
There is a mmc_unbind() function which is supposed to handle unbinding
the mmc block device Can you got into a little more detail as to what
is going wrong?
Regards,
Simon
Re: [PATCH] bootstd: cros: store partition type in an efi_guid_t
Hi,
On Thu, 27 Jun 2024 at 20:28, Heinrich Schuchardt wrote:
>
>
>
> Am 27. Juni 2024 19:06:29 MESZ schrieb "Vincent Stehlé"
> :
> >The scan_part() function uses a struct uuid to store the little-endian
> >partition type GUID, but this structure should be used only to contain a
> >big-endian UUID. Use an efi_guid_t instead.
> >
> >Signed-off-by: Vincent Stehlé
> >Cc: Simon Glass
> >Cc: Tom Rini
> >---
> > boot/bootmeth_cros.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
> >index f015f2e1c75..1f83c14aeab 100644
> >--- a/boot/bootmeth_cros.c
> >+++ b/boot/bootmeth_cros.c
> >@@ -148,7 +148,7 @@ static int scan_part(struct udevice *blk, int partnum,
> > {
> > struct blk_desc *desc = dev_get_uclass_plat(blk);
> > struct vb2_keyblock *hdr;
> >- struct uuid type;
> >+ efi_guid_t type;
>
> Does Chrome OS only support GPT partitioning?
Indeed.
>
> > ulong num_blks;
> > int ret;
> >
> >@@ -161,7 +161,7 @@ static int scan_part(struct udevice *blk, int partnum,
> >
> > /* Check for kernel partition type */
> > log_debug("part %x: type=%s\n", partnum, info->type_guid);
> >- if (uuid_str_to_bin(info->type_guid, (u8 *),
> >UUID_STR_FORMAT_GUID))
> >+ if (uuid_str_to_bin(info->type_guid, type.b, UUID_STR_FORMAT_GUID))
> > return log_msg_ret("typ", -EINVAL);
>
> struct disk_partition containing a string which is only needed in the CLI
> instead of the 16 byte GUID was a bad idea to start with. Shouldn't we
> replace it or add least add a GUID field instead of first converting to
> string and than back to GUID?
Yes I agree, it would be nice to fix that.
>
> >
> > if (memcmp(_kern_type, , sizeof(type)))
>
> You could use the guidcmp() macro here.
Regards,
Simon
Re: [PATCH 1/3] net: give a different name to rtl8169 interfaces
Hi Quentin, Le 27/06/2024 à 14:27, Quentin Schulz a écrit : Hi Etienne, On 6/25/24 1:42 PM, Etienne Dublé wrote: Hello, Le 25/06/2024 à 12:25, Dragan Simic a écrit : Another option may be to name them "rtl8169@", with "" reflecting the PCI region address (so it is unique and stable). What do you think? I guess that's one way, I'm also wondering how systemd renames those to be unique but stable on the same machine, maybe we could take some inspiration from them for that? Systemd also allows renaming of network interfaces using some rules predefined by the user, so there's also the possibility to rename the interfaces in U-Boot to ethernet0 and ethernet1, using fixed rules that would be based on the PCI region address. OK but the renaming occurs in the rtl8169 driver, that is used by several boards, whereas the PCI region addresses come from the device-tree, so they differ from board to board. I'm of the opinion that we only care about stability for the same product, not for different products with the same Ethernet PHY on different SoCs/products. I agree, but my comment was more about how u-boot code is structured (network interface naming is done in the driver, and the driver code should probably not include board-specific code, so we are quite limited). In theory we could just name the interfaces ethernet0, ethernet1, etc., by using the PCI region address as the sort key, and maybe this is what Dragan was suggesting. But in practice when driver->bind() is called we don't know if more interfaces will be discovered next; and renaming the 1st interface when the 2nd one is discovered with a lower address is probably not the kind of code u-boot code experts would like... Cheers, Etienne Dublé -- Etienne Dublé CNRS / LIG - Bâtiment IMAG 700 avenue Centrale - 38401 St Martin d'Hères Bureau 426 - Tel 0457421431
Re: [PATCH v1] board: mpfs_icicle: implement board_fdt_blob_setup()
On Fri, Jun 28, 2024 at 08:53:11AM +0300, Ilias Apalodimas wrote: > On Thu, 27 Jun 2024 at 23:27, Conor Dooley wrote: > > On Thu, Jun 27, 2024 at 11:50:33AM +0100, Simon Glass wrote: > > > On Thu, 27 Jun 2024 at 10:38, Conor Dooley > > > wrote: > > > > On Thu, Jun 27, 2024 at 09:36:49AM +0100, Simon Glass wrote: > > > > I think the only way a bloblist could work is if it was created at build > > > > time and linked into the firmware, since the on-disk format seems pretty > > > > minimal. Is there tooling for generating a bloblist at build time that I > > > > could use to check whether or not a bloblist is viable? > > > > I'd also have to investigate how that would interact with OpenSBI, since > > > > it's integrated into the firmware and involved with loading U-Boot. > > > > > > There is not such a tool, but it would be easy enough to write. If you > > > think that would help, I could give it a try. > > > > I mean I could also just do it myself, I just wanted to know if it > > existed, since that'd make investigating this pretty straightforward to > > do. > > Someone is already working on it. > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/29253 > this will help! Eww, gerrit. Thanks for the link. > > Either way, the firmware already is capable of doing this with a > > devicetree blob, so I figure even if we manage to get bloblist stuff > > going, there's little harm in supporting what's already there? > > There isn't, but OTOH the bloblist support is already in u-boot. Devicetree in a1 support is already in U-Boot too, it's already been nicely placed in gd->arch.firmware_fdt_addr by the arch code :) > I would prefer to try that out first. Up to you If it is up to me, I am going to say go with what I have already done, as it's much easier to update U-Boot on a disk that you can write to from Linux than it is to change the firmware in envm and something functional already exists. signature.asc Description: PGP signature
Re: [PATCH v1] board: mpfs_icicle: implement board_fdt_blob_setup()
On Fri, Jun 28, 2024 at 07:22:35AM +0100, Simon Glass wrote: > On Thu, 27 Jun 2024 at 21:27, Conor Dooley wrote: > > OK, thanks for all the details. I suppose, to me, 128KB does not sound > that constrained :-) But I can see that messing with a bloblist can > add code. A static tool would help with that. It's all relative - when libsbi.a is > 3 MiB 128KiB is a problem! signature.asc Description: PGP signature
Re: [PATCH v1] board: mpfs_icicle: implement board_fdt_blob_setup()
Hi Conor,
On Thu, 27 Jun 2024 at 21:27, Conor Dooley wrote:
>
> On Thu, Jun 27, 2024 at 11:50:33AM +0100, Simon Glass wrote:
> > On Thu, 27 Jun 2024 at 10:38, Conor Dooley
> > wrote:
> > > On Thu, Jun 27, 2024 at 09:36:49AM +0100, Simon Glass wrote:
> > > > On Tue, 25 Jun 2024 at 15:34, Tom Rini wrote:
> > > > > On Tue, Jun 25, 2024 at 10:08:06AM +0100, Conor Dooley wrote:
> > > > > > The firmware on the Icicle is capable of providing a devicetree in
> > > > > > a1 to
> > > > > > U-Boot, but until now the devicetree has been packaged in a
> > > > > > "payload" [1]
> > > > > > alongside U-Boot (or other bootloaders/RTOSes) and appended to the
> > > > > > image.
> > > > > > The address of this appended devicetree is placed in a1 by the
> > > > > > firmware.
> > > > > > This meant that the mechanism used by OF_SEPARATE to locate the
> > > > > > devicetree at the end of the image would pick up the one provided
> > > > > > by the
> > > > > > firmware when u-boot-nodtb.bin was in the payload and U-Boot's
> > > > > > devicetree
> > > > > > when u-boot.bin was.
> > > > > >
> > > > > > The firmware is now going to be capable of providing a minimal
> > > > > > devicetree
> > > > > > (quite cut down due to severe space constraints), but this
> > > > > > devicetree is
> > > > > > linked into the firmware that runs out of the L2 rather than at the
> > > > > > end
> > > > > > of the U-Boot image. Implement board_fdt_blob_setup() so that this
> > > > > > devicetree can be optionally used, and the devicetree provided in
> > > > > > the
> > > > > > "payload" can be used without relying on "happening" to implement
> > > > > > the
> > > > > > same strategy as OF_SEPARATE expects in combination with
> > > > > > u-boot-nodtb.bin. Unlike other RISC-V boards, the firmware provided
> > > > > > devicetree is only used when OF_BOARD is set, so that the almost
> > > > > > certainly more complete devicetree in U-Boot will be used unless
> > > > > > explicitly requested otherwise.
> > > > > >
> > > > > > Link:
> > > > > > https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator/README.md
> > > > > > [1]
> > > > > > Signed-off-by: Conor Dooley
> > > > > > ---
> > > > > > CC: Ivan Griffin
> > > > > > CC: Padmarao Begari
> > > > > > CC: Cyril Jean
> > > > > > CC: Tom Rini
> > > > > > CC: Conor Dooley
> > > > > > CC: u-boot@lists.denx.de
> > > > > > ---
> > > > > > board/microchip/mpfs_icicle/mpfs_icicle.c | 19 +++
> > > > > > 1 file changed, 19 insertions(+)
> > > > > >
> > > > > > diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c
> > > > > > b/board/microchip/mpfs_icicle/mpfs_icicle.c
> > > > > > index 4d7d843dfa3..2c1f7175f0e 100644
> > > > > > --- a/board/microchip/mpfs_icicle/mpfs_icicle.c
> > > > > > +++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
> > > > > > @@ -9,6 +9,7 @@
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > +#include
> > > > > >
> > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > >
> > > > > > @@ -50,6 +51,24 @@ static void read_device_serial_number(u8
> > > > > > *response, u8 response_size)
> > > > > > response_buf[idx] = readb(MPFS_SYS_SERVICE_MAILBOX +
> > > > > > idx);
> > > > > > }
> > > > > >
> > > > > > +void *board_fdt_blob_setup(int *err)
> > > > > > +{
> > > > > > + *err = 0;
> > > > > > + /*
> > > > > > + * The devicetree provided by the previous stage is very
> > > > > > minimal due to
> > > > > > + * severe space constraints. The firmware performs no fixups
> > > > > > etc.
> > > > > > + * U-Boot, if providing a devicetree, almost certainly has a
> > > > > > better
> > > > > > + * more complete one than the firmware so that provided by
> > > > > > the firmware
> > > > > > + * is ignored for OF_SEPARATE.
> > > > > > + */
> > > > > > + if (IS_ENABLED(CONFIG_OF_BOARD)) {
> > > > > > + if (gd->arch.firmware_fdt_addr)
> > > > > > + return (ulong
> > > > > > *)(uintptr_t)gd->arch.firmware_fdt_addr;
> > > > > > + }
> > > > > > +
> > > > > > + return (ulong *)_end;
> > > > > > +}
> > > > > > +
> > > > > > int board_init(void)
> > > > > > {
> > > > > > /* For now nothing to do here. */
> > > > >
> > > > > I'm adding in Simon and Ilias as this touches on one of those frequent
> > > > > topics about how device trees can/should be passed along to us.
> > > >
> > > > The only thing I can think of is implementing bloblist in the a1 (?)
> > > > firmware, then passing the DT in that.
> > >
> > > a1 is the register that is used on riscv to pass the dtb, I think the
> > > corresponding thing on arm64 is x0.
> > >
> > > Re-reading the firware handoff spec, it's difficult to see what benefits
> > > it actually provides us when we only ever have a single dtb which the
> > > firmware does not interact with/use.
> > > We are super space constrained in the firmware even carving out 4.5 KiB
> > > for a
