Re: [PATCH 05/11] i2c: mediatek: add support for optional arb and pmic clock
Hello Christian, On 05.06.24 21:02, Christian Marangi wrote: Add support for optional arb and pmic clock for i2c provided in upstream linux DTSI. Signed-off-by: Christian Marangi --- drivers/i2c/mtk_i2c.c | 30 ++ 1 file changed, 30 insertions(+) Reviewed-by: Heiko Schocher bye, Heiko -- -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 1/1] usb: Assimilate usb_get_descriptor() to linux
On 6/4/24 12:18 PM, Philip Oberfichtner wrote: Before this commit, usb_get_descriptor() failed for some flakey USB devices. We hereby adopt the more robust linux implementation [1]. For instance, for the "Alcor Micro Corp. Flash Drive" (VID 0x058f, PID 0x6387), the following behavior occurs from time to time: => usb start starting USB... Bus xhci_pci: Register 1840 NbrPorts 16 Starting the controller USB XHCI 1.20 scanning bus xhci_pci for devices... usb_new_device: Cannot read configuration, skipping device 058f:6387 Signed-off-by: Philip Oberfichtner [1] From a38297e3fb012 (Linux 6.9), see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/core/message.c?h=v6.9#n781 Reviewed-by: Marek Vasut Thanks
Allwinner S3: Can't boot from eMMC
Hi, I have been trying to get u-boot booting from internal 4GB eMMC on a custom Allwinner S3 based board for a couple of months, and I'm pretty stuck. Where I've got to: * It boots from SD Card (mmcblk0) no problem. * U-Boot SPL boots fine from eMMC (mmblk2) * SPL tries to boot U-Boot and it gives this: U-Boot SPL 2021.04-rc1 (May 09 2024 - 23:08:06 +0100) DRAM: 128 MiB Trying to boot from MMC2 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### * However, if I boot UBoot using the SD card and probe mmc2 it works: => mmc dev 2 switch to partitions #0, OK mmc2 is current device => info Unknown command 'info' - try 'help' => mmc info Device: mmc@1c11000 Manufacturer ID: 66 OEM: 2346 Name: CS032 Bus Speed: 5000 Mode: SD High Speed (50MHz) Rd Block Len: 512 SD version 2.0 High Capacity: Yes Capacity: 3.6 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes * In fact if I insert an SD card it will boot from it, but sometimes boot linux from the eMMC rather than the SD card. So it is just SPL that isn't finding the EMMC. I'm using the same DTS for both, relevant U-Boot compilation options are (full config attached): CONFIG_MMC_SUNXI=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_SPL_MMC=y Finally here is a successful SD Card boot: U-Boot SPL 2022.07-armbian (Apr 08 2023 - 21:19:01 +) DRAM: 128 MiB Trying to boot from MMC1 U-Boot 2022.07-armbian (Apr 08 2023 - 21:19:01 +) Allwinner Technology CPU: Allwinner V3s (SUN8I 1681) Model: OpenHD X20 Dev DRAM: 128 MiB Core: 45 devices, 15 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c1: 1, mmc@1c11000: 2 Loading Environment from FAT... Unable to use mmc 0:1... In:serial@1c28000 Out: serial@1c28000 Err: serial@1c28000 Net: No ethernet found. Autoboot in 1 seconds, press to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 4060 bytes read in 3 ms (1.3 MiB/s) ## Executing script at 4190 U-boot loaded from SD Boot script loaded from mmc 224 bytes read in 3 ms (72.3 KiB/s) 5021667 bytes read in 210 ms (22.8 MiB/s) 3249856 bytes read in 151 ms (20.5 MiB/s) Found mainline kernel configuration Loading dts:/boot/dtb/sun8i-s3-openhd-x20dev.dtb 10609 bytes read in 5 ms (2 MiB/s) Failed to load '/boot/dtb/overlay/sun8i-v3s-fixup.scr' Kernel image @ 0x4100 [ 0x00 - 0x3196c0 ] ## Loading init Ramdisk from Legacy Image at 41c0 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:5021603 Bytes = 4.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 4180 Booting using the fdt blob at 0x4180 Loading Ramdisk to 42936000, end 42dfffa3 ... OK Loading Device Tree to 428cb000, end 42935fff ... OK Has anyone got any thoughts about what might be wrong? Thank you u-boot-config Description: Binary data
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
On Wed, Jun 05, 2024 at 02:23:21PM -0600, Tom Rini wrote: > On Wed, Jun 05, 2024 at 09:21:32PM +0200, Christian Marangi wrote: > > > This series expand the STATUS LED framework with a new color > > and a big new feature. One thing that many device need is a way > > to communicate to the user that the device is actually doing > > something. > > > > This is especially useful for recovery steps where an > > user (for example) insert an USB drive, keep a button pressed > > and the device autorecover. > > > > There is currently no way to signal the user externally that > > the bootloader is processing/recoverying aside from setting > > a LED on. > > > > A solid LED on is not enough and won't actually signal any > > kind of progress. > > Solution is the good old blinking LED but uboot doesn't > > suggest (and support) interrupts and almost all the LED > > are usually GPIO LED that doesn't support HW blink. > > > > To fix this and handle the problem of device not supporting > > HW blink, expand the STATUS LED framework with new API. > > > > We introduce a new config LED_STATUS_ACTIVITY, that similar > > to the RED, GREEN and others, takes the LED ID set in > > the LED_STATUS config and is used as the global LED for activity > > operations. > > > > We add status_led_activity() that simulate software blink. > > Any function that signal activity will call this function. > > At each call a counter is increased. When the counter reach > > the freq value, the LED is toggled simulating a blink and > > the counter is zeroed. When the counter reach the freq value > > again, the LED is toggled again and so on... > > > > Call to this function is added to the usual operation for > > recovery. Currently added to tftp traffic and mtd spi and > > nand write and erase operation. > > > > This also contains a big fixup for the gpio_led driver that > > currently deviates from the Documentation and make the > > coloured status led feature unusable. > > Thanks for the work here, this is quite interesting. My only real > feedback is, can you please rewrite doc/README.LED as doc/api/led.rst > (and add it to the index), and then document your new functionality > there as well? > Yes totally, actually my bad for not updating the Documentation. Honestly I really wanted an early feedback on this for the implementation. Also I love how it's very easy to add this activity thing also in other cmd or other task. -- Ansuel
[PATCH] arm: mvebu: env_sf_get_env_addr() missing check for CONFIG_ENV_IS_IN_SPI_FLASH
The CONFIG_ENV_OFFSET is undefined if boot device is UART
(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART), or envs are not stored on flash
(CONFIG_ENV_IS_NOWHERE). Check for CONFIG_ENV_IS_IN_SPI_FLASH as the first
condition to determine whether env_sf_get_env_addr() should be provided.
Signed-off-by: Tony Dinh
---
arch/arm/mach-mvebu/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 7c62a5dbb6..6dd729ae6e 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -36,7 +36,7 @@ static const struct mbus_win windows[] = {
};
/* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */
-#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
+#if defined(CONFIG_ENV_IS_IN_SPI_FLASH) && CONFIG_ENV_SPI_BUS == 0 &&
CONFIG_ENV_SPI_CS == 0 && \
CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
void *env_sf_get_env_addr(void)
{
--
2.39.2
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
On Wed, Jun 05, 2024 at 09:21:32PM +0200, Christian Marangi wrote: > This series expand the STATUS LED framework with a new color > and a big new feature. One thing that many device need is a way > to communicate to the user that the device is actually doing > something. > > This is especially useful for recovery steps where an > user (for example) insert an USB drive, keep a button pressed > and the device autorecover. > > There is currently no way to signal the user externally that > the bootloader is processing/recoverying aside from setting > a LED on. > > A solid LED on is not enough and won't actually signal any > kind of progress. > Solution is the good old blinking LED but uboot doesn't > suggest (and support) interrupts and almost all the LED > are usually GPIO LED that doesn't support HW blink. > > To fix this and handle the problem of device not supporting > HW blink, expand the STATUS LED framework with new API. > > We introduce a new config LED_STATUS_ACTIVITY, that similar > to the RED, GREEN and others, takes the LED ID set in > the LED_STATUS config and is used as the global LED for activity > operations. > > We add status_led_activity() that simulate software blink. > Any function that signal activity will call this function. > At each call a counter is increased. When the counter reach > the freq value, the LED is toggled simulating a blink and > the counter is zeroed. When the counter reach the freq value > again, the LED is toggled again and so on... > > Call to this function is added to the usual operation for > recovery. Currently added to tftp traffic and mtd spi and > nand write and erase operation. > > This also contains a big fixup for the gpio_led driver that > currently deviates from the Documentation and make the > coloured status led feature unusable. Thanks for the work here, this is quite interesting. My only real feedback is, can you please rewrite doc/README.LED as doc/api/led.rst (and add it to the index), and then document your new functionality there as well? -- Tom signature.asc Description: PGP signature
Re: [PATCH 9/9] Revert "arm: am335x: Enable SPL_OF_CONTROL on some configs"
On Wed, Jun 05, 2024 at 02:08:54PM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 5 Jun 2024 at 08:42, Tom Rini wrote: > > > > On Tue, Jun 04, 2024 at 09:25:21PM -0600, Simon Glass wrote: > > > > > This is a partial revert which makes boneblack_vboot boot again. > > > > > > This reverts commit f4b64e9736e73ceec14d51600bed9a8ac48f9fe8. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > configs/am335x_boneblack_vboot_defconfig | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig > > > b/configs/am335x_boneblack_vboot_defconfig > > > index d473a1a793b..3ec4abddd77 100644 > > > --- a/configs/am335x_boneblack_vboot_defconfig > > > +++ b/configs/am335x_boneblack_vboot_defconfig > > > @@ -40,7 +40,6 @@ CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > > > # CONFIG_CMD_SETEXPR is not set > > > CONFIG_BOOTP_DNS2=y > > > CONFIG_OF_CONTROL=y > > > -CONFIG_SPL_OF_CONTROL=y > > > CONFIG_ENV_OVERWRITE=y > > > CONFIG_ENV_IS_IN_MMC=y > > > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > > > > So, this change was a while ago. But I did it because some of the > > drivers, tho I forget which ones exactly, really were not functional > > without SPL_OF_CONTROL enabled. That said, does am335x_evm_defconfig > > work in your configuration? I think we have to keep am335x_evm_spiboot > > because it's so radically different from how the rest of the possible > > options boot, but I'm not sure we need a vboot defconfig? Or if we do, > > it should be updated to use the #include logic these days. > > I don't actually have an am335x_evm board, which is why I'm using bbb. > We only have the vboot version, since the non-vboot was removed a > while back. > > In any case, with this patch, bbb boots again. Yes, the am335x_evm build supports all of the TI (or associated, like beagleboard) platforms. Please give it a try. -- Tom signature.asc Description: PGP signature
Re: [PATCH 9/9] Revert "arm: am335x: Enable SPL_OF_CONTROL on some configs"
Hi Tom, On Wed, 5 Jun 2024 at 08:42, Tom Rini wrote: > > On Tue, Jun 04, 2024 at 09:25:21PM -0600, Simon Glass wrote: > > > This is a partial revert which makes boneblack_vboot boot again. > > > > This reverts commit f4b64e9736e73ceec14d51600bed9a8ac48f9fe8. > > > > Signed-off-by: Simon Glass > > --- > > > > configs/am335x_boneblack_vboot_defconfig | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig > > b/configs/am335x_boneblack_vboot_defconfig > > index d473a1a793b..3ec4abddd77 100644 > > --- a/configs/am335x_boneblack_vboot_defconfig > > +++ b/configs/am335x_boneblack_vboot_defconfig > > @@ -40,7 +40,6 @@ CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > > # CONFIG_CMD_SETEXPR is not set > > CONFIG_BOOTP_DNS2=y > > CONFIG_OF_CONTROL=y > > -CONFIG_SPL_OF_CONTROL=y > > CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_IS_IN_MMC=y > > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > > So, this change was a while ago. But I did it because some of the > drivers, tho I forget which ones exactly, really were not functional > without SPL_OF_CONTROL enabled. That said, does am335x_evm_defconfig > work in your configuration? I think we have to keep am335x_evm_spiboot > because it's so radically different from how the rest of the possible > options boot, but I'm not sure we need a vboot defconfig? Or if we do, > it should be updated to use the #include logic these days. I don't actually have an am335x_evm board, which is why I'm using bbb. We only have the vboot version, since the non-vboot was removed a while back. In any case, with this patch, bbb boots again. Regards, Simon
[PATCH 7/7] ubi: implement support for LED status activity
Implement support for LED status activity. If the feature is enabled,
make the defined ACTIVITY LED to signal ubi write operation.
Signed-off-by: Christian Marangi
---
cmd/ubi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/cmd/ubi.c b/cmd/ubi.c
index 0a6a80bdd10..c300f1dc853 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -417,7 +418,21 @@ int ubi_volume_begin_write(char *volume, void *buf, size_t
size,
int ubi_volume_write(char *volume, void *buf, size_t size)
{
- return ubi_volume_begin_write(volume, buf, size, size);
+ int ret;
+
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_BLINKING);
+#endif
+
+ ret = ubi_volume_begin_write(volume, buf, size, size);
+
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_OFF);
+#endif
+
+ return ret;
}
int ubi_volume_read(char *volume, char *buf, size_t size)
--
2.43.0
[PATCH 6/7] mtd: implement support for LED status activity
Implement support for LED status activity. If the feature is enabled,
make the defined ACTIVITY LED to signal mtd write or erase operations.
Signed-off-by: Christian Marangi
---
cmd/mtd.c | 23 +++
drivers/mtd/nand/core.c| 4
drivers/mtd/nand/spi/core.c| 5 +
drivers/mtd/spi/spi-nor-core.c | 9 +
4 files changed, 41 insertions(+)
diff --git a/cmd/mtd.c b/cmd/mtd.c
index 9189f45cabd..aa0a41ac3bb 100644
--- a/cmd/mtd.c
+++ b/cmd/mtd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#if CONFIG_IS_ENABLED(CMD_MTD_OTP)
#include
#endif
@@ -559,6 +560,12 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
argc,
while (mtd_block_isbad(mtd, off))
off += mtd->erasesize;
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ if (!read)
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_BLINKING);
+#endif
+
/* Loop over the pages to do the actual read/write */
while (remaining) {
/* Skip the block if it is bad */
@@ -586,6 +593,12 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
argc,
io_op.oobbuf += io_op.oobretlen;
}
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ if (!read)
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_OFF);
+#endif
+
if (!ret && dump)
mtd_dump_device_buf(mtd, start_off, buf, len, woob);
@@ -653,6 +666,11 @@ static int do_mtd_erase(struct cmd_tbl *cmdtp, int flag,
int argc,
erase_op.addr = off;
erase_op.len = mtd->erasesize;
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_ON);
+#endif
+
while (len) {
if (!scrub) {
ret = mtd_block_isbad(mtd, erase_op.addr);
@@ -681,6 +699,11 @@ static int do_mtd_erase(struct cmd_tbl *cmdtp, int flag,
int argc,
erase_op.addr += mtd->erasesize;
}
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_OFF);
+#endif
+
if (ret && ret != -EIO)
ret = CMD_RET_FAILURE;
else
diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index f6d9c584f78..631a4c83e04 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/**
* nanddev_isbad() - Check if a block is bad
@@ -182,6 +183,9 @@ int nanddev_mtd_erase(struct mtd_info *mtd, struct
erase_info *einfo)
}
nanddev_pos_next_eraseblock(nand, );
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
+#endif
}
return 0;
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 62c28aa422d..86d7ed9e9d0 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#endif
/* SPI NAND index visible in MTD names */
@@ -657,6 +658,10 @@ static int spinand_mtd_write(struct mtd_info *mtd, loff_t
to,
ops->retlen += iter.req.datalen;
ops->oobretlen += iter.req.ooblen;
+
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
+#endif
}
#ifndef __UBOOT__
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index f86003ca8c0..1e7436079e9 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -32,6 +32,8 @@
#include
#include
+#include
+
#include "sf_internal.h"
/* Define max times to check status register before we give up. */
@@ -1039,6 +1041,10 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
ret = spi_nor_wait_till_ready(nor);
if (ret)
goto erase_err;
+
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
+#endif
}
addr_known = false;
@@ -1816,6 +1822,9 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to,
size_t len,
goto write_err;
*retlen += written;
i += written;
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
+#endif
}
write_err:
--
2.43.0
[PATCH 5/7] tftp: implement support for LED status activity
Implement support for LED status activity. If the feature is enabled,
make the defined ACTIVITY LED to signal traffic.
Signed-off-by: Christian Marangi
---
net/tftp.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/tftp.c b/net/tftp.c
index 2e335413492..07dea321bb4 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -19,6 +19,7 @@
#include
#include
#include "bootp.h"
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -193,6 +194,10 @@ static void new_transfer(void)
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_BLINKING);
+#endif
}
#ifdef CONFIG_CMD_TFTPPUT
@@ -228,6 +233,10 @@ static void show_block_marker(void)
{
ulong pos;
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
#ifdef CONFIG_TFTP_TSIZE
if (tftp_tsize) {
pos = tftp_cur_block * tftp_block_size +
@@ -290,6 +299,9 @@ static void tftp_complete(void)
/* Print hash marks for the last packet received */
while (tftp_tsize && tftp_tsize_num_hash < 49) {
putc('#');
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
+#endif
tftp_tsize_num_hash++;
}
puts(" ");
@@ -302,6 +314,10 @@ static void tftp_complete(void)
time_start * 1000, "/s");
}
puts("\ndone\n");
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_set(CONFIG_LED_STATUS_ACTIVITY,
+ CONFIG_LED_STATUS_OFF);
+#endif
if (!tftp_put_active)
efi_set_bootdev("Net", "", tftp_filename,
map_sysmem(tftp_load_addr, 0),
--
2.43.0
[PATCH 4/7] led: status_led: add new activity LED config and functions
Add a new activity LED config and additional functions to implement a
simple software blink feature to signal activity of any kind.
Usual activity might be a file transfer with TFTP, a flash write...
Driver will call status_led_activity on each activity and LED will be
toggled based on the defined FREQ config value.
Signed-off-by: Christian Marangi
---
drivers/led/Kconfig | 15 +++
drivers/misc/status_led.c | 25 -
include/status_led.h | 1 +
3 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 6c4f02d71f2..8eaa74bdd27 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -359,6 +359,21 @@ config LED_STATUS_BOOT
endif # LED_STATUS_BOOT_ENABLE
+config LED_STATUS_ACTIVITY_ENABLE
+ bool "Enable BOOT LED"
+ help
+ Enable to turn an LED on when the board is doing some
+ activity (flash write, file download).
+
+if LED_STATUS_ACTIVITY_ENABLE
+
+config LED_STATUS_ACTIVITY
+ int "LED to light when the board is doing some activity"
+ help
+ Valid enabled LED device number.
+
+endif # LED_STATUS_ACTIVITY_ENABLE
+
config LED_STATUS_RED_ENABLE
bool "Enable red LED"
help
diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c
index 93bfb410662..9490e1d7341 100644
--- a/drivers/misc/status_led.c
+++ b/drivers/misc/status_led.c
@@ -82,6 +82,14 @@ void status_led_init(void)
status_led_init_done = 1;
}
+static void status_led_sw_blink(led_dev_t *ld)
+{
+ if (++ld->cnt >= ld->period) {
+ __led_toggle(ld->mask);
+ ld->cnt -= ld->period;
+ }
+}
+
void status_led_tick(ulong timestamp)
{
led_dev_t *ld;
@@ -95,11 +103,7 @@ void status_led_tick(ulong timestamp)
if (ld->state != CONFIG_LED_STATUS_BLINKING)
continue;
- if (++ld->cnt >= ld->period) {
- __led_toggle (ld->mask);
- ld->cnt -= ld->period;
- }
-
+ status_led_sw_blink(ld);
}
}
@@ -140,3 +144,14 @@ void status_led_toggle(int led)
__led_toggle(ld->mask);
}
+
+void status_led_activity(int led)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
+
+ status_led_sw_blink(ld);
+}
diff --git a/include/status_led.h b/include/status_led.h
index fe0c84fb4b4..037bad159c2 100644
--- a/include/status_led.h
+++ b/include/status_led.h
@@ -39,6 +39,7 @@ void status_led_init(void);
void status_led_tick(unsigned long timestamp);
void status_led_set(int led, int state);
void status_led_toggle(int led);
+void status_led_activity(int led);
/* MVS v1 **/
#if (defined(CONFIG_MVS) && CONFIG_MVS < 2)
--
2.43.0
[PATCH 3/7] led: status_led: add function to toggle a status LED
Add function to toggle a status LED by using the status LED ID reference
configs.
Signed-off-by: Christian Marangi
---
drivers/misc/status_led.c | 28 +++-
include/status_led.h | 1 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c
index a6e9c03a02e..93bfb410662 100644
--- a/drivers/misc/status_led.c
+++ b/drivers/misc/status_led.c
@@ -103,17 +103,24 @@ void status_led_tick(ulong timestamp)
}
}
-void status_led_set(int led, int state)
+static led_dev_t *status_get_led_dev(int led)
{
- led_dev_t *ld;
-
if (led < 0 || led >= MAX_LED_DEV)
- return;
+ return NULL;
if (!status_led_init_done)
status_led_init();
- ld = _dev[led];
+ return _dev[led];
+}
+
+void status_led_set(int led, int state)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
ld->state = state;
if (state == CONFIG_LED_STATUS_BLINKING) {
@@ -122,3 +129,14 @@ void status_led_set(int led, int state)
}
__led_set (ld->mask, state);
}
+
+void status_led_toggle(int led)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
+
+ __led_toggle(ld->mask);
+}
diff --git a/include/status_led.h b/include/status_led.h
index 5ce4522b029..fe0c84fb4b4 100644
--- a/include/status_led.h
+++ b/include/status_led.h
@@ -38,6 +38,7 @@
void status_led_init(void);
void status_led_tick(unsigned long timestamp);
void status_led_set(int led, int state);
+void status_led_toggle(int led);
/* MVS v1 **/
#if (defined(CONFIG_MVS) && CONFIG_MVS < 2)
--
2.43.0
[PATCH 2/7] led: status_led: add support for white LED colour
Add support for white LED colour present on many devices.
Signed-off-by: Christian Marangi
---
cmd/legacy_led.c| 6 ++
common/board_f.c| 2 ++
drivers/led/Kconfig | 14 ++
drivers/misc/gpio_led.c | 12
include/status_led.h| 4
5 files changed, 38 insertions(+)
diff --git a/cmd/legacy_led.c b/cmd/legacy_led.c
index 5256255f052..40dbc05a651 100644
--- a/cmd/legacy_led.c
+++ b/cmd/legacy_led.c
@@ -57,6 +57,9 @@ static const led_tbl_t led_commands[] = {
#endif
#ifdef CONFIG_LED_STATUS_BLUE
{ "blue", CONFIG_LED_STATUS_BLUE, blue_led_off, blue_led_on, NULL },
+#endif
+#ifdef CONFIG_LED_STATUS_WHITE
+ { "white", CONFIG_LED_STATUS_WHITE, white_led_off, white_led_on, NULL },
#endif
{ NULL, 0, NULL, NULL, NULL }
};
@@ -180,6 +183,9 @@ U_BOOT_CMD(
#endif
#ifdef CONFIG_LED_STATUS_BLUE
"blue|"
+#endif
+#ifdef CONFIG_LED_STATUS_WHITE
+ "white|"
#endif
"all] [on|off|toggle|blink] [blink-freq in ms]",
"[led_name] [on|off|toggle|blink] sets or clears led(s)"
diff --git a/common/board_f.c b/common/board_f.c
index 039d6d712d0..54e2009339e 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -72,6 +72,8 @@ __weak void yellow_led_on(void) {}
__weak void yellow_led_off(void) {}
__weak void blue_led_on(void) {}
__weak void blue_led_off(void) {}
+__weak void white_led_on(void) {}
+__weak void white_led_off(void) {}
/*
* Why is gd allocated a register? Prior to reloc it might be better to
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 9837960198d..6c4f02d71f2 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -415,6 +415,20 @@ config LED_STATUS_GREEN
endif # LED_STATUS_GREEN_ENABLE
+config LED_STATUS_WHITE_ENABLE
+ bool "Enable white LED"
+ help
+ Enable white status LED.
+
+if LED_STATUS_WHITE_ENABLE
+
+config LED_STATUS_WHITE
+ int "White LED identification"
+ help
+ Valid enabled LED device number (0-5).
+
+endif # LED_STATUS_WHITE_ENABLE
+
config LED_STATUS_CMD
bool "Enable status LED commands"
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index 0f3682e1465..de84c206b6b 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -112,3 +112,15 @@ void blue_led_off(void)
__led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_OFF);
}
#endif
+
+#ifdef CONFIG_LED_STATUS_WHITE
+void white_led_on(void)
+{
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_WHITE), CONFIG_LED_STATUS_ON);
+}
+
+void white_led_off(void)
+{
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_WHITE), CONFIG_LED_STATUS_OFF);
+}
+#endif
diff --git a/include/status_led.h b/include/status_led.h
index 6707ab1d29d..5ce4522b029 100644
--- a/include/status_led.h
+++ b/include/status_led.h
@@ -87,6 +87,8 @@ void yellow_led_on(void);
void yellow_led_off(void);
void blue_led_on(void);
void blue_led_off(void);
+void white_led_on(void);
+void white_led_off(void);
#else
.extern LED_init
.extern red_led_on
@@ -97,6 +99,8 @@ void blue_led_off(void);
.extern green_led_off
.extern blue_led_on
.extern blue_led_off
+ .extern white_led_on
+ .extern white_led_off
#endif
#endif /* _STATUS_LED_H_ */
--
2.43.0
[PATCH 1/7] misc: gpio_led: fix broken coloured LED status functions
The GPIO LED driver is a backend to provide LED status functions via the
GPIO common functions.
The coloured LED functions are currently broken and deviates from what
is written in README.LED
Quoting the README.LED:
CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors.
This must be a valid LED number (0-5). Other similar color LED's macros
are CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and
CONFIG_STATUS_LED_BLUE.
Hence the value of the config must refer to the ID.
Currently this is not the case and the driver expect the GPIO ID to be
put in these config. On top of this to actually have these functions, a
never define in Kconfig config must be declared to actually compile
them. (CONFIG_GPIO_LED_STUBS)
To fix this and the GPIO problem, introduce some define that reference
the LED_STATUS_BIT config to have the ID->BIT connection (as
described in Docs) and drop the never defined config.
The gpio_led already provide a wrapper to the functions and should not
be enabled if the board provide their custom function hence it's ok to
also provide the wrapper for the colour functions.
Signed-off-by: Christian Marangi
---
drivers/misc/gpio_led.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index 30679f80cf1..0f3682e1465 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -52,56 +52,63 @@ void __led_toggle(led_id_t mask)
gpio_set_value(mask, !gpio_get_value(mask));
}
-#ifdef CONFIG_GPIO_LED_STUBS
-
/* 'generic' override of colored LED stubs, to use GPIO functions instead */
+/* We support up to 6 LEDs, LED 0 STATUS BIT doesn't have the number suffix */
+#define GPIO_BIT0 CONFIG_LED_STATUS_BIT
+#define GPIO_BIT1 CONFIG_LED_STATUS_BIT1
+#define GPIO_BIT2 CONFIG_LED_STATUS_BIT2
+#define GPIO_BIT3 CONFIG_LED_STATUS_BIT3
+#define GPIO_BIT4 CONFIG_LED_STATUS_BIT4
+#define GPIO_BIT5 CONFIG_LED_STATUS_BIT5
+/* C preprocessor magic way to generate a GPIO_LED reference */
+#define GPIO_BIT(id) ___PASTE(GPIO_BIT, id)
+
#ifdef CONFIG_LED_STATUS_RED
+
void red_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_RED), CONFIG_LED_STATUS_ON);
}
void red_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_RED), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_GREEN
void green_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_GREEN), CONFIG_LED_STATUS_ON);
}
void green_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_GREEN), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_YELLOW
void yellow_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_YELLOW), CONFIG_LED_STATUS_ON);
}
void yellow_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_YELLOW), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_BLUE
void blue_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_ON);
}
void blue_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_OFF);
}
#endif
-
-#endif /* CONFIG_GPIO_LED_STUBS */
--
2.43.0
[PATCH 0/7] misc: introduce STATUS LED activity function
This series expand the STATUS LED framework with a new color and a big new feature. One thing that many device need is a way to communicate to the user that the device is actually doing something. This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover. There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on. A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink. To fix this and handle the problem of device not supporting HW blink, expand the STATUS LED framework with new API. We introduce a new config LED_STATUS_ACTIVITY, that similar to the RED, GREEN and others, takes the LED ID set in the LED_STATUS config and is used as the global LED for activity operations. We add status_led_activity() that simulate software blink. Any function that signal activity will call this function. At each call a counter is increased. When the counter reach the freq value, the LED is toggled simulating a blink and the counter is zeroed. When the counter reach the freq value again, the LED is toggled again and so on... Call to this function is added to the usual operation for recovery. Currently added to tftp traffic and mtd spi and nand write and erase operation. This also contains a big fixup for the gpio_led driver that currently deviates from the Documentation and make the coloured status led feature unusable. Christian Marangi (7): misc: gpio_led: fix broken coloured LED status functions led: status_led: add support for white LED colour led: status_led: add function to toggle a status LED led: status_led: add new activity LED config and functions tftp: implement support for LED status activity mtd: implement support for LED status activity ubi: implement support for LED status activity cmd/legacy_led.c | 6 cmd/mtd.c | 23 +++ cmd/ubi.c | 17 ++- common/board_f.c | 2 ++ drivers/led/Kconfig| 29 +++ drivers/misc/gpio_led.c| 41 +++--- drivers/misc/status_led.c | 53 +++--- drivers/mtd/nand/core.c| 4 +++ drivers/mtd/nand/spi/core.c| 5 drivers/mtd/spi/spi-nor-core.c | 9 ++ include/status_led.h | 6 net/tftp.c | 16 ++ 12 files changed, 189 insertions(+), 22 deletions(-) -- 2.43.0
[PATCH 11/11] pinctrl: mediatek: mt7981: init device before relocation
Upstream kernel linux define pinctrl for uart0, hence this pin group
and pinctrl driver is needed before relocation. Add DM_FLAG_PRE_RELOC
flag to init and mute mtk_serial error on early serial init.
Signed-off-by: Christian Marangi
---
drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7981.c
b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
index 3fa198ed79c..4bc4abe6518 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7981.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
@@ -1050,4 +1050,5 @@ U_BOOT_DRIVER(mt7981_pinctrl) = {
.ops = _pinctrl_ops,
.probe = mtk_pinctrl_mt7981_probe,
.priv_auto = sizeof(struct mtk_pinctrl_priv),
+ .flags = DM_FLAG_PRE_RELOC,
};
--
2.43.0
[PATCH 10/11] pinctrl: mediatek: add support for gpio-controller property in root node
Add support for gpio-controller property in root pinctrl node.
This is to follow upstream linux DTSI that doesn't define the
gpio-controller and cells in dedicated nodes.
Signed-off-by: Christian Marangi
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 0baef57c1c2..7465e236bc8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -762,6 +762,15 @@ static int mtk_gpiochip_register(struct udevice *parent)
if (!drv)
return -ENOENT;
+ /*
+* Support upstream linux DTSI that define gpio-controller
+* in the root node (instead of a dedicated subnode)
+*/
+ if (dev_read_bool(dev, "gpio-controller")) {
+ node = dev_ofnode(parent);
+ goto bind;
+ }
+
ret = -ENOENT;
dev_for_each_subnode(node, parent)
if (ofnode_read_bool(node, "gpio-controller")) {
@@ -772,6 +781,7 @@ static int mtk_gpiochip_register(struct udevice *parent)
if (ret)
return ret;
+bind:
ret = device_bind_with_driver_data(parent, _gpio_driver,
"mediatek_gpio", 0, node,
);
--
2.43.0
[PATCH 09/11] clk: mediatek: mt7981: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7981-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7981.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7981.c
b/drivers/clk/mediatek/clk-mt7981.c
index 7fcb81419cd..13dc3df0e9e 100644
--- a/drivers/clk/mediatek/clk-mt7981.c
+++ b/drivers/clk/mediatek/clk-mt7981.c
@@ -543,6 +543,7 @@ static const struct mtk_clk_tree mt7981_infracfg_clk_tree =
{
static const struct udevice_id mt7981_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7981-fixed-plls" },
+ { .compatible = "mediatek,mt7981-apmixedsys" },
{}
};
--
2.43.0
[PATCH 08/11] mmc: mediatek: add support for upstream linux clock and property
Add support for upstream linux clock and map U-Boot property to the one
use in upstream linux where supported.
Also add handling for the use_internal_cd that on upstream is hardcoded
enabled on mt7620.
Signed-off-by: Christian Marangi
---
drivers/mmc/mtk-sd.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index 296aaee7331..93878900dec 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -336,6 +336,7 @@ struct msdc_compatible {
bool enhance_rx;
bool builtin_pad_ctrl;
bool default_pad_dly;
+ bool use_internal_cd;
};
struct msdc_delay_phase {
@@ -366,6 +367,10 @@ struct msdc_host {
struct clk src_clk_cg; /* optional, MSDC source clock control gate */
struct clk h_clk; /* MSDC core clock */
+ /* upstream linux clock */
+ struct clk axi_cg_clk; /* optional, AXI clock */
+ struct clk ahb_cg_clk; /* optional, AHB clock */
+
u32 src_clk_freq; /* source clock */
u32 mclk; /* mmc framework required bus clock */
u32 sclk; /* actual calculated bus clock */
@@ -1638,6 +1643,11 @@ static void msdc_ungate_clock(struct msdc_host *host)
clk_enable(>h_clk);
if (host->src_clk_cg.dev)
clk_enable(>src_clk_cg);
+
+ if (host->axi_cg_clk.dev)
+ clk_enable(>axi_cg_clk);
+ if (host->ahb_cg_clk.dev)
+ clk_enable(>ahb_cg_clk);
}
static int msdc_drv_probe(struct udevice *dev)
@@ -1716,19 +1726,33 @@ static int msdc_of_to_plat(struct udevice *dev)
clk_get_by_name(dev, "source_cg", >src_clk_cg); /* optional */
+ /* upstream linux clock */
+ clk_get_by_name(dev, "axi_cg", >axi_cg_clk); /* optional */
+ clk_get_by_name(dev, "ahb_cg", >ahb_cg_clk); /* optional */
+
#if CONFIG_IS_ENABLED(DM_GPIO)
gpio_request_by_name(dev, "wp-gpios", 0, >gpio_wp, GPIOD_IS_IN);
gpio_request_by_name(dev, "cd-gpios", 0, >gpio_cd, GPIOD_IS_IN);
#endif
host->hs400_ds_delay = dev_read_u32_default(dev, "hs400-ds-delay", 0);
- host->hs200_cmd_int_delay =
- dev_read_u32_default(dev, "cmd_int_delay", 0);
+ if (dev_read_u32(dev, "mediatek,hs200-cmd-int-delay",
+>hs200_cmd_int_delay))
+ host->hs200_cmd_int_delay =
+ dev_read_u32_default(dev, "cmd_int_delay", 0);
+
host->hs200_write_int_delay =
dev_read_u32_default(dev, "write_int_delay", 0);
- host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
+
+ if (dev_read_u32(dev, "mediatek,latch-ck", >latch_ck))
+ host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
+
host->r_smpl = dev_read_u32_default(dev, "r_smpl", 0);
- host->builtin_cd = dev_read_u32_default(dev, "builtin-cd", 0);
+ if (dev_read_bool(dev, "mediatek,hs400-cmd-resp-sel-rising"))
+ host->r_smpl = 1;
+
+ host->builtin_cd = dev_read_u32_default(dev, "builtin-cd", 0) ||
+ host->dev_comp->use_internal_cd;
host->cd_active_high = dev_read_bool(dev, "cd-active-high");
return 0;
@@ -1776,6 +1800,7 @@ static const struct msdc_compatible mt7620_compat = {
.enhance_rx = false,
.builtin_pad_ctrl = true,
.default_pad_dly = true,
+ .use_internal_cd = true,
};
static const struct msdc_compatible mt7621_compat = {
--
2.43.0
[PATCH 07/11] serial: mediatek: add special handling for highspeed and linux compat
Upstream linux serial driver use a different logic to setup serial regs.
They have 2 interval:
- < 115200 we use lowspeed regs and 16 * baud
- >= 115200 we use highspeed
We currently use force_highspeed property to force usage of highspeed
regs even with low baud rate.
Add special handling if the upstream compatible is used where we just
apply the same interval with anything >= 115200 in highspeed simulating
force_highspeed.
Signed-off-by: Christian Marangi
---
drivers/serial/serial_mtk.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index d34a31c9cf0..14be095653a 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -89,8 +89,8 @@ struct mtk_serial_priv {
bool force_highspeed;
};
-static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud,
- uint clk_rate)
+static void _mtk_serial_setbrg(struct udevice *dev, struct mtk_serial_priv
*priv,
+ int baud, uint clk_rate)
{
u32 quot, realbaud, samplecount = 1;
@@ -113,7 +113,12 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv
*priv, int baud,
goto set_baud;
}
- if (priv->force_highspeed)
+ /*
+* Upstream linux use highspeed for anything >= 115200 and lowspeed
+* for < 115200. Simulate this if we are using the upstream compatible.
+*/
+ if (priv->force_highspeed ||
+ (device_is_compatible(dev, "mediatek,mt6577-uart") && baud >=
115200))
goto use_hs3;
if (baud <= 115200) {
@@ -186,7 +191,7 @@ static int mtk_serial_setbrg(struct udevice *dev, int
baudrate)
if (IS_ERR_VALUE(clk_rate) || clk_rate == 0)
clk_rate = priv->fixed_clk_rate;
- _mtk_serial_setbrg(priv, baudrate, clk_rate);
+ _mtk_serial_setbrg(dev, priv, baudrate, clk_rate);
return 0;
}
@@ -302,13 +307,13 @@ DECLARE_GLOBAL_DATA_PTR;
writel(0, _hsuart##port.regs->ier); \
writel(UART_MCRVAL, _hsuart##port.regs->mcr); \
writel(UART_FCRVAL, _hsuart##port.regs->fcr); \
- _mtk_serial_setbrg(_hsuart##port, gd->baudrate, \
+ _mtk_serial_setbrg(NULL, _hsuart##port, gd->baudrate, \
mtk_hsuart##port.fixed_clk_rate); \
return 0 ; \
} \
static void mtk_serial##port##_setbrg(void) \
{ \
- _mtk_serial_setbrg(_hsuart##port, gd->baudrate, \
+ _mtk_serial_setbrg(NULL, _hsuart##port, gd->baudrate, \
mtk_hsuart##port.fixed_clk_rate); \
} \
static int mtk_serial##port##_getc(void) \
@@ -456,7 +461,7 @@ static inline void _debug_uart_init(void)
writel(UART_MCRVAL, >mcr);
writel(UART_FCRVAL, >fcr);
- _mtk_serial_setbrg(, CONFIG_BAUDRATE, priv.fixed_clk_rate);
+ _mtk_serial_setbrg(NULL, , CONFIG_BAUDRATE, priv.fixed_clk_rate);
}
static inline void _debug_uart_putc(int ch)
--
2.43.0
[PATCH 06/11] serial: mediatek: add support for bus clock and enable it
Upstream linux also provide the additional optional bus clock.
Add support for it and also enable the baud and bus clock on probe.
Signed-off-by: Christian Marangi
---
drivers/serial/serial_mtk.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index f146f2b006e..d34a31c9cf0 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -76,6 +76,7 @@ struct mtk_serial_regs {
* driver
* @regs: Register base of the serial port
* @clk: The baud clock device
+ * @clk_bus: The bus clock device
* @fixed_clk_rate:Fallback fixed baud clock rate if baud clock
* device is not specified
* @force_highspeed: Force using high-speed mode
@@ -83,6 +84,7 @@ struct mtk_serial_regs {
struct mtk_serial_priv {
struct mtk_serial_regs __iomem *regs;
struct clk clk;
+ struct clk clk_bus;
u32 fixed_clk_rate;
bool force_highspeed;
};
@@ -220,6 +222,10 @@ static int mtk_serial_probe(struct udevice *dev)
writel(UART_MCRVAL, >regs->mcr);
writel(UART_FCRVAL, >regs->fcr);
+ clk_enable(>clk);
+ if (priv->clk_bus.dev)
+ clk_enable(>clk_bus);
+
return 0;
}
@@ -250,6 +256,8 @@ static int mtk_serial_of_to_plat(struct udevice *dev)
}
}
+ clk_get_by_name(dev, "bus", >clk_bus);
+
priv->force_highspeed = dev_read_bool(dev, "mediatek,force-highspeed");
return 0;
--
2.43.0
[PATCH 05/11] i2c: mediatek: add support for optional arb and pmic clock
Add support for optional arb and pmic clock for i2c provided in upstream
linux DTSI.
Signed-off-by: Christian Marangi
---
drivers/i2c/mtk_i2c.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/i2c/mtk_i2c.c b/drivers/i2c/mtk_i2c.c
index 5592fe91817..3450177741a 100644
--- a/drivers/i2c/mtk_i2c.c
+++ b/drivers/i2c/mtk_i2c.c
@@ -221,6 +221,8 @@ struct mtk_i2c_priv {
void __iomem *pdmabase; /* dma base address*/
struct clk clk_main;/* main clock for i2c bus */
struct clk clk_dma; /* DMA clock for i2c via DMA */
+ struct clk clk_arb; /* DMA clock for i2c ARB */
+ struct clk clk_pmic;/* DMA clock for i2c PMIC */
const struct mtk_i2c_soc_data *soc_data; /* Compatible data for
different IC */
int op; /* operation mode */
bool zero_len; /* Only transfer slave address, no data
*/
@@ -255,6 +257,18 @@ static int mtk_i2c_clk_enable(struct mtk_i2c_priv *priv)
if (ret)
return log_msg_ret("enable clk_dma", ret);
+ if (priv->clk_arb.dev) {
+ ret = clk_enable(>clk_arb);
+ if (ret)
+ return log_msg_ret("enable clk_arb", ret);
+ }
+
+ if (priv->clk_pmic.dev) {
+ ret = clk_enable(>clk_pmic);
+ if (ret)
+ return log_msg_ret("enable clk_pmic", ret);
+ }
+
return 0;
}
@@ -262,6 +276,18 @@ static int mtk_i2c_clk_disable(struct mtk_i2c_priv *priv)
{
int ret;
+ if (priv->clk_pmic.dev) {
+ ret = clk_disable(>clk_pmic);
+ if (ret)
+ return log_msg_ret("disable clk_pmic", ret);
+ }
+
+ if (priv->clk_arb.dev) {
+ ret = clk_disable(>clk_arb);
+ if (ret)
+ return log_msg_ret("disable clk_arb", ret);
+ }
+
ret = clk_disable(>clk_dma);
if (ret)
return log_msg_ret("disable clk_dma", ret);
@@ -748,6 +774,10 @@ static int mtk_i2c_of_to_plat(struct udevice *dev)
ret = clk_get_by_index(dev, 1, >clk_dma);
+ /* optional i2c clock */
+ clk_get_by_name(dev, "arb", >clk_arb);
+ clk_get_by_name(dev, "pmic", >clk_pmic);
+
return ret;
}
--
2.43.0
[PATCH 04/11] net: mediatek: handle alternative name for pn_swap property
Handle alternative name for pn_swap property as upstream linux use
mediatek,pnswap.
Signed-off-by: Christian Marangi
---
drivers/net/mtk_eth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index 75e7bcf83b7..87e2e1d9cda 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -1965,7 +1965,9 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
return -ENODEV;
}
- priv->pn_swap = ofnode_read_bool(args.node, "pn_swap");
+ /* Upstream linux use mediatek,pnswap instead of pn_swap */
+ priv->pn_swap = ofnode_read_bool(args.node, "pn_swap") ||
+ ofnode_read_bool(args.node, "mediatek,pnswap");
} else if (priv->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
/* get corresponding usxgmii phandle */
ret = dev_read_phandle_with_args(dev, "mediatek,usxgmiisys",
--
2.43.0
[PATCH 03/11] spi: mtk_spim: add support for upstream mediatek, spi-ipm compatible
Upstream kernel linux use a different compatible mediatek,spi-ipm.
Add support for this compatible and add handling for the additional
clock similar to how it's done by the upstream driver and handling for
all the property enabled by default.
Signed-off-by: Christian Marangi
---
drivers/spi/mtk_spim.c | 45 --
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/mtk_spim.c b/drivers/spi/mtk_spim.c
index 90f4c3cecb9..b360eca2b91 100644
--- a/drivers/spi/mtk_spim.c
+++ b/drivers/spi/mtk_spim.c
@@ -137,6 +137,8 @@ struct mtk_spim_capability {
* @state: Controller state
* @sel_clk: Pad clock
* @spi_clk: Core clock
+ * @parent_clk:Parent clock (needed for mediatek,spi-ipm,
upstream DTSI)
+ * @hclk: HCLK clock (needed for mediatek,spi-ipm, upstream DTSI)
* @pll_clk_rate: Controller's PLL source clock rate, which is different
* from SPI bus clock rate
* @xfer_len: Current length of data for transfer
@@ -151,6 +153,7 @@ struct mtk_spim_priv {
void __iomem *base;
u32 state;
struct clk sel_clk, spi_clk;
+ struct clk parent_clk, hclk;
u32 pll_clk_rate;
u32 xfer_len;
struct mtk_spim_capability hw_cap;
@@ -650,7 +653,21 @@ static int mtk_spim_probe(struct udevice *dev)
if (!priv->base)
return -EINVAL;
- mtk_spim_get_attr(priv, dev);
+ /*
+* Upstream linux driver for ipm design enable all the modes
+* and setup the calibrarion values directly in the driver with
+* standard values.
+*/
+ if (device_is_compatible(dev, "mediatek,spi-ipm")) {
+ priv->hw_cap.enhance_timing = true;
+ priv->hw_cap.dma_ext = true;
+ priv->hw_cap.ipm_design = true;
+ priv->hw_cap.support_quad = true;
+ priv->sample_sel = 0;
+ priv->tick_dly = 2;
+ } else {
+ mtk_spim_get_attr(priv, dev);
+ }
ret = clk_get_by_name(dev, "sel-clk", >sel_clk);
if (ret < 0) {
@@ -664,8 +681,31 @@ static int mtk_spim_probe(struct udevice *dev)
return ret;
}
- clk_enable(>sel_clk);
+ /*
+* Upstream DTSI use a different compatible that provide additional
+* clock instead of the assigned-clock implementation.
+*/
+ if (device_is_compatible(dev, "mediatek,spi-ipm")) {
+ ret = clk_get_by_name(dev, "parent-clk", >parent_clk);
+ if (ret < 0) {
+ dev_err(dev, "failed to get parent-clk\n");
+ return ret;
+ }
+
+ ret = clk_get_by_name(dev, "hclk", >hclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to get hclk\n");
+ return ret;
+ }
+
+ clk_enable(>parent_clk);
+ clk_set_parent(>sel_clk, >parent_clk);
+
+ clk_enable(>hclk);
+ }
+
clk_enable(>spi_clk);
+ clk_enable(>sel_clk);
priv->pll_clk_rate = clk_get_rate(>spi_clk);
if (priv->pll_clk_rate == 0)
@@ -698,6 +738,7 @@ static const struct dm_spi_ops mtk_spim_ops = {
static const struct udevice_id mtk_spim_ids[] = {
{ .compatible = "mediatek,ipm-spi" },
+ { .compatible = "mediatek,spi-ipm", },
{}
};
--
2.43.0
[PATCH 02/11] pci: mediatek: add PCIe controller support for filogic silicon
From: John Crispin
Add MediaTek GEN3 PCIe controller support for filogic silicon.
This is adapted from the Linux version of the driver.
Signed-off-by: John Crispin
[ fix minor problems, fix checkpatch errors ]
Signed-off-by: Christian Marangi
---
drivers/pci/Kconfig | 7 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_mediatek_gen3.c | 382 +++
3 files changed, 390 insertions(+)
create mode 100644 drivers/pci/pcie_mediatek_gen3.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 8d02ab82ad9..22a56f4ca38 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -350,6 +350,13 @@ config PCIE_MEDIATEK
Say Y here if you want to enable Gen2 PCIe controller,
which could be found on MT7623 SoC family.
+config PCIE_MEDIATEK_GEN3
+ bool "MediaTek PCIe Gen3 controller"
+ depends on ARCH_MEDIATEK
+ help
+ Say Y here if you want to enable Gen3 PCIe controller,
+ which could be found on the Mediatek Filogic SoC family.
+
config PCIE_DW_MESON
bool "Amlogic Meson DesignWare based PCIe controller"
depends on ARCH_MESON
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 2927c519129..5b2d2969802 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o
obj-$(CONFIG_PCIE_DW_COMMON) += pcie_dw_common.o
obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
+obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie_mediatek_gen3.o
obj-$(CONFIG_PCIE_ROCKCHIP) += pcie_rockchip.o
obj-$(CONFIG_PCIE_DW_ROCKCHIP) += pcie_dw_rockchip.o
obj-$(CONFIG_PCIE_DW_MESON) += pcie_dw_meson.o
diff --git a/drivers/pci/pcie_mediatek_gen3.c b/drivers/pci/pcie_mediatek_gen3.c
new file mode 100644
index 000..673813b8b75
--- /dev/null
+++ b/drivers/pci/pcie_mediatek_gen3.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek PCIe host controller driver.
+ *
+ * Copyright (c) 2023 John Crispin
+ * Driver is based on u-boot gen1/2 and upstream linux gen3 code
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pci_internal.h"
+
+/* PCIe shared registers */
+#define PCIE_CFG_ADDR 0x20
+#define PCIE_CFG_DATA 0x24
+
+#define PCIE_SETTING_REG 0x80
+
+#define PCIE_PCI_IDS_1 0x9c
+#define PCIE_RC_MODE BIT(0)
+#define PCI_CLASS(class) ((class) << 8)
+
+#define PCIE_CFGNUM_REG0x140
+#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0))
+#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8))
+#define PCIE_CFG_BYTE_EN(bytes)(((bytes) << 16) & GENMASK(19,
16))
+#define PCIE_CFG_FORCE_BYTE_EN BIT(20)
+#define PCIE_CFG_OFFSET_ADDR 0x1000
+#define PCIE_CFG_HEADER(bus, devfn)(PCIE_CFG_BUS(bus) |
PCIE_CFG_DEVFN(devfn))
+
+#define PCIE_RST_CTRL_REG 0x148
+#define PCIE_MAC_RSTB BIT(0)
+#define PCIE_PHY_RSTB BIT(1)
+#define PCIE_BRG_RSTB BIT(2)
+#define PCIE_PE_RSTB BIT(3)
+
+#define PCIE_LINK_STATUS_REG 0x154
+#define PCIE_PORT_LINKUP BIT(8)
+
+#define PCIE_INT_ENABLE_REG0x180
+
+#define PCIE_MISC_CTRL_REG 0x348
+#define PCIE_DISABLE_DVFSRC_VLT_REQBIT(1)
+
+#define PCIE_TRANS_TABLE_BASE_REG 0x800
+#define PCIE_ATR_SRC_ADDR_MSB_OFFSET0x4
+#define PCIE_ATR_TRSL_ADDR_LSB_OFFSET 0x8
+#define PCIE_ATR_TRSL_ADDR_MSB_OFFSET 0xc
+#define PCIE_ATR_TRSL_PARAM_OFFSET 0x10
+#define PCIE_ATR_TLB_SET_OFFSET 0x20
+
+#define PCIE_MAX_TRANS_TABLES 8
+#define PCIE_ATR_EN BIT(0)
+#define PCIE_ATR_SIZE(size) \
+ (size) - 1) << 1) & GENMASK(6, 1)) | PCIE_ATR_EN)
+#define PCIE_ATR_ID(id) ((id) & GENMASK(3, 0))
+#define PCIE_ATR_TYPE_MEM PCIE_ATR_ID(0)
+#define PCIE_ATR_TYPE_IOPCIE_ATR_ID(1)
+#define PCIE_ATR_TLP_TYPE(type) (((type) << 16) & GENMASK(18, 16))
+#define PCIE_ATR_TLP_TYPE_MEM PCIE_ATR_TLP_TYPE(0)
+#define PCIE_ATR_TLP_TYPE_IOPCIE_ATR_TLP_TYPE(2)
+
+struct mtk_pcie {
+ void __iomem *base;
+ void *priv;
+ struct clk pl_250m_ck;
+ struct clk tl_26m_ck;
+ struct clk peri_26m_ck;
+ struct clk top_133m_ck;
+ struct reset_ctl reset_phy;
+ struct reset_ctl reset_mac;
+ struct phy phy;
+};
+
+static void mtk_pcie_config_tlp_header(const struct udevice *bus,
+ pci_dev_t devfn,
+ int where, int size)
+{
+ struct mtk_pcie *pcie = dev_get_priv(bus);
+ int bytes;
+ u32 val;
+
+ size = 1 << size;
+
[PATCH 01/11] phy: phy-mtk-tphy: add support for phy type switch
Add support for PHY type switch via the mediatek topmisc syscon.
This is needed on mt7981 to make the PCIe correctly work and display
LinkUp.
Follow the same implementation done on Linux kernel with the usage of
the mediatek,syscon-type property.
Example:
u3port0: usb-phy@11e10700 {
reg = <0x11e10700 0x900>;
clocks = < CK_TOP_USB3_PHY_SEL>;
clock-names = "ref";
#phy-cells = <1>;
mediatek,syscon-type = < 0x218 0>;
status = "okay";
};
Signed-off-by: Christian Marangi
---
drivers/phy/phy-mtk-tphy.c | 80 ++
1 file changed, 80 insertions(+)
diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index ea9edf212c6..24938c8d2e3 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -216,6 +218,14 @@
#define ANA_EQ_EYE_CTRL_SIGNAL50xdc
#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
+/* PHY switch between pcie/usb3/sgmii/sata */
+#define USB_PHY_SWITCH_CTRL0x0
+#define RG_PHY_SW_TYPE GENMASK(3, 0)
+#define RG_PHY_SW_PCIE 0x0
+#define RG_PHY_SW_USB3 0x1
+#define RG_PHY_SW_SGMII0x2
+#define RG_PHY_SW_SATA 0x3
+
enum mtk_phy_version {
MTK_TPHY_V1 = 1,
MTK_TPHY_V2,
@@ -258,6 +268,10 @@ struct mtk_phy_instance {
u32 index;
u32 type;
+ struct regmap *type_sw;
+ u32 type_sw_reg;
+ u32 type_sw_index;
+
u32 eye_vrt;
u32 eye_term;
u32 discth;
@@ -617,6 +631,67 @@ static void u2_phy_props_set(struct mtk_tphy *tphy,
FIELD_PREP(PA6_RG_U2_PRE_EMP,
instance->pre_emphasis));
}
+/* type switch for usb3/pcie/sgmii/sata */
+static int phy_type_syscon_get(struct udevice *dev, struct mtk_phy_instance
*instance,
+ ofnode dn)
+{
+ struct ofnode_phandle_args args;
+ int err;
+
+ if (!ofnode_read_bool(dn, "mediatek,syscon-type"))
+ return 0;
+
+ err = ofnode_parse_phandle_with_args(dn, "mediatek,syscon-type",
+NULL, 2, 0, );
+ if (err)
+ return err;
+
+ instance->type_sw_reg = args.args[0];
+ instance->type_sw_index = args.args[1] & 0x3; /* <=3 */
+ instance->type_sw = syscon_node_to_regmap(args.node);
+ if (IS_ERR(instance->type_sw))
+ return PTR_ERR(instance->type_sw);
+
+ debug("phy-%s.%d: type_sw - reg %#x, index %d\n",
+ dev->name, instance->index, instance->type_sw_reg,
+ instance->type_sw_index);
+
+ return 0;
+}
+
+static int phy_type_set(struct mtk_phy_instance *instance)
+{
+ int type;
+ u32 offset;
+
+ if (!instance->type_sw)
+ return 0;
+
+ switch (instance->type) {
+ case PHY_TYPE_USB3:
+ type = RG_PHY_SW_USB3;
+ break;
+ case PHY_TYPE_PCIE:
+ type = RG_PHY_SW_PCIE;
+ break;
+ case PHY_TYPE_SGMII:
+ type = RG_PHY_SW_SGMII;
+ break;
+ case PHY_TYPE_SATA:
+ type = RG_PHY_SW_SATA;
+ break;
+ case PHY_TYPE_USB2:
+ default:
+ return 0;
+ }
+
+ offset = instance->type_sw_index * BITS_PER_BYTE;
+ regmap_update_bits(instance->type_sw, instance->type_sw_reg,
+ RG_PHY_SW_TYPE << offset, type << offset);
+
+ return 0;
+}
+
static int mtk_phy_init(struct phy *phy)
{
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
@@ -747,6 +822,7 @@ static int mtk_phy_xlate(struct phy *phy,
}
phy_parse_property(tphy, instance);
+ phy_type_set(instance);
return 0;
}
@@ -808,6 +884,10 @@ static int mtk_tphy_probe(struct udevice *dev)
>da_ref_clk);
if (err)
return err;
+
+ err = phy_type_syscon_get(dev, instance, subnode);
+ if (err)
+ return err;
}
return 0;
--
2.43.0
[PATCH 00/11] mediatek: cumulative trivial fix for OF_UPSTREAM support
This is an initial series that have all the initial trivial fixes required for usage of OF_UPSTREAM for the mediatek SoC This also contains the pcie-gen3 driver and the required tphy support driver to make it work. Subsequent series will follow with conversion of the mtk-clk to permit usage of OF_UPSTREAM and upstream clk ID. Christian Marangi (10): phy: phy-mtk-tphy: add support for phy type switch spi: mtk_spim: add support for upstream mediatek,spi-ipm compatible net: mediatek: handle alternative name for pn_swap property i2c: mediatek: add support for optional arb and pmic clock serial: mediatek: add support for bus clock and enable it serial: mediatek: add special handling for highspeed and linux compat mmc: mediatek: add support for upstream linux clock and property clk: mediatek: mt7981: support alternative compatible for fixed-plls pinctrl: mediatek: add support for gpio-controller property in root node pinctrl: mediatek: mt7981: init device before relocation John Crispin (1): pci: mediatek: add PCIe controller support for filogic silicon drivers/clk/mediatek/clk-mt7981.c | 1 + drivers/i2c/mtk_i2c.c | 30 ++ drivers/mmc/mtk-sd.c | 33 +- drivers/net/mtk_eth.c | 4 +- drivers/pci/Kconfig | 7 + drivers/pci/Makefile | 1 + drivers/pci/pcie_mediatek_gen3.c | 382 ++ drivers/phy/phy-mtk-tphy.c| 80 drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 + drivers/serial/serial_mtk.c | 27 +- drivers/spi/mtk_spim.c| 45 ++- 12 files changed, 607 insertions(+), 14 deletions(-) create mode 100644 drivers/pci/pcie_mediatek_gen3.c -- 2.43.0
[RFC PATCH] drivers: bootcount: Add support for FAT filesystem
From: Vasileios Amoiridis Add support to save boot count variable in a file in a FAT filesystem. Signed-off-by: Vasileios Amoiridis --- doc/README.bootcount | 12 drivers/bootcount/Kconfig | 49 +++ drivers/bootcount/Makefile| 2 +- drivers/bootcount/bootcount_ext.c | 18 4 files changed, 56 insertions(+), 25 deletions(-) diff --git a/doc/README.bootcount b/doc/README.bootcount index f6c5f82f98..cce66d4d70 100644 --- a/doc/README.bootcount +++ b/doc/README.bootcount @@ -23,15 +23,17 @@ 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. +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..a39a7556bb 100644 --- a/drivers/bootcount/Kconfig +++ b/drivers/bootcount/Kconfig @@ -25,10 +25,9 @@ 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 filesystem" + depends on FS_EXT4 || FS_FAT help Add support for maintaining boot count in a file on an EXT filesystem. @@ -177,6 +176,30 @@ config BOOTCOUNT_BOOTLIMIT counter being cleared. If set to 0, do not set a boot limit in the environment. +if BOOTCOUNT_FS +choice + prompt "Filesystem type" + default BOOTCOUNT_EXT + +config BOOTCOUNT_EXT + bool "Boot counter on EXT filesystem" + depends on FS_EXT4 + select EXT4_WRITE + help + Add support for maintaining boot count in a file on an EXT + filesystem. + +config BOOTCOUNT_FAT + bool "Boot counter on FAT filesystem" + depends on FS_FAT + select FAT_WRITE + help + Add support for maintaining boot count in a file on a FAT + filesystem. + +endchoice +endif + config SYS_BOOTCOUNT_SINGLEWORD bool "Use single word to pack boot count and magic value" depends on BOOTCOUNT_GENERIC @@ -184,26 +207,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 +config SYS_BOOTCOUNT_FS_INTERFACE string "Interface on which to find boot counter EXT 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 +config SYS_BOOTCOUNT_FS_DEVPART string "Partition of the boot counter EXT 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 +config SYS_BOOTCOUNT_FS_NAME string "Path and filename of the EXT 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 +234,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
[RFC PATCH 0/1] drivers: bootcount: Add support for FAT filesystem
From: Vasileios Amoiridis 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 P.S: Documentation has not been modified yet, I will submit in the v2 (if any). Vasileios Amoiridis (1): drivers: bootcount: Add support for FAT filesystem doc/README.bootcount | 12 drivers/bootcount/Kconfig | 49 +++ drivers/bootcount/Makefile| 2 +- drivers/bootcount/bootcount_ext.c | 18 4 files changed, 56 insertions(+), 25 deletions(-) base-commit: c0ea27bccfb7d2d37fd36806ac2a2f7389099420 -- 2.34.1
Re: [RFC PATCH 0/1] drivers: bootcount: Add support for FAT filesystem
On Wed, Jun 05, 2024 at 08:10:40PM +0200, Vasileios Amoiridis wrote: > From: Vasileios Amoiridis > > 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? Yeah, lets call it bootcount_fs.c ? It otherwise all looks good to me, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Wed, Jun 05, 2024 at 06:48:53PM +0200, Marek Vasut wrote: > The following changes since commit ea722aa5eb33740ae77e8816aeb72b385e621cd0: > > Merge branch '2024-05-29-assorted-small-fixes' (2024-05-29 11:21:14 -0600) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to 8f8b4b0833fb8e890d053860ecf1c39d037c8039: > > usb: remove not used variable in usb_ether_curr_dev (2024-06-01 21:42:09 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v5] cmd: move ELF load and boot to lib/elf.c
From: Maxim Moskalets
Loading and running the ELF image is the responsibility of the
library and should not be associated with the command line interface.
It is also required to run ELF images from FIT with the bootm command
so as not to depend on the command line interface.
Signed-off-by: Maxim Moskalets
---
cmd/elf.c | 58 +++
include/elf.h | 10 +
lib/elf.c | 54 +++
3 files changed, 86 insertions(+), 36 deletions(-)
diff --git a/cmd/elf.c b/cmd/elf.c
index a02361f9f5..32b7462f92 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -19,21 +19,6 @@
#include
#endif
-/* Allow ports to override the default behavior */
-static unsigned long do_bootelf_exec(ulong (*entry)(int, char * const[]),
-int argc, char *const argv[])
-{
- unsigned long ret;
-
- /*
-* pass address parameter as argv[0] (aka command name),
-* and all remaining args
-*/
- ret = entry(argc, argv);
-
- return ret;
-}
-
/* Interpreter command to boot an arbitrary ELF image from memory */
int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
@@ -43,8 +28,8 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
#endif
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
- char *sload = NULL;
- int rcode = 0;
+ int rcode = CMD_RET_SUCCESS;
+ Bootelf_flags flags = {0};
/* Consume 'bootelf' */
argc--; argv++;
@@ -52,7 +37,10 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
/* Check for [-p|-s] flag. */
if (argc >= 1 && (argv[0][0] == '-' && \
(argv[0][1] == 'p' || argv[0][1] == 's'))) {
- sload = argv[0];
+ if (argv[0][1] == 'p')
+ flags.phdr = 1;
+ log_debug("Using ELF header format %s\n",
+ flags.phdr ? "phdr" : "shdr");
/* Consume flag. */
argc--; argv++;
}
@@ -75,17 +63,9 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
} else
addr = image_load_addr;
- if (!valid_elf_image(addr))
- return 1;
-
- if (sload && sload[1] == 'p')
- addr = load_elf_image_phdr(addr);
- else
- addr = load_elf_image_shdr(addr);
-
#if CONFIG_IS_ENABLED(CMD_ELF_FDT_SETUP)
if (fdt_addr) {
- printf("## Setting up FDT at 0x%08lx ...\n", fdt_addr);
+ log_debug("Setting up FDT at 0x%08lx ...\n", fdt_addr);
flush();
if (image_setup_libfdt(, (void *)fdt_addr, NULL))
@@ -93,21 +73,27 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
}
#endif
- if (!env_get_autostart())
- return rcode;
-
- printf("## Starting application at 0x%08lx ...\n", addr);
- flush();
+ if (env_get_autostart()) {
+ flags.autostart = 1;
+ log_debug("Starting application at 0x%08lx ...\n", addr);
+ flush();
+ }
/*
* pass address parameter as argv[0] (aka command name),
-* and all remaining args
+* and all remaining arguments
*/
- rc = do_bootelf_exec((void *)addr, argc, argv);
+ rc = bootelf(addr, flags, argc, argv);
if (rc != 0)
- rcode = 1;
+ rcode = CMD_RET_FAILURE;
- printf("## Application terminated, rc = 0x%lx\n", rc);
+ if (flags.autostart)
+ {
+ if (ENOEXEC == errno)
+ log_err("Invalid ELF image\n");
+ else
+ log_debug("## Application terminated, rc = 0x%lx\n",
rc);
+ }
return rcode;
}
diff --git a/include/elf.h b/include/elf.h
index a4ba74d8ab..b88e6cf403 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -12,6 +12,12 @@
#ifndef __ASSEMBLY__
#include "compiler.h"
+/* Flag param bits for bootelf() function */
+typedef struct {
+ unsigned phdr : 1; /* load via program (not section) headers */
+ unsigned autostart : 1; /* Start ELF after loading */
+} Bootelf_flags;
+
/* This version doesn't work for 64-bit ABIs - Erik */
/* These typedefs need to be handled better */
@@ -700,6 +706,10 @@ unsigned long elf_hash(const unsigned char *name);
#define R_RISCV_RELATIVE 3
#ifndef __ASSEMBLY__
+unsigned long bootelf_exec(ulong (*entry)(int, char * const[]),
+ int argc, char *const argv[]);
+unsigned long bootelf(unsigned long addr, Bootelf_flags flags,
+ int argc, char *const argv[]);
int valid_elf_image(unsigned long addr);
unsigned long
[PATCH] cmd: move ELF load and boot to lib/elf.c
From: Maxim Moskalets
Loading and running the ELF image is the responsibility of the
library and should not be associated with the command line interface.
It is also required to run ELF images from FIT with the bootm command
so as not to depend on the command line interface.
Signed-off-by: Maxim Moskalets
---
cmd/elf.c | 58 +++
include/elf.h | 10 +
lib/elf.c | 54 +++
3 files changed, 86 insertions(+), 36 deletions(-)
diff --git a/cmd/elf.c b/cmd/elf.c
index a02361f9f5..32b7462f92 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -19,21 +19,6 @@
#include
#endif
-/* Allow ports to override the default behavior */
-static unsigned long do_bootelf_exec(ulong (*entry)(int, char * const[]),
-int argc, char *const argv[])
-{
- unsigned long ret;
-
- /*
-* pass address parameter as argv[0] (aka command name),
-* and all remaining args
-*/
- ret = entry(argc, argv);
-
- return ret;
-}
-
/* Interpreter command to boot an arbitrary ELF image from memory */
int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
@@ -43,8 +28,8 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
#endif
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
- char *sload = NULL;
- int rcode = 0;
+ int rcode = CMD_RET_SUCCESS;
+ Bootelf_flags flags = {0};
/* Consume 'bootelf' */
argc--; argv++;
@@ -52,7 +37,10 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
/* Check for [-p|-s] flag. */
if (argc >= 1 && (argv[0][0] == '-' && \
(argv[0][1] == 'p' || argv[0][1] == 's'))) {
- sload = argv[0];
+ if (argv[0][1] == 'p')
+ flags.phdr = 1;
+ log_debug("Using ELF header format %s\n",
+ flags.phdr ? "phdr" : "shdr");
/* Consume flag. */
argc--; argv++;
}
@@ -75,17 +63,9 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
} else
addr = image_load_addr;
- if (!valid_elf_image(addr))
- return 1;
-
- if (sload && sload[1] == 'p')
- addr = load_elf_image_phdr(addr);
- else
- addr = load_elf_image_shdr(addr);
-
#if CONFIG_IS_ENABLED(CMD_ELF_FDT_SETUP)
if (fdt_addr) {
- printf("## Setting up FDT at 0x%08lx ...\n", fdt_addr);
+ log_debug("Setting up FDT at 0x%08lx ...\n", fdt_addr);
flush();
if (image_setup_libfdt(, (void *)fdt_addr, NULL))
@@ -93,21 +73,27 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
}
#endif
- if (!env_get_autostart())
- return rcode;
-
- printf("## Starting application at 0x%08lx ...\n", addr);
- flush();
+ if (env_get_autostart()) {
+ flags.autostart = 1;
+ log_debug("Starting application at 0x%08lx ...\n", addr);
+ flush();
+ }
/*
* pass address parameter as argv[0] (aka command name),
-* and all remaining args
+* and all remaining arguments
*/
- rc = do_bootelf_exec((void *)addr, argc, argv);
+ rc = bootelf(addr, flags, argc, argv);
if (rc != 0)
- rcode = 1;
+ rcode = CMD_RET_FAILURE;
- printf("## Application terminated, rc = 0x%lx\n", rc);
+ if (flags.autostart)
+ {
+ if (ENOEXEC == errno)
+ log_err("Invalid ELF image\n");
+ else
+ log_debug("## Application terminated, rc = 0x%lx\n",
rc);
+ }
return rcode;
}
diff --git a/include/elf.h b/include/elf.h
index a4ba74d8ab..b88e6cf403 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -12,6 +12,12 @@
#ifndef __ASSEMBLY__
#include "compiler.h"
+/* Flag param bits for bootelf() function */
+typedef struct {
+ unsigned phdr : 1; /* load via program (not section) headers */
+ unsigned autostart : 1; /* Start ELF after loading */
+} Bootelf_flags;
+
/* This version doesn't work for 64-bit ABIs - Erik */
/* These typedefs need to be handled better */
@@ -700,6 +706,10 @@ unsigned long elf_hash(const unsigned char *name);
#define R_RISCV_RELATIVE 3
#ifndef __ASSEMBLY__
+unsigned long bootelf_exec(ulong (*entry)(int, char * const[]),
+ int argc, char *const argv[]);
+unsigned long bootelf(unsigned long addr, Bootelf_flags flags,
+ int argc, char *const argv[]);
int valid_elf_image(unsigned long addr);
unsigned long
Re: [PATCH 0/3] arm: dts: am625/am62a7: Switch over to OF_UPSTREAM
Hi, On Jun 05, 2024 at 10:27:49 -0500, Nishanth Menon wrote: > Cleanup am625 on by switching over the last two platforms (SK and > beagleplay) over to OF_UPSTREAM, and while at it, switch over am62a7 > (last of the am62* family) over as well. Thanks for the cleanup. > > This superscedes the previous version of beagleplay only patch[1] > > Test logs: https://gist.github.com/nmenon/ba310d3750a80789aca6a4fd90190135 > > Nishanth Menon (3): > arm: dts: am625_beagleplay: Switch to OF_UPSTREAM > arm: dts: am625_sk: Switch to OF_UPSTREAM > arm: dts: am62a7_sk: Switch to OF_UPSTREAM > For the series, Reviewed-by: Dhruva Gole -- Best regards, Dhruva Gole
Re: [PATCH v2 01/14] net: introduce alternative implementation as net-lwip/
On 5/27/24 17:34, Tom Rini wrote: > On Fri, May 24, 2024 at 06:19:55PM +0200, Jerome Forissier wrote: > >> Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by >> adding a new net-lwip/ directory and the NET_LWIP symbol. At this >> point, enabling NET_LWIP simply disables NET. Subsequent commits will >> introduce the lwIP code, re-work the NETDEVICE integration and port >> some of the NET commands and features to lwIP. >> >> SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols >> that are part of NET (such as arp_init(), arp_timeout_check(), >> arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be >> added later. >> >> Similarly, DFU_TFTP is not compatible with NET_LWIP because it depends >> on net_loop(), tftp_timeout_ms, tftp_timeout_count_max. Let's add a >> dependency on !NET_LWIP for now. >> >> Signed-off-by: Jerome Forissier > [snip] >> diff --git a/Kconfig b/Kconfig >> index 82df59f176e..758256ab121 100644 >> --- a/Kconfig >> +++ b/Kconfig >> @@ -747,6 +747,8 @@ source "env/Kconfig" >> >> source "net/Kconfig" >> >> +source "net-lwip/Kconfig" >> + >> source "drivers/Kconfig" >> >> source "fs/Kconfig" > > I think we need to instead rework this to a choice statement instead so > that in the end we have something like: > choice "Networking stack" > config NO_NET > bool "No networking support" > config NET > bool "Legacy U-Boot networking stack" > config NET_LWIP > bool "Use lwIP for networking stack" > > if NET_LEGACY > source "net/Kconfig" > endif > > if NET_LWIP > source "net-lwip/Kconfig" > endif > > And then SPL_NET still depends on !NET_LWIP for now and we sort out the > problems with different networking stacks in SPL vs full U-Boot later > on. Done in v3. Thanks. -- Jerome
[PATCH] board: rockchip: Add FriendlyElec NanoPi R6C
The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Tests in U-Boot proper:
- Booting from eMMC works
- 1GbE Ethernet works using the eth_eqos driver (tested by ping)
- 2.5GbE Ethernet works using the eth_rtl8169 driver (tested by ping),
but the status LEDs on this specific port currently aren't working
- NVMe SSD in M.2 socket does get recognized (tested with `nvme scan`
followed by `nvme details`)
Kernel commit:
d5f1d7437451 ("arm64: dts: rockchip: Add support for NanoPi R6C")
Signed-off-by: Sebastian Kropatsch
---
Hello!
The Ethernet status LEDs which sit directly on the 2.5GbE port using the
RTL8169 driver don't light up when connected and I couldn't figure out
why. The other port with a RTL8211F has no problems with the LEDs.
Have there been occurrences like this in combination with the RTL8125?
I'm trying to figure out if this is something that could be solved in
the devicetree or if this is a potential driver bug.
Secondly, the default active network device in U-Boot is the 1GbE one.
I believe it would make sense to make the 2.5GbE device the default
active one since this one is labeled "LAN", whereas the 1GbE is labeled
"WAN". However, since the 2.5GbE device is PCIe-based, it only shows up
in U-Boot proper after using the `pci enum` command (shows up as in gets
listed in `net list` and `dm tree`).
Do you have any tips on the preferred approach to handle this switch of
the default active net device? Is this even a sensible thing to include
in U-Boot in your opinion?
Thanks for your feedback!
Best regards,
Sebastian
---
arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi | 3 +
arch/arm/mach-rockchip/rk3588/Kconfig | 13 +++
board/friendlyelec/nanopi-r6c-rk3588s/Kconfig | 12 +++
.../nanopi-r6c-rk3588s/MAINTAINERS| 7 ++
configs/nanopi-r6c-rk3588s_defconfig | 83 +++
doc/board/rockchip/rockchip.rst | 1 +
include/configs/nanopi-r6c-rk3588s.h | 12 +++
7 files changed, 131 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/MAINTAINERS
create mode 100644 configs/nanopi-r6c-rk3588s_defconfig
create mode 100644 include/configs/nanopi-r6c-rk3588s.h
diff --git a/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
new file mode 100644
index 00..853ed58cfe
--- /dev/null
+++ b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 820e979abb..0e232ddfb9 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -78,6 +78,18 @@ config TARGET_NANOPCT6_RK3588
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
+config TARGET_NANOPI_R6C_RK3588
+ bool "FriendlyElec NanoPi R6C"
+ select BOARD_LATE_INIT
+ help
+ The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip
+ RK3588s.
+ It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB
+ eMMC storage, one M.2 M-Key connector, one RTL8211F 1GbE and one
+ RTL8125 2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0
+ Type-A port, a HDMI port, a 30-pin GPIO header as well as some
+ buttons and LEDs.
+
config TARGET_NOVA_RK3588
bool "Indiedroid Nova RK3588"
select BOARD_LATE_INIT
@@ -232,6 +244,7 @@ config TEXT_BASE
source "board/edgeble/neural-compute-module-6/Kconfig"
source "board/friendlyelec/nanopc-t6-rk3588/Kconfig"
+source "board/friendlyelec/nanopi-r6c-rk3588s/Kconfig"
source "board/indiedroid/nova/Kconfig"
source "board/pine64/quartzpro64-rk3588/Kconfig"
source "board/turing/turing-rk1-rk3588/Kconfig"
diff --git a/board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
b/board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
new file mode 100644
index 00..5ffbd40af3
--- /dev/null
+++ b/board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_NANOPI_R6C_RK3588
+
+config SYS_BOARD
+ default "nanopi-r6c-rk3588s"
+
+config SYS_VENDOR
+ default "friendlyelec"
+
+config SYS_CONFIG_NAME
+ default "nanopi-r6c-rk3588s"
+
+endif
diff --git a/board/friendlyelec/nanopi-r6c-rk3588s/MAINTAINERS
b/board/friendlyelec/nanopi-r6c-rk3588s/MAINTAINERS
new file mode 100644
index
Re: [PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs
On 05/06/2024 07:59, Heinrich Schuchardt wrote: On 5/31/24 15:50, Caleb Connolly wrote: As more boards adopt support for the EFI CapsuleUpdate mechanism, there is a growing issue of being able to target updates to them properly. The current mechanism of hardcoding UUIDs for each board at compile time is unsustainable, and maintaining lists of GUIDs is similarly cumbersome. In this series, I propose that we adopt v5 GUIDs, these are generated by using a well-known salt GUID as well as board specific information (like the model/revision), these are hashed together and the result is truncated to form a new UUID. The well-known salt GUID can be specific to the architecture (SoC vendor), or OEM. It is defined in the board defconfig so that vendors can easily bring their own. Specifically, the following fields are used to generate a GUID for a particular fw_image: * namespace salt * board compatible (usually the first entry in the dt root compatible array). * fw_image name (the string identifying the specific image, especially relevant for board that can update multiple images). == Usage == Boards can integrate dynamic UUID support as follows: 1. Adjust Kconfig to depend on EFI_CAPSULE_DYNAMIC_UUIDS if EFI_HAVE_CAPSULE_SUPPORT. 2. Skip setting the fw_images image_type_id property. 3. Generate a UUID and set CONFIG_EFI_CAPSULE_NAMESPACE_UUID in your defconfig. Why should we have two alternatives? If we have the dynamic UUIDs, please, get rid of static ones. I don't think this is possible to do without the risk of breaking some boards. Can we assume that ALL existing capsule update image GUIDs are safe to just scrap? == Limitations == * Changing GUIDs The primary limitation with this approach is that if any of the source fields change, so will the GUID for the board. It is therefore pretty important to ensure that GUID changes are caught during development. * Supporting multiple boards with a single image This now requires having an entry with the GUID for every board which might lead to larger UpdateCapsule images. Do we have a test case were a capsule contains images that shall not be installed? == Tooling == This series introduces a new tool: genguid. This can be used to generate the same GUIDs that the board would at runtime. the GUIDs that the board requires at runtime. Best regards Heinrich This series follows a related discussion started by Ilias: https://lore.kernel.org/u-boot/cac_iwjjnha4gmf897mqyzndbgjfg8k4kwgstxwuy72wkyli...@mail.gmail.com/ --- Changes in v3: - Add manpage for genguid - Add dedicated CONFIG_TOOLS_GENGUID option - Minor code fixes addressing v2 feedback - Link to v2: https://lore.kernel.org/r/20240529-b4-dynamic-uuid-v2-0-c26f31057...@linaro.org Changes in v2: - Move namespace UUID to be defined in defconfig - Add tests and tooling - Only use the first board compatible to generate UUID. - Link to v1: https://lore.kernel.org/r/20240426-b4-dynamic-uuid-v1-0-e8154e00e...@linaro.org --- Caleb Connolly (7): lib: uuid: add UUID v5 support efi: add a helper to generate dynamic UUIDs doc: uefi: document dynamic UUID generation sandbox: switch to dynamic UUIDs lib: uuid: supporting building as part of host tools tools: add genguid tool test: lib/uuid: add unit tests for dynamic UUIDs arch/Kconfig | 1 + board/sandbox/sandbox.c | 16 --- configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + doc/develop/uefi/uefi.rst | 31 + doc/genguid.1 | 52 +++ include/sandbox_efi_capsule.h | 6 +- include/uuid.h | 21 ++- lib/Kconfig | 8 ++ lib/efi_loader/Kconfig | 23 +++ lib/efi_loader/efi_capsule.c | 1 + lib/efi_loader/efi_firmware.c | 66 + lib/uuid.c | 81 +-- test/lib/uuid.c | 88 .../test_efi_capsule/test_capsule_firmware_fit.py | 2 +- .../test_efi_capsule/test_capsule_firmware_raw.py | 8 +- .../test_capsule_firmware_signed_fit.py | 2 +- .../test_capsule_firmware_signed_raw.py | 4 +- test/py/tests/test_efi_capsule/version.dts | 6 +- tools/Kconfig | 7 + tools/Makefile | 3 + tools/binman/etype/efi_capsule.py | 2 +- tools/binman/ftest.py | 2 +- tools/genguid.c | 154 + 24 files changed, 538 insertions(+), 48 deletions(-) --- change-id:
Re: [PATCH v7] test/py: net_boot: Add test cases for net boot
On Wed, Jun 05, 2024 at 03:19:35PM +0530, Love Kumar wrote: > Add tests for booting image using tftpboot/pxe boot commands, tftpboot > boot case loads the FIT image into DDR and boots using bootm command > whereas pxe boot cases downloads the pxe configuration file from the > TFTP server and interprets it to boot the images mentioned in the pxe > configurations file. > This test relies on boardenv_* containing configuration values including > the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the > boot log pattern value is matched. For example, if the parameter > 'pattern' is defined as 'login:', it will boot till login prompt. > > Signed-off-by: Love Kumar Thanks for iterating on this so many times, I'm now able to run all of these tests in my lab. Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PULL] u-boot-usb/master
The following changes since commit ea722aa5eb33740ae77e8816aeb72b385e621cd0: Merge branch '2024-05-29-assorted-small-fixes' (2024-05-29 11:21:14 -0600) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to 8f8b4b0833fb8e890d053860ecf1c39d037c8039: usb: remove not used variable in usb_ether_curr_dev (2024-06-01 21:42:09 +0200) Heiko Schocher (1): usb: remove not used variable in usb_ether_curr_dev cmd/usb.c | 3 --- 1 file changed, 3 deletions(-)
Re: [PATCH 0/3] rockchip: rk8xx: fix broken [np]ldo callbacks
Hi Anand, On 6/5/24 3:11 PM, Anand Moon wrote: Hi Quentin, On Wed, 5 Jun 2024 at 15:03, Quentin Schulz wrote: This is for master branch, merge ASAP as it's known to break at least Chromebook Jerry. @Simon, can you please check that this fixes your CB? The wrong udevice was passed to the functions, making them call the pmic callbacks on the parent of the pmic udevice instead of the pmic udevice itself. While at it, ensure consistency by having all internal functions use pmic udevice instead of the regulator udevice. Finally, clarify operator precedence in ternary condition as reported by my linter. Signed-off-by: Quentin Schulz I see we have not been able to follow configs on a few of the board's for RK3588 CONFIG_CMD_REGULATOR=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_RK8XX=y could you enable the options with imply for all the rockchip boards? This patch series is a bug fix (ok, plus some cosmetic stuff) for master before the next release in July, the suggested change is not a bug fix so feel free to send a patch for the next branch instead :) I'm personally not too keen in adding a lot of "imply" but I am no authority there, so whatever the maintainer(s) prefer :) Thanks, Quentin
[PATCH next v2 6/6] rockchip: ringneck-px30: fix TPL_MAX_SIZE
From: Quentin Schulz
Ringneck was mistakenly set to allow up to 128KiB for the TPL code size
while PX30 SoC only has 16KiB of SRAM.
Therefore, let's use the default value of TPL_MAX_SIZE from the SoC
(which is 10KiB) so that the max code size is actually checked and
useful.
Fixes: c925be73a0a8 ("rockchip: add support for PX30 Ringneck SoM on Haikou
Devkit")
Signed-off-by: Quentin Schulz
---
configs/ringneck-px30_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig
index a22d25e0089..9965e55d611 100644
--- a/configs/ringneck-px30_defconfig
+++ b/configs/ringneck-px30_defconfig
@@ -14,7 +14,6 @@ CONFIG_SPL_DRIVERS_MISC=y
CONFIG_DEBUG_UART_BASE=0xFF03
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_SYS_LOAD_ADDR=0x800800
-CONFIG_TPL_MAX_SIZE=0x2
CONFIG_DEBUG_UART=y
# CONFIG_ANDROID_BOOT_IMAGE is not set
CONFIG_FIT=y
--
2.45.1
[PATCH next v2 5/6] power: rk8xx: properly print all supported PMICs name
From: Quentin Schulz
The ID of the PMIC is stored in the 2 16b registers but the only part
that matters right now is the 3 MSB, which make the 3 digits (in hex) of
the part number.
Right now, only RK808 was properly displayed, with this all currently
supported PMICs should display the proper part number.
Additionally, when the PMIC variant is not found, print that value
instead of the masked unshifted value as all PMICs we support for now
have their LSB ignored to represent the actual part number.
Tested on RK806 (RK3588 Jaguar), RK808 (RK3399 Puma) and RK809 (PX30
Ringneck).
Signed-off-by: Quentin Schulz
---
drivers/power/pmic/rk8xx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 12ff26a0855..4d07e630579 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -277,10 +277,9 @@ static int rk8xx_probe(struct udevice *dev)
return ret;
priv->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
- show_variant = priv->variant;
+ show_variant = bitfield_extract_by_mask(priv->variant, RK8XX_ID_MSK);
switch (priv->variant) {
case RK808_ID:
- show_variant = 0x808; /* RK808 hardware ID is 0 */
break;
case RK805_ID:
case RK816_ID:
@@ -311,7 +310,7 @@ static int rk8xx_probe(struct udevice *dev)
init_data_num = ARRAY_SIZE(rk806_init_reg);
break;
default:
- printf("Unknown PMIC: RK%x!!\n", priv->variant);
+ printf("Unknown PMIC: RK%x!!\n", show_variant);
return -EINVAL;
}
--
2.45.1
[PATCH next v2 4/6] rockchip: px30-ringneck: Update SPL_PAD_TO Kconfig option
From: Quentin Schulz
On px30-ringneck the FIT payload is located at sector 0x200 compared to
the more Rockchip common sector 0x4000 offset:
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
Because FIT payload is located at sector 0x200 and the TPL+SPL is
located at sector 64, the combined size of TPL+SPL cannot take up more
than 224KiB:
(0x200 - 64) x 512 = 0x38000 (224 KiB)
Adjust SPL_PAD_TO to match the used 0x200 sector offset.
While at it, update the px30-ringneck-u-boot.dtsi to remove the now
unnecessary override of simple-bin:fit:offset since SPL_PAD_TO matches
with the current formula.
Signed-off-by: Quentin Schulz
---
arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi | 8
configs/ringneck-px30_defconfig | 2 +-
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi
b/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi
index e04766ad09c..29ea2763636 100644
--- a/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi
+++ b/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi
@@ -15,14 +15,6 @@
};
};
- {
- simple-bin {
- fit {
- offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR -
64) * 512)>;
- };
- };
-};
-
_clk {
bootph-all;
};
diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig
index dedf35d4347..a22d25e0089 100644
--- a/configs/ringneck-px30_defconfig
+++ b/configs/ringneck-px30_defconfig
@@ -25,7 +25,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/px30-ringneck-haikou.dtb"
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_MISC_INIT_R=y
CONFIG_SPL_MAX_SIZE=0x2
-CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_PAD_TO=0x38000
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_BOOTROM_SUPPORT=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
--
2.45.1
[PATCH next v2 3/6] rockchip: rk3399-puma: remove unnecessary simple-bin:fit:offset override
From: Quentin Schulz
Since commit 6007b69d544e ("rockchip: rk3399-puma: Update SPL_PAD_TO
Kconfig option"), SPL_PAD_TO matches
(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512 and the default
value for simple-bin:fit:offset in rockchip-u-boot.dtsi is
SPL_PAD_TO, so let's remove this override.
Signed-off-by: Quentin Schulz
---
arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 5a9bd320ec4..55895d0dd19 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -33,12 +33,6 @@
};
{
- simple-bin {
- fit {
- offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR -
64) * 512)>;
- };
- };
-
#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
simple-bin-spi {
fit {
--
2.45.1
[PATCH next v2 2/6] rockchip: rk3399-puma: remove default value from defconfig
From: Quentin Schulz CONFIG_ENV_OFFSET already defaults to 0x3F8000, however it is stored in lowercase hexdigits instead of uppercase like in the defconfig. No change in behavior intended. Signed-off-by: Quentin Schulz --- configs/puma-rk3399_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 34a0b575991..42819102d70 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_GPIO=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_ENV_SIZE=0x3000 -CONFIG_ENV_OFFSET=0x3F8000 CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-puma-haikou" CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3399=y -- 2.45.1
[PATCH next v2 1/6] rockchip: jaguar-rk3588: use default env size for Rockchip on MMC
From: Quentin Schulz The default env size is 0x8000 when building for Rockchip SoCs with support for environment stored in MMC. Jaguar hasn't entered mass production just yet, so it's a breaking change we can afford in the name of consistency. Signed-off-by: Quentin Schulz --- configs/jaguar-rk3588_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/jaguar-rk3588_defconfig b/configs/jaguar-rk3588_defconfig index b69cf4cd057..36bf34d97c8 100644 --- a/configs/jaguar-rk3588_defconfig +++ b/configs/jaguar-rk3588_defconfig @@ -5,7 +5,6 @@ CONFIG_ARCH_ROCKCHIP=y CONFIG_SPL_GPIO=y CONFIG_SF_DEFAULT_SPEED=2400 CONFIG_SF_DEFAULT_MODE=0x2000 -CONFIG_ENV_SIZE=0x1f000 CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3588-jaguar" CONFIG_ROCKCHIP_RK3588=y CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0 -- 2.45.1
[PATCH next v2 0/6] rockchip: display PMIC variant properly + misc fixes for Theobroma boards
This fixes how the Rockchip PMIC variant is shown for all but RK808 by stripping the LSB. Also fix the size of the environment on Jaguar to match the default (smaller) size. Fix SPL_PAD_TO on Ringneck. Remove duplicated default value of ENV_OFFSET in puma defconfig. Remove unnecessary override of the fit offset in u-boot dtsi for Puma and Ringneck. Fix TPL_MAX_SIZE for Ringneck to match the (valid) default value for PX30 boards. Signed-off-by: Quentin Schulz --- Changes in v2: - add patch for fixing TPL_MAX_SIZE on PX30 Ringneck - print show_variant when PMIC variant not found - use bitfield_extract_by_mask instead of using hardcoded shift operator - Link to v1: https://lore.kernel.org/r/20240524-misc-tsd-v1-0-b7bde1344...@cherry.de --- Quentin Schulz (6): rockchip: jaguar-rk3588: use default env size for Rockchip on MMC rockchip: rk3399-puma: remove default value from defconfig rockchip: rk3399-puma: remove unnecessary simple-bin:fit:offset override rockchip: px30-ringneck: Update SPL_PAD_TO Kconfig option power: rk8xx: properly print all supported PMICs name rockchip: ringneck-px30: fix TPL_MAX_SIZE arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi | 8 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 6 -- configs/jaguar-rk3588_defconfig | 1 - configs/puma-rk3399_defconfig | 1 - configs/ringneck-px30_defconfig | 3 +-- drivers/power/pmic/rk8xx.c| 5 ++--- 6 files changed, 3 insertions(+), 21 deletions(-) --- base-commit: 8887ffb625f65475fd6619f8b05fb7a5a12b016b change-id: 20240524-misc-tsd-e08551c01c8a Best regards, -- Quentin Schulz
Re: [PATCH 0/2] Cleanup fit documentation
Hi Sam, On Tue, 4 Jun 2024 at 20:13, Simon Glass wrote: > > Hi Sam, > > On Tue, 4 Jun 2024 at 13:53, Sam Povilus wrote: > > > > Sam Povilus (2): > > doc: Remove extraneous curly braces > > doc: add clarity to what a "fpga" image is > > > > doc/usage/fit/source_file_format.rst | 28 ++-- > > 1 file changed, 14 insertions(+), 14 deletions(-) > > This is now at [1]. Could you please instead do a PR for that? > > I am not sure yet the best way to incorporate or link the FIT spec > from the U-Boot documentation. I suppose we could employ a script to > sync it? Hmm actually it is at [2]. So perhaps we can just link to it and drop some of the files from U-Boot? Regards, Simon [2] https://fitspec.osfw.foundation/
Re: [PATCH v1 0/4] Sync StarFive JH7110 clock and reset dt-bindings with Linux
On Wed, Jun 05, 2024 at 08:35:15AM -0600, Tom Rini wrote:
> On Wed, Jun 05, 2024 at 01:56:13AM +, Hal Feng wrote:
> > > On 04.06.24 04:32, E Shattow wrote:
> > > Hi Hal,
> > >
> > > Instead of manual dt-bindings sync can we please adopt OF_UPSTREAM for
> > > JH7110 ?
> >
> > Yeah, I will try to do it recently, although I am not sure whether the
> > U-Boot
> > drivers and Linux drivers are compatible so that they can use the same DT.
>
> They must be compatible so that they can use the same DT, U-Boot needs
> updating if it doesn't match.
Other than the naming, I think they are compatible. IIRC there were some
issues where U-Boot originally used different numbers to linux, but this
was fixed in commit 9a12e304dd ("dt-bindings: clock: jh7110: Modify clock
id to be same with Linux").
signature.asc
Description: PGP signature
[PATCH 2/3] arm: dts: am625_sk: Switch to OF_UPSTREAM
Enable OF_UPSTREAM for am625-sk board. Remove DT files that
are now available in dts/upstream. Update the appended files based on
version of latest OF_UPSTREAM sync point (v6.10-rc1).
Signed-off-by: Nishanth Menon
---
arch/arm/dts/Makefile|3 +-
arch/arm/dts/k3-am62-main.dtsi | 1058 --
arch/arm/dts/k3-am62-mcu.dtsi| 176 -
arch/arm/dts/k3-am62-thermal.dtsi| 36 -
arch/arm/dts/k3-am62-wakeup.dtsi | 96 ---
arch/arm/dts/k3-am62.dtsi| 122 ---
arch/arm/dts/k3-am625-sk-binman.dtsi |2 +-
arch/arm/dts/k3-am625-sk.dts | 299
arch/arm/dts/k3-am625.dtsi | 155
arch/arm/dts/k3-am62x-sk-common.dtsi | 535 -
configs/am62x_evm_a53_defconfig |3 +-
11 files changed, 4 insertions(+), 2481 deletions(-)
delete mode 100644 arch/arm/dts/k3-am62-main.dtsi
delete mode 100644 arch/arm/dts/k3-am62-mcu.dtsi
delete mode 100644 arch/arm/dts/k3-am62-thermal.dtsi
delete mode 100644 arch/arm/dts/k3-am62-wakeup.dtsi
delete mode 100644 arch/arm/dts/k3-am62.dtsi
delete mode 100644 arch/arm/dts/k3-am625-sk.dts
delete mode 100644 arch/arm/dts/k3-am625.dtsi
delete mode 100644 arch/arm/dts/k3-am62x-sk-common.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 813426a3e519..5b0bcf336924 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1198,8 +1198,7 @@ dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-r5-evm.dtb \
k3-am642-r5-sk.dtb \
k3-am642-r5-phycore-som-2gb.dtb
-dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
- k3-am625-r5-sk.dtb \
+dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-r5-sk.dtb \
k3-am625-r5-beagleplay.dtb \
k3-am625-verdin-r5.dtb \
k3-am625-r5-phycore-som-2gb.dtb
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
deleted file mode 100644
index e9cffca073ef..
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ /dev/null
@@ -1,1058 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only OR MIT
-/*
- * Device Tree Source for AM625 SoC Family Main Domain peripherals
- *
- * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-_main {
- oc_sram: sram@7000 {
- compatible = "mmio-sram";
- reg = <0x00 0x7000 0x00 0x1>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x00 0x7000 0x1>;
- };
-
- gic500: interrupt-controller@180 {
- compatible = "arm,gic-v3";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- #interrupt-cells = <3>;
- interrupt-controller;
- reg = <0x00 0x0180 0x00 0x1>, /* GICD */
- <0x00 0x0188 0x00 0xc>, /* GICR */
- <0x00 0x0188 0x00 0xc>, /* GICR */
- <0x01 0x 0x00 0x2000>,/* GICC */
- <0x01 0x0001 0x00 0x1000>,/* GICH */
- <0x01 0x0002 0x00 0x2000>;/* GICV */
- /*
-* vcpumntirq:
-* virtual CPU interface maintenance interrupt
-*/
- interrupts = ;
-
- gic_its: msi-controller@182 {
- compatible = "arm,gic-v3-its";
- reg = <0x00 0x0182 0x00 0x1>;
- socionext,synquacer-pre-its = <0x100 0x40>;
- msi-controller;
- #msi-cells = <1>;
- };
- };
-
- main_conf: bus@10 {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x00 0x0010 0x2>;
-
- phy_gmii_sel: phy@4044 {
- compatible = "ti,am654-phy-gmii-sel";
- reg = <0x4044 0x8>;
- #phy-cells = <1>;
- };
-
- epwm_tbclk: clock-controller@4130 {
- compatible = "ti,am62-epwm-tbclk";
- reg = <0x4130 0x4>;
- #clock-cells = <1>;
- };
-
- audio_refclk0: clock-controller@82e0 {
- compatible = "ti,am62-audio-refclk";
- reg = <0x82e0 0x4>;
- clocks = <_clks 157 0>;
- assigned-clocks = <_clks 157 0>;
- assigned-clock-parents = <_clks 157 8>;
- #clock-cells = <0>;
- };
-
- audio_refclk1: clock-controller@82e4 {
- compatible = "ti,am62-audio-refclk";
- reg =
[PATCH 3/3] arm: dts: am62a7_sk: Switch to OF_UPSTREAM
Enable OF_UPSTREAM for am62a7-sk board. Remove DT files that
are now available in dts/upstream. Update the appended files based on
version of latest OF_UPSTREAM sync point (v6.10-rc1).
Signed-off-by: Nishanth Menon
---
arch/arm/dts/Makefile|3 +-
arch/arm/dts/k3-am62a-main.dtsi | 1054 --
arch/arm/dts/k3-am62a-mcu.dtsi | 170 -
arch/arm/dts/k3-am62a-sk-binman.dtsi |2 +-
arch/arm/dts/k3-am62a-thermal.dtsi | 50 --
arch/arm/dts/k3-am62a-wakeup.dtsi| 73 --
arch/arm/dts/k3-am62a.dtsi | 125 ---
arch/arm/dts/k3-am62a7-sk.dts| 702 -
configs/am62ax_evm_a53_defconfig |3 +-
9 files changed, 4 insertions(+), 2178 deletions(-)
delete mode 100644 arch/arm/dts/k3-am62a-main.dtsi
delete mode 100644 arch/arm/dts/k3-am62a-mcu.dtsi
delete mode 100644 arch/arm/dts/k3-am62a-thermal.dtsi
delete mode 100644 arch/arm/dts/k3-am62a-wakeup.dtsi
delete mode 100644 arch/arm/dts/k3-am62a.dtsi
delete mode 100644 arch/arm/dts/k3-am62a7-sk.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5b0bcf336924..27f38908f268 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1203,8 +1203,7 @@ dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-r5-sk.dtb \
k3-am625-verdin-r5.dtb \
k3-am625-r5-phycore-som-2gb.dtb
-dtb-$(CONFIG_SOC_K3_AM62A7) += k3-am62a7-sk.dtb \
- k3-am62a7-r5-sk.dtb
+dtb-$(CONFIG_SOC_K3_AM62A7) += k3-am62a7-r5-sk.dtb
dtb-$(CONFIG_SOC_K3_AM62P5) += k3-am62p5-r5-sk.dtb
diff --git a/arch/arm/dts/k3-am62a-main.dtsi b/arch/arm/dts/k3-am62a-main.dtsi
deleted file mode 100644
index aa1e057082f0..
--- a/arch/arm/dts/k3-am62a-main.dtsi
+++ /dev/null
@@ -1,1054 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only OR MIT
-/*
- * Device Tree Source for AM62A SoC Family Main Domain peripherals
- *
- * Copyright (C) 2022-2024 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-_main {
- oc_sram: sram@7000 {
- compatible = "mmio-sram";
- reg = <0x00 0x7000 0x00 0x1>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x00 0x7000 0x1>;
- };
-
- gic500: interrupt-controller@180 {
- compatible = "arm,gic-v3";
- reg = <0x00 0x0180 0x00 0x1>, /* GICD */
- <0x00 0x0188 0x00 0xc>, /* GICR */
- <0x00 0x0188 0x00 0xc>, /* GICR */
- <0x01 0x 0x00 0x2000>,/* GICC */
- <0x01 0x0001 0x00 0x1000>,/* GICH */
- <0x01 0x0002 0x00 0x2000>;/* GICV */
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- #interrupt-cells = <3>;
- interrupt-controller;
- /*
-* vcpumntirq:
-* virtual CPU interface maintenance interrupt
-*/
- interrupts = ;
-
- gic_its: msi-controller@182 {
- compatible = "arm,gic-v3-its";
- reg = <0x00 0x0182 0x00 0x1>;
- socionext,synquacer-pre-its = <0x100 0x40>;
- msi-controller;
- #msi-cells = <1>;
- };
- };
-
- main_conf: bus@10 {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x00 0x00 0x0010 0x2>;
-
- phy_gmii_sel: phy@4044 {
- compatible = "ti,am654-phy-gmii-sel";
- reg = <0x4044 0x8>;
- #phy-cells = <1>;
- };
-
- epwm_tbclk: clock-controller@4130 {
- compatible = "ti,am62-epwm-tbclk";
- reg = <0x4130 0x4>;
- #clock-cells = <1>;
- };
- };
-
- dmss: bus@4800 {
- compatible = "simple-bus";
- #address-cells = <2>;
- #size-cells = <2>;
- dma-ranges;
- ranges = <0x00 0x4800 0x00 0x4800 0x00 0x0600>;
-
- ti,sci-dev-id = <25>;
-
- secure_proxy_main: mailbox@4d00 {
- compatible = "ti,am654-secure-proxy";
- reg = <0x00 0x4d00 0x00 0x8>,
- <0x00 0x4a60 0x00 0x8>,
- <0x00 0x4a40 0x00 0x8>;
- reg-names = "target_data", "rt", "scfg";
- #mbox-cells = <1>;
- interrupt-names = "rx_012";
- interrupts = ;
- };
-
- inta_main_dmss:
[PATCH 1/3] arm: dts: am625_beagleplay: Switch to OF_UPSTREAM
Enable OF_UPSTREAM for AM625-beagleplay board. Remove DT files that
are now available in dts/upstream. Update the appended files based on
version of latest OF_UPSTREAM sync point (v6.10-rc1).
Signed-off-by: Nishanth Menon
---
arch/arm/dts/Makefile| 1 -
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 4 +-
arch/arm/dts/k3-am625-beagleplay.dts | 932 ---
configs/am62x_beagleplay_a53_defconfig | 3 +-
4 files changed, 4 insertions(+), 936 deletions(-)
delete mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 624dadf8ece2..813426a3e519 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1200,7 +1200,6 @@ dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-r5-evm.dtb \
dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
k3-am625-r5-sk.dtb \
- k3-am625-beagleplay.dtb \
k3-am625-r5-beagleplay.dtb \
k3-am625-verdin-r5.dtb \
k3-am625-r5-phycore-som-2gb.dtb
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index 9ac4a825f841..dd5b335ed2ee 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -66,9 +66,9 @@
#ifdef CONFIG_TARGET_AM625_A53_BEAGLEPLAY
#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
-#define SPL_AM625_BEAGLEPLAY_DTB "spl/dts/k3-am625-beagleplay.dtb"
+#define SPL_AM625_BEAGLEPLAY_DTB "spl/dts/ti/k3-am625-beagleplay.dtb"
#define UBOOT_NODTB "u-boot-nodtb.bin"
-#define AM625_BEAGLEPLAY_DTB "arch/arm/dts/k3-am625-beagleplay.dtb"
+#define AM625_BEAGLEPLAY_DTB
"dts/upstream/src/arm64/ti/k3-am625-beagleplay.dtb"
{
ti-dm {
diff --git a/arch/arm/dts/k3-am625-beagleplay.dts
b/arch/arm/dts/k3-am625-beagleplay.dts
deleted file mode 100644
index 8ab838f1697c..
--- a/arch/arm/dts/k3-am625-beagleplay.dts
+++ /dev/null
@@ -1,932 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only OR MIT
-/*
- * https://beagleplay.org/
- *
- * Copyright (C) 2022-2024 Texas Instruments Incorporated - https://www.ti.com/
- * Copyright (C) 2022-2024 Robert Nelson, BeagleBoard.org Foundation
- */
-
-/dts-v1/;
-
-#include
-#include
-#include
-#include "k3-am625.dtsi"
-
-/ {
- compatible = "beagle,am625-beagleplay", "ti,am625";
- model = "BeagleBoard.org BeaglePlay";
-
- aliases {
- ethernet0 = _port1;
- ethernet1 = _port2;
- gpio0 = _gpio0;
- gpio1 = _gpio1;
- gpio2 = _gpio0;
- i2c0 = _i2c0;
- i2c1 = _i2c1;
- i2c2 = _i2c2;
- i2c3 = _i2c3;
- i2c4 = _i2c0;
- i2c5 = _i2c0;
- mmc0 =
- mmc1 =
- mmc2 =
- rtc0 =
- serial0 = _uart5;
- serial1 = _uart6;
- serial2 = _uart0;
- usb0 =
- usb1 =
- };
-
- chosen {
- stdout-path = "serial2:115200n8";
- };
-
- memory@8000 {
- bootph-pre-ram;
- device_type = "memory";
- /* 2G RAM */
- reg = <0x 0x8000 0x 0x8000>;
- };
-
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- ramoops: ramoops@9ca0 {
- compatible = "ramoops";
- reg = <0x00 0x9ca0 0x00 0x0010>;
- record-size = <0x8000>;
- console-size = <0x8000>;
- ftrace-size = <0x00>;
- pmsg-size = <0x8000>;
- };
-
- secure_tfa_ddr: tfa@9e78 {
- reg = <0x00 0x9e78 0x00 0x8>;
- no-map;
- };
-
- secure_ddr: optee@9e80 {
- reg = <0x00 0x9e80 0x00 0x0180>;
- no-map;
- };
-
- wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9db0 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9db0 0x00 0xc0>;
- no-map;
- };
- };
-
- vsys_5v0: regulator-1 {
- bootph-all;
- compatible = "regulator-fixed";
- regulator-name = "vsys_5v0";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- vdd_3v3: regulator-2 {
- /* output of TLV62595DMQR-U12 */
- bootph-all;
- compatible = "regulator-fixed";
-
[PATCH 0/3] arm: dts: am625/am62a7: Switch over to OF_UPSTREAM
Cleanup am625 on by switching over the last two platforms (SK and beagleplay) over to OF_UPSTREAM, and while at it, switch over am62a7 (last of the am62* family) over as well. This superscedes the previous version of beagleplay only patch[1] Test logs: https://gist.github.com/nmenon/ba310d3750a80789aca6a4fd90190135 Nishanth Menon (3): arm: dts: am625_beagleplay: Switch to OF_UPSTREAM arm: dts: am625_sk: Switch to OF_UPSTREAM arm: dts: am62a7_sk: Switch to OF_UPSTREAM arch/arm/dts/Makefile|7 +- arch/arm/dts/k3-am62-main.dtsi | 1058 -- arch/arm/dts/k3-am62-mcu.dtsi| 176 --- arch/arm/dts/k3-am62-thermal.dtsi| 36 - arch/arm/dts/k3-am62-wakeup.dtsi | 96 -- arch/arm/dts/k3-am62.dtsi| 122 -- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi |4 +- arch/arm/dts/k3-am625-beagleplay.dts | 932 --- arch/arm/dts/k3-am625-sk-binman.dtsi |2 +- arch/arm/dts/k3-am625-sk.dts | 299 - arch/arm/dts/k3-am625.dtsi | 155 --- arch/arm/dts/k3-am62a-main.dtsi | 1054 - arch/arm/dts/k3-am62a-mcu.dtsi | 170 --- arch/arm/dts/k3-am62a-sk-binman.dtsi |2 +- arch/arm/dts/k3-am62a-thermal.dtsi | 50 - arch/arm/dts/k3-am62a-wakeup.dtsi| 73 -- arch/arm/dts/k3-am62a.dtsi | 125 --- arch/arm/dts/k3-am62a7-sk.dts| 702 arch/arm/dts/k3-am62x-sk-common.dtsi | 535 - configs/am62ax_evm_a53_defconfig |3 +- configs/am62x_beagleplay_a53_defconfig |3 +- configs/am62x_evm_a53_defconfig |3 +- 22 files changed, 12 insertions(+), 5595 deletions(-) delete mode 100644 arch/arm/dts/k3-am62-main.dtsi delete mode 100644 arch/arm/dts/k3-am62-mcu.dtsi delete mode 100644 arch/arm/dts/k3-am62-thermal.dtsi delete mode 100644 arch/arm/dts/k3-am62-wakeup.dtsi delete mode 100644 arch/arm/dts/k3-am62.dtsi delete mode 100644 arch/arm/dts/k3-am625-beagleplay.dts delete mode 100644 arch/arm/dts/k3-am625-sk.dts delete mode 100644 arch/arm/dts/k3-am625.dtsi delete mode 100644 arch/arm/dts/k3-am62a-main.dtsi delete mode 100644 arch/arm/dts/k3-am62a-mcu.dtsi delete mode 100644 arch/arm/dts/k3-am62a-thermal.dtsi delete mode 100644 arch/arm/dts/k3-am62a-wakeup.dtsi delete mode 100644 arch/arm/dts/k3-am62a.dtsi delete mode 100644 arch/arm/dts/k3-am62a7-sk.dts delete mode 100644 arch/arm/dts/k3-am62x-sk-common.dtsi [1] https://lore.kernel.org/u-boot/20240604134751.249048-1...@ti.com/ base-commit: 227be29df37545f74243a98c12a4a33c4160e3cd -- 2.43.0
Re: [PATCH v2 0/8] efi_loader: improve device-tree loading
Hi Simon, [...] > > >>> > > >> > > > > > > Can we use the best-match compatible approach as expected by the new > > > 'make image.fit' in Linux? > > > > > > Filenames should be deprecated IMO. I am happy to help work on how to > > > do that if you agree. > > > > Hello Simon, > > > > It is the OS that creates boot options. The OS can determine the exact > > dtb file based on the compatible string and the kernel version once per > > kernel upgrade. This is much more efficient than doing the same on every > > boot. > > > > Replacing $fdtfile by a matching logic could make sense. But please > > consider the effect on boot time if have to read through more than 1000 > > arm64 dtbs with U-Boot's non-caching file-system drivers. > > The suggested option here is to use FIT, which is very fast at > scanning the files. Please see [1] > > Failing that, we could implement a way (in FIT) of specifying that the > FDT is in an external file. In that case FIT would become a mapping > from compatible strings to filenames. This is kind of irrelevant to FIT. This is how the efibootmgr configures the files it has to load. commit 76e8acce12fe, commit 53f6a5aa8626, and doc/develop/uefi/uefi.rst, Chapter Load file 2 protocol has enough information of how the initrd is implemented. What Heinrich is doing here is extending the existing code to load a DT Regards /Ilias > > Regards, > Simon > > [1] > https://github.com/open-source-firmware/flat-image-tree/blob/main/source/chapter3-usage.rst
Re: [PATCH v3 03/25] mbedtls: add mbedtls into the build system
On Wed, Jun 05, 2024 at 04:30:58PM +0300, Ilias Apalodimas wrote: > Hi Andy, > > [...] > > > > > > > Is this approach maintainable? > > > > > > I don't remember if we have similar in Linux kernel, for example. > > > > > > (There are few candidates like compression algorithms that are > > > > > > usually > > > > > > being > > > > > > hosted elsewhere) > > > > > > > > No answer? > > > > > > subtrees is what was decided on OF_UPSRTEAM as well. If you have a > > > better idea feel free to propose it, but for the sake of conformance > > > we are better off doing the same thing on every external tree we pull > > > in > > > > How do they will (or already do) maintain this? > > > > There's a script to do that in dts/update-dts-subtree.sh And with: https://patchwork.ozlabs.org/project/uboot/patch/20240517174930.1028063-2-tr...@konsulko.com/ we document the frequency and rules for the resync. The mbedTLS (and lwIP) series need to do similar. -- Tom signature.asc Description: PGP signature
RE: [External] Re: [PATCH 2/3] tools: binman: fix deprecated Python ConfigParser methods
Hi Simon, > -Original Message- > From: Simon Glass > Sent: Tuesday, June 4, 2024 9:14 PM > To: Maier, Brandon L Collins > Cc: u-boot@lists.denx.de > Subject: [External] Re: [PATCH 2/3] tools: binman: fix deprecated Python > ConfigParser methods > > Hi Brandon, > > On Tue, 4 Jun 2024 at 10:16, Brandon Maier > wrote: > > > > The method `ConfigParser.readfp()` is marked deprecated[1]. > > > > In Python 3.12 this method have been removed, so replace it with > > `ConfigParser.read_file()`. > > > > [1] > https://docs.python.org/3.11/library/configparser.html#configparser.ConfigParser.read_file > > Signed-off-by: Brandon Maier > > CC: Simon Glass > > --- > > tools/buildman/bsettings.py | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > Does this still work in earlier Pythons? The Python docs say ConfigParser.read_file() was added in Python 3.2. The tools/buildman/pyproject.toml says `requires-python = ">=3.7"` so I assume this is fine. > > Regards, > Simon
Re: [PATCH] cmd: fwu: Also print information about size
On Wed, 5 Jun 2024 at 17:58, Michal Simek wrote:
>
> It is useful when structure is also used for saving vendor data covered
> by CRC32.
>
> Signed-off-by: Michal Simek
> ---
>
> cmd/fwu_mdata.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
> index 3c8be576ac7a..9c048d69a131 100644
> --- a/cmd/fwu_mdata.c
> +++ b/cmd/fwu_mdata.c
> @@ -22,6 +22,7 @@ static void print_mdata(struct fwu_data *data)
> printf("\tFWU Metadata\n");
> printf("crc32: %#x\n", data->crc32);
> printf("version: %#x\n", data->version);
> + printf("size: %#x\n", data->metadata_size);
That's only available in v2
IS_ENABLED(CONFIG_FWU_MDATA_V1) etc?
> printf("active_index: %#x\n", data->active_index);
> printf("previous_active_index: %#x\n", data->previous_active_index);
>
> --
> 2.40.1
>
Cheers
/Ilias
Re: [PATCH] fs/erofs: fix an overflow issue of unmapped extents
On 2024/6/5 22:05, Jianan Huang wrote:
Here the size should be `length - skip`, otherwise it could cause
the destination buffer overflow.
Reported-by: jianqiang wang
Fixes: 65cb73057b65 ("fs/erofs: add lz4 decompression support")
Signed-off-by: Jianan Huang
Reviewed-by: Gao Xiang
Thanks,
Gao Xiang
[PATCH] cmd: fwu: Also print information about size
It is useful when structure is also used for saving vendor data covered
by CRC32.
Signed-off-by: Michal Simek
---
cmd/fwu_mdata.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 3c8be576ac7a..9c048d69a131 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -22,6 +22,7 @@ static void print_mdata(struct fwu_data *data)
printf("\tFWU Metadata\n");
printf("crc32: %#x\n", data->crc32);
printf("version: %#x\n", data->version);
+ printf("size: %#x\n", data->metadata_size);
printf("active_index: %#x\n", data->active_index);
printf("previous_active_index: %#x\n", data->previous_active_index);
--
2.40.1
[RFC PATCH] cmd: fwu: Dump custom fields from mdata structure
The commit cb9ae40a16f0 ("tools: mkfwumdata: add logic to append vendor
data to the FWU metadata") added support for adding vendor data to mdata
structure but it is not visible anywhere that's why extend fwu command to
dump it.
Signed-off-by: Michal Simek
---
I am using this for some time to check various configurations that's why it
can be useful for others too.
Sughosh: Maybe there is better way how to dump it.
---
cmd/fwu_mdata.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 9c048d69a131..ff6435505167 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,30 @@ static void print_mdata(struct fwu_data *data)
img_info->accepted == 0x1 ? "yes" : "no");
}
}
+
+ if (data->version == 2) {
+ struct fwu_mdata *mdata = data->fwu_mdata;
+ struct fwu_fw_store_desc *desc;
+ void *end;
+ u32 diff;
+
+ /*
+* fwu_mdata defines only header that's why taking it as array
+* which exactly point to image description location
+*/
+ desc = (struct fwu_fw_store_desc *)[1];
+
+ /* Number of entries is taken from for loop - variable i */
+ end = >img_entry[i];
+ debug("mdata %p, desc %p, end %p\n", mdata, desc, end);
+
+ diff = data->metadata_size - ((void *)end - (void *)mdata);
+ if (diff) {
+ printf("Custom fields covered by CRC 0x%x\n", diff);
+ print_hex_dump_bytes("CUSTOM ", DUMP_PREFIX_OFFSET,
+end, diff);
+ }
+ }
}
int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
--
2.40.1
Re: [PATCH] arm: dts; am625_beagleplay: Switch to OF_UPSTREAM
On 08:47-20240604, Nishanth Menon wrote: > Enable OF_UPSTREAM for AM625-beagleplay board. Remove DT files that > are now available in dts/upstream. Update the appended files based on > version of latest OF_UPSTREAM sync point (v6.10-rc1). > > Signed-off-by: Nishanth Menon > --- > > Based off u-boot > next 15d0dcc0ec1f Merge tag 'u-boot-imx-next-20240603' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next > Doing a bit more cleanup since I got a few mins to do it.. will resubmit this patch as part of a series. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 9/9] Revert "arm: am335x: Enable SPL_OF_CONTROL on some configs"
On Tue, Jun 04, 2024 at 09:25:21PM -0600, Simon Glass wrote: > This is a partial revert which makes boneblack_vboot boot again. > > This reverts commit f4b64e9736e73ceec14d51600bed9a8ac48f9fe8. > > Signed-off-by: Simon Glass > --- > > configs/am335x_boneblack_vboot_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/am335x_boneblack_vboot_defconfig > b/configs/am335x_boneblack_vboot_defconfig > index d473a1a793b..3ec4abddd77 100644 > --- a/configs/am335x_boneblack_vboot_defconfig > +++ b/configs/am335x_boneblack_vboot_defconfig > @@ -40,7 +40,6 @@ CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > # CONFIG_CMD_SETEXPR is not set > CONFIG_BOOTP_DNS2=y > CONFIG_OF_CONTROL=y > -CONFIG_SPL_OF_CONTROL=y > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_IS_IN_MMC=y > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y So, this change was a while ago. But I did it because some of the drivers, tho I forget which ones exactly, really were not functional without SPL_OF_CONTROL enabled. That said, does am335x_evm_defconfig work in your configuration? I think we have to keep am335x_evm_spiboot because it's so radically different from how the rest of the possible options boot, but I'm not sure we need a vboot defconfig? Or if we do, it should be updated to use the #include logic these days. -- Tom signature.asc Description: PGP signature
Re: [PATCH 6/9] spl: Allow ATF to work when dcache is disabled
On Tue, Jun 04, 2024 at 09:25:18PM -0600, Simon Glass wrote: > The dcache may not be enabled in SPL. Add a check to avoid trying to > use an undefined function. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 0/4] Sync StarFive JH7110 clock and reset dt-bindings with Linux
On Wed, Jun 05, 2024 at 01:56:13AM +, Hal Feng wrote: > > On 04.06.24 04:32, E Shattow wrote: > > Hi Hal, > > > > Instead of manual dt-bindings sync can we please adopt OF_UPSTREAM for > > JH7110 ? > > Yeah, I will try to do it recently, although I am not sure whether the U-Boot > drivers and Linux drivers are compatible so that they can use the same DT. They must be compatible so that they can use the same DT, U-Boot needs updating if it doesn't match. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 03/25] mbedtls: add mbedtls into the build system
Hi Andy and Ilias, On Wed, 5 Jun 2024 at 09:31, Ilias Apalodimas wrote: > Hi Andy, > > [...] > > > > > > > Is this approach maintainable? > > > > > > I don't remember if we have similar in Linux kernel, for example. > > > > > > (There are few candidates like compression algorithms that are > usually > > > > > > being > > > > > > hosted elsewhere) > > > > > > > > No answer? > > > > > > subtrees is what was decided on OF_UPSRTEAM as well. If you have a > > > better idea feel free to propose it, but for the sake of conformance > > > we are better off doing the same thing on every external tree we pull > > > in > > > > How do they will (or already do) maintain this? > > > > There's a script to do that in dts/update-dts-subtree.sh > > > At least it's a good to have a few words on the choice made in the cover > > letter, so we will have no questions on it. > > > > > > > > > Moreover, due to the Windows-style files from mbedtls git repo, > > > > > > > we need to convert the CRLF endings to LF and do a commit > manually: > > > > > > > > > > > > > > $ git add --renormalize . > > > > > > > $ git commit > > > > ... > > > > > > > > > lib/mbedtls/mbedtls_def_config.h | 4262 > ++ > > > > > > > > > > > > This is ridiculously HUGE! This is unreviewable. Moreover, this > is even > > > > > > hard to > > > > > > configure by the user! Can you rather make it modular and maybe > create a > > > > > > separate documentation for the most important options (I do not > believe one > > > > > > needs _all_ of them to be set / tuned)? > > > > > > > > > > > > This is a file from MbedTLS and follows its own style. > > > > > And this is how MbedTLS is configured - with all features listed > in a > > > > > config file and > > > > > commenting out the unused features with "//"). > > > > > The modification here is just to control those existing options > with > > > > > Kconfigs. > > > > > > > > And why should we blindly follow this nonsense? > > > > > > It's easier to follow up future changes tbh. But I do agree the config > > > file is huge. Perhaps splitting in 2 files is going to be easier > > > mbedtls_def_config.h -> contains all the options that rarely need > > > tuning, which I assume is the majority of the header > > > mbedtls_usef_config.h -> contains the imporant options, crypto, > > > checksum algorithms etc > > > > > > Thoughts? > > > > The problem is on who decides which are "rarely need". > > Us. Sure it's going to take some time, but eventually we should be > able to isolate options that rarely need a change > > > The feasible (to me) approach is to split per domain. Like you listed at > the very end of your reply. > > We can also learn from managing MTA configurations, such as Exim4 where > user > > may decide if they want a single file or split version. > > I am not sure tbh. Let me backpaddle from my previous suggestion :). > Looking at it closer config.h is copied from mbedTLS, commenting out > features we don't want. > > What we could do instead is either trim those comments out and only > define the options we need for now. That would make the patch easily > reviewable. If in the future we decide we need a more modular > approach, we can retrofit it without breaking anything. > > Alternatively, we can undef the options we don't want in our header, > but I am not sure how often these change or how scalable this is going > to end up being. I prefer option #1 > > I can remove the disabled features and only keep the ones that should be controlled by the Kconfigs if you don't want a huge list for user's fine-tune. Currently most of them can be regarded as default setting by U-Boot. In the future if any of them needs to be exposed as a Kconfig for tuning, we can add them back. Regards, Raymond
Re: Several potential vulnerabilities in the filesystem
On 2024/6/5 19:18, Gao Xiang wrote:
> Hi Jianqiang,
>
> On 2024/6/5 19:00, jianqiang wang wrote:
>> Hi,
>>
>> I do have the crafted image.
>>
>> payload_00500, payload_00763, payload_00846 can be used to reproduce
>> 1,2,3 vulnerabilities respectively.
>>
>> Each image is a hard drive file and the vulnerabilities can be
>> triggered by performing the following operations:
>>
>> struct udevice *dev;
>> uclass_first_device_err(UCLASS_IDE, ); //detect the block
>> device
>>
>> fs_set_blk_dev("ide","0:1", 0);
>> fs_ls("/"); //mount the first partition and list the root
>> directory files
>>
>> fs_set_blk_dev("ide","0:1", 0);
>> char buf[10];
>> buf[0] = 0;
>> buf[1] = 0;
>> buf[2] = 0;
>> buf[3] = 0;
>> loff_t actread = 0;
>> fs_read("/a.txt", (ulong)buf, 0, 5, );
>> printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
>> read the /a.txt file
>>
>>
>> fs_set_blk_dev("ide","0:1", 0);
>> fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
>> printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
>> read the /a.txt.ln symbol file
>>
>> fs_set_blk_dev("ide","0:1", 0);
>> fs_unlink("/a.txt.ln"); //unlink it
>>
>> The second and third may not trigger a crash however, can be observed
>> by inserting logging before the memset/memcpy function.
>
> Sorry, I just found that this issue was already fixed in erofs-utils:
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
>
>
> Would you mind checking if the patch above fixes the issue?
>
> Hi Jianan,
> Would you mind backporting this patch for u-boot?
https://lore.kernel.org/u-boot/20240605140554.1883-1-jnhuan...@gmail.com/T/#u
Thanks,
Jianan
>
> Thanks,
> Gao Xiang
>
>>
>> Best regards
>>
>> Gao Xiang 于2024年6月5日周三 05:10写道：
>>>
>>>
>>>
>>> On 2024/6/5 06:53, jianqiang wang wrote:
Hi Das U-Boot developers,
>>>
>>> ...
>>>
2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
data is read from the storage, however, without a proper check, the
data can be corrupted. For example, the inode data is used in function
z_erofs_read_data, map.m_llen will be calculated to a very large
value, which means the length variable will be very large. It will
cause a large memory clear with memset(buffer + end - offset, 0,
length);
>>>
>>> Would you mind giving a reproducer or a crafted image to trigger
>>> this? Or it's your pure observation.
>>>
>>> Thanks,
>>> Gao XIang
>>>
[PATCH] fs/erofs: fix an overflow issue of unmapped extents
Here the size should be `length - skip`, otherwise it could cause
the destination buffer overflow.
Reported-by: jianqiang wang
Fixes: 65cb73057b65 ("fs/erofs: add lz4 decompression support")
Signed-off-by: Jianan Huang
---
fs/erofs/data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index f4b21d7917..95b609d8ea 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -313,7 +313,7 @@ static int z_erofs_read_data(struct erofs_inode *inode,
char *buffer,
}
if (!(map.m_flags & EROFS_MAP_MAPPED)) {
- memset(buffer + end - offset, 0, length);
+ memset(buffer + end - offset, 0, length - skip);
end = map.m_la;
continue;
}
--
2.34.1
Re: [PATCH v2 0/8] efi_loader: improve device-tree loading
On 05.06.24 15:17, Simon Glass wrote: Hi Heinrich, On Wed, 5 Jun 2024 at 02:40, Heinrich Schuchardt wrote: On 29.05.24 18:30, Simon Glass wrote: Hi, On Tue, 28 May 2024 at 18:38, E Shattow wrote: Hi, On Tue, May 28, 2024 at 7:43 AM Heinrich Schuchardt wrote: In U-Boot EFI boot options can already specify both an EFI binary and an initrd. With this series we can additionally define the matching device-tree to be loaded in the boot option. With the last patch the boot manager will fall back the device-tree specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' on the boot device if no device-tree is specified in the boot option or via a bootefi command parameter. As tested the $fdtfile environment variable has no effect on global EFI boot when i.e. EFI/BOOT/BOOTRISCV64.EFI on EFI System Partition and no user-added boot option; $fdtfile env variable is not used with "mmc 0" or whichever global boot option is enabled by default in the boot order. Adding a boot option for EFI/BOOT/BOOTRISCV64.EFI and giving this priority in the boot order allows $fdtfile to be effective here. This is consistent with what is described by the series. Would the global EFI boot also get support for $fdtfile either with this or a later series? v2: Update efi_dp_concat() instead of new function efi_dp_merge(). Carve out a function efi_load_option_dp_join() which we can use both for the eficonfig and the efidebug command. Rename variables id_dp, final_dp_size. Rename create_initrd_dp() to create_lo_dp_part(). Use enum as parameter for create_lo_dp_part(). Put all related changes into one patch. Heinrich Schuchardt (8): efi_loader: allow concatenation with contained end node cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr boot/bootmeth_efi.c| 60 +- cmd/eficonfig.c| 83 + cmd/efidebug.c | 130 +++-- include/efi_loader.h | 24 +++- lib/efi_loader/Makefile| 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 75 +++- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 40 --- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 +++ lib/efi_loader/efi_helper.c| 44 +++ 12 files changed, 445 insertions(+), 136 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c -- 2.43.0 Can we use the best-match compatible approach as expected by the new 'make image.fit' in Linux? Filenames should be deprecated IMO. I am happy to help work on how to do that if you agree. Hello Simon, It is the OS that creates boot options. The OS can determine the exact dtb file based on the compatible string and the kernel version once per kernel upgrade. This is much more efficient than doing the same on every boot. Replacing $fdtfile by a matching logic could make sense. But please consider the effect on boot time if have to read through more than 1000 arm64 dtbs with U-Boot's non-caching file-system drivers. The suggested option here is to use FIT, which is very fast at scanning the files. Please see [1] Failing that, we could implement a way (in FIT) of specifying that the FDT is in an external file. In that case FIT would become a mapping from compatible strings to filenames. FIT has no place in UEFI. Best regards Heinrich
Re: [PATCH v3 6/7] tools: add genguid tool
+ CC Sughosh On Wed, 5 Jun 2024 at 15:29, Caleb Connolly wrote: > > > > On 05/06/2024 11:25, Ilias Apalodimas wrote: > > Hi Heinrich > > > > On Wed, 5 Jun 2024 at 09:36, Heinrich Schuchardt wrote: > >> > >> On 5/31/24 15:50, Caleb Connolly wrote: > >>> Add a tool that can generate GUIDs that match those generated internally > >>> by U-Boot for capsule update fw_images. > >>> > >>> Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it > >>> with the board model, compatible, and fw_image name. > >>> > >>> This tool accepts the same inputs and will produce the same GUID as > >>> U-Boot would at runtime. > >> > >> This functionality should be integrated into the mkeficapsule. > >> > >> Just pass the device-tree into mkeficapsule and generate the GUIDs > >> whereever they are needed. > > > > I like the idea of moving this mkeficapsule which is already part of > > distro packages but, isn't it easier to pass the compatible string > > node and the namespace? > > Yeah, we only need the first entry in the compatible property, so > parsing the whole DT is a bit overkill. > > I can look at combining these tools, can mkeficapsule generate a capsule > for multiple images? Not yet. There's [0] which adds that functionality but we are discussing parsing a .yaml file instead of a custom format > > Would we want it to work such that you provide the namespace GUID, > compatible, and image names, and have it generate a capsule with the > right image GUIDs? > > Or would it be simple enough to just incorporate the functionality of > genguid? > I'd argue for both since people might choose other tools to generate a capsule. So you want 2 flags ideally (random flags) -x: dump the autogenerated GUIDs -y use the autogenerated GUIDs on capsule generation Since mkeficapsule can't generate a capsule with multiple payloads yet, you will be limited to just one, but I guess it's easy to expand it once [0] is merged [0] https://lore.kernel.org/u-boot/20240419065542.1160527-1-sughosh.g...@linaro.org/ Thanks /Ilias
Needs a check in the device tree
Dear Das U-Boot developers, I found that the u-boot device tree implementation lacks a check for the off_dt_struct field in the device tree. In file scripts\dtc\libfdt\libfdt_internal.h, fdt_offset_ptr_ returns the dt struct address. It calculates the address by adding the header address, fdt offset, and a specified offset. However, the fdt offset is read from the device tree and lacks a proper check. The returned pointer can even point to any address, leading to arbitrary read or write. Could you please confirm it is a vulnerability? best regards Jianqiang
Re: [PATCH v3 03/25] mbedtls: add mbedtls into the build system
Hi Andy, [...] > > > > > Is this approach maintainable? > > > > > I don't remember if we have similar in Linux kernel, for example. > > > > > (There are few candidates like compression algorithms that are usually > > > > > being > > > > > hosted elsewhere) > > > > > > No answer? > > > > subtrees is what was decided on OF_UPSRTEAM as well. If you have a > > better idea feel free to propose it, but for the sake of conformance > > we are better off doing the same thing on every external tree we pull > > in > > How do they will (or already do) maintain this? > There's a script to do that in dts/update-dts-subtree.sh > At least it's a good to have a few words on the choice made in the cover > letter, so we will have no questions on it. > > > > > > > Moreover, due to the Windows-style files from mbedtls git repo, > > > > > > we need to convert the CRLF endings to LF and do a commit manually: > > > > > > > > > > > > $ git add --renormalize . > > > > > > $ git commit > > ... > > > > > > > lib/mbedtls/mbedtls_def_config.h | 4262 > > > > > > ++ > > > > > > > > > > This is ridiculously HUGE! This is unreviewable. Moreover, this is > > > > > even > > > > > hard to > > > > > configure by the user! Can you rather make it modular and maybe > > > > > create a > > > > > separate documentation for the most important options (I do not > > > > > believe one > > > > > needs _all_ of them to be set / tuned)? > > > > > > > > > > This is a file from MbedTLS and follows its own style. > > > > And this is how MbedTLS is configured - with all features listed in a > > > > config file and > > > > commenting out the unused features with "//"). > > > > The modification here is just to control those existing options with > > > > Kconfigs. > > > > > > And why should we blindly follow this nonsense? > > > > It's easier to follow up future changes tbh. But I do agree the config > > file is huge. Perhaps splitting in 2 files is going to be easier > > mbedtls_def_config.h -> contains all the options that rarely need > > tuning, which I assume is the majority of the header > > mbedtls_usef_config.h -> contains the imporant options, crypto, > > checksum algorithms etc > > > > Thoughts? > > The problem is on who decides which are "rarely need". Us. Sure it's going to take some time, but eventually we should be able to isolate options that rarely need a change > The feasible (to me) approach is to split per domain. Like you listed at the > very end of your reply. > We can also learn from managing MTA configurations, such as Exim4 where user > may decide if they want a single file or split version. I am not sure tbh. Let me backpaddle from my previous suggestion :). Looking at it closer config.h is copied from mbedTLS, commenting out features we don't want. What we could do instead is either trim those comments out and only define the options we need for now. That would make the patch easily reviewable. If in the future we decide we need a more modular approach, we can retrofit it without breaking anything. Alternatively, we can undef the options we don't want in our header, but I am not sure how often these change or how scalable this is going to end up being. I prefer option #1 Regards /Ilias > > -- > With Best Regards, > Andy Shevchenko > >
Re: [PATCH v2 0/8] efi_loader: improve device-tree loading
Hi Heinrich, On Wed, 5 Jun 2024 at 02:40, Heinrich Schuchardt wrote: > > On 29.05.24 18:30, Simon Glass wrote: > > Hi, > > > > On Tue, 28 May 2024 at 18:38, E Shattow wrote: > >> > >> Hi, > >> > >> On Tue, May 28, 2024 at 7:43 AM Heinrich Schuchardt > >> wrote: > >>> > >>> In U-Boot EFI boot options can already specify both an EFI binary and > >>> an initrd. With this series we can additionally define the matching > >>> device-tree to be loaded in the boot option. > >>> > >>> With the last patch the boot manager will fall back the device-tree > >>> specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' > >>> on the boot device if no device-tree is specified in the boot > >>> option or via a bootefi command parameter. > >>> > >> > >> As tested the $fdtfile environment variable has no effect on > >> global EFI boot when i.e. EFI/BOOT/BOOTRISCV64.EFI > >> on EFI System Partition and no user-added boot option; > >> $fdtfile env variable is not used with "mmc 0" or whichever > >> global boot option is enabled by default in the boot order. > >> > >> Adding a boot option for EFI/BOOT/BOOTRISCV64.EFI > >> and giving this priority in the boot order allows $fdtfile to > >> be effective here. This is consistent with what is described > >> by the series. Would the global EFI boot also get support > >> for $fdtfile either with this or a later series? > >> > >>> v2: > >>> Update efi_dp_concat() instead of new function efi_dp_merge(). > >>> Carve out a function efi_load_option_dp_join() which we can > >>> use both for the eficonfig and the efidebug command. > >>> Rename variables id_dp, final_dp_size. > >>> Rename create_initrd_dp() to create_lo_dp_part(). > >>> Use enum as parameter for create_lo_dp_part(). > >>> Put all related changes into one patch. > >>> > >>> Heinrich Schuchardt (8): > >>>efi_loader: allow concatenation with contained end node > >>>cmd: eficonfig: add support for setting fdt > >>>cmd: efidebug: add support for setting fdt > >>>efi_loader: load device-tree specified in boot option > >>>efi_loader: move distro_efi_get_fdt_name() > >>>efi_loader: return binary from efi_dp_from_lo() > >>>efi_loader: export efi_load_image_from_path > >>>efi_loader: load distro dtb in bootmgr > >>> > >>> boot/bootmeth_efi.c| 60 +- > >>> cmd/eficonfig.c| 83 + > >>> cmd/efidebug.c | 130 +++-- > >>> include/efi_loader.h | 24 +++- > >>> lib/efi_loader/Makefile| 1 + > >>> lib/efi_loader/efi_bootbin.c | 2 +- > >>> lib/efi_loader/efi_bootmgr.c | 75 +++- > >>> lib/efi_loader/efi_boottime.c | 3 +- > >>> lib/efi_loader/efi_device_path.c | 40 --- > >>> lib/efi_loader/efi_device_path_utilities.c | 2 +- > >>> lib/efi_loader/efi_fdt.c | 117 +++ > >>> lib/efi_loader/efi_helper.c| 44 +++ > >>> 12 files changed, 445 insertions(+), 136 deletions(-) > >>> create mode 100644 lib/efi_loader/efi_fdt.c > >>> > >>> -- > >>> 2.43.0 > >>> > >> > > > > Can we use the best-match compatible approach as expected by the new > > 'make image.fit' in Linux? > > > > Filenames should be deprecated IMO. I am happy to help work on how to > > do that if you agree. > > Hello Simon, > > It is the OS that creates boot options. The OS can determine the exact > dtb file based on the compatible string and the kernel version once per > kernel upgrade. This is much more efficient than doing the same on every > boot. > > Replacing $fdtfile by a matching logic could make sense. But please > consider the effect on boot time if have to read through more than 1000 > arm64 dtbs with U-Boot's non-caching file-system drivers. The suggested option here is to use FIT, which is very fast at scanning the files. Please see [1] Failing that, we could implement a way (in FIT) of specifying that the FDT is in an external file. In that case FIT would become a mapping from compatible strings to filenames. Regards, Simon [1] https://github.com/open-source-firmware/flat-image-tree/blob/main/source/chapter3-usage.rst
Re: [PATCH v5 0/3] Introduce mtdblock device
Hi Alexey, On Wed, 5 Jun 2024 at 04:09, Alexey Romanov wrote: > > Hi Simon, > your message is empty. > > On Tue, Jun 04, 2024 at 08:13:34PM -0600, Simon Glass wrote: > > Hi Alexey, > > > > On Mon, Jun 3, 2024, 09:57 Alexey Romanov > > wrote: > > > > > Hello! > > > > > > This series adds support for the mtdblock device, which > > > allows to read/write data block by block. For example, > > > it can now be used for BCB or Android AB command: > > > > > > $ bcb load mtd 0 part_name > > > > > > Tested only on SPI NAND, so bind is made only for > > > SPI NAND drivers. > > > > > > --- > > > > > > Changes V1 -> V2 [1]: > > > > > > - Drop patch [2]. > > > - Add warning if bind NAND mtdblock device. > > > - Move documentation of mtdblock implementation > > > from commit message to the source code. > > > - Remove __maybe_unused from mtd partition functions > > > description. > > > - Use blk_enabled() instead of #ifdefs. > > > > > > Changes V2 -> V3 [2]: > > > > > > - Rebased over [3]. > > > - Rename mtd_bread/bwrite -> mtd_blk_read/write. > > > - Fix GPL-2.0 license short name definiton in headers. > > > - Add empty line after MTD_ENTRY_NUMBERS define. > > > > > > Changes V3 -> V4 [4]: > > > > > > - Fix build warnings: use LBAF printf format string for lbaint_t types. > > > > > > Changes V4 -> V5 [5]: > > > > > > - Rebased over u-boot/master. > > > - Fix build errors and warnings if CONFIG_BLK isn't enabled. > > > - Fix failed tests in cases is mtdblock device isn't binded. > > > > > > Links: > > > > > > - [1] > > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > > - [2] > > > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > > > - [3] > > > https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u > > > - [4] > > > https://lore.kernel.org/all/20240404105813.1520732-1-avroma...@salutedevices.com/ > > > - [5] > > > https://lore.kernel.org/all/20240524102920.2631731-1-avroma...@salutedevices.com/ > > > > > > Alexey Romanov (3): > > > disk: support MTD partitions > > > drivers: introduce mtdblock abstraction > > > spinand: bind mtdblock > > > > > > disk/part.c | 3 +- > > > drivers/block/blk-uclass.c | 1 + > > > drivers/mtd/Kconfig | 1 + > > > drivers/mtd/Makefile| 1 + > > > drivers/mtd/mtdblock.c | 227 > > > drivers/mtd/mtdpart.c | 76 > > > drivers/mtd/nand/spi/core.c | 20 > > > include/linux/mtd/mtd.h | 21 > > > include/part.h | 3 + > > > 9 files changed, 352 insertions(+), 1 deletion(-) > > > create mode 100644 drivers/mtd/mtdblock.c > > > > > > -- > > > 2.34.1 > > > > > > > Are you able to add a sandbox test for this code? Regards, Simon
Re: [PATCH 0/3] rockchip: rk8xx: fix broken [np]ldo callbacks
Hi Quentin, On Wed, 5 Jun 2024 at 15:03, Quentin Schulz wrote: > > This is for master branch, merge ASAP as it's known to break at least > Chromebook Jerry. > > @Simon, can you please check that this fixes your CB? > > The wrong udevice was passed to the functions, making them call the > pmic callbacks on the parent of the pmic udevice instead of the pmic > udevice itself. > > While at it, ensure consistency by having all internal functions use > pmic udevice instead of the regulator udevice. > > Finally, clarify operator precedence in ternary condition as reported by > my linter. > > Signed-off-by: Quentin Schulz I see we have not been able to follow configs on a few of the board's for RK3588 CONFIG_CMD_REGULATOR=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_RK8XX=y could you enable the options with imply for all the rockchip boards? Thanks -Anand > --- > Quentin Schulz (3): > regulator: rk8xx: fix incorrect device used for > _ldo_[sg]et_suspend_value > regulator: rk8xx: pass pmic udevice instead of regulator to all > internal functions > regulator: rk8xx: clarify operator precedence > > drivers/power/regulator/rk8xx.c | 54 > - > 1 file changed, 27 insertions(+), 27 deletions(-) > --- > base-commit: c0ea27bccfb7d2d37fd36806ac2a2f7389099420 > change-id: 20240605-pmic-rk8xx-52f2286be334 > > Best regards, > -- > Quentin Schulz >
Re: [PATCH v3 0/8] qcom: implement capsule updates
Hi Sumit, On 05/06/2024 07:31, Sumit Garg wrote: Hi Caleb, On Mon, 3 Jun 2024 at 18:19, Caleb Connolly wrote: Hook up support for capsule updates loaded from disk on Qualcomm platforms. Most Qualcomm devices have an A/B partition layout, with most partitions duplicated. The metadata on which slot is active is stored in the GPT headers in the vendor-specific attribute bits of each partition. It's good to see capsule updates support coming up for Qualcomm platforms. AFAICS, with this series we only update U-Boot on the current active partition. IOW, real A/B support is still not supported. Do you think it is possible for U-Boot to update metadata in GPT headers and for proprietary bootloaders to pick up the U-Boot from the updated partition? Yes this would be possible, I have some WIP patches to let us modify the slot attribute bits and write back the header. The reason I haven't implement A/B is because we don't support it from the OS level on any of the boards I work on. We often patch ABL to disable or skip the slot logic and flash a partition table without slots. It also unlocks a bunch of additional complexity... This isn't super high on my todo list but I'd be happy to help if someone wants to enable this functionality. We'd need: 1. Upstream support for modifying the GPT (see my PoC at [1] and [2]). 2. Logic to configure flashing the active or inactive slot This logic would have to run after the capsule update, I don't know if there is currently a way to add a callback after the update. If we enable updating other images (like XBL, hyp, tz, etc), we would need to either agree that a capsule update would have to update ALL partitions, or implement logic to copy over partitions that weren't flashed to the other slot. [1]: https://git.codelinaro.org/linaro/qcomlt/u-boot/-/commit/34d3de6f79550527746303e0bf6337fa37e31fe5 [2]: https://git.codelinaro.org/linaro/qcomlt/u-boot/-/commit/656d9e816bef85e586460a999cc7874255be9f1d -Sumit Add support for reading this attributes via the disk_partition struct and using them to determine which boot partition U-Boot is flashed to and generate the appropriate DFU string. This logic is gated behind a check to ensure that U-Boot is actually being chainloaded and not run via some other mechanism. SCSI support for most Qualcomm platforms is not yet enabled upstream, but will follow in future patches. This series enables capsule updates on the RB2, however [1] is required for it to work properly (as otherwise MMC won't be available). [1]: https://lore.kernel.org/u-boot/20240527-b4-clk-stub-v2-0-29013855e...@linaro.org/ To: Tom Rini To: Simon Glass To: Lukasz Majewski To: Mattijs Korpershoek To: Caleb Connolly To: Neil Armstrong To: Sumit Garg Cc: Ilias Apalodimas Cc: u-boot@lists.denx.de Cc: u-boot-q...@groups.io Changes in v3: - Address comments in scsi dfu support - enable CONFIG_DFU_SCSI for qcom - Link to v2: https://lore.kernel.org/r/20240527-b4-qcom-capsule-updates-v2-0-47583d7ad...@linaro.org Changes in v2: - Add qcom capsule update support patches - Link to v1: https://lore.kernel.org/r/20240409-b4-dfu-scsi-v1-0-3e1441a60...@linaro.org --- Caleb Connolly (8): dfu: add scsi backend disk: expose partition type flags mmc: msm_sdhci: work around a bug when writing mach-snapdragon: implement capsule update support qcom_defconfig: savedefconfig mach-snapdragon: use SYSRESET_PSCI mach-snapdragon: bump up heap size qcom_defconfig: enable capsule update support arch/arm/Kconfig | 2 + arch/arm/mach-snapdragon/Kconfig | 3 + arch/arm/mach-snapdragon/Makefile | 1 + arch/arm/mach-snapdragon/board.c | 8 +- arch/arm/mach-snapdragon/capsule_update.c | 147 ++ arch/arm/mach-snapdragon/qcom-priv.h | 6 + configs/qcom_defconfig| 19 +- disk/part_efi.c | 1 + doc/usage/dfu.rst | 32 +++ drivers/dfu/Kconfig | 7 + drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c | 5 +- drivers/dfu/dfu_scsi.c| 435 ++ drivers/mmc/msm_sdhci.c | 7 + include/configs/qcom.h| 5 + include/dfu.h | 26 ++ include/part.h| 1 + 17 files changed, 695 insertions(+), 11 deletions(-) --- change-id: 20240523-b4-qcom-capsule-updates-ea2e4f8f0ff0 base-commit: 5d8881a0801241d68701e8644d495f1d535506f0 // Caleb (they/them) -- // Caleb (they/them)
Re: [PATCH v5 0/3] Introduce mtdblock device
Hi Simon, your message is empty. On Tue, Jun 04, 2024 at 08:13:34PM -0600, Simon Glass wrote: > Hi Alexey, > > On Mon, Jun 3, 2024, 09:57 Alexey Romanov > wrote: > > > Hello! > > > > This series adds support for the mtdblock device, which > > allows to read/write data block by block. For example, > > it can now be used for BCB or Android AB command: > > > > $ bcb load mtd 0 part_name > > > > Tested only on SPI NAND, so bind is made only for > > SPI NAND drivers. > > > > --- > > > > Changes V1 -> V2 [1]: > > > > - Drop patch [2]. > > - Add warning if bind NAND mtdblock device. > > - Move documentation of mtdblock implementation > > from commit message to the source code. > > - Remove __maybe_unused from mtd partition functions > > description. > > - Use blk_enabled() instead of #ifdefs. > > > > Changes V2 -> V3 [2]: > > > > - Rebased over [3]. > > - Rename mtd_bread/bwrite -> mtd_blk_read/write. > > - Fix GPL-2.0 license short name definiton in headers. > > - Add empty line after MTD_ENTRY_NUMBERS define. > > > > Changes V3 -> V4 [4]: > > > > - Fix build warnings: use LBAF printf format string for lbaint_t types. > > > > Changes V4 -> V5 [5]: > > > > - Rebased over u-boot/master. > > - Fix build errors and warnings if CONFIG_BLK isn't enabled. > > - Fix failed tests in cases is mtdblock device isn't binded. > > > > Links: > > > > - [1] > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > - [2] > > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > > - [3] > > https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u > > - [4] > > https://lore.kernel.org/all/20240404105813.1520732-1-avroma...@salutedevices.com/ > > - [5] > > https://lore.kernel.org/all/20240524102920.2631731-1-avroma...@salutedevices.com/ > > > > Alexey Romanov (3): > > disk: support MTD partitions > > drivers: introduce mtdblock abstraction > > spinand: bind mtdblock > > > > disk/part.c | 3 +- > > drivers/block/blk-uclass.c | 1 + > > drivers/mtd/Kconfig | 1 + > > drivers/mtd/Makefile| 1 + > > drivers/mtd/mtdblock.c | 227 > > drivers/mtd/mtdpart.c | 76 > > drivers/mtd/nand/spi/core.c | 20 > > include/linux/mtd/mtd.h | 21 > > include/part.h | 3 + > > 9 files changed, 352 insertions(+), 1 deletion(-) > > create mode 100644 drivers/mtd/mtdblock.c > > > > -- > > 2.34.1 > > > > -- Thank you, Alexey
RE: [PATCH v1 0/4] Sync StarFive JH7110 clock and reset dt-bindings with Linux
> On 04.06.24 04:32, E Shattow wrote: > Hi Hal, > > Instead of manual dt-bindings sync can we please adopt OF_UPSTREAM for > JH7110 ? Yeah, I will try to do it recently, although I am not sure whether the U-Boot drivers and Linux drivers are compatible so that they can use the same DT. Best regards, Hal > > > On Mon, Jun 3, 2024 at 6:57 AM Hal Feng wrote: > > > > There are differences in clock / reset dt-bindings between U-Boot and > > Linux. Sync them, so it is feasible to use OF_UPSTREAM for StarFive > > JH7110 SoC. > > > > Hal Feng (4): > > dt-bindings: clock: jh7110: Sync with Linux > > dt-bindings: reset: jh7110: Sync with Linux > > clk: starfive: jh7110: Sync clock definitions with Linux > > riscv: dts: jh7110: Sync clock and reset definitions with Linux > > > > .../dts/jh7110-starfive-visionfive-2.dtsi | 6 +- > > arch/riscv/dts/jh7110-u-boot.dtsi | 2 +- > > arch/riscv/dts/jh7110.dtsi| 28 +-- > > drivers/clk/starfive/clk-jh7110-pll.c | 6 +- > > drivers/clk/starfive/clk-jh7110.c | 44 ++--- > > .../dt-bindings/clock/starfive,jh7110-crg.h | 180 +++--- > > .../dt-bindings/reset/starfive,jh7110-crg.h | 144 -- > > 7 files changed, 243 insertions(+), 167 deletions(-) > > > > > > base-commit: ea722aa5eb33740ae77e8816aeb72b385e621cd0 > > -- > > 2.43.2 > >
Re: [PATCH v3 4/8] mach-snapdragon: implement capsule update support
Hi Sumit,
+/**
+ * qcom_configure_capsule_updates() - Configure the DFU string for capsule
updates
+ *
+ * U-Boot is flashed to the boot partition on Qualcomm boards. In most cases
there
+ * are two boot partitions, boot_a and boot_b. As we don't currently support
doing
+ * full A/B updates, we only support updating the currently active boot
partition.
+ *
+ * So we need to find the current slot suffix and the associated boot
partition.
+ * We do this by looking for the boot partition that has the 'active' flag set
+ * in the GPT partition vendor attribute bits.
+ */
+void qcom_configure_capsule_updates(void)
+{
+ struct blk_desc *desc;
+ int ret = 0, partnum = -1, devnum;
+ static char dfu_string[32] = { 0 };
+ char name[32]; /* GPT partition name */
+ char *partname = "boot";
+ struct udevice *dev = NULL;
+
+ /*
+* There is currently no good way to check how U-Boot is booting, but
we have
+* a few hueristics, like here checking if our DTB has a kaslr-seed
specified
+* will tell us if we were chainloaded by another bootloader.
+* FIXME: we should do this check once and use some proper API to
expose the data.
If U-Boot is built with LINUX_KERNEL_IMAGE_HEADER enabled then we
should know that U-Boot is built as a replacement of Linux kernel and
hence chainloaded. Isn't that what you need here?
Not necessarily, you can build with LINUX_KERNEL_IMAGE_HEADER and then
pack U-Boot into XBL or flash it to hyp and it will still run (the
kernel header is specifically written to behave like a nop slide). So we
can't rely on this.
-Sumit
Kind regards,
--
// Caleb (they/them)
Re: [PATCH v3 6/7] tools: add genguid tool
On 05/06/2024 11:25, Ilias Apalodimas wrote: Hi Heinrich On Wed, 5 Jun 2024 at 09:36, Heinrich Schuchardt wrote: On 5/31/24 15:50, Caleb Connolly wrote: Add a tool that can generate GUIDs that match those generated internally by U-Boot for capsule update fw_images. Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it with the board model, compatible, and fw_image name. This tool accepts the same inputs and will produce the same GUID as U-Boot would at runtime. This functionality should be integrated into the mkeficapsule. Just pass the device-tree into mkeficapsule and generate the GUIDs whereever they are needed. I like the idea of moving this mkeficapsule which is already part of distro packages but, isn't it easier to pass the compatible string node and the namespace? Yeah, we only need the first entry in the compatible property, so parsing the whole DT is a bit overkill. I can look at combining these tools, can mkeficapsule generate a capsule for multiple images? Would we want it to work such that you provide the namespace GUID, compatible, and image names, and have it generate a capsule with the right image GUIDs? Or would it be simple enough to just incorporate the functionality of genguid? Kind regards, Thanks /Ilias Best regards Heinrich [...] Thanks /Ilias -- // Caleb (they/them)
Re: [PATCH v3 2/7] efi: add a helper to generate dynamic UUIDs
On 05/06/2024 07:52, Heinrich Schuchardt wrote:
On 5/31/24 15:50, Caleb Connolly wrote:
Introduce a new helper efi_capsule_update_info_gen_ids() which populates
the capsule update fw images image_type_id field. This allows for
determinstic UUIDs to be used that can scale to a large number of
different boards and board variants without the need to maintain a big
list.
We call this from efi_fill_image_desc_array() to populate the UUIDs
lazily on-demand.
This is behind an additional config option as it depends on V5 UUIDs and
the SHA1 implementation.
Signed-off-by: Caleb Connolly
---
lib/efi_loader/Kconfig | 23 +++
lib/efi_loader/efi_capsule.c | 1 +
lib/efi_loader/efi_firmware.c | 66
+++
3 files changed, 90 insertions(+)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 430bb7f0f7dc..e90caf4f8e14 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -235,8 +235,31 @@ config EFI_CAPSULE_ON_DISK_EARLY
If this option is enabled, capsules will be enforced to be
executed as part of U-Boot initialisation so that they will
surely take place whatever is set to distro_bootcmd.
+config EFI_CAPSULE_DYNAMIC_UUIDS
+ bool "Dynamic UUIDs for capsules"
+ depends on EFI_HAVE_CAPSULE_SUPPORT
+ select UUID_GEN_V5
This select will create a build error if CONFIG_SHA1=n as
CONFIG_UUID_GEN_V5 depends on it.
Ack
+ help
+ Select this option if you want to use dynamically generated v5
+ UUIDs for your board. To make use of this feature, your board
+ code should call efi_capsule_update_info_gen_ids() with a seed
+ UUID to generate the image_type_id field for each fw_image.
+
+ The CapsuleUpdate payloads are expected to generate matching UUIDs
+ using the same scheme.
+
+config EFI_CAPSULE_NAMESPACE_UUID
+ string "Namespace UUID for dynamic UUIDs"
+ depends on EFI_CAPSULE_DYNAMIC_UUIDS
+ help
+ Define the namespace or "salt" UUID used to generate the per-image
+ UUIDs. This should be a UUID in the standard 8-4-4-4-12 format.
As UUIDs can be formatted low-endian or big-endian I would not know how
the value will be interpreted.
Arguably it doesn't matter, it's just salt which is roughly UUID shaped :D
Why do we need a vendor specific name-space if we are using compatible
strings which are vendor specific themselves?
If vendor A and vendor B both build embedded products based on a
Qualcomm RB2 (for example), they might both use the same DTB but
customise other parts of U-Boot. We want them both to be able to use
LVFS to provide updates, so they need a way to avoid conflicting UUIDs.
I think requiring them to use a custom compatible might be a bit
arbitrary, especially if they aren't using any custom hardware.
+
+ Device vendors are expected to generate their own namespace UUID
+ to avoid conflicts with existing products.
+
config EFI_CAPSULE_FIRMWARE
bool
config EFI_CAPSULE_FIRMWARE_MANAGEMENT
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 0937800e588f..ac02e79ae7d8 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -19,8 +19,9 @@
#include
#include
#include
#include
+#include
#include
#include
#include
diff --git a/lib/efi_loader/efi_firmware.c
b/lib/efi_loader/efi_firmware.c
index ba5aba098c0f..a8dafe4f01a5 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -244,8 +244,71 @@ void efi_firmware_fill_version_info(struct
efi_firmware_image_descriptor *image_
free(var_state);
}
+#if CONFIG_IS_ENABLED(EFI_CAPSULE_DYNAMIC_UUIDS)
+/**
+ * efi_capsule_update_info_gen_ids - generate GUIDs for the images
+ *
+ * Generate the image_type_id for each image in the
update_info.images array
+ * using the first compatible from the device tree and a salt
+ * UUID defined at build time.
+ *
+ * Returns: status code
+ */
+static efi_status_t efi_capsule_update_info_gen_ids(void)
+{
+ int ret, i;
+ struct uuid namespace;
+ const char *compatible; /* Full array including null bytes */
+ struct efi_fw_image *fw_array;
+
+ fw_array = update_info.images;
+ /* Check if we need to run (there are images and we didn't
already generate their IDs) */
+ if (!update_info.num_images ||
+ memchr_inv(_array[0].image_type_id, 0,
sizeof(fw_array[0].image_type_id)))
+ return EFI_SUCCESS;
+
+ ret = uuid_str_to_bin(CONFIG_EFI_CAPSULE_NAMESPACE_UUID,
+ (unsigned char *), UUID_STR_FORMAT_GUID);
+ if (ret) {
+ log_debug("%s: CONFIG_EFI_CAPSULE_NAMESPACE_UUID is invalid:
%d\n", __func__, ret);
+ return EFI_UNSUPPORTED;
+ }
You don't want end-users to be the first to find this issue. This must
be a build time check.
Simply boot testing a production build should hit this error path... But
sure a built time check would be better.
Re: [PATCH v3 1/7] lib: uuid: add UUID v5 support
Hi Simon,
On 05/06/2024 04:13, Simon Glass wrote:
Hi Caleb,
On Fri, 31 May 2024 at 07:50, Caleb Connolly wrote:
Add support for generating version 5 UUIDs, these are determistic and work
spelling
by hashing a "namespace" UUID together with some unique data. One intended
usecase is to allow for dynamically generate payload UUIDs for UEFI
capsule updates, so that supported boards can have their own UUIDs
without needing to hardcode them.
Tests for this are added in an upcoming patch.
Signed-off-by: Caleb Connolly
---
include/uuid.h | 17 +
lib/Kconfig| 8
lib/uuid.c | 37 +
3 files changed, 62 insertions(+)
diff --git a/include/uuid.h b/include/uuid.h
index f5a941250f48..539affaa47b9 100644
--- a/include/uuid.h
+++ b/include/uuid.h
@@ -10,8 +10,9 @@
#ifndef __UUID_H__
#define __UUID_H__
#include
+#include
/*
* UUID - Universally Unique IDentifier - 128 bits unique number.
*There are 5 versions and one variant of UUID defined by RFC4122
@@ -142,8 +143,24 @@ void gen_rand_uuid(unsigned char *uuid_bin);
* @param - uuid output type: UUID - 0, GUID - 1
*/
void gen_rand_uuid_str(char *uuid_str, int str_format);
+#if IS_ENABLED(CONFIG_UUID_GEN_V5)
+/**
+ * gen_uuid_v5() - generate UUID v5 from namespace and other seed data.
+ *
+ * @namespace: pointer to UUID namespace salt
+ * @uuid:pointer to allocated UUID output
+ * @...: NULL terminated list of seed data as pairs of pointers
+ * to data and their lengths
+ */
+void gen_uuid_v5(const struct uuid *namespace, struct uuid *uuid, ...);
+#else
+static inline void gen_uuid_v5(const struct uuid *namespace, struct uuid
*uuid, ...)
+{
+}
+#endif
Can you explain somewhere why the static inline is needed?
The explicit "inline" certainly isn't, but this must be static because
it's defined in a header, so we'd otherwise have multiple definitions
for every #include.
+
/**
* uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
* @uuid_str: pointer to UUID string
* @uuid_bin: pointer to allocated array for little endian output [16B]
diff --git a/lib/Kconfig b/lib/Kconfig
index 189e6eb31aa1..2941532f25cf 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -80,8 +80,16 @@ config RANDOM_UUID
help
Enable the generation of partitions with random UUIDs if none
are provided.
+config UUID_GEN_V5
+ bool "Enable UUID version 5 generation"
+ select LIB_UUID
+ depends on SHA1
+ help
+ Enable the generation of version 5 UUIDs, these are determistic and
spelling
+ generated from a namespace UUID, and a string (such as a board name).
+
config SPL_LIB_UUID
depends on SPL
bool
diff --git a/lib/uuid.c b/lib/uuid.c
index dfa2320ba267..2df0523e717f 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -21,8 +21,9 @@
#include
#include
#include
#include
+#include
int uuid_str_valid(const char *uuid)
{
int i, valid;
@@ -368,8 +369,44 @@ void uuid_bin_to_str(const unsigned char *uuid_bin, char
*uuid_str,
}
}
}
+#if IS_ENABLED(CONFIG_UUID_GEN_V5)
+void gen_uuid_v5(const struct uuid *namespace, struct uuid *uuid, ...)
+{
+ sha1_context ctx;
+ va_list args;
+ const uint8_t *data;
+ uint8_t hash[SHA1_SUM_LEN];
+ uint32_t tmp;
+
+ sha1_starts();
+ /* Hash the namespace UUID as salt */
+ sha1_update(, (unsigned char *)namespace, UUID_BIN_LEN);
+ va_start(args, uuid);
+
+ while ((data = va_arg(args, const uint8_t *))) {
+ unsigned int len = va_arg(args, size_t);
+
+ sha1_update(, data, len);
+ }
+
+ va_end(args);
+ sha1_finish(, hash);
+
+ /* Truncate the hash into output UUID, it is already big endian */
+ memcpy(uuid, hash, sizeof(*uuid));
+
+ /* Configure variant/version bits */
+ tmp = be32_to_cpu(uuid->time_hi_and_version);
+ tmp = (tmp & ~UUID_VERSION_MASK) | (5 << UUID_VERSION_SHIFT);
+ uuid->time_hi_and_version = cpu_to_be32(tmp);
+
+ uuid->clock_seq_hi_and_reserved &= UUID_VARIANT_MASK;
+ uuid->clock_seq_hi_and_reserved |= UUID_VARIANT << UUID_VARIANT_SHIFT;
+}
+#endif
+
#if defined(CONFIG_RANDOM_UUID) || defined(CONFIG_CMD_UUID)
void gen_rand_uuid(unsigned char *uuid_bin)
{
u32 ptr[4];
--
2.45.0
Regards,
Simon
--
// Caleb (they/them)
Re: Several potential vulnerabilities in the filesystem
Could you please forward the issues to whoever is responsible for them?
Gao Xiang 于2024年6月5日周三 13:35写道：
>
>
>
> On 2024/6/5 19:26, jianqiang wang wrote:
> > Hi Xiang,
> >
> > I just checked the second crash, the patch can solve this issue. Did
> > you also look into the other two issues?
>
> I'm only responsible for the EROFS project.
>
> Thanks,
> Gao Xiang
>
> >
> > Best
> > Jianqiang
> >
> > Gao Xiang 于2024年6月5日周三 13:18写道：
> >>
> >> Hi Jianqiang,
> >>
> >> On 2024/6/5 19:00, jianqiang wang wrote:
> >>> Hi,
> >>>
> >>> I do have the crafted image.
> >>>
> >>> payload_00500, payload_00763, payload_00846 can be used to reproduce
> >>> 1,2,3 vulnerabilities respectively.
> >>>
> >>> Each image is a hard drive file and the vulnerabilities can be
> >>> triggered by performing the following operations:
> >>>
> >>> struct udevice *dev;
> >>> uclass_first_device_err(UCLASS_IDE, ); //detect the block
> >>> device
> >>>
> >>> fs_set_blk_dev("ide","0:1", 0);
> >>> fs_ls("/"); //mount the first partition and list the root
> >>> directory files
> >>>
> >>> fs_set_blk_dev("ide","0:1", 0);
> >>> char buf[10];
> >>> buf[0] = 0;
> >>> buf[1] = 0;
> >>> buf[2] = 0;
> >>> buf[3] = 0;
> >>> loff_t actread = 0;
> >>> fs_read("/a.txt", (ulong)buf, 0, 5, );
> >>> printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
> >>>read the /a.txt file
> >>>
> >>>
> >>> fs_set_blk_dev("ide","0:1", 0);
> >>> fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
> >>> printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
> >>>read the /a.txt.ln symbol file
> >>>
> >>> fs_set_blk_dev("ide","0:1", 0);
> >>> fs_unlink("/a.txt.ln"); //unlink it
> >>>
> >>> The second and third may not trigger a crash however, can be observed
> >>> by inserting logging before the memset/memcpy function.
> >>
> >> Sorry, I just found that this issue was already fixed in erofs-utils:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
> >>
> >> Would you mind checking if the patch above fixes the issue?
> >>
> >> Hi Jianan,
> >> Would you mind backporting this patch for u-boot?
> >>
> >> Thanks,
> >> Gao Xiang
> >>
> >>>
> >>> Best regards
> >>>
> >>> Gao Xiang 于2024年6月5日周三 05:10写道：
>
>
>
> On 2024/6/5 06:53, jianqiang wang wrote:
> > Hi Das U-Boot developers,
> >
>
> ...
>
> >
> > 2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
> > data is read from the storage, however, without a proper check, the
> > data can be corrupted. For example, the inode data is used in function
> > z_erofs_read_data, map.m_llen will be calculated to a very large
> > value, which means the length variable will be very large. It will
> > cause a large memory clear with memset(buffer + end - offset, 0,
> > length);
>
> Would you mind giving a reproducer or a crafted image to trigger
> this? Or it's your pure observation.
>
> Thanks,
> Gao XIang
>
Re: Several potential vulnerabilities in the filesystem
On 2024/6/5 19:26, jianqiang wang wrote:
Hi Xiang,
I just checked the second crash, the patch can solve this issue. Did
you also look into the other two issues?
I'm only responsible for the EROFS project.
Thanks,
Gao Xiang
Best
Jianqiang
Gao Xiang 于2024年6月5日周三 13:18写道：
Hi Jianqiang,
On 2024/6/5 19:00, jianqiang wang wrote:
Hi,
I do have the crafted image.
payload_00500, payload_00763, payload_00846 can be used to reproduce
1,2,3 vulnerabilities respectively.
Each image is a hard drive file and the vulnerabilities can be
triggered by performing the following operations:
struct udevice *dev;
uclass_first_device_err(UCLASS_IDE, ); //detect the block device
fs_set_blk_dev("ide","0:1", 0);
fs_ls("/"); //mount the first partition and list the root directory
files
fs_set_blk_dev("ide","0:1", 0);
char buf[10];
buf[0] = 0;
buf[1] = 0;
buf[2] = 0;
buf[3] = 0;
loff_t actread = 0;
fs_read("/a.txt", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt file
fs_set_blk_dev("ide","0:1", 0);
fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt.ln symbol file
fs_set_blk_dev("ide","0:1", 0);
fs_unlink("/a.txt.ln"); //unlink it
The second and third may not trigger a crash however, can be observed
by inserting logging before the memset/memcpy function.
Sorry, I just found that this issue was already fixed in erofs-utils:
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
Would you mind checking if the patch above fixes the issue?
Hi Jianan,
Would you mind backporting this patch for u-boot?
Thanks,
Gao Xiang
Best regards
Gao Xiang 于2024年6月5日周三 05:10写道：
On 2024/6/5 06:53, jianqiang wang wrote:
Hi Das U-Boot developers,
...
2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
data is read from the storage, however, without a proper check, the
data can be corrupted. For example, the inode data is used in function
z_erofs_read_data, map.m_llen will be calculated to a very large
value, which means the length variable will be very large. It will
cause a large memory clear with memset(buffer + end - offset, 0,
length);
Would you mind giving a reproducer or a crafted image to trigger
this? Or it's your pure observation.
Thanks,
Gao XIang
Re: Several potential vulnerabilities in the filesystem
Hi Xiang,
I just checked the second crash, the patch can solve this issue. Did
you also look into the other two issues?
Best
Jianqiang
Gao Xiang 于2024年6月5日周三 13:18写道：
>
> Hi Jianqiang,
>
> On 2024/6/5 19:00, jianqiang wang wrote:
> > Hi,
> >
> > I do have the crafted image.
> >
> > payload_00500, payload_00763, payload_00846 can be used to reproduce
> > 1,2,3 vulnerabilities respectively.
> >
> > Each image is a hard drive file and the vulnerabilities can be
> > triggered by performing the following operations:
> >
> > struct udevice *dev;
> > uclass_first_device_err(UCLASS_IDE, ); //detect the block device
> >
> > fs_set_blk_dev("ide","0:1", 0);
> > fs_ls("/"); //mount the first partition and list the root directory
> > files
> >
> > fs_set_blk_dev("ide","0:1", 0);
> > char buf[10];
> > buf[0] = 0;
> > buf[1] = 0;
> > buf[2] = 0;
> > buf[3] = 0;
> > loff_t actread = 0;
> > fs_read("/a.txt", (ulong)buf, 0, 5, );
> > printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
> > read the /a.txt file
> >
> >
> > fs_set_blk_dev("ide","0:1", 0);
> > fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
> > printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
> > read the /a.txt.ln symbol file
> >
> > fs_set_blk_dev("ide","0:1", 0);
> > fs_unlink("/a.txt.ln"); //unlink it
> >
> > The second and third may not trigger a crash however, can be observed
> > by inserting logging before the memset/memcpy function.
>
> Sorry, I just found that this issue was already fixed in erofs-utils:
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
>
> Would you mind checking if the patch above fixes the issue?
>
> Hi Jianan,
> Would you mind backporting this patch for u-boot?
>
> Thanks,
> Gao Xiang
>
> >
> > Best regards
> >
> > Gao Xiang 于2024年6月5日周三 05:10写道：
> >>
> >>
> >>
> >> On 2024/6/5 06:53, jianqiang wang wrote:
> >>> Hi Das U-Boot developers,
> >>>
> >>
> >> ...
> >>
> >>>
> >>> 2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
> >>> data is read from the storage, however, without a proper check, the
> >>> data can be corrupted. For example, the inode data is used in function
> >>> z_erofs_read_data, map.m_llen will be calculated to a very large
> >>> value, which means the length variable will be very large. It will
> >>> cause a large memory clear with memset(buffer + end - offset, 0,
> >>> length);
> >>
> >> Would you mind giving a reproducer or a crafted image to trigger
> >> this? Or it's your pure observation.
> >>
> >> Thanks,
> >> Gao XIang
> >>
Re: [PATCH] cmd: bcb: Fix bcb compilation when CONFIG_CMD_BCB=n
Thank you and sorry for missing that Reviewed-by: Dmitrii Merkurev
Re: [PATCH 3/3] regulator: rk8xx: clarify operator precedence
Hi Quentin,
Thank you for the patch.
On mer., juin 05, 2024 at 11:33, Quentin Schulz wrote:
> From: Quentin Schulz
>
> My linter complains that the order isn't clear enough so let's put
> parentheses around the ternary condition to make it happy.
>
> Signed-off-by: Quentin Schulz
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/power/regulator/rk8xx.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
> index bd5a37e718f..3125835bc07 100644
> --- a/drivers/power/regulator/rk8xx.c
> +++ b/drivers/power/regulator/rk8xx.c
> @@ -520,7 +520,7 @@ static int _buck_get_enable(struct udevice *pmic, int
> buck)
> if (ret < 0)
> return ret;
>
> - return ret & mask ? true : false;
> + return (ret & mask) ? true : false;
> }
>
> static int _buck_set_suspend_enable(struct udevice *pmic, int buck, bool
> enable)
> @@ -585,7 +585,7 @@ static int _buck_get_suspend_enable(struct udevice *pmic,
> int buck)
> val = pmic_reg_read(pmic, RK816_REG_DCDC_SLP_EN);
> if (val < 0)
> return val;
> - ret = val & mask ? 1 : 0;
> + ret = (val & mask) ? 1 : 0;
> break;
> case RK806_ID:
> {
> @@ -608,7 +608,7 @@ static int _buck_get_suspend_enable(struct udevice *pmic,
> int buck)
> val = pmic_reg_read(pmic, REG_SLEEP_SET_OFF1);
> if (val < 0)
> return val;
> - ret = val & mask ? 0 : 1;
> + ret = (val & mask) ? 0 : 1;
> break;
> case RK809_ID:
> case RK817_ID:
> @@ -620,7 +620,7 @@ static int _buck_get_suspend_enable(struct udevice *pmic,
> int buck)
> val = pmic_reg_read(pmic, RK817_POWER_SLP_EN(0));
> if (val < 0)
> return val;
> - ret = val & mask ? 1 : 0;
> + ret = (val & mask) ? 1 : 0;
> break;
> default:
> ret = -EINVAL;
> @@ -723,7 +723,7 @@ static int _ldo_get_enable(struct udevice *pmic, int ldo)
> if (ret < 0)
> return ret;
>
> - return ret & mask ? true : false;
> + return (ret & mask) ? true : false;
> }
>
> static int _nldo_get_enable(struct udevice *pmic, int nldo)
> @@ -980,7 +980,7 @@ static int _ldo_get_suspend_enable(struct udevice *pmic,
> int ldo)
> val = pmic_reg_read(pmic, RK816_REG_LDO_SLP_EN);
> if (val < 0)
> return val;
> - ret = val & mask ? 1 : 0;
> + ret = (val & mask) ? 1 : 0;
> break;
> case RK808_ID:
> case RK818_ID:
> @@ -988,7 +988,7 @@ static int _ldo_get_suspend_enable(struct udevice *pmic,
> int ldo)
> val = pmic_reg_read(pmic, REG_SLEEP_SET_OFF2);
> if (val < 0)
> return val;
> - ret = val & mask ? 0 : 1;
> + ret = (val & mask) ? 0 : 1;
> break;
> case RK809_ID:
> case RK817_ID:
> @@ -997,13 +997,13 @@ static int _ldo_get_suspend_enable(struct udevice
> *pmic, int ldo)
> val = pmic_reg_read(pmic, RK817_POWER_SLP_EN(0));
> if (val < 0)
> return val;
> - ret = val & mask ? 1 : 0;
> + ret = (val & mask) ? 1 : 0;
> } else {
> mask = 1 << ldo;
> val = pmic_reg_read(pmic, RK817_POWER_SLP_EN(1));
> if (val < 0)
> return val;
> - ret = val & mask ? 1 : 0;
> + ret = (val & mask) ? 1 : 0;
> }
> break;
> }
> @@ -1438,7 +1438,7 @@ static int switch_get_enable(struct udevice *dev)
> if (ret < 0)
> return ret;
>
> - return ret & mask ? true : false;
> + return (ret & mask) ? true : false;
> }
>
> static int switch_set_suspend_value(struct udevice *dev, int uvolt)
> @@ -1493,21 +1493,21 @@ static int switch_get_suspend_enable(struct udevice
> *dev)
> val = pmic_reg_read(dev->parent, REG_SLEEP_SET_OFF1);
> if (val < 0)
> return val;
> - ret = val & mask ? 0 : 1;
> + ret = (val & mask) ? 0 : 1;
> break;
> case RK809_ID:
> mask = 1 << (sw + 6);
> val = pmic_reg_read(dev->parent, RK817_POWER_SLP_EN(0));
> if (val < 0)
> return val;
> - ret = val & mask ? 1 : 0;
> + ret = (val & mask) ? 1 : 0;
> break;
> case RK818_ID:
> mask = 1 << 6;
> val = pmic_reg_read(dev->parent, REG_SLEEP_SET_OFF1);
> if (val < 0)
> return val;
> -
Re: Several potential vulnerabilities in the filesystem
Hi Jianqiang,
On 2024/6/5 19:00, jianqiang wang wrote:
Hi,
I do have the crafted image.
payload_00500, payload_00763, payload_00846 can be used to reproduce
1,2,3 vulnerabilities respectively.
Each image is a hard drive file and the vulnerabilities can be
triggered by performing the following operations:
struct udevice *dev;
uclass_first_device_err(UCLASS_IDE, ); //detect the block device
fs_set_blk_dev("ide","0:1", 0);
fs_ls("/"); //mount the first partition and list the root directory files
fs_set_blk_dev("ide","0:1", 0);
char buf[10];
buf[0] = 0;
buf[1] = 0;
buf[2] = 0;
buf[3] = 0;
loff_t actread = 0;
fs_read("/a.txt", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt file
fs_set_blk_dev("ide","0:1", 0);
fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt.ln symbol file
fs_set_blk_dev("ide","0:1", 0);
fs_unlink("/a.txt.ln"); //unlink it
The second and third may not trigger a crash however, can be observed
by inserting logging before the memset/memcpy function.
Sorry, I just found that this issue was already fixed in erofs-utils:
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
Would you mind checking if the patch above fixes the issue?
Hi Jianan,
Would you mind backporting this patch for u-boot?
Thanks,
Gao Xiang
Best regards
Gao Xiang 于2024年6月5日周三 05:10写道：
On 2024/6/5 06:53, jianqiang wang wrote:
Hi Das U-Boot developers,
...
2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
data is read from the storage, however, without a proper check, the
data can be corrupted. For example, the inode data is used in function
z_erofs_read_data, map.m_llen will be calculated to a very large
value, which means the length variable will be very large. It will
cause a large memory clear with memset(buffer + end - offset, 0,
length);
Would you mind giving a reproducer or a crafted image to trigger
this? Or it's your pure observation.
Thanks,
Gao XIang
Re: [PATCH v2 1/2] bootstd: Fix a handful of doc typos in bootmeth
Hi,
Le 04/06/2024 à 17:15, Mattijs Korpershoek a écrit :
Fix some trivial typos found by browsing the code.
Done with flyspell.
Reviewed-by: Quentin Schulz
Signed-off-by: Mattijs Korpershoek
---
include/bootmeth.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/bootmeth.h b/include/bootmeth.h
index 0fc36104ece0..529c4d813d82 100644
--- a/include/bootmeth.h
+++ b/include/bootmeth.h
@@ -40,7 +40,7 @@ struct bootmeth_ops {
/**
* get_state_desc() - get detailed state information
*
-* Prodecues a textual description of the state of the bootmeth. This
+* Produces a textual description of the state of the bootmeth. This
* can include newline characters if it extends to multiple lines. It
* must be a nul-terminated string.
*
@@ -138,7 +138,7 @@ struct bootmeth_ops {
* @dev:Bootmethod device to boot
* @bflow: Bootflow to boot
* Return: does not return on success, since it should boot the
-* Operating Systemn. Returns -EFAULT if that fails, -ENOTSUPP if
+* Operating System. Returns -EFAULT if that fails, -ENOTSUPP if
* trying method resulted in finding out that is not actually
* supported for this boot and should not be tried again unless
* something changes, other -ve on other error
@@ -151,7 +151,7 @@ struct bootmeth_ops {
/**
* bootmeth_get_state_desc() - get detailed state information
*
- * Prodecues a textual description of the state of the bootmeth. This
+ * Produces a textual description of the state of the bootmeth. This
* can include newline characters if it extends to multiple lines. It
* must be a nul-terminated string.
*
@@ -244,7 +244,7 @@ int bootmeth_read_file(struct udevice *dev, struct bootflow
*bflow,
* @dev: Bootmethod device to use
* @bflow:Bootflow to read
* Return: does not return on success, since it should boot the
- * Operating Systemn. Returns -EFAULT if that fails, other -ve on
+ * Operating System. Returns -EFAULT if that fails, other -ve on
*other error
*/
int bootmeth_read_all(struct udevice *dev, struct bootflow *bflow);
@@ -255,7 +255,7 @@ int bootmeth_read_all(struct udevice *dev, struct bootflow
*bflow);
* @dev: Bootmethod device to boot
* @bflow:Bootflow to boot
* Return: does not return on success, since it should boot the
- * Operating Systemn. Returns -EFAULT if that fails, other -ve on
+ * Operating System. Returns -EFAULT if that fails, other -ve on
*other error
*/
int bootmeth_boot(struct udevice *dev, struct bootflow *bflow);
@@ -264,7 +264,7 @@ int bootmeth_boot(struct udevice *dev, struct bootflow
*bflow);
* bootmeth_setup_iter_order() - Set up the ordering of bootmeths to scan
*
* This sets up the ordering information in @iter, based on the selected
- * ordering of the bootmethds in bootstd_priv->bootmeth_order. If there is no
+ * ordering of the bootmeths in bootstd_priv->bootmeth_order. If there is no
* ordering there, then all bootmethods are added
*
* @iter: Iterator to update with the order
Reviewed-by: Guillaume La Roque
Guillaume
Re: [PATCH] cmd: bcb: Fix bcb compilation when CONFIG_CMD_BCB=n
hi,
Le 03/06/2024 à 11:04, Mattijs Korpershoek a écrit :
commit dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the
fields")
introduced the bcb_get() function.
When CONFIG_CMD_BCB=n, that function is stubbed.
The stubbed function has a wrong prototype: value_size arg is missing.
Add the missing argument to fix build when CONFIG_CMD_BCB=n.
Fixes: dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the
fields")
Signed-off-by: Mattijs Korpershoek
---
include/bcb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/bcb.h b/include/bcb.h
index 1941d8c28b4f..a56b547595a6 100644
--- a/include/bcb.h
+++ b/include/bcb.h
@@ -58,7 +58,8 @@ static inline int bcb_set(enum bcb_field field, const char
*value)
return -EOPNOTSUPP;
}
-static inline int bcb_get(enum bcb_field field, char *value_out)
+static inline int bcb_get(enum bcb_field field,
+ char *value_out, size_t value_size)
{
return -EOPNOTSUPP;
}
---
base-commit: ea722aa5eb33740ae77e8816aeb72b385e621cd0
change-id: 20240603-bcb-compil-d8eaf7074475
Best regards,
Reviewed-by: Guillaume La Roque
Regards
Guillaume
Re: [PATCH 7/9] rockchip: bob: kevin: Disable dcache in SPL
Hi Simon,
On 2024-06-05 05:25, Simon Glass wrote:
> This causes a hang, so disable it.
When I initially tested this on multiple boards there was some boards
that also hanged, that turned out to be an issue in one of the drivers.
If I remember correctly such hang was related to a null pointer
dereference or unaligned access in one of the drivers.
Could there be a similar underlying issue for these boards?
Regards,
Jonas
>
> Fixes: 6d8cdfd1536 ("rockchip: spl: Enable caches to speed up checksum
> validation")
>
> Signed-off-by: Simon Glass
> ---
>
> configs/chromebook_bob_defconfig | 1 +
> configs/chromebook_kevin_defconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/configs/chromebook_bob_defconfig
> b/configs/chromebook_bob_defconfig
> index acfe3934104..b2ecfa6050c 100644
> --- a/configs/chromebook_bob_defconfig
> +++ b/configs/chromebook_bob_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_ARM=y
> CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_SPL_SYS_DCACHE_OFF=y
> CONFIG_COUNTER_FREQUENCY=2400
> CONFIG_ARCH_ROCKCHIP=y
> CONFIG_TEXT_BASE=0x0020
> diff --git a/configs/chromebook_kevin_defconfig
> b/configs/chromebook_kevin_defconfig
> index 95fdb418d82..da748e4f022 100644
> --- a/configs/chromebook_kevin_defconfig
> +++ b/configs/chromebook_kevin_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
> CONFIG_SKIP_LOWLEVEL_INIT=y
> CONFIG_COUNTER_FREQUENCY=2400
> CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SPL_SYS_DCACHE_OFF=y
> CONFIG_TEXT_BASE=0x0020
> CONFIG_SPL_GPIO=y
> CONFIG_NR_DRAM_BANKS=1
Re: [PATCH 4/9] power: regulator: Handle autoset in regulators_enable_boot_on()
Hi Simon,
On 2024-06-05 05:25, Simon Glass wrote:
> With a recent change, regulators_enable_boot_on() returns an error if a
> regulator is already set. Check for and handle this situation.
I am guessing this is being hit because of the call in veyron_init() ?
regulators_enable_boot_on() is also called for rockchip boards in the
rockchip common boards.c board_init().
Maybe the call to regulators_enable_boot_on() in veyron_init() could
be dropped?
>
> Fixes: d99fb64a98a power: regulator: Only run autoset once for each regulator
>
> Signed-off-by: Simon Glass
Reviewed-by: Jonas Karlman
Regards,
Jonas
> ---
>
> drivers/power/regulator/regulator-uclass.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/regulator/regulator-uclass.c
> b/drivers/power/regulator/regulator-uclass.c
> index 77d101f262e..d9e1fb68295 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@ -518,7 +518,7 @@ int regulators_enable_boot_on(bool verbose)
>dev;
>uclass_next_device()) {
> ret = regulator_autoset(dev);
> - if (ret == -EMEDIUMTYPE) {
> + if (ret == -EMEDIUMTYPE || ret == -EALREADY) {
> ret = 0;
> continue;
> }
Re: Several potential vulnerabilities in the filesystem
Hi,
I do have the crafted image.
payload_00500, payload_00763, payload_00846 can be used to reproduce
1,2,3 vulnerabilities respectively.
Each image is a hard drive file and the vulnerabilities can be
triggered by performing the following operations:
struct udevice *dev;
uclass_first_device_err(UCLASS_IDE, ); //detect the block device
fs_set_blk_dev("ide","0:1", 0);
fs_ls("/"); //mount the first partition and list the root directory files
fs_set_blk_dev("ide","0:1", 0);
char buf[10];
buf[0] = 0;
buf[1] = 0;
buf[2] = 0;
buf[3] = 0;
loff_t actread = 0;
fs_read("/a.txt", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt file
fs_set_blk_dev("ide","0:1", 0);
fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt.ln symbol file
fs_set_blk_dev("ide","0:1", 0);
fs_unlink("/a.txt.ln"); //unlink it
The second and third may not trigger a crash however, can be observed
by inserting logging before the memset/memcpy function.
Best regards
Gao Xiang 于2024年6月5日周三 05:10写道：
>
>
>
> On 2024/6/5 06:53, jianqiang wang wrote:
> > Hi Das U-Boot developers,
> >
>
> ...
>
> >
> > 2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
> > data is read from the storage, however, without a proper check, the
> > data can be corrupted. For example, the inode data is used in function
> > z_erofs_read_data, map.m_llen will be calculated to a very large
> > value, which means the length variable will be very large. It will
> > cause a large memory clear with memset(buffer + end - offset, 0,
> > length);
>
> Would you mind giving a reproducer or a crafted image to trigger
> this? Or it's your pure observation.
>
> Thanks,
> Gao XIang
>
payload_00763
Description: Binary data
payload_00846
Description: Binary data
payload_00500
Description: Binary data
Re: [PATCH v3 03/25] mbedtls: add mbedtls into the build system
On Wed, Jun 05, 2024 at 12:35:37PM +0300, Ilias Apalodimas wrote: > On Wed, 5 Jun 2024 at 12:30, Andy Shevchenko > wrote: > > On Tue, Jun 04, 2024 at 05:50:08PM -0400, Raymond Mao wrote: > > > On Tue, 4 Jun 2024 at 16:17, Andy Shevchenko < > > > andriy.shevche...@linux.intel.com> wrote: > > > > On Tue, May 28, 2024 at 07:09:14AM -0700, Raymond Mao wrote: ... > > > > > This patch series requires mbedtls git repo to be added as a > > > > > subtree to the main U-Boot repo via: > > > > > > > > > > $ git subtree add --prefix lib/mbedtls/external/mbedtls \ > > > > > https://github.com/Mbed-TLS/mbedtls.git \ > > > > > v3.6.0 --squash > > > > > > > > Is this approach maintainable? > > > > I don't remember if we have similar in Linux kernel, for example. > > > > (There are few candidates like compression algorithms that are usually > > > > being > > > > hosted elsewhere) > > > > No answer? > > subtrees is what was decided on OF_UPSRTEAM as well. If you have a > better idea feel free to propose it, but for the sake of conformance > we are better off doing the same thing on every external tree we pull > in How do they will (or already do) maintain this? At least it's a good to have a few words on the choice made in the cover letter, so we will have no questions on it. > > > > > Moreover, due to the Windows-style files from mbedtls git repo, > > > > > we need to convert the CRLF endings to LF and do a commit manually: > > > > > > > > > > $ git add --renormalize . > > > > > $ git commit ... > > > > > lib/mbedtls/mbedtls_def_config.h | 4262 > > > > > ++ > > > > > > > > This is ridiculously HUGE! This is unreviewable. Moreover, this is even > > > > hard to > > > > configure by the user! Can you rather make it modular and maybe create a > > > > separate documentation for the most important options (I do not believe > > > > one > > > > needs _all_ of them to be set / tuned)? > > > > > > > > This is a file from MbedTLS and follows its own style. > > > And this is how MbedTLS is configured - with all features listed in a > > > config file and > > > commenting out the unused features with "//"). > > > The modification here is just to control those existing options with > > > Kconfigs. > > > > And why should we blindly follow this nonsense? > > It's easier to follow up future changes tbh. But I do agree the config > file is huge. Perhaps splitting in 2 files is going to be easier > mbedtls_def_config.h -> contains all the options that rarely need > tuning, which I assume is the majority of the header > mbedtls_usef_config.h -> contains the imporant options, crypto, > checksum algorithms etc > > Thoughts? The problem is on who decides which are "rarely need". The feasible (to me) approach is to split per domain. Like you listed at the very end of your reply. We can also learn from managing MTA configurations, such as Exim4 where user may decide if they want a single file or split version. -- With Best Regards, Andy Shevchenko
[PATCH 7/7] arm64: zynqmp: Update the usb5744 hub node as per binding
Updating the usb5744 hub node as per the latest upstream DT binding
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
tree/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml?h=v6.8.8
Signed-off-by: Venkatesh Yadav Abbarapu
---
arch/arm/dts/zynqmp-sck-kr-g-revA.dtso | 48 ++
arch/arm/dts/zynqmp-sck-kr-g-revB.dtso | 48 ++
arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 18 ++
arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 25 +-
4 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
b/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
index ce7c5eb6d34..18e9d308de3 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
@@ -105,11 +105,19 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+ hub_1: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
usbhub_i2c1: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+ hub_2: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
/* Bus 2/3 are not connected */
};
@@ -164,6 +172,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <_3_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <_2_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
};
{ /* mio64 - mio75 */
@@ -188,6 +216,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub1_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <_3_0>;
+ i2c-bus = <_2>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub1_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <_2_0>;
+ i2c-bus = <_2>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
};
{ /* mdio mio50/51 */
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
b/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
index 0a0cbd2b69a..5261e793c14 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
@@ -117,11 +117,19 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+ hub_1: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
usbhub_i2c1: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+ hub_2: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
/* Bus 2/3 are not connected */
};
@@ -184,6 +192,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <_3_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <_2_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
};
{ /* mio64 - mio75 */
@@ -209,6 +237,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub1_2_0: hub@1 {
+ compatible =
[PATCH 5/7] usb: onboard-hub: Bail out if peer hub is already probed
Many physical hub chips include multiple logical hubs to handle both
USB and 2 and 3. Both logical hubs will then match the onboard hub
driver, which means it will end up with two driver instances trying to
control the reset GPIO that is only present once on the physical chip.
The reference for this change is taken from
https://lore.barebox.org/barebox/20240327165554.894805-1-l.st...@pengutronix.de/
Signed-off-by: Venkatesh Yadav Abbarapu
---
common/usb_onboard_hub.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 09ce452af1b..519bad337e1 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,7 +22,7 @@
#define USB5744_CONFIG_REG_ACCESS_LSB 0x99
struct onboard_hub {
- struct udevice *vdd;
+ struct udevice *vdd, *dev;
struct gpio_desc *reset_gpio;
};
@@ -106,8 +107,18 @@ static int usb_onboard_hub_probe(struct udevice *dev)
struct onboard_hub_data *data =
(struct onboard_hub_data *)dev_get_driver_data(dev);
struct onboard_hub *hub = dev_get_priv(dev);
+ struct ofnode_phandle_args phandle;
+ struct udevice *hub_dev;
int ret;
+ if (!dev_read_phandle_with_args(dev, "peer-hub", NULL, 0, 0, ))
{
+ if (ofnode_valid(phandle.node)) {
+ ret = uclass_find_device_by_ofnode(UCLASS_USB_HUB,
phandle.node, _dev);
+ if (hub_dev && hub_dev->priv_)
+ return 0;
+ }
+ }
+
if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
ret = device_get_supply_regulator(dev, "vdd-supply",
>vdd);
@@ -148,6 +159,9 @@ static int usb_onboard_hub_probe(struct udevice *dev)
return ret;
}
}
+ hub->dev = dev;
+ dev->priv_ = hub;
+
return 0;
}
--
2.17.1
[PATCH 6/7] configs: zynqmp_kria: Enable the USB onboard hub
USB host support on ZYNQMP KRIA SOM needs onboard USB hub driver for handling reset GPIO and for i2c initialization sequence. Signed-off-by: Venkatesh Yadav Abbarapu --- configs/xilinx_zynqmp_kria_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index ba42f0c7848..8ca80b67ee0 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -199,6 +199,7 @@ CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y +CONFIG_USB_ONBOARD_HUB=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_GADGET=y -- 2.17.1
[PATCH 4/7] usb: onboard-hub: Add i2c initialization for usb5744 hub
Add i2c initialization hook and set usb5744 platform
data with function having required i2c initialization sequence.
Apart from the USB command attach, prevent the hub from suspend.
when the “USB Attach with SMBUS (0xAA56)” command is issued to the hub,
the hub is getting enumerated and then it puts in a suspend mode.
This causes the hub to NAK any SMBUS access made by the SMBUS Master
during this period and not able to see the hub's slave address while
running the "i2c probe" command.
Prevent the MCU from the putting the HUB in suspend mode through register
write. The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2 register at
address 0x411D controls this aspect of the hub. The BYPASS_UDC_SUSPEND
bit in register 0x411Dh must be set to ensure that the MCU is always
enabled and ready to respond to SMBus runtime commands. This register
needs to be written before the USB attach command is issued.
The byte sequence is as follows:
Slave addr: 0x2d 00 00 05 00 01 41 1D 08
Slave addr: 0x2d 99 37 00
Slave addr: 0x2d AA 56 00
Signed-off-by: Venkatesh Yadav Abbarapu
---
common/usb_onboard_hub.c | 86
1 file changed, 86 insertions(+)
diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 50870285995..09ce452af1b 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -11,9 +11,15 @@
#include
#include
#include
+#include
#include
#include
+#define USB5744_COMMAND_ATTACH0x0056
+#define USB5744_COMMAND_ATTACH_LSB0xAA
+#define USB5744_CONFIG_REG_ACCESS 0x0037
+#define USB5744_CONFIG_REG_ACCESS_LSB 0x99
+
struct onboard_hub {
struct udevice *vdd;
struct gpio_desc *reset_gpio;
@@ -21,8 +27,80 @@ struct onboard_hub {
struct onboard_hub_data {
unsigned long reset_us;
+ int (*onboard_dev_i2c_init)(struct udevice *dev);
};
+static int usb5744_i2c_init(struct udevice *dev)
+{
+ /*
+* Prevent the MCU from the putting the HUB in suspend mode through
register write.
+* The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2 register at
address
+* 0x411D controls this aspect of the hub.
+* Format to write to hub registers via SMBus- 2D 00 00 05 00 01 41 1D
08
+* Byte 0: Address of slave 2D
+* Byte 1: Memory address 00
+* Byte 2: Memory address 00
+* Byte 3: Number of bytes to write to memory
+* Byte 4: Write configuration register (00)
+* Byte 5: Write the number of data bytes (01- 1 data byte)
+* Byte 6: LSB of register address 0x41
+* Byte 7: MSB of register address 0x1D
+* Byte 8: value to be written to the register
+*/
+ char data_buf[8] = {0x0, 0x5, 0x0, 0x1, 0x41, 0x1D, 0x08};
+ int ret, slave_addr;
+ u32 buf = USB5744_COMMAND_ATTACH;
+ u32 config_reg_access_buf = USB5744_CONFIG_REG_ACCESS;
+ struct dm_i2c_chip *i2c_chip;
+ struct ofnode_phandle_args phandle;
+ struct udevice *i2c_bus = NULL, *i2c_dev;
+
+ if (!dev_read_phandle_with_args(dev, "i2c-bus", NULL, 0, 0, )) {
+ ret =
device_get_global_by_ofnode(ofnode_get_parent(phandle.node), _bus);
+ if (ret) {
+ dev_err(dev, "Failed to get i2c node, err: %d\n", ret);
+ return ret;
+ }
+ ret = ofnode_read_u32(phandle.node, "reg", _addr);
+ if (ret)
+ return ret;
+
+ ret = i2c_get_chip(i2c_bus, slave_addr, 1, _dev);
+ if (ret) {
+ debug("%s: can't find i2c chip device for addr %x\n",
__func__,
+ slave_addr);
+ return ret;
+ }
+
+ i2c_chip = dev_get_parent_plat(i2c_dev);
+ if (i2c_chip) {
+ i2c_chip->flags &= ~DM_I2C_CHIP_WR_ADDRESS;
+ /* SMBus write command */
+ ret = dm_i2c_write(i2c_dev, 0, (uint8_t *)_buf, 8);
+ if (ret) {
+ dev_err(dev, "data_buf i2c_write failed,
err:%d\n", ret);
+ return ret;
+ }
+
+ /* Configuration register access command */
+ ret = dm_i2c_write(i2c_dev,
USB5744_CONFIG_REG_ACCESS_LSB,
+ (uint8_t *)_reg_access_buf,
2);
+ if (ret) {
+ dev_err(dev, "config_reg_access i2c_write
failed, err: %d\n", ret);
+ return ret;
+ }
+
+ /* USB Attach with SMBus */
+ ret = dm_i2c_write(i2c_dev, USB5744_COMMAND_ATTACH_LSB,
(uint8_t *), 2);
+ if (ret) {
+ dev_err(dev, "usb_attach i2c_write
[PATCH 3/7] usb: onboard-hub: add support for Microchip USB5744
Add support for the Microchip USB5744 USB3.0 and USB2.0 Hub.
The usb5744 driver trigger hub reset signal after soft reset.
The usb5744 hub need to reset after the phy initialization,
which toggles the gpio.
Signed-off-by: Venkatesh Yadav Abbarapu
---
common/usb_onboard_hub.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 0cfaa90fce3..50870285995 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -88,11 +88,21 @@ static const struct onboard_hub_data usb2514_data = {
/* TBD */
};
+static const struct onboard_hub_data usb5744_data = {
+ .reset_us = 1,
+};
+
static const struct udevice_id usb_onboard_hub_ids[] = {
/* Use generic usbVID,PID dt-bindings (usb-device.yaml) */
{
.compatible = "usb424,2514", /* USB2514B USB 2.0 */
.data = (ulong)_data,
+ }, {
+ .compatible = "usb424,5744", /* USB5744 USB 3.0 */
+ .data = (ulong)_data,
+ }, {
+ .compatible = "usb424,2744", /* USB2744 USB 2.0 */
+ .data = (ulong)_data,
}
};
--
2.17.1
[PATCH 2/7] usb: onboard-hub: Fix the return values of regulator APIs
Use the regulator API's only if the config DM_REGULATOR is enabled.
Don't error out if there is no vdd regulator supply, as these are
optional properties.
Signed-off-by: Venkatesh Yadav Abbarapu
---
common/usb_onboard_hub.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 2f6fb71935d..0cfaa90fce3 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -30,16 +30,22 @@ static int usb_onboard_hub_probe(struct udevice *dev)
struct onboard_hub *hub = dev_get_priv(dev);
int ret;
- ret = device_get_supply_regulator(dev, "vdd-supply", >vdd);
- if (ret) {
- dev_err(dev, "can't get vdd-supply: %d\n", ret);
- return ret;
+ if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
+ ret = device_get_supply_regulator(dev, "vdd-supply",
+ >vdd);
+ if (ret && ret != -ENOENT) {
+ dev_err(dev, "Failed to get VDD regulator: %d\n", ret);
+ return ret;
+ }
+ if (hub->vdd) {
+ ret = regulator_set_enable_if_allowed(hub->vdd, true);
+ if (ret && ret != -ENOSYS) {
+ dev_err(dev, "Failed to enable VDD regulator:
%d\n", ret);
+ return ret;
+ }
+ }
}
- ret = regulator_set_enable_if_allowed(hub->vdd, true);
- if (ret)
- dev_err(dev, "can't enable vdd-supply: %d\n", ret);
-
hub->reset_gpio = devm_gpiod_get_optional(dev, "reset",
GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW);
/* property is optional, don't return error! */
--
2.17.1
