Re: [PATCH v4 4/5] usb: dwc3-generic: Add rk3568 support
On 7/28/23 14:40, Jonas Karlman wrote:
RK3568 share glue and ctrl in a single node. Use glue_get_ctrl_dev to
return the glue node as the ctrl node.
Signed-off-by: Jonas Karlman
Reviewed-by: Jagan Teki
---
v4:
- No change
v3:
- No change
v2:
- No change
- Collect r-b tag
drivers/usb/dwc3/dwc3-generic.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 2331ac453132..f6d087722c9f 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -405,6 +405,22 @@ struct dwc3_glue_ops ti_ops = {
.glue_configure = dwc3_ti_glue_configure,
};
+static int dwc3_rk_glue_get_ctrl_dev(struct udevice *dev, ofnode *node)
+{
+ if (!device_is_compatible(dev, "snps,dwc3"))
+ return -EINVAL;
Can this ever happen ?
Re: [PATCH v4 3/5] usb: dwc3-generic: Relax unsupported dr_mode check
On 7/28/23 14:40, Jonas Karlman wrote:
When dr_mode is peripheral or otg and U-Boot has not been built with
DM_USB_GADGET support, booting such device may end up with:
dwc3_glue_bind_common: subnode name: usb@fcc0
Error binding driver 'dwc3-generic-wrapper': -6
Some drivers failed to bind
initcall sequence effbca08 failed at call 00a217c8 (err=-6)
### ERROR ### Please RESET the board ###
Instead fail gracfully with ENODEV to allow board continue booting.
dwc3_glue_bind_common: subnode name: usb@fcc0
dwc3_glue_bind_common: unsupported dr_mode 3
Also use CONFIG_IS_ENABLED(USB_HOST) and change switch to if statements
to improve readability of the code.
Fixes: 446e3a205b87 ("dwc3-generic: Handle the PHYs, the clocks and the reset
lines")
Signed-off-by: Jonas Karlman
Reviewed-by: Marek Vasut
Re: [PATCH 1/1] doc: move README.falcon to HTML
On Fri, 28 Jul 2023 at 14:49, Heinrich Schuchardt wrote: > > Move the Falcon mode documentation to HTML. > > Signed-off-by: Heinrich Schuchardt > --- > doc/README.falcon | 232 > doc/develop/falcon.rst | 258 + > doc/develop/index.rst | 1 + > 3 files changed, 259 insertions(+), 232 deletions(-) > delete mode 100644 doc/README.falcon > create mode 100644 doc/develop/falcon.rst Reviewed-by: Simon Glass
Re: [PATCHv4 1/5] net/lwip: add lwip-external submodule
Hi Tom, On Fri, 28 Jul 2023 at 12:09, Tom Rini wrote: > > On Thu, Jul 27, 2023 at 03:34:48PM +0300, Ilias Apalodimas wrote: > > > Tom, Simon > > are you ok with submodules on this one? > > Still punting on that question and waiting for commentary from > distribution people. I really quite badly don't want the pain of submodules. They are used in coreboot and I sometimes end up just deleting everything and starting again. Regards, Simon
Re: [bug report] cros_ec: Add vstore support
Hi Dan,
On Tue, 25 Jul 2023 at 00:51, Dan Carpenter wrote:
>
> Hello Simon Glass,
>
> The patch 10f746591fba: "cros_ec: Add vstore support" from Jan 16,
> 2021 (linux-next), leads to the following Smatch static checker
> warning:
>
> drivers/misc/cros_ec_sandbox.c:543 process_cmd() error: buffer overflow
> 'ec->slot' 4 <= 31
> drivers/misc/cros_ec_sandbox.c:556 process_cmd() error: buffer overflow
> 'ec->slot' 4 <= 31
>
> drivers/misc/cros_ec_sandbox.c
> 521 len = sizeof(*resp);
> 522 break;
> 523 }
> 524 case EC_CMD_VSTORE_INFO: {
> 525 struct ec_response_vstore_info *resp = resp_data;
> 526 int i;
> 527
> 528 resp->slot_count = VSTORE_SLOT_COUNT;
>
> There are two related defines. VSTORE_SLOT_COUNT (4) is the number of
> elements in ec->slot[].
>
> 529 resp->slot_locked = 0;
> 530 for (i = 0; i < VSTORE_SLOT_COUNT; i++) {
> 531 if (ec->slot[i].locked)
> 532 resp->slot_locked |= 1 << i;
> 533 }
> 534 len = sizeof(*resp);
> 535 break;
> 536 };
> 537 case EC_CMD_VSTORE_WRITE: {
> 538 const struct ec_params_vstore_write *req = req_data;
> 539 struct vstore_slot *slot;
> 540
> 541 if (req->slot >= EC_VSTORE_SLOT_MAX)
> 542 return -EINVAL;
> --> 543 slot = >slot[req->slot];
>
> But here the check is for EC_VSTORE_SLOT_MAX (32) so Smatch thinks that
> 32 is more than 4 so this is an out of bounds. Should the limit be
> smaller or the array larger?
The limit should be EC_VSTORE_SLOT_COUNT since we don't support the
max number of slots in the emulator.
So this should check for EC_VSTORE_SLOT_COUNT instead of EC_VSTORE_SLOT_MAX.
>
> 544 slot->locked = true;
> 545 memcpy(slot->data, req->data, EC_VSTORE_SLOT_SIZE);
> 546 len = 0;
> 547 break;
> 548 }
> 549 case EC_CMD_VSTORE_READ: {
> 550 const struct ec_params_vstore_read *req = req_data;
> 551 struct ec_response_vstore_read *resp = resp_data;
> 552 struct vstore_slot *slot;
> 553
> 554 if (req->slot >= EC_VSTORE_SLOT_MAX)
> 555 return -EINVAL;
> 556 slot = >slot[req->slot];
>
> Same.
Same here.
>
> 557 memcpy(resp->data, slot->data, EC_VSTORE_SLOT_SIZE);
> 558 len = sizeof(*resp);
> 559 break;
> 560 }
> 561 case EC_CMD_PWM_GET_DUTY: {
> 562 const struct ec_params_pwm_get_duty *req = req_data;
Regards,
Simon
Re: [PATCH 01/14] bloblist: Update the tag numbering
> Ok, but if we do that we need to be careful with the standard. Things > like BLOBLISTT_U_BOOT_VIDEO dont feel U-Boot specific. The idea behind the Transfer List tag allocation policy is low friction allocation and organically emerging standards. You're not supposed to need to have big up-front debates about how exactly e.g. a video info descriptor should look like or whether it can be shared with other projects. Projects are just supposed to add what they need in the moment, in whatever format they prefer, and can call it something specific to that project to begin with (e.g. U_BOOT_VIDEO). Then, later, if other projects feel that this is a good format that would be worthwhile to reuse, they can just start using it. Just because it says U_BOOT or the ID number is close to the number for other U-Boot descriptors doesn't mean that it's not appropriate to be used anywhere else as long as the same structure with the same meaning makes sense there. If we eventually find that a bunch of different projects are all using this tag and it has become a de facto standard, we can also change the name to drop the U_BOOT (or different projects can even use different names for the same thing, that doesn't really matter as long as the ID and format matches). Or, if U-Boot eventually finds that this structure doesn't work well for them anymore they can just allocate a new U_BOOT_VIDEO2 and stop using the old one (or rename the old one to U_BOOT_VIDEO_DEPRECATED and call a new ID with a new format U_BOOT_VIDEO). Basically, the idea here is that upfront "perfect" design by committee tends to not work well for these things anyway and the friction it adds would be too much of a barrier to adoption. So it's better to not even try, just let everyone allocate what they want, and then later see what tends to work out well in practice and where there are opportunities for tag sharing between projects.
Re: [PATCH] doc: board: ti: Add SPDX License to svg images
On 7/28/23 22:05, Nishanth Menon wrote: Add Licensing to svg images to clarify the terms. Signed-off-by: Nishanth Menon Reviewed-by: Heinrich Schuchardt
[PATCH v4 0/3] board: toradex: add verdin am62 support
From: Marcel Ziswiler This series adds initial support for the Toradex Verdin AM62 SoM [1]. The first commit adds resp. PID4s to the ConfigBlock, the second one fixes an early clocking issue confirmed to be a weird bug in TI's scripting. And last but not least support for the Toradex Verdin AM62 is added. [1] https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62 Changes in v4: - Re-based on top of master with recent binman integration, mac_efuse, cpsw-phy-sel and mdio clean-up and dtsi bump from linux v6.5-rc1. - Verdin AM62 binman enablement and further clean-up after re-base. - Removed all ifdefs from DTs now with bumped Linux dtsi. - Avoid relocated U-Boot and DT reserved-memory clash. - Enable of_system_setup. Changes in v3: - Add Verdin AM62 launch configuration SKUs as well. - Integrate our recent find of CTRL_SLEEP_MOCI# needing to be driven from A53 SPL as it may be used to control some power-rails on the carrier board. E.g. on the Yavia carrier board it is needed to power the I2C EEPROM on the carrier board. - Improve boot environment in R5 SPL vs. A53. - Integrate launch configuration SKUs to Wi-Fi handling. - Re-sync device trees from Linux kernel v6.5-rc1. - Add warning if memory is less than expected. Changes in v2: - Add Bryan's reviewed-by tag. Thanks! - Use 1.2 GHz rather than 1.25 GHz A53 clock as on the EVM/SK. - Also add power-domain 166 as on the EVM/SK. - Get rid of main_bcdma and main_pktdma as not required in R5 SPL. - Get rid of all bootph-pre-ram in Ethernet and SDHC1 aka SD card related pinctrls as not required in any SPL. - Enable CONFIG_TI_SECURE_DEVICE by default as Non-HS devices will continue to boot due to runtime device type detection. - Disable FAT and SPI support as not required in R5 SPL. - Also enable CONFIG_SPL_MMC_HS200_SUPPORT in R5 SPL. - Enable CONFIG_LEGACY_IMAGE_FORMAT to allow sourcing unsigned script images e.g. like our current boot scripts. - Increase CONFIG_SYS_BOOTM_LEN to 64 MB to allow booting bigger compressed images as e.g. in the Toradex Easy Installer case. - Change memory configurations to operate at temperatures of up to 95 degrees celsius. - Increase CONFIG_SYS_MAXARGS from default 16 to 64. - Enable CONFIG_CMD_REMOTEPROC, CONFIG_SPL_DM_GPIO_LOOKUP_LABEL and CONFIG_SPL_I2C_EEPROM. - For R5 SPL increase CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN to 0x14, enable CONFIG_SPL_I2C, CONFIG_DM_I2C and CONFIG_SYS_I2C_OMAP24XX and savedefconfig got rid of CONFIG_SPL_FIT_IMAGE_POST_PROCESS. Marcel Ziswiler (3): toradex: tdx-cfg-block: add verdin am62 skus arm: mach-k3: am62: fix 2nd mux option of clkout0 board: toradex: add verdin am62 support arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-am62-verdin-dev.dtsi | 192 ++ arch/arm/dts/k3-am62-verdin-wifi.dtsi | 39 + arch/arm/dts/k3-am62-verdin.dtsi | 1405 +++ .../dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 2190 + arch/arm/dts/k3-am625-verdin-r5.dts | 116 + .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 570 + .../dts/k3-am625-verdin-wifi-dev-u-boot.dtsi | 201 ++ arch/arm/dts/k3-am625-verdin-wifi-dev.dts | 22 + arch/arm/mach-k3/Kconfig |1 + arch/arm/mach-k3/am62x/clk-data.c |5 +- board/toradex/common/tdx-cfg-block.c |7 + board/toradex/common/tdx-cfg-block.h | 10 +- board/toradex/verdin-am62/Kconfig | 82 + board/toradex/verdin-am62/MAINTAINERS | 17 + board/toradex/verdin-am62/Makefile|6 + board/toradex/verdin-am62/board-cfg.yaml | 36 + board/toradex/verdin-am62/pm-cfg.yaml | 12 + board/toradex/verdin-am62/rm-cfg.yaml | 1088 board/toradex/verdin-am62/sec-cfg.yaml| 379 +++ board/toradex/verdin-am62/verdin-am62.c | 131 + configs/verdin-am62_a53_defconfig | 187 ++ configs/verdin-am62_r5_defconfig | 111 + doc/board/toradex/verdin-am62.rst | 169 ++ include/configs/verdin-am62.h | 55 + 25 files changed, 7030 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/k3-am62-verdin-dev.dtsi create mode 100644 arch/arm/dts/k3-am62-verdin-wifi.dtsi create mode 100644 arch/arm/dts/k3-am62-verdin.dtsi create mode 100644 arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi create mode 100644 arch/arm/dts/k3-am625-verdin-r5.dts create mode 100644 arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi create mode 100644 arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi create mode 100644 arch/arm/dts/k3-am625-verdin-wifi-dev.dts create mode 100644 board/toradex/verdin-am62/Kconfig create mode 100644 board/toradex/verdin-am62/MAINTAINERS create mode 100644 board/toradex/verdin-am62/Makefile create mode 100644 board/toradex/verdin-am62/board-cfg.yaml create mode 100644 board/toradex/verdin-am62/pm-cfg.yaml create mode 100644
[PATCH v4 2/3] arm: mach-k3: am62: fix 2nd mux option of clkout0
From: Marcel Ziswiler
Fix second mux option of clkout0 which should really be
DEV_BOARD0_CLKOUT0_IN_PARENT_HSDIV4_16FFT_MAIN_2_HSDIVOUT1_CLK10
rather than twice the same according to [1].
[1]
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/clocks.html#clocks-for-board0-device
Signed-off-by: Marcel Ziswiler
Reviewed-by: Bryan Brattlof
---
(no changes since v2)
Changes in v2:
- Add Bryan's reviewed-by tag. Thanks!
arch/arm/mach-k3/am62x/clk-data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/am62x/clk-data.c
b/arch/arm/mach-k3/am62x/clk-data.c
index c0881778fe7..d7bfed0e031 100644
--- a/arch/arm/mach-k3/am62x/clk-data.c
+++ b/arch/arm/mach-k3/am62x/clk-data.c
@@ -57,7 +57,7 @@ static const char * const
sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
static const char * const clkout0_ctrl_out0_parents[] = {
"hsdiv4_16fft_main_2_hsdivout1_clk",
- "hsdiv4_16fft_main_2_hsdivout1_clk",
+ "hsdiv4_16fft_main_2_hsdivout1_clk10",
};
static const char * const clk_32k_rc_sel_out0_parents[] = {
@@ -195,6 +195,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_1_hsdivout1_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681084, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_1_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681088, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_2_hsdivout1_clk",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682084, 0, 7, 0, 0),
+ CLK_DIV("hsdiv4_16fft_main_2_hsdivout1_clk10",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682084, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_2_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682088, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_mcu_0_hsdivout0_clk",
"pllfracf_ssmod_16fft_mcu_0_foutvcop_clk", 0x4040080, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("sam62_pll_ctrl_wrap_main_0_sysclkout_clk",
sam62_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
@@ -313,7 +314,7 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(146, 5, "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(157, 20, "clkout0_ctrl_out0"),
DEV_CLK(157, 21, "hsdiv4_16fft_main_2_hsdivout1_clk"),
- DEV_CLK(157, 22, "hsdiv4_16fft_main_2_hsdivout1_clk"),
+ DEV_CLK(157, 22, "hsdiv4_16fft_main_2_hsdivout1_clk10"),
DEV_CLK(157, 24, "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(157, 25, "board_0_ddr0_ck0_out"),
DEV_CLK(157, 40, "mshsi2c_main_0_porscl"),
--
2.36.1
[PATCH v4 1/3] toradex: tdx-cfg-block: add verdin am62 skus
From: Marcel Ziswiler
Add initial Verdin AM62 Quad 1GB WB IT prototype and launch
configuration SKUs to ConfigBlock handling.
0069: Verdin AM62 Quad 1GB WB IT
0071: Verdin AM62 Solo 512MB
0072: Verdin AM62 Solo 512MB WB IT
0073: Verdin AM62 Dual 1GB ET
0074: Verdin AM62 Dual 1GB IT
0075: Verdin AM62 Dual 1GB WB IT
0076: Verdin AM62 Quad 2GB WB IT
Signed-off-by: Marcel Ziswiler
Signed-off-by: Emanuele Ghidoli
---
(no changes since v3)
Changes in v3:
- Add Verdin AM62 launch configuration SKUs as well.
board/toradex/common/tdx-cfg-block.c | 7 +++
board/toradex/common/tdx-cfg-block.h | 10 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index e513f4a2919..8ad4907bfe4 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -139,7 +139,14 @@ const struct toradex_som toradex_modules[] = {
[66] = { "Verdin iMX8M Plus Quad 8GB WB",
TARGET_IS_ENABLED(VERDIN_IMX8MP) },
[67] = { "Apalis iMX8QM 8GB WB IT",
TARGET_IS_ENABLED(APALIS_IMX8) },
[68] = { "Verdin iMX8M Mini Quad 2GB WB IT",
TARGET_IS_ENABLED(VERDIN_IMX8MM) },
+ [69] = { "Verdin AM62 Quad 1GB WB IT",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
[70] = { "Verdin iMX8M Plus Quad 8GB WB IT",
TARGET_IS_ENABLED(VERDIN_IMX8MP) },
+ [71] = { "Verdin AM62 Solo 512MB",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
+ [72] = { "Verdin AM62 Solo 512MB WB IT",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
+ [73] = { "Verdin AM62 Dual 1GB ET",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
+ [74] = { "Verdin AM62 Dual 1GB IT",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
+ [75] = { "Verdin AM62 Dual 1GB WB IT",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
+ [76] = { "Verdin AM62 Quad 2GB WB IT",
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
};
const char * const toradex_carrier_boards[] = {
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index 45fa04ca38a..5c204931a2d 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -94,8 +94,14 @@ enum {
VERDIN_IMX8MPQ_8GB_WIFI_BT,
APALIS_IMX8QM_8GB_WIFI_BT_IT,
VERDIN_IMX8MMQ_WIFI_BT_IT_NO_CAN,
- /* 69 */
- VERDIN_IMX8MPQ_8GB_WIFI_BT_IT = 70, /* 70 */
+ VERDIN_AM62Q_WIFI_BT_IT,
+ VERDIN_IMX8MPQ_8GB_WIFI_BT_IT, /* 70 */
+ VERDIN_AM62S_512MB,
+ VERDIN_AM62S_512MB_WIFI_BT_IT,
+ VERDIN_AM62D_1G_ET,
+ VERDIN_AM62D_1G_IT,
+ VERDIN_AM62D_1G_WIFI_BT_IT, /* 75 */
+ VERDIN_AM62Q_2G_WIFI_BT_IT,
};
enum {
--
2.36.1
Re: [PATCH v4 1/2] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
Hi Maxime On Fri, 2023-07-28 at 15:52 +0200, mrip...@kernel.org wrote: > On Fri, Jul 28, 2023 at 01:34:38PM +, Marcel Ziswiler wrote: [snip] > > However, so far I could not make this work for our use-case [1]. It just > > keeps crashing. Any ideas? > > > > [snip] [snip] > > [1] https://lore.kernel.org/all/20230715074050.941051-1-mar...@ziswiler.com > > It looks like this series is fairly outdated and won't reasonably work > with these patches. Do you have a branch where you pulled our patches? I figured it out now. I was missing CONFIG_PHY_ETHERNET_ID required for reset-gpios in the PHY node to work in U-Boot. Sorry for the noise. Cleaned-up v4 of our stuff incoming... Thanks! > Maxime Cheers Marcel
[PATCH 1/1] doc: move README.falcon to HTML
Move the Falcon mode documentation to HTML. Signed-off-by: Heinrich Schuchardt --- doc/README.falcon | 232 doc/develop/falcon.rst | 258 + doc/develop/index.rst | 1 + 3 files changed, 259 insertions(+), 232 deletions(-) delete mode 100644 doc/README.falcon create mode 100644 doc/develop/falcon.rst diff --git a/doc/README.falcon b/doc/README.falcon deleted file mode 100644 index 88218d35b9..00 --- a/doc/README.falcon +++ /dev/null @@ -1,232 +0,0 @@ -U-Boot Falcon Mode - - -Introduction - - -This document provides an overview of how to add support for Falcon Mode -to a board. - -Falcon Mode is introduced to speed up the booting process, allowing -to boot a Linux kernel (or whatever image) without a full blown U-Boot. - -Falcon Mode relies on the SPL framework. In fact, to make booting faster, -U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot -image. In most implementations, SPL is used to start U-Boot when booting from -a mass storage, such as NAND or SD-Card. SPL has now support for other media, -and can generally be seen as a way to start an image performing the minimum -required initialization. SPL mainly initializes the RAM controller, and then -copies U-Boot image into the memory. - -The Falcon Mode extends this way allowing to start the Linux kernel directly -from SPL. A new command is added to U-Boot to prepare the parameters that SPL -must pass to the kernel, using ATAGS or Device Tree. - -In normal mode, these parameters are generated each time before -loading the kernel, passing to Linux the address in memory where -the parameters can be read. -With Falcon Mode, this snapshot can be saved into persistent storage and SPL is -informed to load it before running the kernel. - -To boot the kernel, these steps under a Falcon-aware U-Boot are required: - -1. Boot the board into U-Boot. -After loading the desired legacy-format kernel image into memory (and DT as -well, if used), use the "spl export" command to generate the kernel parameters -area or the DT. U-Boot runs as when it boots the kernel, but stops before -passing the control to the kernel. - -2. Save the prepared snapshot into persistent media. -The address where to save it must be configured into board configuration -file (CONFIG_CMD_SPL_NAND_OFS for NAND). - -3. Boot the board into Falcon Mode. SPL will load the kernel and copy -the parameters which are saved in the persistent area to the required address. -If a valid uImage is not found at the defined location, U-Boot will be -booted instead. - -It is required to implement a custom mechanism to select if SPL loads U-Boot -or another image. - -The value of a GPIO is a simple way to operate the selection, as well as -reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. - -Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells -SPL that U-Boot is not the only available image that SPL is able to start. - -Configuration - -CONFIG_CMD_SPL Enable the "spl export" command. - The command "spl export" is then available in U-Boot - mode -CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be - copied by SPL. - In most cases, it is + 0x100 - -CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is stored - -CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was saved. - -CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved. - -CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied - -CONFIG_SPL_OS_BOOT Activate Falcon Mode. - -Function that a board must implement - - -void spl_board_prepare_for_linux(void) : optional - Called from SPL before starting the kernel - -spl_start_uboot() : required - Returns "0" if SPL should start the kernel, "1" if U-Boot - must be started. - -Environment variables -- - -A board may chose to look at the environment for decisions about falcon -mode. In this case the following variables may be supported: - -boot_os : Set to yes/Yes/true/True/1 to enable booting to OS, - any other value to fall back to U-Boot (including - unset) -falcon_args_file : Filename to load as the 'args' portion of falcon mode - rather than the hard-coded value. -falcon_image_file :Filename to load as the OS image portion of falcon - mode rather than the hard-coded value. - -Using spl command -- - -spl - SPL configuration - -Usage: - -spl export [kernel_addr] [initrd_addr] [fdt_addr ] - -img: "atags" or "fdt" -kernel_addr: kernel is
[PATCH] doc: board: ti: Add SPDX License to svg images
Add Licensing to svg images to clarify the terms. Signed-off-by: Nishanth Menon --- doc/board/ti/img/boot_diagram_am65.svg | 4 doc/board/ti/img/boot_diagram_j721e.svg| 4 doc/board/ti/img/boot_diagram_k3_current.svg | 4 doc/board/ti/img/boot_flow_01.svg | 4 doc/board/ti/img/boot_flow_02.svg | 4 doc/board/ti/img/boot_flow_03.svg | 4 doc/board/ti/img/dm_tispl.bin.svg | 4 doc/board/ti/img/emmc_am65x_evm_boot0.svg | 4 doc/board/ti/img/emmc_j7200_evm_boot01.svg | 4 doc/board/ti/img/emmc_j7200_evm_udafs.svg | 4 doc/board/ti/img/j7200_tiboot3.bin.svg | 4 doc/board/ti/img/multi_cert_tiboot3.bin.svg| 4 doc/board/ti/img/no_multi_cert_tiboot3.bin.svg | 4 doc/board/ti/img/nodm_tispl.bin.svg| 4 doc/board/ti/img/ospi_sysfw.svg| 4 doc/board/ti/img/sysfw.itb.svg | 4 16 files changed, 64 insertions(+) diff --git a/doc/board/ti/img/boot_diagram_am65.svg b/doc/board/ti/img/boot_diagram_am65.svg index fe5533a51973..79c65e115ff5 100644 --- a/doc/board/ti/img/boot_diagram_am65.svg +++ b/doc/board/ti/img/boot_diagram_am65.svg @@ -1,4 +1,8 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Re: [PATCH v2 1/1] doc: U-Boot boot phases
On 7/28/23 19:32, Simon Glass wrote: Hi Heinrich, On Fri, 28 Jul 2023 at 09:58, Heinrich Schuchardt wrote: Add more detail to the description of U-Boot boot phases: * describe which steps are optional * mentions alternative boot flows Signed-off-by: Heinrich Schuchardt Reviewed-by: Bin Meng --- v2: add missing comma --- doc/develop/spl.rst | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst index a1515a7b43..5743bdf37c 100644 --- a/doc/develop/spl.rst +++ b/doc/develop/spl.rst @@ -77,10 +77,11 @@ To check whether a feature is enabled, use CONFIG_IS_ENABLED():: This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build, CONFIG_TPL_CLK for the TPL build, etc. -U-Boot Phases -- +U-Boot Boot Phases +-- -U-Boot boots through the following phases: +U-Boot goes through the following boot phases where TPL, VPL, SPL are optional. +While many boards use SPL, less use TPL. TPL Very early init, as tiny as possible. This loads SPL (or VPL if enabled). @@ -97,6 +98,12 @@ SPL U-Boot U-Boot proper, containing the command line and boot logic. +Further usages of U-Boot SPL comprise: + +* Launching BL31 of ARM Trusted Firmware which invokes main U-Boot as BL33 +* launching EDK II Really? Where are the instructions for that? OpenSBI is used to start RISCV_VIRT_CODE.fd. So you just need to put both into a FIT image. If you follow the EBBR, this would be a file FIRMWARE/vendor/board/edk2.fit on the EFI System Partition. Then launch the FIT image with SPL on qemu-riscv64_spl_defconfig. You could do the same on real hardware with EDK II support like the SiFive HiFive Unleashed. +* launching Linux kernel This is falcon boot, is it? Can we link to the docs? No, falcon mode is described in doc/README.falcon and not in the HTML documentation. Falcon mode (i.e. using a legacy U-boot image) would be one possibility to boot into Linux from SPL. Instead you could also use a FIT image. As legacy U-Boot images are deprecated linking to Falcon mode would seem misleading. Best regards Heinrich +* launching RISC-V OpenSBI which invokes main U-Boot Checking the boot phase --- -- 2.40.1 Regards, Simon
Re: [PATCHv4 1/5] net/lwip: add lwip-external submodule
On Thu, Jul 27, 2023 at 03:34:48PM +0300, Ilias Apalodimas wrote: > Tom, Simon > are you ok with submodules on this one? Still punting on that question and waiting for commentary from distribution people. -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/9] board_f: Fix corruption of relocaddr
Hi,
+Tom Rini for comment
On Fri, 28 Jul 2023 at 02:35, Nikhil M Jain wrote:
>
> Hi Simon,
>
> On 27/07/23 23:31, Simon Glass wrote:
> > Hi Nikhil,
> >
> > On Wed, 26 Jul 2023 at 23:22, Nikhil M Jain wrote:
> >>
> >> Hi Simon,
> >>
> >> On 27/07/23 06:23, Simon Glass wrote:
> >>> Hi Devarsh,
> >>>
> >>> On Wed, 26 Jul 2023 at 05:09, Devarsh Thakkar wrote:
>
> Hi Simon,
>
> On 26/07/23 02:58, Simon Glass wrote:
> > Hi Devarsh,
> >
> > On Tue, 25 Jul 2023 at 03:21, Devarsh Thakkar wrote:
> >>
> >> Hi Simon,
> >>
> >> On 24/07/23 20:22, Simon Glass wrote:
> >>> When the video framebuffer comes from the bloblist, we should not
> >>> change
> >>> relocaddr to this address, since it interfers with the normal memory
> >>> allocation.
> >>>
> >>> This fixes a boot loop in qemu-x86_64
> >>>
> >>> Signed-off-by: Simon Glass
> >>> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL
> >>> to u-boot")
> >>> ---
> >>>
> >>>common/board_f.c | 1 -
> >>>1 file changed, 1 deletion(-)
> >>>
> >>> diff --git a/common/board_f.c b/common/board_f.c
> >>> index 7d2c380e91e2..5c8646b22283 100644
> >>> --- a/common/board_f.c
> >>> +++ b/common/board_f.c
> >>> @@ -419,7 +419,6 @@ static int reserve_video(void)
> >>> if (!ho)
> >>> return log_msg_ret("blf", -ENOENT);
> >>> video_reserve_from_bloblist(ho);
> >>> - gd->relocaddr = ho->fb;
> >>
> >> I think this change was done as relocaddr pointer was required to be
> >> updated
> >> to move after frame-buffer reserved area to ensure that any further
> >> memory
> >> reservations done using gd->relocaddr (for e.g. in
> >> reserve_trace/uboot/malloc)
> >> don't overlap with frame-buffer reserved area passed from blob, so I
> >> think
> >> removing this line may cause further memory reservations to overlap
> >> with
> >> reserved framebuffer.
> >>
> >> Could you please confirm?
> >
> > SPL and U-Boot have different memory layouts. The current code is
> > interrupting U-Boot's careful building up of chunks of memory used for
> > different purposes.
> >
>
> But it is possible they could be using similar memory layout for some
> components like framebuffer.
> For e.g. in our case we are using same video_reserve func in A53 SPL too
> and which allocates framebuffer from gd->relocaddr as seen here:
>
> https://source.denx.de/u-boot/u-boot/-/blob/v2023.10-rc1/common/board_f.c?ref_type=tags#L427
> >>>
> >>> Even if it is similar, the point is that U-Boot proper needs to do its
> >>> own allocation stuff.
> >>>
> >>> Of course, if SPL sets up the video, it will provide the framebuffer
> >>> address, but only that. The other addresses need to be done using the
> >>> normal mechanism.
> >>>
>
> > The video memory has already been allocated by SPL, so we don't need
> > to insert a new one here, as your code demonstrates.
> >
>
> Agreed.
>
> > But also we have no way of knowing if it is legal to relocate U-Boot
> > (and various other things) just below the frame buffer chosen by SPL.
> >
>
> Yes, so i suppose your case is that framebuffer address which is being
> passed
> by SPL is totally disjoint and too far away from gd->relocaddr, for e.g.
> it is
> at the start (or bottom of DDR) and doesn't interfere with gd->relocaddr
> in
> any manner since relocaddr points to ramtop (i.e. near to end address of
> DDR).
>
> In that case I agree it doesn't make sense to move relocaddr to ho->fb.
>
> But for the scenario where gd->relocaddr and ho->fb are nearby there is
> every
> possibility that gd->relocaddr may overlap with framebuffer, also the
> code in
> reserve_trace, reserve_uboot doesn't have any intelligence or check that
> it is
> overlapping with framebuffer area or not.
>
> I think one thing that can probably be done here is to have a check that
> if
> passed framebuffer area falls within current relocaddr region, then
> update the
> relocaddr else don't touch relocaddr :
>
> if (ho->fb <= gd->relocaddr - ho->size)
> //It means framebuffer are is overlapping with current relocaddr so
> update
> relocaddr
> gd->relocaddr = ho->fb
>
> We should go ahead with this check because it won't disrupt u-boot's
> allocation of memory and will allow both the cases if a platform is
> using same memory layout or different memory layout across SPL and
> u-boot proper. Below are the logs for both scenarios.
>
> https://gist.github.com/NikMJain/aca198ae77b6f1855459bc8fbdd683df
>
> else
> //don't update gd->relocaddr since
Re: [PATCH 2/9] video: Tidy up Makefile rule for video
Hi Bin, On Fri, 28 Jul 2023 at 09:46, Bin Meng wrote: > > Hi Simon, > > On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote: > > > > Drop the duplication and add a single rule which can handle SPL as well. > > > > Signed-off-by: Simon Glass > > --- > > > > drivers/Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/Makefile b/drivers/Makefile > > index 3bc6d279d7cb..7272681fc741 100644 > > --- a/drivers/Makefile > > +++ b/drivers/Makefile > > @@ -39,6 +39,8 @@ obj-$(CONFIG_$(SPL_TPL_)TPM) += tpm/ > > obj-$(CONFIG_$(SPL_)NVME) += nvme/ > > obj-$(CONFIG_XEN) += xen/ > > obj-$(CONFIG_$(SPL_)FPGA) += fpga/ > > +obj-$(CONFIG_$(SPL_TPL_)VIDEO) += video/ > > This should be $(SPL_) as the original codes do not enable video build for TPL Yes, but SPL_TPL supports that, in that TPL_VIDEO is not enabled, so it will not be built for TPL. In general, we never need the $(SPL) variant. Regards, Simon
Re: [PATCH 4/9] Revert "x86: Switch QEMU over to use the bochs driver"
Hi Bin, On Fri, 28 Jul 2023 at 09:46, Bin Meng wrote: > > Hi Simon, > > On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote: > > > > Unfortunately the bochs driver does not currently work with distros. It > > causes a hang sometime between grub menu selection and the OS displaying > > something. > > Does this reproduce reliably? Yes, it does. BTW I've also hit another problem with '-M accel-kvm' which hangs on the move to 64-bit mode. Oddly if I boot U-Boot from coreboot, the problem goes away. So perhaps coreboot is doing some x86 init which U-Boot is missing. > > > > > This reverts commit b8956425d525c3c25fd218f252f89a5e44df6a9f. > > > > Signed-off-by: Simon Glass > > --- > > > > arch/x86/cpu/qemu/Kconfig | 2 +- > > configs/qemu-x86_64_defconfig | 4 > > configs/qemu-x86_defconfig| 3 +++ > > 3 files changed, 8 insertions(+), 1 deletion(-) > > > > Regards, > Bin Regards, Simon
Re: [PATCH v2 1/1] doc: U-Boot boot phases
Hi Heinrich, On Fri, 28 Jul 2023 at 09:58, Heinrich Schuchardt wrote: > > Add more detail to the description of U-Boot boot phases: > > * describe which steps are optional > * mentions alternative boot flows > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Bin Meng > --- > v2: > add missing comma > --- > doc/develop/spl.rst | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst > index a1515a7b43..5743bdf37c 100644 > --- a/doc/develop/spl.rst > +++ b/doc/develop/spl.rst > @@ -77,10 +77,11 @@ To check whether a feature is enabled, use > CONFIG_IS_ENABLED():: > This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build, > CONFIG_TPL_CLK for the TPL build, etc. > > -U-Boot Phases > -- > +U-Boot Boot Phases > +-- > > -U-Boot boots through the following phases: > +U-Boot goes through the following boot phases where TPL, VPL, SPL are > optional. > +While many boards use SPL, less use TPL. > > TPL > Very early init, as tiny as possible. This loads SPL (or VPL if enabled). > @@ -97,6 +98,12 @@ SPL > U-Boot > U-Boot proper, containing the command line and boot logic. > > +Further usages of U-Boot SPL comprise: > + > +* Launching BL31 of ARM Trusted Firmware which invokes main U-Boot as BL33 > +* launching EDK II Really? Where are the instructions for that? > +* launching Linux kernel This is falcon boot, is it? Can we link to the docs? > +* launching RISC-V OpenSBI which invokes main U-Boot > > Checking the boot phase > --- > -- > 2.40.1 > Regards, Simon
Re: [PATCH v2] gpio: Use separate bitfield array to indicate GPIO is claimed
Hi Marek,
On Fri, 28 Jul 2023 at 11:17, Marek Vasut wrote:
>
> The current gpio-uclass design uses name field in struct gpio_dev_priv as
> an indicator that GPIO is claimed by consumer. This overloads the function
> of name field and does not work well for named pins not configured as GPIO
> pins.
>
> Introduce separate bitfield array as the claim indicator.
>
> This unbreaks dual-purpose AF and GPIO operation on STM32MP since commit
> 2c38f7c31806 ("pinctrl: pinctrl_stm32: Populate uc_priv->name[] with pinmux
> node's name")
> where any pin which has already been configured as AF could no longer be
> claimed as dual-purpose GPIO. This is important for pins like STM32 MMCI
> st,cmd-gpios .
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Michal Suchanek
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Rasmus Villemoes
> Cc: Samuel Holland
> Cc: Simon Glass
> ---
> V2: Add set/clear helpers
> ---
> drivers/gpio/gpio-uclass.c | 61 ++
> include/asm-generic/gpio.h | 2 ++
> 2 files changed, 58 insertions(+), 5 deletions(-)
I'm OK with a separate bitfield thing if you really want it.
>
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index 712119c3415..68c079a3ccd 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -75,6 +75,46 @@ static int gpio_to_device(unsigned int gpio, struct
> gpio_desc *desc)
> return -ENOENT;
> }
>
> +/**
> + * gpio_is_claimed() - Test whether GPIO is claimed by consumer
> + *
> + * Test whether GPIO is claimed by consumer already.
> + *
> + * @uc_priv: gpio_dev_priv pointer.
> + * @offset:gpio offset within the device
> + * @return:true if claimed, false if not claimed
> + */
> +static bool gpio_is_claimed(struct gpio_dev_priv *uc_priv, unsigned int
> offset)
> +{
> + return !!(uc_priv->claimed[offset / 32] & BIT(offset % 32));
> +}
> +
> +/**
> + * gpio_set_claim() - Set GPIO claimed by consumer
> + *
> + * Set a bit which indicate the GPIO is claimed by consumer
> + *
> + * @uc_priv: gpio_dev_priv pointer.
> + * @offset:gpio offset within the device
> + */
> +static void gpio_set_claim(struct gpio_dev_priv *uc_priv, unsigned int
> offset)
> +{
> + uc_priv->claimed[offset / 32] |= BIT(offset % 32);
> +}
> +
> +/**
> + * gpio_clear_claim() - Clear GPIO claimed by consumer
> + *
> + * Clear a bit which indicate the GPIO is claimed by consumer
> + *
> + * @uc_priv: gpio_dev_priv pointer.
> + * @offset:gpio offset within the device
> + */
> +static void gpio_clear_claim(struct gpio_dev_priv *uc_priv, unsigned int
> offset)
> +{
> + uc_priv->claimed[offset / 32] &= ~BIT(offset % 32);
> +}
> +
> #if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
> /**
> * dm_gpio_lookup_label() - look for name in gpio device
> @@ -94,7 +134,7 @@ static int dm_gpio_lookup_label(const char *name,
>
> *offset = -1;
> for (i = 0; i < uc_priv->gpio_count; i++) {
> - if (!uc_priv->name[i])
> + if (!gpio_is_claimed(uc_priv, i))
> continue;
> if (!strcmp(name, uc_priv->name[i])) {
> *offset = i;
> @@ -350,7 +390,7 @@ int dm_gpio_request(struct gpio_desc *desc, const char
> *label)
> int ret;
>
> uc_priv = dev_get_uclass_priv(dev);
> - if (uc_priv->name[desc->offset])
> + if (gpio_is_claimed(uc_priv, desc->offset))
> return -EBUSY;
> str = strdup(label);
> if (!str)
> @@ -362,6 +402,8 @@ int dm_gpio_request(struct gpio_desc *desc, const char
> *label)
> return ret;
> }
> }
> +
> + gpio_set_claim(uc_priv, desc->offset);
> uc_priv->name[desc->offset] = str;
>
> return 0;
> @@ -438,7 +480,7 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
> int ret;
>
> uc_priv = dev_get_uclass_priv(dev);
> - if (!uc_priv->name[offset])
> + if (!gpio_is_claimed(uc_priv, offset))
> return -ENXIO;
> if (ops->rfree) {
> ret = ops->rfree(dev, offset);
> @@ -446,6 +488,7 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
> return ret;
> }
>
> + gpio_clear_claim(uc_priv, offset);
> free(uc_priv->name[offset]);
> uc_priv->name[offset] = NULL;
>
> @@ -480,7 +523,7 @@ static int check_reserved(const struct gpio_desc *desc,
> const char *func)
> return -ENOENT;
>
> uc_priv = dev_get_uclass_priv(desc->dev);
> - if (!uc_priv->name[desc->offset]) {
> + if (!gpio_is_claimed(uc_priv, desc->offset)) {
> printf("%s: %s: error: gpio %s%d not reserved\n",
>desc->dev->name, func,
>uc_priv->bank_name ? uc_priv->bank_name : "",
> @@ -826,7 +869,7 @@ static int get_function(struct udevice *dev, int offset,
> bool skip_unused,
>
Re: [PATCH] Remove unused parameters
Hi, On Fri, 28 Jul 2023 at 06:19, Yuepeng Xing wrote: > > Remove unused parameters from function arch_env_get_location What is the motivation for this patch? I don't know for sure, but perhaps the operation is important in deciding which location to use? > > Signed-off-by: Yuepeng Xing > --- > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +- > arch/arm/mach-imx/imx8m/soc.c | 2 +- > board/theobroma-systems/puma_rk3399/puma-rk3399.c | 2 +- > env/env.c | 4 ++-- > include/env_internal.h| 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) Regards, Simon
Re: [PATCH] Remove unused parameters
Hi,
On Fri, 28 Jul 2023 at 06:19, Shenlin Liang
wrote:
>
> Removes unused function arguments from the riscv_cpu_setup function
>
> Signed-off-by: Shenlin Liang
> ---
> arch/riscv/cpu/cpu.c | 2 +-
> arch/riscv/include/asm/system.h | 2 +-
> arch/riscv/lib/spl.c | 2 +-
> board/starfive/visionfive2/spl.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index ecfb1fb08c..728cdfe9c9 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -91,7 +91,7 @@ static void dummy_pending_ipi_clear(ulong hart, ulong arg0,
> ulong arg1)
> }
> #endif
>
> -int riscv_cpu_setup(void *ctx, struct event *event)
These params are needed since there is an EVENT_SPY() declaration just
below it. It needs those params.
Or perhaps you have another patch to remove it?
> +int riscv_cpu_setup(void)
> {
> int ret;
>
> diff --git a/arch/riscv/include/asm/system.h b/arch/riscv/include/asm/system.h
> index ffa7649f3f..87a804bfd5 100644
> --- a/arch/riscv/include/asm/system.h
> +++ b/arch/riscv/include/asm/system.h
> @@ -26,6 +26,6 @@ struct event;
> } while (0)
>
> /* Hook to set up the CPU (called from SPL too) */
> -int riscv_cpu_setup(void *ctx, struct event *event);
> +int riscv_cpu_setup(void);
>
> #endif /* __ASM_RISCV_SYSTEM_H */
> diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
> index f4d3b67e5d..9b242ed821 100644
> --- a/arch/riscv/lib/spl.c
> +++ b/arch/riscv/lib/spl.c
> @@ -28,7 +28,7 @@ __weak void board_init_f(ulong dummy)
> if (ret)
> panic("spl_early_init() failed: %d\n", ret);
>
> - riscv_cpu_setup(NULL, NULL);
> + riscv_cpu_setup();
>
> preloader_console_init();
>
> diff --git a/board/starfive/visionfive2/spl.c
> b/board/starfive/visionfive2/spl.c
> index 7acd3995aa..ad5f71a201 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -218,7 +218,7 @@ void board_init_f(ulong dummy)
> if (ret)
> panic("spl_early_init() failed: %d\n", ret);
>
> - riscv_cpu_setup(NULL, NULL);
> + riscv_cpu_setup();
> preloader_console_init();
>
> /* Set the parent clock of cpu_root clock to pll0,
> --
> 2.31.1.windows.1
>
Regards,
Simon
Re: [PATCH v2 1/1] doc: update doc/sphinx/requirements.txt
On Fri, 28 Jul 2023 at 00:20, Heinrich Schuchardt wrote: > > Update the following requirements to their latest version: > > * Pygments - syntax highlighting > * pytz - world timezone definitions > * certifi - Mozilla's CA bundle > > Signed-off-by: Heinrich Schuchardt > --- > v2: > fix typo in title > --- > doc/sphinx/requirements.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass
[PATCH v2] gpio: Use separate bitfield array to indicate GPIO is claimed
The current gpio-uclass design uses name field in struct gpio_dev_priv as
an indicator that GPIO is claimed by consumer. This overloads the function
of name field and does not work well for named pins not configured as GPIO
pins.
Introduce separate bitfield array as the claim indicator.
This unbreaks dual-purpose AF and GPIO operation on STM32MP since commit
2c38f7c31806 ("pinctrl: pinctrl_stm32: Populate uc_priv->name[] with pinmux
node's name")
where any pin which has already been configured as AF could no longer be
claimed as dual-purpose GPIO. This is important for pins like STM32 MMCI
st,cmd-gpios .
Signed-off-by: Marek Vasut
---
Cc: Michal Suchanek
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Rasmus Villemoes
Cc: Samuel Holland
Cc: Simon Glass
---
V2: Add set/clear helpers
---
drivers/gpio/gpio-uclass.c | 61 ++
include/asm-generic/gpio.h | 2 ++
2 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 712119c3415..68c079a3ccd 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -75,6 +75,46 @@ static int gpio_to_device(unsigned int gpio, struct
gpio_desc *desc)
return -ENOENT;
}
+/**
+ * gpio_is_claimed() - Test whether GPIO is claimed by consumer
+ *
+ * Test whether GPIO is claimed by consumer already.
+ *
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ * @return:true if claimed, false if not claimed
+ */
+static bool gpio_is_claimed(struct gpio_dev_priv *uc_priv, unsigned int offset)
+{
+ return !!(uc_priv->claimed[offset / 32] & BIT(offset % 32));
+}
+
+/**
+ * gpio_set_claim() - Set GPIO claimed by consumer
+ *
+ * Set a bit which indicate the GPIO is claimed by consumer
+ *
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ */
+static void gpio_set_claim(struct gpio_dev_priv *uc_priv, unsigned int offset)
+{
+ uc_priv->claimed[offset / 32] |= BIT(offset % 32);
+}
+
+/**
+ * gpio_clear_claim() - Clear GPIO claimed by consumer
+ *
+ * Clear a bit which indicate the GPIO is claimed by consumer
+ *
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ */
+static void gpio_clear_claim(struct gpio_dev_priv *uc_priv, unsigned int
offset)
+{
+ uc_priv->claimed[offset / 32] &= ~BIT(offset % 32);
+}
+
#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
/**
* dm_gpio_lookup_label() - look for name in gpio device
@@ -94,7 +134,7 @@ static int dm_gpio_lookup_label(const char *name,
*offset = -1;
for (i = 0; i < uc_priv->gpio_count; i++) {
- if (!uc_priv->name[i])
+ if (!gpio_is_claimed(uc_priv, i))
continue;
if (!strcmp(name, uc_priv->name[i])) {
*offset = i;
@@ -350,7 +390,7 @@ int dm_gpio_request(struct gpio_desc *desc, const char
*label)
int ret;
uc_priv = dev_get_uclass_priv(dev);
- if (uc_priv->name[desc->offset])
+ if (gpio_is_claimed(uc_priv, desc->offset))
return -EBUSY;
str = strdup(label);
if (!str)
@@ -362,6 +402,8 @@ int dm_gpio_request(struct gpio_desc *desc, const char
*label)
return ret;
}
}
+
+ gpio_set_claim(uc_priv, desc->offset);
uc_priv->name[desc->offset] = str;
return 0;
@@ -438,7 +480,7 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
int ret;
uc_priv = dev_get_uclass_priv(dev);
- if (!uc_priv->name[offset])
+ if (!gpio_is_claimed(uc_priv, offset))
return -ENXIO;
if (ops->rfree) {
ret = ops->rfree(dev, offset);
@@ -446,6 +488,7 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
return ret;
}
+ gpio_clear_claim(uc_priv, offset);
free(uc_priv->name[offset]);
uc_priv->name[offset] = NULL;
@@ -480,7 +523,7 @@ static int check_reserved(const struct gpio_desc *desc,
const char *func)
return -ENOENT;
uc_priv = dev_get_uclass_priv(desc->dev);
- if (!uc_priv->name[desc->offset]) {
+ if (!gpio_is_claimed(uc_priv, desc->offset)) {
printf("%s: %s: error: gpio %s%d not reserved\n",
desc->dev->name, func,
uc_priv->bank_name ? uc_priv->bank_name : "",
@@ -826,7 +869,7 @@ static int get_function(struct udevice *dev, int offset,
bool skip_unused,
return -EINVAL;
if (namep)
*namep = uc_priv->name[offset];
- if (skip_unused && !uc_priv->name[offset])
+ if (skip_unused && !gpio_is_claimed(uc_priv, offset))
return GPIOF_UNUSED;
if (ops->get_function) {
int ret;
@@ -1341,6 +1384,13 @@ static int gpio_post_probe(struct udevice *dev)
if (!uc_priv->name)
Re: [PATCH 1/5] x86: fsp: Use mtrr_set_next_var() for graphics memory
Hi Bin, On Fri, 28 Jul 2023 at 10:44, Bin Meng wrote: > > Hi Simon, > > On Sat, Jul 29, 2023 at 12:03 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Fri, 28 Jul 2023 at 03:38, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Thu, Jul 27, 2023 at 8:55 AM Simon Glass wrote: > > > > > > > > Hi Bin, > > > > > > > > On Tue, 25 Jul 2023 at 07:43, Bin Meng wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, Jul 24, 2023 at 6:14 AM Simon Glass wrote: > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > On Sun, 23 Jul 2023 at 09:50, Bin Meng wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Sun, Jul 23, 2023 at 11:43 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > On Fri, 21 Jul 2023 at 10:12, Bin Meng > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > At present this uses mtrr_add_request() & mtrr_commit() > > > > > > > > > combination > > > > > > > > > to program the MTRR for graphics memory. This usage has two > > > > > > > > > major > > > > > > > > > issues as below: > > > > > > > > > > > > > > > > > > - mtrr_commit() will re-initialize all MTRR registers from > > > > > > > > > index 0, > > > > > > > > > using the settings previously added by mtrr_add_request() > > > > > > > > > and saved > > > > > > > > > in gd->arch.mtrr_req[], which won't cause any issue but is > > > > > > > > > unnecessary > > > > > > > > > - The way such combination works is based on the assumption > > > > > > > > > that U-Boot > > > > > > > > > has full control with MTRR programming (e.g.: U-Boot > > > > > > > > > without any blob > > > > > > > > > that does all low-level initialization on its own, or using > > > > > > > > > FSP2 which > > > > > > > > > does not touch MTRR), but this is not the case with FSP. > > > > > > > > > FSP programs > > > > > > > > > some MTRRs during its execution but U-Boot does not have > > > > > > > > > the settings > > > > > > > > > saved in gd->arch.mtrr_req[] and when doing mtrr_commit() > > > > > > > > > it will > > > > > > > > > corrupt what was already programmed previously. > > > > > > > > > > > > > > > > > > Correct this to use mtrr_set_next_var() instead. > > > > > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > > --- > > > > > > > > > > > > > > > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +-- > > > > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > > > > > > > > > Thanks for looking into this. The series works fine on link. I > > > > > > > > suspect > > > > > > > > it will be find on samus too, but I cannot test right now. Sadly > > > > > > > > minnowmax is also dead right now but I hope to fix it soon. I > > > > > > > > don't > > > > > > > > expect any problems there. > > > > > > > > > > > > > > > > However, for coral, this first patch breaks the mtrrs. With > > > > > > > > master we get: > > > > > > > > > > > > > > > > => mtrr > > > > > > > > CPU 0: > > > > > > > > Reg Valid Write-type Base ||Mask ||Size > > > > > > > > || > > > > > > > > 0 Y Back fef0 0078 > > > > > > > > 0008 > > > > > > > > 1 Y Back fef8 007c > > > > > > > > 0004 > > > > > > > > 2 Y Back 007f8000 > > > > > > > > 8000 > > > > > > > > 3 Y Combine b000 007ff000 > > > > > > > > 1000 > > > > > > > > 4 Y Back 0001 007f8000 > > > > > > > > 8000 > > > > > > > > 5 N Uncacheable > > > > > > > > 0080 > > > > > > > > 6 N Uncacheable > > > > > > > > 0080 > > > > > > > > 7 N Uncacheable > > > > > > > > 0080 > > > > > > > > 8 N Uncacheable > > > > > > > > 0080 > > > > > > > > 9 N Uncacheable > > > > > > > > 0080 > > > > > > > > > > > > > > > > with this patch on coral we get: > > > > > > > > > > > > > > > > => mtrr > > > > > > > > CPU 0: > > > > > > > > Reg Valid Write-type Base ||Mask ||Size > > > > > > > > || > > > > > > > > 0 Y Back fef0 0078 > > > > > > > > 0008 > > > > > > > > 1 Y Back fef8 007c > > > > > > > > 0004 > > > > > > > > 2 Y Combine b000 007ff000 > > > > > > > > 1000 > > > > > > > > 3 N Uncacheable > > > > > > > > 0080 > > > > > > > > > > > > > > > > At present coral expects to handle the MTRRs itself, and it > > > > > > > > seems that > > > > > > > > perhaps the APL FSPv2 does
Re: Pull request for efi-2023-10-rc2
On Fri, Jul 28, 2023 at 06:07:59PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit c98c401dfb485b39c7453a4147b17cd4b8d10c67: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-07-27 > 10:35:36 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-10-rc2 > > for you to fetch changes up to 6e8fa0611f19824e200fe4725f18bce7e271: > > board: ti: k3: Convert boot flow ascii flow to svg (2023-07-28 11:36:38 > +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17105 > > @Nishanth > Please, add SPDX headers to the SVG files in a follow up patch. > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 3/3] arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On Thu, Jul 27, 2023 at 04:03:31AM -0500, Nishanth Menon wrote: > Update the am62 and am625 device-trees from linux v6.5-rc1. This needed > the following tweaks to the u-boot specific dtsi as well: > - Switch tick-timer to the main_timer as it's now defined in the main dtsi > - Secure proxies are defined in SoC dtsi > - Drop duplicate nodes - u-boot.dtsi is includes in r5-sk, no need for > either the definitions from main.dtsi OR duplication from u-boot.dtsi > > Reviewed-by: Roger Quadros > Cc: Francesco Dolcini > Cc: Sjoerd Simons > Cc: Wadim Egorov > Signed-off-by: Nishanth Menon Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 2/3] arm: mach-k3: am62: Add timer0 id to the dev list
On Thu, Jul 27, 2023 at 04:03:30AM -0500, Nishanth Menon wrote: > From: Sjoerd Simons > > Timer0 is used by u-boot as the tick timer; Add it to the soc devices > list so it can be enabled via the k3 power controller. > > Signed-off-by: Sjoerd Simons > Reviewed-by: Tom Rini > Reviewed-by: Roger Quadros > Tested-by: Ravi Gunasekaran > Tested-by: Mattijs Korpershoek > Cc: Francesco Dolcini > Cc: Wadim Egorov > Signed-off-by: Nishanth Menon Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/5] configs: iot2050: Enabled keyed autoboot
On Thu, Jul 27, 2023 at 06:34:56AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > Only accept SPACE to stop autobooting. This is safer to avoid accidental > interruptions on unattended devices. > > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] doc: board: siemens: iot2050: Update build env vars
On Thu, Jul 27, 2023 at 06:34:55AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > ATF is now called BL31, and OP-TEE since 3.21 suggests to use > tee-raw.bin instead of (the still identical) tee-pager_v2.bin. > > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
On Thu, Jul 27, 2023 at 06:34:54AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > This avoids having to maintain to defconfigs that are 99% equivalent. > The approach is to use binman to generate two flash images, > flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we > can avoid duplicating the common binman image definitions. > > Suggested-by: Andrew Davis > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/5] iot2050: Use binman in signing script
On Thu, Jul 27, 2023 at 06:34:53AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > The underlying issue was fixed in the meantime. Also signing the U-Boot > proper fit image now works. Just supporting custom cert templates > remains a todo. > > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 1/3] omap: timer: add ti,am654-timer compatibility
On Thu, Jul 27, 2023 at 04:03:29AM -0500, Nishanth Menon wrote: > From: Sjoerd Simons > > The TI AM654 timer is compatible with the omap-timer implementation, > so add it to the compatible id list. > > Signed-off-by: Sjoerd Simons > Reviewed-by: Roger Quadros > Reviewed-by: Tom Rini > Tested-by: Ravi Gunasekaran > Tested-by: Mattijs Korpershoek > Cc: Francesco Dolcini > Cc: Wadim Egorov > Signed-off-by: Nishanth Menon Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] boards: siemens: iot2050: Fix boot configuration
On Thu, Jul 27, 2023 at 06:34:52AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> The common env bits now come via ti_armv7_common.env, include it.
> Futhermore restore the board-specific boot targets and their ordering
> that is now enforced k3-wide differently. Finally, enable
> CONFIG_LEGACY_IMAGE_FORMAT explicitly which got lost while turning
> FIT_SIGNATURE on by default for k3 devices.
>
> Fixes: 53873974 ("include: armv7: Enable distroboot across all configs")
> Fixes: 4ae1a247 ("env: Make common bootcmd across all k3 devices")
> Fixes: 86fab110 ("Kconfig: Enable FIT_SIGNATURE if ARM64")
> Signed-off-by: Jan Kiszka
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1] arm: k3: fix fdt_del_node_path implicit declaration and a missing include
On Wed, Jul 26, 2023 at 04:36:50PM +0200, Emanuele Ghidoli wrote:
> From: Emanuele Ghidoli
>
> Fix missing declaration of fdt_del_node_path() while compiling am625_fdt.c and
> missing common_fdt.h include in common_fdt.c
>
> Fixes: 70aa5a94d451 ("arm: mach-k3: am62: Fixup CPU core, gpu and pru nodes
> in fdt")
> Signed-off-by: Emanuele Ghidoli
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] configs: keystone2: Change to using env files
On Tue, Jul 25, 2023 at 01:15:21PM -0500, Andrew Davis wrote: > Move to using .env file for setting up environment variables for K2x_evm. > > Signed-off-by: Andrew Davis > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] configs: keystone2: Unwind KERNEL_MTD_PARTS definition
On Tue, Jul 25, 2023 at 01:15:20PM -0500, Andrew Davis wrote: > This is more complex than it needs to be and makes converting these > boards over to plain text env files more difficult. Remove setting > mtdparts as the DTS already contain the partitions. While here also > drop the conflicting definitions from the K2 defconfigs. > > Signed-off-by: Andrew Davis > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/5] mach-k3: security: improve the checks around authentication
On Tue, Jul 25, 2023 at 01:09:22PM +0530, Manorit Chawdhry wrote: > The following checks are more reasonable as the previous logs were a bit > misleading as we could still get the logs that the authetication is > being skipped but still authenticate. Move the debug prints and checks > to proper locations. > > Signed-off-by: Manorit Chawdhry Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] env: ti: mmc.env: Fix overlays directory path
On Tue, Jul 25, 2023 at 01:09:21PM +0530, Manorit Chawdhry wrote: > From: Vignesh Raghavendra > > Similar to get_fdt_mmc make get_overlays_mmc look at /boot/dtb/* path > for overlay files. > > Signed-off-by: Vignesh Raghavendra > Signed-off-by: Manorit Chawdhry > Reviewed-by: Nikhil M Jain Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] configs: am62x: add SPL_MAX_SIZE back
On Tue, Jul 25, 2023 at 01:09:18PM +0530, Manorit Chawdhry wrote:
> This was regressed by the following commit and is required to build with
> additional configs enabled.
>
> Fixes: 14439cd71c1a ("configs: k3: make consistent bootcmd across all k3
> socs")
>
> Signed-off-by: Manorit Chawdhry
> Tested-by: Nikhil M Jain
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/5] env: ti: mmc.env: Move mmc related args to common place
On Tue, Jul 25, 2023 at 01:09:20PM +0530, Manorit Chawdhry wrote: > From: Vignesh Raghavendra > > All K3 SoCs use same set of args to load kernel for MMC. So move this to > common place to avoid duplication. > > Signed-off-by: Vignesh Raghavendra > Signed-off-by: Manorit Chawdhry > Reviewed-by: Nikhil M Jain Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/2] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
On Mon, Jul 24, 2023 at 03:57:30PM +0200, Maxime Ripard wrote: > The binding represents the MDIO controller as a child device tree > node of the MAC device tree node. > > The U-Boot driver mostly ignores that child device tree node and just > hardcodes the resources it uses to support both the MAC and MDIO in a > single driver. > > However, some resources like pinctrl muxing states are thus ignored. > This has been a problem with some device trees that will put some > pinctrl states on the MDIO device tree node, like the SK-AM62 Device > Tree does. > > Let's rework the driver a bit to create a dummy MDIO driver that we will > then get during our initialization to force the core to select the right > muxing. > > Signed-off-by: Maxime Ripard > Reviewed-by: Siddharth Vadapalli > Acked-by: Roger Quadros > Acked-by: Nishanth Menon Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/4] net: ti: am65-cpsw-nuss: Get port mode register from standard "phys" property
On Sat, Jul 22, 2023 at 10:31:49PM +0300, Roger Quadros wrote: > Approved DT binding has the port mode register in the > "phys" property. Get it from there instead of the custom > "cpsw-phy-sel" property. > > This will allow us to keep DT in sync with Linux. > > Signed-off-by: Roger Quadros > Acked-by: Nishanth Menon Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/4] net: ti: am65-cpsw-nuss: Use approved property to get efuse address
On Sat, Jul 22, 2023 at 10:31:48PM +0300, Roger Quadros wrote: > The approved DT property for MAC efuse (ROM) address is > "ti,syscon-efuse". > > Use that and drop custom property "mac_efuse". > > Signed-off-by: Roger Quadros > Acked-by: Nishanth Menon Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-rockchip-20230728
On Fri, Jul 28, 2023 at 07:33:37PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the updates for rockchip platform: > - Enable pcie support for rk3568; > - Add boards: > rk3399: Radxa ROCK 4SE; > rk3328: Orange Pi R1 Plus, Orange Pi R1 Plus LTS > rk3568: FriendlyARM NanoPi R5S/R5C, Hardkernel ODROID-M1 > rk3588: Edgeble Neu6B > - support OP-TEE with binman; > - support Winbond SPI flash; > - rk3588 usbdp phy support; > - dts and config updates for different boards; > > > CI: > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/17104 > > Thanks, > - Kever > > The following changes since commit c98c401dfb485b39c7453a4147b17cd4b8d10c67: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-07-27 > 10:35:36 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20230728 > > for you to fetch changes up to 94da929b933668c4b9ece7d56a2a2bb5543198c9: > > board: rockchip: Add Hardkernel ODROID-M1 (2023-07-28 18:45:03 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] x86: fsp: Use mtrr_set_next_var() for graphics memory
Hi Simon, On Sat, Jul 29, 2023 at 12:03 AM Simon Glass wrote: > > Hi Bin, > > On Fri, 28 Jul 2023 at 03:38, Bin Meng wrote: > > > > Hi Simon, > > > > On Thu, Jul 27, 2023 at 8:55 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Tue, 25 Jul 2023 at 07:43, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Mon, Jul 24, 2023 at 6:14 AM Simon Glass wrote: > > > > > > > > > > Hi Bin, > > > > > > > > > > On Sun, 23 Jul 2023 at 09:50, Bin Meng wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Sun, Jul 23, 2023 at 11:43 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > On Fri, 21 Jul 2023 at 10:12, Bin Meng wrote: > > > > > > > > > > > > > > > > At present this uses mtrr_add_request() & mtrr_commit() > > > > > > > > combination > > > > > > > > to program the MTRR for graphics memory. This usage has two > > > > > > > > major > > > > > > > > issues as below: > > > > > > > > > > > > > > > > - mtrr_commit() will re-initialize all MTRR registers from > > > > > > > > index 0, > > > > > > > > using the settings previously added by mtrr_add_request() and > > > > > > > > saved > > > > > > > > in gd->arch.mtrr_req[], which won't cause any issue but is > > > > > > > > unnecessary > > > > > > > > - The way such combination works is based on the assumption > > > > > > > > that U-Boot > > > > > > > > has full control with MTRR programming (e.g.: U-Boot without > > > > > > > > any blob > > > > > > > > that does all low-level initialization on its own, or using > > > > > > > > FSP2 which > > > > > > > > does not touch MTRR), but this is not the case with FSP. FSP > > > > > > > > programs > > > > > > > > some MTRRs during its execution but U-Boot does not have the > > > > > > > > settings > > > > > > > > saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it > > > > > > > > will > > > > > > > > corrupt what was already programmed previously. > > > > > > > > > > > > > > > > Correct this to use mtrr_set_next_var() instead. > > > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > --- > > > > > > > > > > > > > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +-- > > > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > > > > > > > Thanks for looking into this. The series works fine on link. I > > > > > > > suspect > > > > > > > it will be find on samus too, but I cannot test right now. Sadly > > > > > > > minnowmax is also dead right now but I hope to fix it soon. I > > > > > > > don't > > > > > > > expect any problems there. > > > > > > > > > > > > > > However, for coral, this first patch breaks the mtrrs. With > > > > > > > master we get: > > > > > > > > > > > > > > => mtrr > > > > > > > CPU 0: > > > > > > > Reg Valid Write-type Base ||Mask ||Size || > > > > > > > 0 Y Back fef0 0078 > > > > > > > 0008 > > > > > > > 1 Y Back fef8 007c > > > > > > > 0004 > > > > > > > 2 Y Back 007f8000 > > > > > > > 8000 > > > > > > > 3 Y Combine b000 007ff000 > > > > > > > 1000 > > > > > > > 4 Y Back 0001 007f8000 > > > > > > > 8000 > > > > > > > 5 N Uncacheable > > > > > > > 0080 > > > > > > > 6 N Uncacheable > > > > > > > 0080 > > > > > > > 7 N Uncacheable > > > > > > > 0080 > > > > > > > 8 N Uncacheable > > > > > > > 0080 > > > > > > > 9 N Uncacheable > > > > > > > 0080 > > > > > > > > > > > > > > with this patch on coral we get: > > > > > > > > > > > > > > => mtrr > > > > > > > CPU 0: > > > > > > > Reg Valid Write-type Base ||Mask ||Size || > > > > > > > 0 Y Back fef0 0078 > > > > > > > 0008 > > > > > > > 1 Y Back fef8 007c > > > > > > > 0004 > > > > > > > 2 Y Combine b000 007ff000 > > > > > > > 1000 > > > > > > > 3 N Uncacheable > > > > > > > 0080 > > > > > > > > > > > > > > At present coral expects to handle the MTRRs itself, and it seems > > > > > > > that > > > > > > > perhaps the APL FSPv2 does not? Do we need a new Kconfig for > > > > > > > dealing > > > > > > > with FSPv2 perhaps? > > > > > > > > > > > > I am a little bit confused. The comment in > > > > > > arch/x86/lib/fsp/fsp_dram.c:: > > > > > > dram_init_banksize() says: > > > > > > > > > > > > /* > > > > > > * For FSP1, the system memory and reserved
Re: [PATCH 6/9] x86: Correct copying of BIOS mode information
On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote:
>
> This is copying beyond the end of the destination buffer. Correct the code
> by using a constant for the buffer size.
>
> This long-standing bug prevents virtio bootdevs working correctly on
> qemu-x86 at present.
Nice catch!
>
> Signed-off-by: Simon Glass
> Fixes: 0ca2426beae ("x86: Add support for running option ROMs natively")
> ---
>
> arch/x86/lib/bios.c | 2 +-
> include/vesa.h | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/lib/bios.c b/arch/x86/lib/bios.c
> index e29cae78e509..3a9d7f5ddd41 100644
> --- a/arch/x86/lib/bios.c
> +++ b/arch/x86/lib/bios.c
> @@ -204,7 +204,7 @@ static u8 vbe_get_mode_info(struct vesa_state *mi)
>
> realmode_interrupt(0x10, VESA_GET_MODE_INFO, 0x, mi->video_mode,
>0x, buffer_seg, buffer_adr);
> - memcpy(mi->mode_info_block, buffer, sizeof(struct vesa_state));
> + memcpy(mi->mode_info_block, buffer, VESA_MODE_INFO_SIZE);
or "sizeof(struct vesa_mode_info)"
> mi->valid = true;
>
> return 0;
> diff --git a/include/vesa.h b/include/vesa.h
> index 9285bfa921a2..28828ab56aa4 100644
> --- a/include/vesa.h
> +++ b/include/vesa.h
> @@ -83,12 +83,14 @@ struct __packed vesa_mode_info {
> u8 reserved[206];
> };
>
> +#define VESA_MODE_INFO_SIZE256
> +
> struct vesa_state {
> u16 video_mode;
> bool valid;
> union {
> struct vesa_mode_info vesa;
> - u8 mode_info_block[256];
> + u8 mode_info_block[VESA_MODE_INFO_SIZE];
> };
> };
>
Reviewed-by: Bin Meng
Pull request for efi-2023-10-rc2
Dear Tom, The following changes since commit c98c401dfb485b39c7453a4147b17cd4b8d10c67: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-07-27 10:35:36 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-10-rc2 for you to fetch changes up to 6e8fa0611f19824e200fe4725f18bce7e271: board: ti: k3: Convert boot flow ascii flow to svg (2023-07-28 11:36:38 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17105 @Nishanth Please, add SPDX headers to the SVG files in a follow up patch. Pull request for efi-2023-10-rc2 Documentation: * Update the documentation for TI K3 boards (use SVG images) * Update doc/sphinx/requirements.txt * Describe QEMU emulation of block devices UEFI * Fix device paths for special block devices Dan Carpenter (1): efi_loader: fix uninitialized variable bug in efi_set_load_options() Heinrich Schuchardt (5): doc: update doc/sphinx/requirements.txt efi_loader: device paths for special block devices efi_loader: simplify dp_fill() doc: fix typo device_compat/.h doc: describe QEMU emulation of block devices Ilias Apalodimas (1): efi_loader: make efi_delete_handle() follow the EFI spec Nishanth Menon (19): doc: board: ti: Optimize sources references doc: board: ti: am62x/j7200: Update with common boot flow diagram doc: board: ti: am65x: Update with boot flow diagram doc: board: ti: j721e: Update with boot flow diagram doc: board: ti: k3: Reuse build instructions doc: board: ti: j7200: Convert the image format to svg doc: board: ti: j721e: Convert the image format to svg doc: board: ti: am65x: Convert the image format to svg doc: board: ti: am62x: Convert the image format to svg doc: board: ti: am62x_sk: Add labels to reuse memory map doc: board: ti: am62x_sk: Convert switch settings to list tables doc: board: ti: j7200_evm: Convert switch settings to list tables doc: board: ti: am65x_evm: Convert the UART boot responsibility to list table doc: board: ti: am65/j721e: Convert OSPI memory map to svg doc: board: ti: am65x_evm: Convert the emmc layout to svg doc: board: ti: j7200_evm: Convert the emmc layout to svg doc: board: ti: *: Add platform information doc: board: ti: k3: Sort the boards in alphabetical order board: ti: k3: Convert boot flow ascii flow to svg Tom Rini (1): doc: ti: Clarify required file names for K3 platforms cmd/bootefi.c | 21 +- doc/board/emulation/blkdev.rst | 38 + doc/board/emulation/index.rst |4 +- doc/board/ti/am62x_sk.rst | 246 +-- doc/board/ti/am65x_evm.rst | 301 +--- doc/board/ti/img/boot_diagram_am65.svg | 1779 + doc/board/ti/img/boot_diagram_j721e.svg| 2012 doc/board/ti/img/boot_diagram_k3_current.svg | 1925 +++ doc/board/ti/img/boot_flow_01.svg | 220 +++ doc/board/ti/img/boot_flow_02.svg | 459 ++ doc/board/ti/img/boot_flow_03.svg | 583 +++ doc/board/ti/img/dm_tispl.bin.svg | 317 doc/board/ti/img/emmc_am65x_evm_boot0.svg | 748 + doc/board/ti/img/emmc_j7200_evm_boot01.svg | 662 doc/board/ti/img/emmc_j7200_evm_udafs.svg | 505 ++ doc/board/ti/img/j7200_tiboot3.bin.svg | 447 ++ doc/board/ti/img/multi_cert_tiboot3.bin.svg| 287 doc/board/ti/img/no_multi_cert_tiboot3.bin.svg | 238 +++ doc/board/ti/img/nodm_tispl.bin.svg| 277 doc/board/ti/img/ospi_sysfw.svg| 721 + doc/board/ti/img/sysfw.itb.svg | 317 doc/board/ti/j7200_evm.rst | 301 +--- doc/board/ti/j721e_evm.rst | 271 +--- doc/board/ti/k3.rst| 136 +- doc/develop/codingstyle.rst|2 +- doc/sphinx/requirements.txt|6 +- include/efi_loader.h |2 +- lib/efi_driver/efi_uclass.c| 12 +- lib/efi_loader/efi_boottime.c | 20 +- lib/efi_loader/efi_device_path.c | 155 +- lib/efi_loader/efi_disk.c |7 +- lib/efi_loader/efi_load_options.c |2 +- 32 files changed, 12019 insertions(+), 1002 deletions(-) create mode 100644 doc/board/emulation/blkdev.rst create mode 100644 doc/board/ti/img/boot_diagram_am65.svg create mode 100644 doc/board/ti/img/boot_diagram_j721e.svg create mode 100644
Re: [PATCH 1/5] x86: fsp: Use mtrr_set_next_var() for graphics memory
Hi Bin, On Fri, 28 Jul 2023 at 03:38, Bin Meng wrote: > > Hi Simon, > > On Thu, Jul 27, 2023 at 8:55 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Tue, 25 Jul 2023 at 07:43, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Mon, Jul 24, 2023 at 6:14 AM Simon Glass wrote: > > > > > > > > Hi Bin, > > > > > > > > On Sun, 23 Jul 2023 at 09:50, Bin Meng wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Sun, Jul 23, 2023 at 11:43 AM Simon Glass > > > > > wrote: > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > On Fri, 21 Jul 2023 at 10:12, Bin Meng wrote: > > > > > > > > > > > > > > At present this uses mtrr_add_request() & mtrr_commit() > > > > > > > combination > > > > > > > to program the MTRR for graphics memory. This usage has two major > > > > > > > issues as below: > > > > > > > > > > > > > > - mtrr_commit() will re-initialize all MTRR registers from index > > > > > > > 0, > > > > > > > using the settings previously added by mtrr_add_request() and > > > > > > > saved > > > > > > > in gd->arch.mtrr_req[], which won't cause any issue but is > > > > > > > unnecessary > > > > > > > - The way such combination works is based on the assumption that > > > > > > > U-Boot > > > > > > > has full control with MTRR programming (e.g.: U-Boot without > > > > > > > any blob > > > > > > > that does all low-level initialization on its own, or using > > > > > > > FSP2 which > > > > > > > does not touch MTRR), but this is not the case with FSP. FSP > > > > > > > programs > > > > > > > some MTRRs during its execution but U-Boot does not have the > > > > > > > settings > > > > > > > saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it > > > > > > > will > > > > > > > corrupt what was already programmed previously. > > > > > > > > > > > > > > Correct this to use mtrr_set_next_var() instead. > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > --- > > > > > > > > > > > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +-- > > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > > > > > Thanks for looking into this. The series works fine on link. I > > > > > > suspect > > > > > > it will be find on samus too, but I cannot test right now. Sadly > > > > > > minnowmax is also dead right now but I hope to fix it soon. I don't > > > > > > expect any problems there. > > > > > > > > > > > > However, for coral, this first patch breaks the mtrrs. With master > > > > > > we get: > > > > > > > > > > > > => mtrr > > > > > > CPU 0: > > > > > > Reg Valid Write-type Base ||Mask ||Size || > > > > > > 0 Y Back fef0 0078 > > > > > > 0008 > > > > > > 1 Y Back fef8 007c > > > > > > 0004 > > > > > > 2 Y Back 007f8000 > > > > > > 8000 > > > > > > 3 Y Combine b000 007ff000 > > > > > > 1000 > > > > > > 4 Y Back 0001 007f8000 > > > > > > 8000 > > > > > > 5 N Uncacheable > > > > > > 0080 > > > > > > 6 N Uncacheable > > > > > > 0080 > > > > > > 7 N Uncacheable > > > > > > 0080 > > > > > > 8 N Uncacheable > > > > > > 0080 > > > > > > 9 N Uncacheable > > > > > > 0080 > > > > > > > > > > > > with this patch on coral we get: > > > > > > > > > > > > => mtrr > > > > > > CPU 0: > > > > > > Reg Valid Write-type Base ||Mask ||Size || > > > > > > 0 Y Back fef0 0078 > > > > > > 0008 > > > > > > 1 Y Back fef8 007c > > > > > > 0004 > > > > > > 2 Y Combine b000 007ff000 > > > > > > 1000 > > > > > > 3 N Uncacheable > > > > > > 0080 > > > > > > > > > > > > At present coral expects to handle the MTRRs itself, and it seems > > > > > > that > > > > > > perhaps the APL FSPv2 does not? Do we need a new Kconfig for dealing > > > > > > with FSPv2 perhaps? > > > > > > > > > > I am a little bit confused. The comment in > > > > > arch/x86/lib/fsp/fsp_dram.c:: > > > > > dram_init_banksize() says: > > > > > > > > > > /* > > > > > * For FSP1, the system memory and reserved memory used by > > > > > FSP are > > > > > * already programmed in the MTRR by FSP. Also it is observed > > > > > that > > > > > * FSP on Intel Queensbay platform reports the TSEG memory > > > > > range > > > > > * that has the same RES_MEM_RESERVED resource type whose > > > > > address > > > > > * is programmed by
[PATCH v2 1/1] doc: U-Boot boot phases
Add more detail to the description of U-Boot boot phases: * describe which steps are optional * mentions alternative boot flows Signed-off-by: Heinrich Schuchardt Reviewed-by: Bin Meng --- v2: add missing comma --- doc/develop/spl.rst | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst index a1515a7b43..5743bdf37c 100644 --- a/doc/develop/spl.rst +++ b/doc/develop/spl.rst @@ -77,10 +77,11 @@ To check whether a feature is enabled, use CONFIG_IS_ENABLED():: This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build, CONFIG_TPL_CLK for the TPL build, etc. -U-Boot Phases -- +U-Boot Boot Phases +-- -U-Boot boots through the following phases: +U-Boot goes through the following boot phases where TPL, VPL, SPL are optional. +While many boards use SPL, less use TPL. TPL Very early init, as tiny as possible. This loads SPL (or VPL if enabled). @@ -97,6 +98,12 @@ SPL U-Boot U-Boot proper, containing the command line and boot logic. +Further usages of U-Boot SPL comprise: + +* Launching BL31 of ARM Trusted Firmware which invokes main U-Boot as BL33 +* launching EDK II +* launching Linux kernel +* launching RISC-V OpenSBI which invokes main U-Boot Checking the boot phase --- -- 2.40.1
R: Pull request: u-boot-rockchip-20230728
Hi Kever, > Da: U-Boot Per conto di Jagan Teki > Inviato: venerdì 28 luglio 2023 14:07 > A: Kever Yang > Cc: tr...@konsulko.com; u-boot@lists.denx.de > Oggetto: Re: Pull request: u-boot-rockchip-20230728 > > Hi Kever, > > On Fri, Jul 28, 2023 at 5:04 PM Kever Yang > wrote: > > > > Hi Tom, > > > > Please pull the updates for rockchip platform: > > - Enable pcie support for rk3568; > > - Add boards: > > rk3399: Radxa ROCK 4SE; > > rk3328: Orange Pi R1 Plus, Orange Pi R1 Plus LTS > > rk3568: FriendlyARM NanoPi R5S/R5C, Hardkernel ODROID-M1 > > rk3588: Edgeble Neu6B > > - support OP-TEE with binman; > > - support Winbond SPI flash; > > - rk3588 usbdp phy support; > > - dts and config updates for different boards; > > > > > > CI: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource. > denx.de%2Fu-boot%2Fcustodians%2Fu-boot-rockchip%2F- > %2Fpipelines%2F17104=05%7C01%7Cmassimo.pegorer%40vimar.com% > 7C7a0717653d424089e6cb08db8f634729%7Ca1f008bcd59b4c668f8760fd9af1 > 5c7f%7C1%7C0%7C638261428788951158%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 3000%7C%7C%7C=IAoZukFSp4U5SAscsBg0C8WD34lJtp9uP24HOF2m%2 > Fmw%3D=0 > > > > Thanks, > > - Kever > > > > The following changes since commit > c98c401dfb485b39c7453a4147b17cd4b8d10c67: > > > > Merge > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource. > denx.de%2Fu-boot%2Fcustodians%2Fu-boot- > usb=05%7C01%7Cmassimo.pegorer%40vimar.com%7C7a0717653d4240 > 89e6cb08db8f634729%7Ca1f008bcd59b4c668f8760fd9af15c7f%7C1%7C0%7C6 > 38261428788951158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& > sdata=aKCQ9wv4LMz3rDXenesuslQX%2BiI6qkKTmJgS%2FSsVBeQ%3D > d=0 (2023-07-27 10:35:36 -0400) > > > > are available in the Git repository at: > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource. > denx.de%2Fu-boot%2Fcustodians%2Fu-boot- > rockchip.git=05%7C01%7Cmassimo.pegorer%40vimar.com%7C7a071765 > 3d424089e6cb08db8f634729%7Ca1f008bcd59b4c668f8760fd9af15c7f%7C1%7 > C0%7C638261428788951158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7 > C%7C=tcJtJGfmfanqa7PBTPTL6Vom%2B8mC4DIY6CwgLZytk%2Fo%3D > eserved=0 tags/u-boot-rockchip-20230728 > > > > for you to fetch changes up to > 94da929b933668c4b9ece7d56a2a2bb5543198c9: > > > > board: rockchip: Add Hardkernel ODROID-M1 (2023-07-28 18:45:03 +0800) > > > > > > Alex Bee (4): > > rockchip: Support OP-TEE for ARM in FIT images created by binman > > configs: evb-rk3229: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN > > rockchip: RK322x: Select SPL_OPTEE_IMAGE > > rockchip: evb_rk3229: Update/fix README > > > > Alper Nebi Yasak (1): > > rockchip: veyron: Enable Winbond SPI flash > > > > Chris Morgan (7): > > rockchip: board: Update Odroid Go2 to Support Additional Revisions > > board: rockchip: Correct i2c2 pinctrl for RGxx3 > > board: rockchip: add DSI and DSI-DPHY for Anbernic RGxx3 > > board: rockchip: Add support for RG353PS to RGxx3 > > board: rockchip: Add panel auto-detection for Anbernic RGxx3 > > configs: Update anbernic-rgxx3_defconfig for panel detection > > doc: anbernic: Update RGxx3 Docs for panel detection > > > > Christopher Obbard (3): > > configs: rockchip: rock5b-rk3588: Enable CONFIG_PCI_INIT_R > > arm: rockchip: sync ROCK Pi 4 SoCs from Linux > > arm: rockchip: Add Radxa ROCK 4SE > > > > Eugen Hristev (4): > > configs: rock5b-rk3588: add rtl8169 driver > > ARM: dts: rockchip: rk3588: sync with Linux > > ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB3 support > > configs: rock5b-rk3588: enable USB 3.0 controller, command, gadget > > > > Frank Wang (1): > > phy: rockchip: add usbdp combo phy driver > > > > Jagan Teki (5): > > arch: rockchip: rk3588: Fix missing suffix 'A' for Edgeble Neu6A > > arm64: dts: rockchip: Add Rockchip RK3588J > > ARM: dts: rockchip: Add rk3588j-u-boot.dtsi > > arm64: dts: rockchip: Add rk3588 Edgeble Neu6B > > board: rockchip: Add Edgeble Neural Compute Module 6B > > > > Johan Jonker (1): > > mtd: nand: raw: rockchip_nfc: copy hwecc PA data to o
Re: [PATCH 1/1] doc: U-Boot boot phases
Hey Heinrich, On Fri, Jul 28, 2023 at 05:48:31PM +0200, Heinrich Schuchardt wrote: > Add more detail to the description of U-Boot boot phases: > > * describe which steps are optional > * mentions alternative boot flows > > Signed-off-by: Heinrich Schuchardt > --- > doc/develop/spl.rst | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst > index a1515a7b43..5743bdf37c 100644 > --- a/doc/develop/spl.rst > +++ b/doc/develop/spl.rst > @@ -77,10 +77,11 @@ To check whether a feature is enabled, use > CONFIG_IS_ENABLED():: > This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build, > CONFIG_TPL_CLK for the TPL build, etc. > > -U-Boot Phases > -- > +U-Boot Boot Phases > +-- > > -U-Boot boots through the following phases: > +U-Boot goes through the following boot phases where TPL, VPL, SPL are > optional. > +While many boards use SPL less use TPL. I think you need to add a comma here after SPL. I had to read this a few times before it made sense to me! > > TPL > Very early init, as tiny as possible. This loads SPL (or VPL if enabled). > @@ -97,6 +98,12 @@ SPL > U-Boot > U-Boot proper, containing the command line and boot logic. > > +Further usages of U-Boot SPL comprise: > + > +* Launching BL31 of ARM Trusted Firmware which invokes main U-Boot as BL33 > +* launching EDK II > +* launching Linux kernel > +* launching RISC-V OpenSBI which invokes main U-Boot > > Checking the boot phase > --- > -- > 2.40.1 > signature.asc Description: PGP signature
Re: [PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
On Fri, Jul 28, 2023 at 9:54 PM Heinrich Schuchardt wrote: > > The EFI_RNG_PROTOCOL is needed for Linux' KASLR. > > QEMU can provide a virtio-rng device to emulate a hardware random number > generator which is supported by our virtio_rng driver. > > Enabling CONFIG_DM_RNG will enable CONFIG_VIRTIO_RNG and > CONFIG_EFI_RNG_PROTOCOL by default too. > > Signed-off-by: Heinrich Schuchardt > --- > board/emulation/qemu-riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng
Re: [PATCH 1/1] doc: U-Boot boot phases
On Fri, Jul 28, 2023 at 11:49 PM Heinrich Schuchardt wrote: > > Add more detail to the description of U-Boot boot phases: > > * describe which steps are optional > * mentions alternative boot flows > > Signed-off-by: Heinrich Schuchardt > --- > doc/develop/spl.rst | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > Reviewed-by: Bin Meng
[PATCH 1/1] doc: U-Boot boot phases
Add more detail to the description of U-Boot boot phases: * describe which steps are optional * mentions alternative boot flows Signed-off-by: Heinrich Schuchardt --- doc/develop/spl.rst | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst index a1515a7b43..5743bdf37c 100644 --- a/doc/develop/spl.rst +++ b/doc/develop/spl.rst @@ -77,10 +77,11 @@ To check whether a feature is enabled, use CONFIG_IS_ENABLED():: This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build, CONFIG_TPL_CLK for the TPL build, etc. -U-Boot Phases -- +U-Boot Boot Phases +-- -U-Boot boots through the following phases: +U-Boot goes through the following boot phases where TPL, VPL, SPL are optional. +While many boards use SPL less use TPL. TPL Very early init, as tiny as possible. This loads SPL (or VPL if enabled). @@ -97,6 +98,12 @@ SPL U-Boot U-Boot proper, containing the command line and boot logic. +Further usages of U-Boot SPL comprise: + +* Launching BL31 of ARM Trusted Firmware which invokes main U-Boot as BL33 +* launching EDK II +* launching Linux kernel +* launching RISC-V OpenSBI which invokes main U-Boot Checking the boot phase --- -- 2.40.1
Re: [PATCH 4/9] Revert "x86: Switch QEMU over to use the bochs driver"
Hi Simon, On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote: > > Unfortunately the bochs driver does not currently work with distros. It > causes a hang sometime between grub menu selection and the OS displaying > something. Does this reproduce reliably? > > This reverts commit b8956425d525c3c25fd218f252f89a5e44df6a9f. > > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/qemu/Kconfig | 2 +- > configs/qemu-x86_64_defconfig | 4 > configs/qemu-x86_defconfig| 3 +++ > 3 files changed, 8 insertions(+), 1 deletion(-) > Regards, Bin
Re: [PATCH 3/9] x86: Run QEMU machine setup in SPL
On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote:
>
> Call the hardware-init function from QEMU from SPL. This allows the video
> BIOS to operate correctly.
>
> Create an x86-wide qemu.h header to avoid having to #ifdef the header in
> spl.c
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/qemu/qemu.c| 2 +-
> arch/x86/include/asm/qemu.h | 14 ++
> arch/x86/lib/spl.c | 3 +++
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/include/asm/qemu.h
>
> diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
> index 274978c023b6..70414556086c 100644
> --- a/arch/x86/cpu/qemu/qemu.c
> +++ b/arch/x86/cpu/qemu/qemu.c
> @@ -48,7 +48,7 @@ static void enable_pm_ich9(void)
> pci_write_config32(ICH9_PM, PMBA, CONFIG_ACPI_PM1_BASE | 1);
> }
>
> -static void qemu_chipset_init(void)
> +void qemu_chipset_init(void)
> {
> u16 device, xbcs;
> int pam, i;
> diff --git a/arch/x86/include/asm/qemu.h b/arch/x86/include/asm/qemu.h
> new file mode 100644
> index ..f1e95ffd7a4d
> --- /dev/null
> +++ b/arch/x86/include/asm/qemu.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Generic QEMU header
> + *
> + * Copyright 2023 Google LLC
> + */
> +
> +#ifndef __QEMU_H
> +#define __QEMU_H
> +
> +/* set up the chipset for QEMU so that video can be used */
> +void qemu_chipset_init(void);
> +
> +#endif
> diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
> index 55c061570864..74949b2c13cb 100644
> --- a/arch/x86/lib/spl.c
> +++ b/arch/x86/lib/spl.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -291,6 +292,8 @@ void spl_board_init(void)
> #ifndef CONFIG_TPL
> preloader_console_init();
> #endif
> + if (IS_ENABLED(CONFIG_X86) && IS_ENABLED(CONFIG_QEMU))
CONFIG_X86 is not necessary.
> + qemu_chipset_init();
>
> if (CONFIG_IS_ENABLED(VIDEO)) {
> struct udevice *dev;
> --
Otherwise,
Reviewed-by: Bin Meng
Re: [PATCH 2/9] video: Tidy up Makefile rule for video
Hi Simon, On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote: > > Drop the duplication and add a single rule which can handle SPL as well. > > Signed-off-by: Simon Glass > --- > > drivers/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/Makefile b/drivers/Makefile > index 3bc6d279d7cb..7272681fc741 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -39,6 +39,8 @@ obj-$(CONFIG_$(SPL_TPL_)TPM) += tpm/ > obj-$(CONFIG_$(SPL_)NVME) += nvme/ > obj-$(CONFIG_XEN) += xen/ > obj-$(CONFIG_$(SPL_)FPGA) += fpga/ > +obj-$(CONFIG_$(SPL_TPL_)VIDEO) += video/ This should be $(SPL_) as the original codes do not enable video build for TPL > + > obj-y += bus/ > > ifndef CONFIG_TPL_BUILD > @@ -64,7 +66,6 @@ obj-$(CONFIG_SPL_USB_HOST) += usb/host/ > obj-$(CONFIG_SPL_SATA) += ata/ scsi/ > obj-$(CONFIG_SPL_LEGACY_BLOCK) += block/ > obj-$(CONFIG_SPL_THERMAL) += thermal/ > -obj-$(CONFIG_SPL_VIDEO) +=video/ > > endif > endif > @@ -99,7 +100,6 @@ obj-y += rtc/ > obj-y += scsi/ > obj-y += sound/ > obj-y += spmi/ > -obj-y += video/ > obj-y += watchdog/ > obj-$(CONFIG_QE) += qe/ > obj-$(CONFIG_U_QE) += qe/ > -- Regards, Bin
Re: [PATCH 1/9] x86: spl: Drop unwanted debug()
On Mon, Jul 24, 2023 at 10:52 PM Simon Glass wrote: > > This was left over from some previous debugging. Drop it. > > Signed-off-by: Simon Glass > --- > > arch/x86/lib/spl.c | 1 - > 1 file changed, 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v5 3/6] mips: add a ls1c300 based board
On Fri, Jul 28, 2023 at 10:59:16AM +0800, Du Huanpeng wrote: > On Thu, Jul 27, 2023 at 03:05:28PM -0400, Tom Rini wrote: > > On Wed, Jul 26, 2023 at 08:30:24PM +0800, Du Huanpeng wrote: > > > > > - devicetree for ls1c300 SoC and board > this devicetree was writen from scratch, I read the SoC's manual > and devicetree-specification-v0.3.pdf, and write a Excel to generate > it. > the v0.3 was lastest version when I wrote it. > https://www.devicetree.org/specifications/ > the manual seens not available now from official site, > https://www.loongson.cn/product/list?id=2 > here is my backup: > https://github.com/hodcarrier/ls1c300_bsp The device tree in U-Boot needs to be kept in sync with the device tree in Linux. I haven't been following loongarch closely so I don't know the state of upstreaming the work there. We can be a little bit flexible when it comes to new platforms / chips, but we can't be "two different source trees". -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/5] configs: am64x_evm_a53_defconfig: remove SYS_SPI_U_BOOT_OFFS
On Tue, Jul 25, 2023 at 01:09:19PM +0530, Manorit Chawdhry wrote:
> This got added mistakenly during patch posting, remove it.
>
> Fixes: a5e8678e0a32 ("configs: k3: Remove saved environments")
> Signed-off-by: Manorit Chawdhry
This isn't required as the resync cleared this from the defconfig.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCHv4 2/5] net/lwip: add lwip library for the network stack
On Thu, 27 Jul 2023 at 19:29, Ilias Apalodimas
wrote:
> Hi Maxim,
>
>
> This is too much for a single patch review. Can you pleas split it in
> something that's easier to review and comment.
>
> For example,
> #1 add the lwip library only
> #2-#5 add ping, wget, tcp and ping
>
> Some random comments below as well.
>
> On Fri, Jul 14, 2023 at 08:19:57PM +0600, Maxim Uvarov wrote:
> > This commit adds lwip library for the U-boot network
> > stack. Supported commands: ping, tftp, dhcp and wget.
> >
> > Signed-off-by: Maxim Uvarov
> > ---
> > .gitignore| 9 +
> > boot/bootmeth_pxe.c | 2 +-
> > cmd/net.c | 48 +
> > cmd/pxe.c | 2 +-
> > include/net.h | 8 +-
> > lib/Kconfig | 2 +
> > lib/Makefile | 2 +
> > lib/lwip/Kconfig | 63 ++
> > lib/lwip/Makefile | 101 ++
> > lib/lwip/apps/dhcp/lwip-dhcp.c| 52 +
> > lib/lwip/apps/http/lwip-wget.c| 74 +++
> > lib/lwip/apps/ping/lwip_ping.c| 37
> > lib/lwip/apps/ping/lwip_ping.h| 24 +++
> > lib/lwip/apps/ping/ping.h | 35
> > lib/lwip/apps/tftp/lwip-tftp.c| 124
> > lib/lwip/cmd-lwip.c | 269 ++
> > lib/lwip/lwipopts.h | 203 +++
> > lib/lwip/port/if.c| 260 +
> > lib/lwip/port/include/arch/cc.h | 46 +
> > lib/lwip/port/include/arch/sys_arch.h | 59 ++
> > lib/lwip/port/include/limits.h| 0
> > lib/lwip/port/sys-arch.c | 20 ++
> > lib/lwip/ulwip.h | 9 +
> > net/Kconfig | 1 +
> > net/net.c | 24 +++
> > 25 files changed, 1430 insertions(+), 44 deletions(-)
> > create mode 100644 lib/lwip/Kconfig
> > create mode 100644 lib/lwip/Makefile
> > create mode 100644 lib/lwip/apps/dhcp/lwip-dhcp.c
> > create mode 100644 lib/lwip/apps/http/lwip-wget.c
> > create mode 100644 lib/lwip/apps/ping/lwip_ping.c
> > create mode 100644 lib/lwip/apps/ping/lwip_ping.h
> > create mode 100644 lib/lwip/apps/ping/ping.h
> > create mode 100644 lib/lwip/apps/tftp/lwip-tftp.c
> > create mode 100644 lib/lwip/cmd-lwip.c
> > create mode 100644 lib/lwip/lwipopts.h
> > create mode 100644 lib/lwip/port/if.c
> > create mode 100644 lib/lwip/port/include/arch/cc.h
> > create mode 100644 lib/lwip/port/include/arch/sys_arch.h
> > create mode 100644 lib/lwip/port/include/limits.h
> > create mode 100644 lib/lwip/port/sys-arch.c
> > create mode 100644 lib/lwip/ulwip.h
> >
> > diff --git a/.gitignore b/.gitignore
> > index eb769f144c..be3676c59e 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -104,3 +104,12 @@ __pycache__
> > # pylint files
> > /pylint.cur
> > /pylint.out/
> > +
> > +lib/lwip/lwip-external
> > +lib/lwip/apps/ping/ping.c
> > +lib/lwip/apps/http/http_client.c
> > +lib/lwip/apps/http/http_client.h
> > +lib/lwip/apps/tftp/tftp.c
> > +lib/lwip/apps/tftp/tftp_client.h
> > +lib/lwip/apps/tftp/tftp_common.h
> > +lib/lwip/apps/tftp/tftp_example.h
> > diff --git a/boot/bootmeth_pxe.c b/boot/bootmeth_pxe.c
> > index e6992168c0..30331a9806 100644
> > --- a/boot/bootmeth_pxe.c
> > +++ b/boot/bootmeth_pxe.c
> > @@ -118,7 +118,7 @@ static int distro_pxe_read_file(struct udevice *dev,
> struct bootflow *bflow,
> > tftp_argv[1] = file_addr;
> > tftp_argv[2] = (void *)file_path;
> >
> > - if (do_tftpb(ctx->cmdtp, 0, 3, tftp_argv))
> > + if (do_lwip_tftp(ctx->cmdtp, 0, 3, tftp_argv))
> > return -ENOENT;
> > ret = pxe_get_file_size();
> > if (ret)
> > diff --git a/cmd/net.c b/cmd/net.c
> > index 0e9f200ca9..6d704fba86 100644
> > --- a/cmd/net.c
> > +++ b/cmd/net.c
> > @@ -36,19 +36,9 @@ U_BOOT_CMD(
> > #endif
> >
> > #ifdef CONFIG_CMD_TFTPBOOT
> > -int do_tftpb(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> > -{
> > - int ret;
> > -
> > - bootstage_mark_name(BOOTSTAGE_KERNELREAD_START, "tftp_start");
> > - ret = netboot_common(TFTPGET, cmdtp, argc, argv);
> > - bootstage_mark_name(BOOTSTAGE_KERNELREAD_STOP, "tftp_done");
> > - return ret;
> > -}
> > -
> > #if IS_ENABLED(CONFIG_IPV6)
> > U_BOOT_CMD(
> > - tftpboot, 4, 1, do_tftpb,
> > + tftpboot, 4, 1, do_lwip_tftp,
> > "boot image via network using TFTP protocol\n"
> > "To use IPv6 add -ipv6 parameter or use IPv6 hostIPaddr framed "
> > "with [] brackets",
> > @@ -56,7 +46,7 @@ U_BOOT_CMD(
> > );
> > #else
> > U_BOOT_CMD(
> > - tftpboot, 3, 1, do_tftpb,
> > + tftpboot, 3, 1, do_lwip_tftp,
> > "load file via network using TFTP protocol",
> > "[loadAddress]
Re: [PATCH v2 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Jul 28, 2023 at 02:55:23PM +0200, Miquel Raynal wrote: > Hi Tom, > > tr...@konsulko.com wrote on Mon, 24 Jul 2023 14:13:45 -0400: > > > On Sun, Jul 23, 2023 at 07:49:55PM +0200, Miquel Raynal wrote: > > > Hi Marek, > > > > > > ma...@denx.de wrote on Mon, 17 Jul 2023 13:21:34 +0200: > > > > > > > Extend the driver core to perform lookup by both OF node and driver > > > > bound to the node. Use this to look up specific device instances to > > > > unbind from nodes in the unbind command. One example where this is > > > > needed is USB peripheral controller, which may have multiple gadget > > > > drivers bound to it. The unbind command has to select that specific > > > > gadget driver instance to unbind from the controller, not unbind the > > > > controller driver itself from the controller. > > > > > > > > USB ethernet gadget usage looks as follows with this change. Notice > > > > the extra 'usb_ether' addition in the 'unbind' command at the end. > > > > " > > > > bind /soc/usb-otg@4900 usb_ether > > > > > > I don't really get why this is needed? Yes, having proper bind and > > > unbind methods and having them called internally is relevant, but when > > > you have a single OTG controller, why is this needed? It basically > > > breaks the CLI, making bisects more painful and all updates just fail. > > > > I think part of the issue here is how usb_ether didn't act like the rest > > of the gadget do, for example fastboot. > > It definitely is. "before it was working, now it does not anymore". > That's the gut feeling many people get when the community breaks common > habits. If we break something like this, we must at least be very clear > on what is the new behavior. I'm not sure that in the end there will be a behavior change here, but the first step to figuring out if things do or don't automatically bind right in the end is to fix the MUSB problem (see below). Then we can worry if there's a real behavior change or not. > > > > setenv ethact usb_ether > > > > setenv loadaddr 0xc200 > > > > setenv ipaddr 10.0.0.2 > > > > setenv serverip 10.0.0.1 > > > > setenv netmask 255.255.255.0 > > > > tftpboot 0xc200 10.0.0.1:test.file > > > > unbind /soc/usb-otg@4900 usb_ether > > > > " > > > > > > > > Signed-off-by: Marek Vasut > > > > --- > > > > Cc: Kevin Hilman > > > > Cc: Lukasz Majewski > > > > Cc: Marek Vasut > > > > Cc: Simon Glass > > > > > > I've tested the whole series, unfortunately is does not work on > > > AM335x/BBBW: > > > > > > * Any recovery attempted using the network will now fail in > > > the SPL, where, AFAIK, there is no way to manually bind: > > > > > > U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) > > > Trying to boot from USB eth > > > Could not get PHY for eth_cpsw: addr 0 > > > eth0: eth_cpswusing musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > > > MAC de:ad:be:ef:00:01 > > > HOST MAC de:ad:be:ef:00:00 > > > RNDIS ready > > > , eth1: usb_ether > > > > For testing, what happens if you disable CPSW? Does it both bind (as it > > shows here) and then use the expected device? > > Disabling CPSW breaks the link, I had to ensure ft_board_setup in the > am335x arch folder was still available (and returned 0). But once I > managed to start I did not observe any improvements. > > U-Boot SPL 2023.07-00806-gac80e6de9cf-dirty (Jul 28 2023 - 14:49:48 +0200) > Trying to boot from USB eth > Could not get PHY for eth_cpsw: addr 0 > eth0: eth_cpswusing musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > MAC de:ad:be:ef:00:01 > HOST MAC de:ad:be:ef:00:00 > RNDIS ready > , eth1: usb_ether So it's just not working, is what we both observe, on this platform. > > > * The bind command was not available on my default configuration, > > > making it even difficult for people unaware that this command is > > > now required to fix their common commands. > > > > Yes, we'll need to make that default y if USB_ETHER. > > Agreed. > > > > * Any command that expects the usb_ether driver will now fail badly > > > even after the bind call: > > > > > > => bind /ocp/usb@4740/usb@47401000 usb_ether > > > => fastboot usb 0 > > > couldn't find an available UDC > > > g_dnl_register: failed!, error: -19 > > > exit not allowed from main input shell. > > > => tftp 0x8100 zImage > > > dev_get_priv: null device > > > > Well, does it work if you do: > > bind /ocp/usb@4740/usb@47401000 usb_ether > > tftp 0x8100 zImage > > ? > > No, I already tried both: > > U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) > Trying to boot from MMC2 > > > U-Boot 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) > > CPU : AM335X-GP rev 2.1 > Model: TI AM335x BeagleBone Black > DRAM: 512 MiB > Core: 160 devices, 18 uclasses, devicetree: separate > WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Loading
Re: [PATCH] gpio: Use separate bitfield array to indicate GPIO is claimed
On 7/28/23 03:52, Simon Glass wrote:
[...]
@@ -1341,6 +1358,13 @@ static int gpio_post_probe(struct udevice *dev)
if (!uc_priv->name)
return -ENOMEM;
+ uc_priv->claimed = calloc(DIV_ROUND_UP(uc_priv->gpio_count, 32),
+ sizeof(*uc_priv->claimed));
+ if (!uc_priv->claimed) {
+ free(uc_priv->name);
+ return -ENOMEM;
+ }
We already have the name[] array which holds the name for each GPIO.
What do you think about a struct for each GPIO, with both the name and
the bool in it. It is messy to have two separate, mirrored arrays.
I think that would not be memory efficient, which is why I picked the
array. You would basically waste a few bytes for each "claimed" flag
instead of just one bit for each flag.
[...]
[PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
The EFI_RNG_PROTOCOL is needed for Linux' KASLR. QEMU can provide a virtio-rng device to emulate a hardware random number generator which is supported by our virtio_rng driver. Enabling CONFIG_DM_RNG will enable CONFIG_VIRTIO_RNG and CONFIG_EFI_RNG_PROTOCOL by default too. Signed-off-by: Heinrich Schuchardt --- board/emulation/qemu-riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 6114e1b812..21d6160f01 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -53,6 +53,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply NVME imply PCI imply PCIE_ECAM_GENERIC + imply DM_RNG imply SCSI imply DM_SCSI imply SYS_NS16550 -- 2.40.1
Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication
On Fri, Jul 28, 2023 at 02:00:25PM +0300, Ilias Apalodimas wrote: > Hi Tom > > On Thu, 27 Jul 2023 at 19:43, Tom Rini wrote: > > > > On Thu, Jul 27, 2023 at 05:07:11PM +0100, Abdellatif El Khlifi wrote: > > > > > Add MM communication support using FF-A transport > > > > > > This feature allows accessing MM partitions services through > > > EFI MM communication protocol. MM partitions such as StandAlonneMM > > > or smm-gateway secure partitions which reside in secure world. > > > > > > An MM shared buffer and a door bell event are used to exchange > > > the data. > > > > > > The data is used by EFI services such as GetVariable()/SetVariable() > > > and copied from the communication buffer to the MM shared buffer. > > > > > > The secure partition is notified about availability of data in the > > > MM shared buffer by an FF-A message (door bell). > > > > > > On such event, MM SP can read the data and updates the MM shared > > > buffer with the response data. > > > > > > The response data is copied back to the communication buffer and > > > consumed by the EFI subsystem. > > > > > > MM communication protocol supports FF-A 64-bit direct messaging. > > > > > > Signed-off-by: Abdellatif El Khlifi > > > Tested-by: Gowtham Suresh Kumar > > > Reviewed-by: Simon Glass > > > Cc: Tom Rini > > > Cc: Ilias Apalodimas > > > Cc: Jens Wiklander > > > > > > --- > > > > > > Changelog: > > > === > > > > > > v17: > > > > > > * show a debug message rather than an error when FF-A is not detected > > [snip] > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > index c5835e6ef6..8fbadb9201 100644 > > > --- a/lib/efi_loader/Kconfig > > > +++ b/lib/efi_loader/Kconfig > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > config EFI_MM_COMM_TEE > > > - bool "UEFI variables storage service via OP-TEE" > > > - depends on OPTEE > > > + bool "UEFI variables storage service via the trusted world" > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > You didn't get my changes in here however. If you can do EFI_MM_COMM_TEE > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) then > > you don't make this option depend on . If FF-A is only > > for use here, you make FF-A depend on this, and the FF-A specific > > variable depend on ARM_FFA_TRANSPORT. > > Abdellatif hinted at what's going on here. When I added this Kconfig > option to lx2160 FF-A wasn't implemented yet. The defconfig has existed since May 2020, which is when you added EFI_MM_COMM_TEE itself too. So I think it's that no one did the check I did until now and saw this series was disabling what was on the other platform. > Since FF-A isn't a new > communication mechanism but builds upon the existing SMCs to build an > easier API, I asked Abdellatif to hide this complexity. > We had two options, either make Kconfig options for either FF-A or the > traditional SMCs and remove the dependencies, or piggyback on FF-As > discovery mechanism and make the choice at runtime. The latter has a > small impact on code size, but imho makes developers' life a lot > easier. I'm not sure how much you can do a run-time option here since you're setting a bunch of default values for FF-A to 0 in Kconfig. If we're supposed to be able to get them at run time, we shouldn't need a Kconfig option at all. I'm also not sure how valid a use case it is where we won't know at build time what the rest of the firmware stack supports here. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/2] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
On Fri, Jul 28, 2023 at 01:34:38PM +, Marcel Ziswiler wrote:
> Hi Maxime
>
> Just a minor nitpick in the comments below.
>
> On Mon, 2023-07-24 at 15:57 +0200, Maxime Ripard wrote:
> > The binding represents the MDIO controller as a child device tree
> > node of the MAC device tree node.
> >
> > The U-Boot driver mostly ignores that child device tree node and just
> > hardcodes the resources it uses to support both the MAC and MDIO in a
> > single driver.
> >
> > However, some resources like pinctrl muxing states are thus ignored.
> > This has been a problem with some device trees that will put some
> > pinctrl states on the MDIO device tree node, like the SK-AM62 Device
> > Tree does.
> >
> > Let's rework the driver a bit to create a dummy MDIO driver that we will
> > then get during our initialization to force the core to select the right
> > muxing.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/net/ti/Kconfig | 1 +
> > drivers/net/ti/am65-cpsw-nuss.c | 60
> > +
> > 2 files changed, 61 insertions(+)
> >
> > diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
> > index d9f1c019a885..02660e4fbb44 100644
> > --- a/drivers/net/ti/Kconfig
> > +++ b/drivers/net/ti/Kconfig
> > @@ -41,6 +41,7 @@ endchoice
> > config TI_AM65_CPSW_NUSS
> > bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
> > depends on ARCH_K3
> > + imply DM_MDIO
> > imply MISC_INIT_R
> > imply MISC
> > imply SYSCON
> > diff --git a/drivers/net/ti/am65-cpsw-nuss.c
> > b/drivers/net/ti/am65-cpsw-nuss.c
> > index ce52106e5238..51a8167d14a9 100644
> > --- a/drivers/net/ti/am65-cpsw-nuss.c
> > +++ b/drivers/net/ti/am65-cpsw-nuss.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -605,14 +606,62 @@ static const struct soc_attr k3_mdio_soc_data[] = {
> > { /* sentinel */ },
> > };
> >
> > +static ofnode am65_cpsw_find_mdio(ofnode parent)
> > +{
> > + ofnode node;
> > +
> > + ofnode_for_each_subnode(node, parent)
> > + if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
> > + return node;
> > +
> > + return ofnode_null();
> > +}
> > +
> > +static int am65_cpsw_mdio_setup(struct udevice *dev)
> > +{
> > + struct am65_cpsw_priv *priv = dev_get_priv(dev);
> > + struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> > + struct udevice *mdio_dev;
> > + ofnode mdio;
> > + int ret;
> > +
> > + mdio = am65_cpsw_find_mdio(dev_ofnode(cpsw_common->dev));
> > + if (!ofnode_valid(mdio))
> > + return 0;
> > +
> > + /*
> > + * The MDIO controller is represented in the DT binding by a
> > + * subnode of the MAC controller.
> > + *
> > + * We don't have a DM driver for the MDIO device yet, and thus any
> > + * pinctrl setting on its node will be ignored.
> > + *
> > + * However, we do need to make sure the pins states tied to the
> > + * MDIO node are configured properly. Fortunately, the core DM
> > + * does that for use when we get a device, so we can work around
>
> Does that for us?
>
> > + * that whole issue by just requesting a dummy MDIO driver to
> > + * probe, and our pins will get muxed.
> > + */
> > + ret = uclass_get_device_by_ofnode(UCLASS_MDIO, mdio, _dev);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > static int am65_cpsw_mdio_init(struct udevice *dev)
> > {
> > struct am65_cpsw_priv *priv = dev_get_priv(dev);
> > struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> > + int ret;
> >
> > if (!priv->has_phy || cpsw_common->bus)
> > return 0;
> >
> > + ret = am65_cpsw_mdio_setup(dev);
> > + if (ret)
> > + return ret;
> > +
> > cpsw_common->bus = cpsw_mdio_init(dev->name,
> > cpsw_common->mdio_base,
> > cpsw_common->bus_freq,
> > @@ -868,3 +917,14 @@ U_BOOT_DRIVER(am65_cpsw_nuss_port) = {
> > .plat_auto = sizeof(struct eth_pdata),
> > .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_OS_PREPARE,
> > };
> > +
> > +static const struct udevice_id am65_cpsw_mdio_ids[] = {
> > + { .compatible = "ti,cpsw-mdio" },
> > + { }
> > +};
> > +
> > +U_BOOT_DRIVER(am65_cpsw_mdio) = {
> > + .name = "am65_cpsw_mdio",
> > + .id = UCLASS_MDIO,
> > + .of_match = am65_cpsw_mdio_ids,
> > +};
>
> However, so far I could not make this work for our use-case [1]. It just
> keeps crashing. Any ideas?
>
> [snip]
>
> Model: Toradex 0076 Verdin AM62 Quad 2GB WB IT V1.0A
> Serial#: 15037380
> Carrier: Toradex Dahlia V1.1A, Serial# 10763237
>
AW: getting u-boot to work on raspi 3b (32bit)
Hi Simon,
meanwhile I've tried booting from an FIT image. I.e. I wrote an ist file and
baked an itb for booting.
However, that gave me errors along the lines of "Wrong image format for bootm
command".
So I kept trying to boot the thing using the old fashioned way.
After some trial and error (recompiling the kernel with identical setting and
hooking up a monitor) u-boot handed control over to the kernel and I was indeed
greeted by 4 raspberries.
Unfortunately it got stuck after that, not leaving any (error) messages.
I next tried to boot from a pre-built raspbian kernel which I knew should work.
It gave identical results.
For fun, I also tried to boot from the console, entering the commands manually.
Then it complained about wrong magic bytes or some such (also for the Raspbian
kernel). Why this, all of a sudden?
I'm running out of ideas of might go wrong here.
Am I missing something completely here?
Have a nice weekend
Robert
PS: The problems with the serial port outputting garbage when scanning USB and
starting the kernel still persist. I guess this doesn't work as intended?
PPS: A ready to go distribution probably isn't going to help much as, figuring
out how to setup the boot process with u-boot from scratch is the whole point
of the project. Later on we want to repeat the process on some old, exotic
embedded system which is already known to be quite quirky. (Of course, it has
dropped out of support a long time ago...)
-Ursprüngliche Nachricht-
Von: Simon Glass
Gesendet: Dienstag, 25. Juli 2023 23:29
An: Robert Wenisch
Cc: u-boot@lists.denx.de
Betreff: Re: getting u-boot to work on raspi 3b (32bit)
Hi Robert,
On Tue, 25 Jul 2023 at 09:42, Robert Wenisch wrote:
>
> Hello,
>
> in order to study the boot process of embedded ARM systems, I decided to
> start with something well documented: booting as raspi 3b using u-boot.
> I downloaded kernel sources and u-boot sources. I built the kernel
> with
>
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make bcmrpi_defconfig
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make -j6 zImage dtbs
> modules cp arch/arm/boot/zImage /path/to/sdcard-boot-partition cp
> arch/arm/boot/dts/bcm2710-rpi-3-b.dtb /path/to/sdcard-boot-partition
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm INSTALL_MOD_PATH make
> modules_install
>
> Further I compiled and setup u-boot:
>
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make rpi_3_32b_defconfig
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make -j6
>
> cp u-boot.bin /path/to/ sdcard-boot-partition
>
> I then went on to edit the config.txt:
>
> kernel=u-boot-bin
> enable_uart=1
> arm_64bit=0
> device_tree=bcm2710-rpi-3-b.dtb
>
> and boot.txt goes
>
> fatload mmc 0:1 ${fdt_addr_r} bcm2710-rpi-3-b.dtb fatload mmc 0:1
> $kernel_addr_r} zImage setenv bootargs console=ttyS0,115200
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rw earlyprintk bootz
> ${kernel_addr_r} - {fdt_addr_r}
>
> I produced an image of boot.txt
>
> mkimage -A arm -O linux -T script -d boot.txt boot.scr
>
> Frustratingly, it didn't go as smoothly as expected.
You should really be using FIT [1] for this, rather than legacy images.
>
> With these setting I got up to state "Starting Kernel ..." over the serial
> port, then it freezes (or at least doesn't log anything on the tty).
> I can't post the whole log as I only have it on my dev-machine.
You could try things like earlycon to get some console output.
> However some interesting bits for now:
> I'm booting on u-boot 2023-07-0967-g94e7cb181a
> 1 - Pretty much at the beginning it says "Loading Environment from FAT... ***
> warning - bad CRC, using default environment"
> I suppose this only means we're not providing a .env file?
Yes
>
> 2 - Upon "Scanning bus usb@7e98 for devices... it's logging a lot of
> garbage (as in misinterpreted character codes), what might be going on there?
No...some sort of clock problem?
>
> 3 - A bit further down it states "Found U-Boot script /boot.scr"
> [...]
> "## Executing script at 0240"
> As this changes when I edit around the boot.txt and mkimage, I infer u-boot
> is indeed loading my boot instructions not just some default values.
OK
>
> Then follow some info on kernel image flatted device tree blob and their
> respective memory addresses.
> It the tries to load the kernel to little apparent success :/
>
> This procedure is what I gathered from a plethora of tutorial and howtos.
> Most of these are quite old, have there been breaking changes in u-boot's
> development in the meanwhile?
> For example some sources state the kernel is launched via booti
> ${kernel_addr_r} - {fdt_addr_r}, however the booti command seem to be absent
> in my u-boot version.
I believe booti is for arm64 but you are using the 32-bit build of rpi-3, so
you should be using bootm.
>
> Is there anything else I#m doing wrong?
>
> I'll be grateful for any hints at this point...
You could send a patch to [1] to help others!
There are also
Re: [PATCH v4 1/2] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
Hi Maxime
Just a minor nitpick in the comments below.
On Mon, 2023-07-24 at 15:57 +0200, Maxime Ripard wrote:
> The binding represents the MDIO controller as a child device tree
> node of the MAC device tree node.
>
> The U-Boot driver mostly ignores that child device tree node and just
> hardcodes the resources it uses to support both the MAC and MDIO in a
> single driver.
>
> However, some resources like pinctrl muxing states are thus ignored.
> This has been a problem with some device trees that will put some
> pinctrl states on the MDIO device tree node, like the SK-AM62 Device
> Tree does.
>
> Let's rework the driver a bit to create a dummy MDIO driver that we will
> then get during our initialization to force the core to select the right
> muxing.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/net/ti/Kconfig | 1 +
> drivers/net/ti/am65-cpsw-nuss.c | 60
> +
> 2 files changed, 61 insertions(+)
>
> diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
> index d9f1c019a885..02660e4fbb44 100644
> --- a/drivers/net/ti/Kconfig
> +++ b/drivers/net/ti/Kconfig
> @@ -41,6 +41,7 @@ endchoice
> config TI_AM65_CPSW_NUSS
> bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
> depends on ARCH_K3
> + imply DM_MDIO
> imply MISC_INIT_R
> imply MISC
> imply SYSCON
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index ce52106e5238..51a8167d14a9 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -605,14 +606,62 @@ static const struct soc_attr k3_mdio_soc_data[] = {
> { /* sentinel */ },
> };
>
> +static ofnode am65_cpsw_find_mdio(ofnode parent)
> +{
> + ofnode node;
> +
> + ofnode_for_each_subnode(node, parent)
> + if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
> + return node;
> +
> + return ofnode_null();
> +}
> +
> +static int am65_cpsw_mdio_setup(struct udevice *dev)
> +{
> + struct am65_cpsw_priv *priv = dev_get_priv(dev);
> + struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> + struct udevice *mdio_dev;
> + ofnode mdio;
> + int ret;
> +
> + mdio = am65_cpsw_find_mdio(dev_ofnode(cpsw_common->dev));
> + if (!ofnode_valid(mdio))
> + return 0;
> +
> + /*
> + * The MDIO controller is represented in the DT binding by a
> + * subnode of the MAC controller.
> + *
> + * We don't have a DM driver for the MDIO device yet, and thus any
> + * pinctrl setting on its node will be ignored.
> + *
> + * However, we do need to make sure the pins states tied to the
> + * MDIO node are configured properly. Fortunately, the core DM
> + * does that for use when we get a device, so we can work around
Does that for us?
> + * that whole issue by just requesting a dummy MDIO driver to
> + * probe, and our pins will get muxed.
> + */
> + ret = uclass_get_device_by_ofnode(UCLASS_MDIO, mdio, _dev);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> static int am65_cpsw_mdio_init(struct udevice *dev)
> {
> struct am65_cpsw_priv *priv = dev_get_priv(dev);
> struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> + int ret;
>
> if (!priv->has_phy || cpsw_common->bus)
> return 0;
>
> + ret = am65_cpsw_mdio_setup(dev);
> + if (ret)
> + return ret;
> +
> cpsw_common->bus = cpsw_mdio_init(dev->name,
> cpsw_common->mdio_base,
> cpsw_common->bus_freq,
> @@ -868,3 +917,14 @@ U_BOOT_DRIVER(am65_cpsw_nuss_port) = {
> .plat_auto = sizeof(struct eth_pdata),
> .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_OS_PREPARE,
> };
> +
> +static const struct udevice_id am65_cpsw_mdio_ids[] = {
> + { .compatible = "ti,cpsw-mdio" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(am65_cpsw_mdio) = {
> + .name = "am65_cpsw_mdio",
> + .id = UCLASS_MDIO,
> + .of_match = am65_cpsw_mdio_ids,
> +};
However, so far I could not make this work for our use-case [1]. It just keeps
crashing. Any ideas?
[snip]
Model: Toradex 0076 Verdin AM62 Quad 2GB WB IT V1.0A
Serial#: 15037380
Carrier: Toradex Dahlia V1.1A, Serial# 10763237
am65_cpsw_nuss ethernet@800: K3 CPSW: nuss_ver: 0x6BA01103 cpsw_ver: 0x6BA81
103 ale_ver: 0x00290105 Ports:2 mdio_freq:100
Setting variant to wifi
Net:
Warning: ethernet@800port@1 MAC addresses don't match:
Address in ROM is 1c:63:49:22:5f:f9
Address in environment is 00:14:2d:e5:73:c4
eth0: ethernet@800port@1
Re: [PATCH v2 1/4] cmd: bind: Add unbind command with driver filter
Hi Marek, ma...@denx.de wrote on Sun, 23 Jul 2023 23:45:55 +0200: > On 7/23/23 19:49, Miquel Raynal wrote: > > Hi Marek, > > Hi, > > > ma...@denx.de wrote on Mon, 17 Jul 2023 13:21:34 +0200: > > > >> Extend the driver core to perform lookup by both OF node and driver > >> bound to the node. Use this to look up specific device instances to > >> unbind from nodes in the unbind command. One example where this is > >> needed is USB peripheral controller, which may have multiple gadget > >> drivers bound to it. The unbind command has to select that specific > >> gadget driver instance to unbind from the controller, not unbind the > >> controller driver itself from the controller. > >> > >> USB ethernet gadget usage looks as follows with this change. Notice > >> the extra 'usb_ether' addition in the 'unbind' command at the end. > >> " > >> bind /soc/usb-otg@4900 usb_ether > > > > I don't really get why this is needed? Yes, having proper bind and > > unbind methods and having them called internally is relevant, but when > > you have a single OTG controller, why is this needed? > > Because you do need to bind the usb_ether driver to a controller. Right now it seems that binding is kind of performed in the context of a command execution (and then everything is cleaned up). I also think it is not optimal, but I would like to avoid breaking common commands like you propose. At the *very least* the error messages should be very clear about what has changed and what the user needs to do now in order to workaround it. But the best would be to avoid user interaction as much as possible. So why not load the first driver needed and expect the user the run the correct unbind/bind commands if it wants to change? > I suspect you are trying to point in the direction of usb_ether_init() , > right ? That is bogus and should be removed, because that is hard-coding one > specific (ethernet) function to an OTG controller. Well, hardcoding is bad, but setting a default is often useful and much more user friendly, IMHO. > > > It basically > > breaks the CLI > > Can you elaborate on this ? > > How does calling a 'bind' command breaks CLI ? I've attempted a bisect between U-Boot 2018 and 2023, it was already very painful. But if I try again in 2024 and need to cope with the new rules added in 2023 for binding drivers which were not needed until, then it becomes even more painful. So yes, it breaks the CLI. Before: => tftp xxx => fastboot xxx just worked, after you patchset these simple operations won't work anymore. > > , making bisects more painful and all updates just fail. > > This is just utter nonsense, sorry. Well, I am a U-Boot user, and I expect this change to break a good amount of boot scripts after an update. > >> setenv ethact usb_ether > >> setenv loadaddr 0xc200 > >> setenv ipaddr 10.0.0.2 > >> setenv serverip 10.0.0.1 > >> setenv netmask 255.255.255.0 > >> tftpboot 0xc200 10.0.0.1:test.file > >> unbind /soc/usb-otg@4900 usb_ether > >> " > >> > >> Signed-off-by: Marek Vasut > >> --- > >> Cc: Kevin Hilman > >> Cc: Lukasz Majewski > >> Cc: Marek Vasut > >> Cc: Simon Glass > > > > I've tested the whole series, unfortunately is does not work on > > AM335x/BBBW: > > > > * Any recovery attempted using the network will now fail in > >the SPL, where, AFAIK, there is no way to manually bind: > > > > U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) > > Trying to boot from USB eth > > Could not get PHY for eth_cpsw: addr 0 > > eth0: eth_cpswusing musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > > MAC de:ad:be:ef:00:01 > > HOST MAC de:ad:be:ef:00:00 > > RNDIS ready > > , eth1: usb_ether > > It seems the RNDIS adapter is actually ready based on the above ^ ? > > > * The bind command was not available on my default configuration, > >making it even difficult for people unaware that this command is > >now required to fix their common commands. > > It has been required ever since, it's just that many ignored the need to move > over to DM and depended on board-specific hackage to set up their USB > ethernet. Now that hackage broke, time to switch to the proper way. It breaks because there is something wrong elsewhere. It's not at all the fault of the board hack (if any, I have no idea, I'll trust your judgment regarding the BBB support). My series fixes a real problem in the current code. The fact that it won't be visible after your series is almost anecdotic... until it triggers again for whatever reason. > > * Any command that expects the usb_ether driver will now fail badly > >even after the bind call: > > > > => bind /ocp/usb@4740/usb@47401000 usb_ether > > => fastboot usb 0 > > couldn't find an available UDC > > You already have the ethernet function bound to the UDC and now you are > trying to bind another function, fastboot, right ? This is likely the > problem. Unbind the ethernet first, then use fastboot. > > >
Re: [PATCH 2/6] board: phytec: common: Add imx8m specific EEPROM detection support
Hi Teresa,
On Tue, 2023-07-18 at 15:35 +0200, Teresa Remmet wrote:
> Add imx8m specific detection part. Which includes checking the
> EEPROM data for article number options.
>
> Signed-off-by: Teresa Remmet
> ---
> board/phytec/common/Kconfig | 8 +
> board/phytec/common/Makefile | 1 +
> board/phytec/common/imx8m_som_detection.c | 169
> ++
> board/phytec/common/imx8m_som_detection.h | 54 +++
> 4 files changed, 232 insertions(+)
> create mode 100644 board/phytec/common/imx8m_som_detection.c
> create mode 100644 board/phytec/common/imx8m_som_detection.h
>
> diff --git a/board/phytec/common/Kconfig
> b/board/phytec/common/Kconfig
> index d614d45b1d60..3b1c5aa0d02b 100644
> --- a/board/phytec/common/Kconfig
> +++ b/board/phytec/common/Kconfig
> @@ -3,3 +3,11 @@ config PHYTEC_SOM_DETECTION
> select SPL_CRC8 if SPL
> help
> Support of I2C EEPROM based SoM detection.
> +
> +config PHYTEC_IMX8M_SOM_DETECTION
> + bool "Support SoM detection for i.MX8M PHYTEC platforms"
> + depends on ARCH_IMX8M && PHYTEC_SOM_DETECTION
> + default y
> + help
> + Support of I2C EEPROM based SoM detection. Supported
> + for PHYTEC i.MX8MM/i.MX8MP boards
> diff --git a/board/phytec/common/Makefile
> b/board/phytec/common/Makefile
> index 5fe8725ef684..fe28964ce21c 100644
> --- a/board/phytec/common/Makefile
> +++ b/board/phytec/common/Makefile
> @@ -8,3 +8,4 @@ obj- := __dummy__.o
> endif
>
> obj-$(CONFIG_PHYTEC_SOM_DETECTION) += phytec_som_detection.o
> +obj-$(CONFIG_PHYTEC_IMX8M_SOM_DETECTION) += imx8m_som_detection.o
> diff --git a/board/phytec/common/imx8m_som_detection.c
> b/board/phytec/common/imx8m_som_detection.c
> new file mode 100644
> index ..a732d619fcf3
> --- /dev/null
> +++ b/board/phytec/common/imx8m_som_detection.c
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2023 PHYTEC Messtechnik GmbH
> + * Author: Teresa Remmet
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx8m_som_detection.h"
> +
> +extern struct phytec_eeprom_data eeprom_data;
> +
> +/* Check if the SoM is actually one of the following products:
> + * - i.MX8MM
> + * - i.MX8MN
> + * - i.MX8MP
> + * - i.MX8MQ
> + *
> + * Returns 0 in case it's a known SoM. Otherwise, returns -1.
> + */
> +u8 __maybe_unused phytec_imx8m_detect(struct phytec_eeprom_data
> *data)
> +{
> + char *opt;
> + u8 som;
> +
> + /* We can not do the check for early API revsions */
> + if (data->api_rev < PHYTEC_API_REV2)
> + return -1;
> +
> + if (!data)
> + data = _data;
> +
> + som = data->data.data_api2.som_no;
> + debug("%s: som id: %u\n", __func__, som);
> +
> + opt = phytec_get_opt(data);
> + if (!opt)
> + return -1;
> +
> + if (som == PHYTEC_IMX8MP_SOM && is_imx8mp())
> + return 0;
> +
> + if (som == PHYTEC_IMX8MM_SOM) {
> + if ((PHYTEC_GET_OPTION(opt[0]) != 0) &&
> + (PHYTEC_GET_OPTION(opt[1]) == 0) && is_imx8mm())
> + return 0;
> + else if ((PHYTEC_GET_OPTION(opt[0]) == 0) &&
> + (PHYTEC_GET_OPTION(opt[1]) != 0) &&
> is_imx8mn())
> + return 0;
> + }
> +
> + if (som == PHYTEC_IMX8MQ_SOM && is_imx8mq())
> + return 0;
> +
> + pr_err("%s: SoM ID does not match. Wrong EEPROM data?\n",
> __func__);
> + return -1;
> +}
> +
> +/*
> + * All PHYTEC i.MX8M boards have RAM size definition at the
> + * same location.
> + */
> +u8 __maybe_unused phytec_get_imx8m_ddr_size(struct
> phytec_eeprom_data *data)
> +{
> + char *opt;
> + u8 ddr_id;
> +
> + if (!data)
> + data = _data;
> +
> + opt = phytec_get_opt(data);
> + if (opt)
> + ddr_id = PHYTEC_GET_OPTION(opt[2]) - '0';
Is the "- '0'" a bug? While testing, I noticed that the RAM size is not
detected correctly and looking at the macro definiton this - '0' case
is already covered. I assume in this line you meant to simply call the
macro.
Regards,
Yannic
> + else
> + ddr_id = PHYTEC_EEPROM_INVAL;
> +
> + debug("%s: ddr id: %u\n", __func__, ddr_id);
> + return ddr_id;
> +}
> +
> +/*
> + * Filter SPI-NOR flash information. All i.MX8M boards have this at
> + * the same location.
> + * returns: 0x0 if no SPI is populated. Otherwise a board depended
> + * code for the size. PHYTEC_EEPROM_INVAL when the data is invalid.
> + */
> +u8 __maybe_unused phytec_get_imx8m_spi(struct phytec_eeprom_data
> *data)
> +{
> + char *opt;
> + u8 spi;
> +
> + if (!data)
> + data = _data;
> +
> + if (data->api_rev < PHYTEC_API_REV2)
> + return PHYTEC_EEPROM_INVAL;
> +
> + opt = phytec_get_opt(data);
> +
R: [PATCH 1/4] rockchip: rk3308: fix board_debug_uart_init
Hi Kever,
> Da: Tom Rini
> Inviato: giovedì 27 luglio 2023 03:07
> A: Kever Yang
> Cc: Pegorer Massimo ; Simon Glass
> ; u-boot@lists.denx.de
> Oggetto: Re: [PATCH 1/4] rockchip: rk3308: fix board_debug_uart_init
>
> On Thu, Jul 27, 2023 at 09:00:52AM +0800, Kever Yang wrote:
> > Hi Tom,
> >
> > I have reply the review tag to the list last week, but this mail
> > does not appear at the patchwork system[1],
> >
> > did you met this kind of issue and do you know how to fix it?
>
> There've been a few hiccups with the mailing list of late, hopefully your
> message will get re-tried and show up in patchwork. Otherwise you may have
> to manually add tags back when putting together a pull request, sorry about
> that.
I see that patches [1] in patchwork system are missing the reviewed flag
despite your replies with Reviewed-by tag.
Would you like me to send a v2, or to re-send them?
Massimo
[1]
https://patchwork.ozlabs.org/project/uboot/list/?series==85278=*==both=93623
> >
> >
> > Thanks,
> >
> > - Kever
> >
> > [1]
> > https://patchwork.ozlabs.org/project/uboot/patch/GV1PR08MB801036B040F2
> > 57c97c652296e5...@gv1pr08mb8010.eurprd08.prod.outlook.com/
> >
> > On 2023/7/21 17:05, Kever Yang wrote:
> > >
> > > On 2023/7/15 18:19, Pegorer Massimo wrote:
> > > > Definition of function board_debug_uart_init() must be under
> > > > CONFIG_DEBUG_UART_BOARD_INIT and not under
> CONFIG_DEBUG_UART, as
> > > > it was: see debug_uart.h. In this way the debug uart can be used
> > > > but its board-specific initialization skipped by configuration, if
> > > > useless.
> > > >
> > > > Signed-off-by: Massimo Pegorer
> > > Reviewed-by: Kever Yang
> > >
> > > Thanks,
> > > - Kever
> > > > ---
> > > > arch/arm/mach-rockchip/rk3308/rk3308.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c
> > > > b/arch/arm/mach-rockchip/rk3308/rk3308.c
> > > > index dd9109b7c3..5763604dc3 100644
> > > > --- a/arch/arm/mach-rockchip/rk3308/rk3308.c
> > > > +++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
> > > > @@ -174,7 +174,7 @@ int rk_board_init(void)
> > > > return 0;
> > > > }
> > > > -#if defined(CONFIG_DEBUG_UART)
> > > > +#ifdef CONFIG_DEBUG_UART_BOARD_INIT
> > > > __weak void board_debug_uart_init(void)
> > > > {
> > > > static struct rk3308_grf * const grf = (void *)GRF_BASE;
>
> --
> Tom
Re: [PATCH 0/5] board: rockchip: Add Pine64 Quartz64 and SOQuartz boards
On 2023-07-28 13:02, Kever Yang wrote: > > On 2023/7/23 22:55, Jonas Karlman wrote: >> This series was created in collaboration with Nicolas Frattaroli and add >> support for Pine64 Quartz64 and SOQuartz boards with a RK3566 SoC. >> >> - Pine64 Quartz64-A Board >> - Pine64 Quartz64-B Board >> - Pine64 SOQuartz on Model A >> - Pine64 SOQuartz on Blade >> - Pine64 SOQuartz on CM4-IO >> >> Device trees have been imported from linux v6.4. >> >> This series have loose dependencies on the following series: >> - rockchip: Fix PCIe and NVMe support on RK3568 [1] >> - rockchip: rk3568: Use dwc3-generic driver [2] > > This patch is still waiting for review, and this patchset may need to > update once it get merged. Thanks, I have re-sent the following series that I hope should help you with applying. - "rockchip: rk3568: Device Tree updates" v2 - "rockchip: rk35xx: Fix SPI Flash alias" v2 - "rockchip: rk3568: Use dwc3-generic driver" v4 There may only be a runtime depend on the patch "usb: dwc3-generic: Relax unsupported dr_mode check" of the "rockchip: rk3568: Use dwc3-generic driver" series. Or it may not be since we define dr_mode = "host" on some of these boards. Our runtime testing has however been done with all the mentioned series applied. Will re-send this series if needed :-) Regards, Jonas > > Thanks, > - Kever >> - rockchip: rk3568: Fix alloc space exhausted in SPL [3] >> - rockchip: rk3568: Device Tree updates [4] >> - rockchip: rk35xx: Fix SPI Flash alias [5] >> - board: rockchip: Add Hardkernel ODROID-M1 [6] >> >> A copy of this series with above dependencies can be found at [7]. >> >> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=365195 >> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=364127 >> [3] https://patchwork.ozlabs.org/project/uboot/list/?series=361999 >> [4] https://patchwork.ozlabs.org/project/uboot/list/?series=362030 >> [5] https://patchwork.ozlabs.org/project/uboot/list/?series=363527 >> [6] https://patchwork.ozlabs.org/project/uboot/list/?series=365198 >> [7] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-quartz64-v1 >> >> Jonas Karlman (5): >>board: rockchip: Add Pine64 Quartz64-A Board >>board: rockchip: Add Pine64 Quartz64-B Board >>board: rockchip: Add Pine64 SOQuartz on Model A >>board: rockchip: Add Pine64 SOQuartz on Blade >>board: rockchip: Add Pine64 SOQuartz on CM4-IO >> >> arch/arm/dts/Makefile | 5 + >> arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi| 55 ++ >> arch/arm/dts/rk3566-quartz64-a.dts| 839 ++ >> arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi| 47 + >> arch/arm/dts/rk3566-quartz64-b.dts| 739 +++ >> .../arm/dts/rk3566-soquartz-blade-u-boot.dtsi | 3 + >> arch/arm/dts/rk3566-soquartz-blade.dts| 194 >> arch/arm/dts/rk3566-soquartz-cm4-u-boot.dtsi | 3 + >> arch/arm/dts/rk3566-soquartz-cm4.dts | 192 >> .../dts/rk3566-soquartz-model-a-u-boot.dtsi | 3 + >> arch/arm/dts/rk3566-soquartz-model-a.dts | 232 + >> arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 30 + >> arch/arm/dts/rk3566-soquartz.dtsi | 688 ++ >> arch/arm/mach-rockchip/rk3568/Kconfig | 6 + >> board/pine64/quartz64_rk3566/Kconfig | 15 + >> board/pine64/quartz64_rk3566/MAINTAINERS | 23 + >> board/pine64/quartz64_rk3566/Makefile | 3 + >> .../pine64/quartz64_rk3566/quartz64-rk3566.c | 1 + >> configs/quartz64-a-rk3566_defconfig | 110 +++ >> configs/quartz64-b-rk3566_defconfig | 106 +++ >> configs/soquartz-blade-rk3566_defconfig | 90 ++ >> configs/soquartz-cm4-rk3566_defconfig | 90 ++ >> configs/soquartz-model-a-rk3566_defconfig | 90 ++ >> doc/board/rockchip/rockchip.rst | 5 + >> include/configs/quartz64_rk3566.h | 10 + >> 25 files changed, 3579 insertions(+) >> create mode 100644 arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3566-quartz64-a.dts >> create mode 100644 arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3566-quartz64-b.dts >> create mode 100644 arch/arm/dts/rk3566-soquartz-blade-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3566-soquartz-blade.dts >> create mode 100644 arch/arm/dts/rk3566-soquartz-cm4-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3566-soquartz-cm4.dts >> create mode 100644 arch/arm/dts/rk3566-soquartz-model-a-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3566-soquartz-model-a.dts >> create mode 100644 arch/arm/dts/rk3566-soquartz-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3566-soquartz.dtsi >> create mode 100644 board/pine64/quartz64_rk3566/Kconfig >> create mode 100644 board/pine64/quartz64_rk3566/MAINTAINERS >> create mode 100644 board/pine64/quartz64_rk3566/Makefile >> create mode 100644
Re: [PATCH v2 0/4] net: ti: am65-cpsw-nuss: Drop custom properties
Hi Roger On Sat, 2023-07-22 at 22:31 +0300, Roger Quadros wrote: > Hi, > > This series gets rid of 2 custom properties (mac_efuse and cpsw-phy-sel) > that were used in u-boot for the cpsw3g node. > > This makes it easier for us to have u-boot DT in sync with Linux. > > Last 2 patches are RFC so they can come separately. i.e. squashed with > DT cleanup series from Nishanth. > > cheers, > -roger > > Changelog: > v2: > - drop enabling CONFIG_SYSCON from defconfig. Use imply in Kconfig instead. > - add patch to drop cpsw-phy-sel custom DT property. > > Roger Quadros (4): > net: ti: am65-cpsw-nuss: Use approved property to get efuse address > net: ti: am65-cpsw-nuss: Get port mode register from standard "phys" > property > arm: dts: k3-am625-sk-u-boot.dtsi: drop mac_efuse > arm: dts: k3-am625-sk-u-boot.dtsi: drop cpsw-phy-sel property > > arch/arm/dts/k3-am625-sk-u-boot.dtsi | 10 --- > drivers/net/ti/Kconfig | 1 + > drivers/net/ti/am65-cpsw-nuss.c | 115 +-- > 3 files changed, 74 insertions(+), 52 deletions(-) This also works with our in-flight stuff [1] with the same adjustments which we will shortly send as a v4. Tested-by: Marcel Ziswiler [1] https://lore.kernel.org/all/20230715074050.941051-1-mar...@ziswiler.com Cheers Marcel
Re: [PATCH v2 1/4] cmd: bind: Add unbind command with driver filter
Hi Tom, tr...@konsulko.com wrote on Mon, 24 Jul 2023 14:13:45 -0400: > On Sun, Jul 23, 2023 at 07:49:55PM +0200, Miquel Raynal wrote: > > Hi Marek, > > > > ma...@denx.de wrote on Mon, 17 Jul 2023 13:21:34 +0200: > > > > > Extend the driver core to perform lookup by both OF node and driver > > > bound to the node. Use this to look up specific device instances to > > > unbind from nodes in the unbind command. One example where this is > > > needed is USB peripheral controller, which may have multiple gadget > > > drivers bound to it. The unbind command has to select that specific > > > gadget driver instance to unbind from the controller, not unbind the > > > controller driver itself from the controller. > > > > > > USB ethernet gadget usage looks as follows with this change. Notice > > > the extra 'usb_ether' addition in the 'unbind' command at the end. > > > " > > > bind /soc/usb-otg@4900 usb_ether > > > > I don't really get why this is needed? Yes, having proper bind and > > unbind methods and having them called internally is relevant, but when > > you have a single OTG controller, why is this needed? It basically > > breaks the CLI, making bisects more painful and all updates just fail. > > I think part of the issue here is how usb_ether didn't act like the rest > of the gadget do, for example fastboot. It definitely is. "before it was working, now it does not anymore". That's the gut feeling many people get when the community breaks common habits. If we break something like this, we must at least be very clear on what is the new behavior. > > > setenv ethact usb_ether > > > setenv loadaddr 0xc200 > > > setenv ipaddr 10.0.0.2 > > > setenv serverip 10.0.0.1 > > > setenv netmask 255.255.255.0 > > > tftpboot 0xc200 10.0.0.1:test.file > > > unbind /soc/usb-otg@4900 usb_ether > > > " > > > > > > Signed-off-by: Marek Vasut > > > --- > > > Cc: Kevin Hilman > > > Cc: Lukasz Majewski > > > Cc: Marek Vasut > > > Cc: Simon Glass > > > > I've tested the whole series, unfortunately is does not work on > > AM335x/BBBW: > > > > * Any recovery attempted using the network will now fail in > > the SPL, where, AFAIK, there is no way to manually bind: > > > > U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) > > Trying to boot from USB eth > > Could not get PHY for eth_cpsw: addr 0 > > eth0: eth_cpswusing musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > > MAC de:ad:be:ef:00:01 > > HOST MAC de:ad:be:ef:00:00 > > RNDIS ready > > , eth1: usb_ether > > For testing, what happens if you disable CPSW? Does it both bind (as it > shows here) and then use the expected device? Disabling CPSW breaks the link, I had to ensure ft_board_setup in the am335x arch folder was still available (and returned 0). But once I managed to start I did not observe any improvements. U-Boot SPL 2023.07-00806-gac80e6de9cf-dirty (Jul 28 2023 - 14:49:48 +0200) Trying to boot from USB eth Could not get PHY for eth_cpsw: addr 0 eth0: eth_cpswusing musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether > > * The bind command was not available on my default configuration, > > making it even difficult for people unaware that this command is > > now required to fix their common commands. > > Yes, we'll need to make that default y if USB_ETHER. Agreed. > > * Any command that expects the usb_ether driver will now fail badly > > even after the bind call: > > > > => bind /ocp/usb@4740/usb@47401000 usb_ether > > => fastboot usb 0 > > couldn't find an available UDC > > g_dnl_register: failed!, error: -19 > > exit not allowed from main input shell. > > => tftp 0x8100 zImage > > dev_get_priv: null device > > Well, does it work if you do: > bind /ocp/usb@4740/usb@47401000 usb_ether > tftp 0x8100 zImage > ? No, I already tried both: U-Boot SPL 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) Trying to boot from MMC2 U-Boot 2023.07-00806-gac80e6de9cf (Jul 23 2023 - 19:45:51 +0200) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB Core: 160 devices, 18 uclasses, devicetree: separate WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc1:1... not set. Validating first E-fuse MAC Net: Could not get PHY for ethernet@4a10: addr 0 eth2: ethernet@4a10using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth3: usb_ether => bind /ocp/usb@4740/usb@47401000 usb_ether => tftp 0x8100 zImage dev_get_priv: null device data abort pc : [<9ffa04ba>] lr : [<9ff86d5f>] reloc pc : [<8083b4ba>]lr : [<80821d5f>] sp : 9df2f920 ip : fp : 0003 r10: 9df4cf48 r9 : 9df44ea0 r8 : 9ffec33c r7 : 538c r6 :
Re: [PATCH RFC 2/3] WIP: getting signing nodes to work in FIT generator node
Hi Simon
On 28/07/23 08:05, Simon Glass wrote:
Hi Neha,
On Thu, 27 Jul 2023 at 06:12, Neha Malcom Francis wrote:
They need to get the contents of the FIT section beforehand, process
them and prepend the signing certificate to the FIT contents
Signed-off-by: Neha Malcom Francis
---
tools/binman/etype/collection.py | 38 +++-
tools/binman/etype/fit.py| 1 +
tools/binman/etype/ti_secure.py | 13 ---
tools/binman/etype/x509_cert.py | 9 ++--
4 files changed, 46 insertions(+), 15 deletions(-)
I am not quite sure about this, but it seems there is a bit too much magic?
From what I can tell, you want:
@fdt-SEQ {
ti-secure {
content = <>;
}
dtb: blob-ext {
filename = "u-boot-spl.dtb";
}
};
where the 'dtb' phande can work even though it is in a generated node.
Not exactly, so the dtb phandle contains a node that is itself generated
on the fly different for each node. More like:
@fdt-SEQ {
ti-secure {
content = <>;
};
dtb: blob-ext {
filename = "NAME.dtb";
};
};
But since NAME is just a string substitutions this wouldn't work I
understand, but this example is to get the problem I'm trying to solve here.
Is that right? If so, I suspect it could be done.
Re the fit,fdt-indir that is where I get confused...you want it to
affect the generator somehow? How is that? The last patch gives me
some clues but I don't understand why some nodes have the
fit,fdt-indir property and some do not?
Right, so some of our generated binaries use the SPL device tree which
is in spl/dts and the rest use the standard U-Boot device tree from
arch/arm/dts which is the default. So that's an independent problem I'm
trying to fix in FIT generator.
I suspect what would help me understand is to write a test .dts and a
test that doesn't work, but illustrates what you want...then we might
get closer to a suitable design. Once the design is clean, the impl
should follow.
I'll do that when I send a follow up next.
Regards,
Simon
--
Thanking You
Neha Malcom Francis
Re: [PATCH] docs: boards: ti: add openocd spl debugging docs
On 08:52-20230728, Heinrich Schuchardt wrote:
> On 7/21/23 21:19, Jason Kacines wrote:
> > Add documentation on how to use OpenOCD to debug U-Boot for TI K3
> > Generation boards.
> >
> > Signed-off-by: Jason Kacines
>
> Thank you for providing OpenOCD usage guidance.
>
> This patch cannot be applied to origin/master. Please, rebase it.
>
> Please, remove trailing spaces.
>
> Please, try to avoid lines over 80 characters. See below.
Jason,
I will pick this patch up if you don't mind as part of my documentation
cleanup series. I think we will need to structure it a bit so that it is
re-usable across multiple platforms. I'd rather do that in a single shot
than have to deal with refactoring later.
>
> > ---
> > doc/board/ti/am62x_openocd.rst | 248 +
> > doc/board/ti/k3.rst| 20 ++-
> > 2 files changed, 265 insertions(+), 3 deletions(-)
> > create mode 100644 doc/board/ti/am62x_openocd.rst
> >
> > diff --git a/doc/board/ti/am62x_openocd.rst b/doc/board/ti/am62x_openocd.rst
> > new file mode 100644
> > index 00..4e33bd6f58
> > --- /dev/null
> > +++ b/doc/board/ti/am62x_openocd.rst
> > @@ -0,0 +1,248 @@
> > +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> > +.. sectionauthor:: Jason Kacines
> > +
> > +Debugging SPL in OpenOCD
> > +
> > +
> > +The following section demonstrates how to connect a board to OpenOCD and
> > +load the SPL symbols for debugging with a K3 generation device. For the
> > +guide below, users are expected to generate custom binaries, boot their
> > +board from an SD card and work with OpenOCD in a Linux environment. This
> > +guide uses the AM625-SK for device specific examples but can be extended
> > +to any K3 generation device.
> > +
> > +Step 1: Downloading OpenOCD
> > +---
> > +
> > +Download OpenOCD using the following command.
> > +
> > +.. code-block:: bash
> > +
> > + sudo apt-get install openocd
> > +
> > +.. note::
> > +
> > + OpenOCD version 0.12.0 is required to connect to the AM625-SK. Some
> > + major GNU/Linux distros do not support version 0.12.0. Check the
> > + version of OpenOCD with ``openocd -v``
> > +
> > +**For OpenOCD installations prior to version 0.12.0:**
> > +
> > +Clone the OpenOCD source code (https://openocd.org/).
> > +
> > +.. code-block:: bash
> > +
> > + git clone https://git.code.sf.net/p/openocd/code openocd-code
> > +
> > +Move the required config files to the package installation of OpenOCD.
> > +
> > +.. code-block:: bash
> > +
> > + cd {OpenOCD Source}
> > + cp tcl/board/ti_am625evm.cfg /usr/local/share/openocd/scripts/board
> > + cp tcl/target/ti_k3.cfg /usr/local/share/openocd/scripts/target
> > +
> > +Now you can move on to SK/EVM Setup to prepare your SK/EVM for debugging.
> > +
> > +Step 2: SK/EVM Setup
> > +
> > +
> > +Make the appropriate board cable connections.
> > +
> > +.. note::
> > +
> > + Ensure that the BOOT MODE switches are set appropriately for an SD
> > + Card boot (refer to the TRM for boot mode switch settings). For
> > + AM62x devices, refer to :doc:`/board/ti/am62x_sk`.
> > +
> > +After connecting each of the cables from the figure above, run the
> > +following command to ensure that each connection is established.
> > +
> > +.. code-block:: bash
> > +
> > + sudo dmesg | grep tty
> > +
> > +An output similar to the figure below should appear.
> > +
> > +::
> > +
> > + [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
> > attached to ttyUSB0 <- Used for UART Flashing, UART boot, Linux Kernel,
> > U-Boot
>
> Users don't like scrolling horizontally. Please, put the comments above
> or below the output lines.
>
> > + [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
> > attached to ttyUSB1
> > + [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
> > attached to ttyUSB2 <- Used for Console for DM R5F (WKUP R5F)
> > + [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
> > attached to ttyUSB3 <- Used for Console on MCU M4F
> > + [XX.XX] cdc_acm 1-5.3.1:1.0: ttyACM0: USB ACM device
> > + [XX.XX] cdc_acm 1-5.3.1:1.3: ttyACM1: USB ACM device
> > +
> > +Open a serial connection with a baud rate of 115200 to view the kernel
> >
Re: [PATCH V3 3/3] arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On Thu, 27 Jul 2023 04:03:31 -0500, Nishanth Menon wrote: > Update the am62 and am625 device-trees from linux v6.5-rc1. This needed > the following tweaks to the u-boot specific dtsi as well: > - Switch tick-timer to the main_timer as it's now defined in the main dtsi > - Secure proxies are defined in SoC dtsi > - Drop duplicate nodes - u-boot.dtsi is includes in r5-sk, no need for > > [ ... ] Reviewed-by: Maxime Ripard Thanks! Maxime
Re: [PATCH V3 0/3] arm: dts: Sync k3-am62 with upstream kernel
On Thu, 27 Jul 2023 04:03:28 -0500, Nishanth Menon wrote: > Hopefully, third time is a charm.. ;) > > I have picked up part of Sjoerd's series[1] to keep it constrained just > to dts sync at this point rather than adding newer functionality on top. > > > [ ... ] Tested-by: Maxime Ripard Thanks! Maxime
Re: [PATCH 02/16] doc: board: ti: am62x/j7200: Update with common boot flow diagram
On 09:31-20230728, Heinrich Schuchardt wrote: > > > On 7/27/23 11:40, Neha Malcom Francis wrote: > > These look nice! > > > > On 27/07/23 13:30, Nishanth Menon wrote: > > > Update the bootflow svg diagram and reuse across the platforms as they > > > are common. > > We should add SPDX license information to all the SVG files that you > created. > > e.g. > > like the license in TI's *.rst files. > > Could you, please, send a follow up patch for the series. > Thank you for catching this. will fix and resubmit. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH v4 5/5] rockchip: rk3568: Use dwc3-generic driver
Change RK3568 devices to use the newer dwc3-generic driver instead of the old xhci-dwc3 driver for USB 3.0 support. Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang --- v4: - Rebase on u-boot-rockchip/master and include change to nanopi-r5c-rk3568 and nanopi-r5s-rk3568 - Collect r-b tag v3: - No change v2: - No change configs/nanopi-r5c-rk3568_defconfig | 3 +-- configs/nanopi-r5s-rk3568_defconfig | 3 +-- configs/radxa-cm3-io-rk3566_defconfig | 2 +- configs/rock-3a-rk3568_defconfig | 2 +- 4 files changed, 4 insertions(+), 6 deletions(-) diff --git a/configs/nanopi-r5c-rk3568_defconfig b/configs/nanopi-r5c-rk3568_defconfig index b913ad4494c2..201b21ad77e3 100644 --- a/configs/nanopi-r5c-rk3568_defconfig +++ b/configs/nanopi-r5c-rk3568_defconfig @@ -13,7 +13,6 @@ CONFIG_ROCKCHIP_RK3568=y CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK_R_ADDR=0x60 -CONFIG_TARGET_EVB_RK3568=y CONFIG_SPL_STACK=0x40 CONFIG_DEBUG_UART_BASE=0xFE66 CONFIG_DEBUG_UART_CLOCK=2400 @@ -76,10 +75,10 @@ CONFIG_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_ERRNO_STR=y diff --git a/configs/nanopi-r5s-rk3568_defconfig b/configs/nanopi-r5s-rk3568_defconfig index 0a298c65a76b..67b28430709e 100644 --- a/configs/nanopi-r5s-rk3568_defconfig +++ b/configs/nanopi-r5s-rk3568_defconfig @@ -13,7 +13,6 @@ CONFIG_ROCKCHIP_RK3568=y CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK_R_ADDR=0x60 -CONFIG_TARGET_EVB_RK3568=y CONFIG_SPL_STACK=0x40 CONFIG_DEBUG_UART_BASE=0xFE66 CONFIG_DEBUG_UART_CLOCK=2400 @@ -76,10 +75,10 @@ CONFIG_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_ERRNO_STR=y diff --git a/configs/radxa-cm3-io-rk3566_defconfig b/configs/radxa-cm3-io-rk3566_defconfig index 488723dfaa30..f89777184ceb 100644 --- a/configs/radxa-cm3-io-rk3566_defconfig +++ b/configs/radxa-cm3-io-rk3566_defconfig @@ -75,8 +75,8 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_ERRNO_STR=y diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig index 42fd47eb57be..44ff054df665 100644 --- a/configs/rock-3a-rk3568_defconfig +++ b/configs/rock-3a-rk3568_defconfig @@ -97,10 +97,10 @@ CONFIG_ROCKCHIP_SFC=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_ERRNO_STR=y -- 2.41.0
[PATCH v4 4/5] usb: dwc3-generic: Add rk3568 support
RK3568 share glue and ctrl in a single node. Use glue_get_ctrl_dev to
return the glue node as the ctrl node.
Signed-off-by: Jonas Karlman
Reviewed-by: Jagan Teki
---
v4:
- No change
v3:
- No change
v2:
- No change
- Collect r-b tag
drivers/usb/dwc3/dwc3-generic.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 2331ac453132..f6d087722c9f 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -405,6 +405,22 @@ struct dwc3_glue_ops ti_ops = {
.glue_configure = dwc3_ti_glue_configure,
};
+static int dwc3_rk_glue_get_ctrl_dev(struct udevice *dev, ofnode *node)
+{
+ if (!device_is_compatible(dev, "snps,dwc3"))
+ return -EINVAL;
+
+ *node = dev_ofnode(dev);
+ if (!ofnode_valid(*node))
+ return -EINVAL;
+
+ return 0;
+}
+
+struct dwc3_glue_ops rk_ops = {
+ .glue_get_ctrl_dev = dwc3_rk_glue_get_ctrl_dev,
+};
+
static int dwc3_glue_bind_common(struct udevice *parent, ofnode node)
{
const char *name = ofnode_get_name(node);
@@ -596,6 +612,7 @@ static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "ti,am654-dwc3" },
{ .compatible = "rockchip,rk3328-dwc3" },
{ .compatible = "rockchip,rk3399-dwc3" },
+ { .compatible = "rockchip,rk3568-dwc3", .data = (ulong)_ops },
{ .compatible = "qcom,dwc3" },
{ .compatible = "fsl,imx8mp-dwc3", .data = (ulong)_ops },
{ .compatible = "fsl,imx8mq-dwc3" },
--
2.41.0
[PATCH v4 3/5] usb: dwc3-generic: Relax unsupported dr_mode check
When dr_mode is peripheral or otg and U-Boot has not been built with
DM_USB_GADGET support, booting such device may end up with:
dwc3_glue_bind_common: subnode name: usb@fcc0
Error binding driver 'dwc3-generic-wrapper': -6
Some drivers failed to bind
initcall sequence effbca08 failed at call 00a217c8 (err=-6)
### ERROR ### Please RESET the board ###
Instead fail gracfully with ENODEV to allow board continue booting.
dwc3_glue_bind_common: subnode name: usb@fcc0
dwc3_glue_bind_common: unsupported dr_mode 3
Also use CONFIG_IS_ENABLED(USB_HOST) and change switch to if statements
to improve readability of the code.
Fixes: 446e3a205b87 ("dwc3-generic: Handle the PHYs, the clocks and the reset
lines")
Signed-off-by: Jonas Karlman
---
v4:
- Add fixes tag
v3:
- Update debug message to include dr_mode (Marek Vasut)
v2:
- Change to use CONFIG_IS_ENABLED for USB_HOST
- Refactor switch to if statements (Marek Vasut)
drivers/usb/dwc3/dwc3-generic.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 4d5d500aefab..2331ac453132 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -226,8 +226,7 @@ U_BOOT_DRIVER(dwc3_generic_peripheral) = {
};
#endif
-#if defined(CONFIG_SPL_USB_HOST) || \
- !defined(CONFIG_SPL_BUILD) && defined(CONFIG_USB_HOST)
+#if CONFIG_IS_ENABLED(USB_HOST)
static int dwc3_generic_host_probe(struct udevice *dev)
{
struct xhci_hcor *hcor;
@@ -409,7 +408,7 @@ struct dwc3_glue_ops ti_ops = {
static int dwc3_glue_bind_common(struct udevice *parent, ofnode node)
{
const char *name = ofnode_get_name(node);
- const char *driver = NULL;
+ const char *driver;
enum usb_dr_mode dr_mode;
struct udevice *dev;
int ret;
@@ -421,27 +420,17 @@ static int dwc3_glue_bind_common(struct udevice *parent,
ofnode node)
if (!dr_mode)
dr_mode = usb_get_dr_mode(node);
- switch (dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
-#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+ if (CONFIG_IS_ENABLED(DM_USB_GADGET) &&
+ (dr_mode == USB_DR_MODE_PERIPHERAL || dr_mode == USB_DR_MODE_OTG)) {
debug("%s: dr_mode: OTG or Peripheral\n", __func__);
driver = "dwc3-generic-peripheral";
-#endif
- break;
-#if defined(CONFIG_SPL_USB_HOST) || !defined(CONFIG_SPL_BUILD)
- case USB_DR_MODE_HOST:
+ } else if (CONFIG_IS_ENABLED(USB_HOST) && dr_mode == USB_DR_MODE_HOST) {
debug("%s: dr_mode: HOST\n", __func__);
driver = "dwc3-generic-host";
- break;
-#endif
- default:
- debug("%s: unsupported dr_mode\n", __func__);
+ } else {
+ debug("%s: unsupported dr_mode %d\n", __func__, dr_mode);
return -ENODEV;
- };
-
- if (!driver)
- return -ENXIO;
+ }
ret = device_bind_driver_to_node(parent, driver, name,
node, );
--
2.41.0
[PATCH v4 1/5] Revert "arm: dts: rockchip: radxa-cm3-io, rock-3a: enable regulators for usb"
Remove regulator-boot-on prop from regulators now that the phy core has
support for phy-supply after the commit c57e0dcd9384 ("phy: add support
for phy-supply").
This reverts commit 7911f409ff20dce5995cc1b703a6e30c94022f6b.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v4:
- Rebase on u-boot-rockchip/master and v2 of the series
"rockchip: rk3568: Device Tree updates"
v3:
- No change
v2:
- No change
arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 4
arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 8
2 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
index a8c31fecafd8..c925439f71cd 100644
--- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
+++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
@@ -21,7 +21,3 @@
bootph-all;
status = "okay";
};
-
-_usb30 {
- regulator-boot-on;
-};
diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
index 68d5935348bb..a36a329f59c5 100644
--- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
@@ -66,11 +66,3 @@
bootph-all;
status = "okay";
};
-
-_usb_host {
- regulator-boot-on;
-};
-
-_usb_hub {
- regulator-boot-on;
-};
--
2.41.0
[PATCH v4 0/5] rockchip: rk3568: Use dwc3-generic driver
This series add support for rk3568 in dwc3-generic driver and change to use the dwc3-generic driver for rk3568 devices having usb enabled. After these changes it should be possible to support usb gadget on rk3568 with e.g.: # CONFIG_USB_FUNCTION_FASTBOOT is not set CONFIG_DM_USB_GADGET=y CONFIG_USB_GADGET=y Patch 1 reverts addition of now unnecessary regulator-boot-on props. Patch 2 improve support for childless glue/ctrl dt node. Patch 3 relax a hard error when usb gadget support is not enabled. Patch 4 add support for the glue/ctrl dt node used by rk3568. Patch 5 change rk3568 devices to use dwc3-generic driver. Changes in v4: - Rebase on u-boot-rockchip/master and v2 of the series "rockchip: rk3568: Device Tree updates" - Add fixes tag - Update nanopi-r5c-rk3568 and nanopi-r5s-rk3568 - Collect r-b tag Changes in v3: - Update debug message to include dr_mode (Marek Vasut) - Collect r-b tag Changes in v2: - Change to use CONFIG_IS_ENABLED for USB_HOST - Refactor switch to if statements (Marek Vasut) - Update commit message - Collect r-b tag This series is also available at [1] [1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-dwc3-generic-v4 Jonas Karlman (5): Revert "arm: dts: rockchip: radxa-cm3-io, rock-3a: enable regulators for usb" usb: dwc3-generic: Return early when there is no child node usb: dwc3-generic: Relax unsupported dr_mode check usb: dwc3-generic: Add rk3568 support rockchip: rk3568: Use dwc3-generic driver arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 4 -- arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 8 configs/nanopi-r5c-rk3568_defconfig | 3 +- configs/nanopi-r5s-rk3568_defconfig | 3 +- configs/radxa-cm3-io-rk3566_defconfig| 2 +- configs/rock-3a-rk3568_defconfig | 2 +- drivers/usb/dwc3/dwc3-generic.c | 50 +++- 7 files changed, 32 insertions(+), 40 deletions(-) -- 2.41.0
[PATCH v4 2/5] usb: dwc3-generic: Return early when there is no child node
The current error check for device_find_first_child is not working as
expected, the documentation for device_find_first_child mention:
@devp: Returns first child device, or NULL if none
Return: 0
Change to return early when there is no child node to avoid any possible
null pointer dereference.
Signed-off-by: Jonas Karlman
Reviewed-by: Marek Vasut
Reviewed-by: Kever Yang
---
v4:
- Collect r-b tag
v3:
- Collect r-b tag
v2:
- Update commit message
drivers/usb/dwc3/dwc3-generic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 35e4b36a695e..4d5d500aefab 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -558,9 +558,9 @@ int dwc3_glue_probe(struct udevice *dev)
return ret;
}
- ret = device_find_first_child(dev, );
- if (ret)
- return ret;
+ device_find_first_child(dev, );
+ if (!child)
+ return 0;
if (glue->clks.count == 0) {
ret = dwc3_glue_clk_init(child, glue);
--
2.41.0
Re: [PATCH RFC 1/3] tools: binman: Enable getting file from specific directory
Hi Simon
On 28/07/23 08:05, Simon Glass wrote:
Hi Neha,
On Thu, 27 Jul 2023 at 06:12, Neha Malcom Francis wrote:
While we have the option of using '-a to grab a file from a
specific directory, this is problematic when searching for a filename
shared by multiple files across directories. An example would be FDT
generated in SPL_BUILD vs. non-SPL_BUILD that is present in spl/dts and
arch/arm/dts respectively with the same DTB name. Maybe running binman
Do you mean spl/arch/arm/dts and arch/arch/dts ?
No I mean spl/dts, that's what is generated.
twice could also solve this issue, but this seems like a valid
implementation.
Signed-off-by: Neha Malcom Francis
---
tools/binman/etype/blob.py | 12 ++--
tools/binman/etype/fit.py | 15 ++-
tools/u_boot_pylib/tools.py | 7 ++-
3 files changed, 30 insertions(+), 4 deletions(-)
I don't fully understand this, but perhaps it would make sense to give
the indirs names, like:
binman -I spl:path/to/spl -I name2:path/to/somewhere-else
Hm yes that could be something, I'll try working on that.
then you could use the names below, instead of the paths. It provide
at least a little separation.
Perhaps if you listed out the two dirs and the files they contain,
that would help me understand better.
Yes sure:
arch/arm/dts:
k3-j7200-common-proc-board.dtb k3-j721e-r5-common-proc-board.dtb
k3-j7200-r5-common-proc-board.dtb k3-j721e-r5-sk.dtb
k3-j721e-common-proc-board.dtb k3-j721e-sk.dtb
spl/dts:
built-in.o k3-j721e-common-proc-board.dtb k3-j721e-sk.dtb
diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
index 064fae5036..eccf6f87ac 100644
--- a/tools/binman/etype/blob.py
+++ b/tools/binman/etype/blob.py
@@ -19,6 +19,8 @@ class Entry_blob(Entry):
Properties / Entry arguments:
- filename: Filename of file to read into entry
+- indir-path: Specific directory to fetch file from, if not provided
+default indir paths will be searched
- compress: Compression algorithm to use:
none: No compression
lz4: Use lz4 compression (via 'lz4' command-line utility)
@@ -35,6 +37,7 @@ class Entry_blob(Entry):
super().__init__(section, etype, node,
auto_write_symbols=auto_write_symbols)
self._filename = fdt_util.GetString(self._node, 'filename',
self.etype)
+self._indir_path = fdt_util.GetString(self._node, 'indir-path', None)
self.elf_fname = fdt_util.GetString(self._node, 'elf-filename',
self.elf_fname)
self.elf_base_sym = fdt_util.GetString(self._node, 'elf-base-sym')
@@ -44,8 +47,13 @@ class Entry_blob(Entry):
def ObtainContents(self, fake_size=0):
self._filename = self.GetDefaultFilename()
-self._pathname = tools.get_input_filename(self._filename,
-self.external and (self.optional or
self.section.GetAllowMissing()))
+if self._indir_path:
+self._pathname = tools.get_input_filename(self._filename,
+self.external and (self.optional or
self.section.GetAllowMissing()),
+self._indir_path)
I think this might as well just read the file, rather than calling
tools.get_input_filename()
+else:
+self._pathname = tools.get_input_filename(self._filename,
+self.external and (self.optional or
self.section.GetAllowMissing()))
# Allow the file to be missing
if not self._pathname:
self._pathname, faked = self.check_fake_fname(self._filename,
diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
index ef4d066757..46db816370 100644
--- a/tools/binman/etype/fit.py
+++ b/tools/binman/etype/fit.py
@@ -87,6 +87,15 @@ class Entry_fit(Entry_section):
fit,fdt-list-val = "dtb1", "dtb2";
+fit,fdt-indir
+Indicates the specific directory (if any) to be used to pick up
fdts
+generated in the gen-fdt-nodes property. For example, picking fdt
from
+spl/dts instead of arch/arm/dts. This is equivalent to '-a
spl/dts' but
+helps when multiple directories contain same named fdt to choose a
+specific one
+
+fit,fdt-indir = "spl/dts"
Should this be a named indir? Otherwise you have to use the actual
dirs and that could be come quite brittle when things change.
Yes let me try working with a named indir
+
Substitutions
~
@@ -362,6 +371,7 @@ class Entry_fit(Entry_section):
if pname.startswith('fit,'):
self._fit_props[pname] = prop
self._fit_list_prop = self._fit_props.get('fit,fdt-list')
+self._fit_indir = fdt_util.GetString(self._node, 'fit,fdt-indir', None)
if self._fit_list_prop:
fdts, = self.GetEntryArgsOrProps(
[EntryArg(self._fit_list_prop.value, str)])
[PATCH] Remove unused parameters
Remove unused parameters from function arch_env_get_location
Signed-off-by: Yuepeng Xing
---
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
arch/arm/mach-imx/imx8m/soc.c | 2 +-
board/theobroma-systems/puma_rk3399/puma-rk3399.c | 2 +-
env/env.c | 4 ++--
include/env_internal.h| 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index c11341a1d3..321900b6d5 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -818,7 +818,7 @@ int mmc_get_env_dev(void)
}
#endif
-enum env_location arch_env_get_location(enum env_operation op, int prio)
+enum env_location arch_env_get_location(int prio)
{
enum boot_src src = get_boot_src();
enum env_location env_loc = ENVL_NOWHERE;
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index a4863281e3..1fe7011f07 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1539,7 +1539,7 @@ void do_error(struct pt_regs *pt_regs)
#endif
#if defined(CONFIG_IMX8MN) || defined(CONFIG_IMX8MP)
-enum env_location arch_env_get_location(enum env_operation op, int prio)
+enum env_location arch_env_get_location(int prio)
{
enum boot_device dev = get_boot_device();
diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 97f398bd75..3b3f1b0e9f 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -140,7 +140,7 @@ int mmc_get_env_dev(void)
#error Please enable CONFIG_ENV_IS_NOWHERE
#endif
-enum env_location arch_env_get_location(enum env_operation op, int prio)
+enum env_location arch_env_get_location(int prio)
{
const char *boot_device =
ofnode_read_chosen_string("u-boot,spl-boot-device");
diff --git a/env/env.c b/env/env.c
index 69848fb060..a8a94d4e2a 100644
--- a/env/env.c
+++ b/env/env.c
@@ -128,7 +128,7 @@ static void env_set_inited(enum env_location location)
* Returns:
* an enum env_location value on success, a negative error code otherwise
*/
-__weak enum env_location arch_env_get_location(enum env_operation op, int prio)
+__weak enum env_location arch_env_get_location(int prio)
{
if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
@@ -156,7 +156,7 @@ __weak enum env_location arch_env_get_location(enum
env_operation op, int prio)
*/
__weak enum env_location env_get_location(enum env_operation op, int prio)
{
- return arch_env_get_location(op, prio);
+ return arch_env_get_location(prio);
}
/**
diff --git a/include/env_internal.h b/include/env_internal.h
index f30fd6159d..4aaa40d17c 100644
--- a/include/env_internal.h
+++ b/include/env_internal.h
@@ -246,7 +246,7 @@ const char *env_ext4_get_dev_part(void);
*highest priority
* Return: an enum env_location value on success, or -ve error code.
*/
-enum env_location arch_env_get_location(enum env_operation op, int prio);
+enum env_location arch_env_get_location(int prio);
/**
* env_get_location()- Provide the best location for the U-Boot environment
--
2.31.1.windows.1
[PATCH] Remove unused parameters
Removes unused function arguments from the riscv_cpu_setup function
Signed-off-by: Shenlin Liang
---
arch/riscv/cpu/cpu.c | 2 +-
arch/riscv/include/asm/system.h | 2 +-
arch/riscv/lib/spl.c | 2 +-
board/starfive/visionfive2/spl.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index ecfb1fb08c..728cdfe9c9 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -91,7 +91,7 @@ static void dummy_pending_ipi_clear(ulong hart, ulong arg0,
ulong arg1)
}
#endif
-int riscv_cpu_setup(void *ctx, struct event *event)
+int riscv_cpu_setup(void)
{
int ret;
diff --git a/arch/riscv/include/asm/system.h b/arch/riscv/include/asm/system.h
index ffa7649f3f..87a804bfd5 100644
--- a/arch/riscv/include/asm/system.h
+++ b/arch/riscv/include/asm/system.h
@@ -26,6 +26,6 @@ struct event;
} while (0)
/* Hook to set up the CPU (called from SPL too) */
-int riscv_cpu_setup(void *ctx, struct event *event);
+int riscv_cpu_setup(void);
#endif /* __ASM_RISCV_SYSTEM_H */
diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
index f4d3b67e5d..9b242ed821 100644
--- a/arch/riscv/lib/spl.c
+++ b/arch/riscv/lib/spl.c
@@ -28,7 +28,7 @@ __weak void board_init_f(ulong dummy)
if (ret)
panic("spl_early_init() failed: %d\n", ret);
- riscv_cpu_setup(NULL, NULL);
+ riscv_cpu_setup();
preloader_console_init();
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
index 7acd3995aa..ad5f71a201 100644
--- a/board/starfive/visionfive2/spl.c
+++ b/board/starfive/visionfive2/spl.c
@@ -218,7 +218,7 @@ void board_init_f(ulong dummy)
if (ret)
panic("spl_early_init() failed: %d\n", ret);
- riscv_cpu_setup(NULL, NULL);
+ riscv_cpu_setup();
preloader_console_init();
/* Set the parent clock of cpu_root clock to pll0,
--
2.31.1.windows.1
[PATCH] Remove unused functions
Function board_switch_core_volt has not been used since it was
defined
Signed-off-by: Shenlin Liang
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 359cbc0430..aa6183c87a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -575,11 +575,6 @@ int get_core_volt_from_fuse(void)
return vdd;
}
-__weak int board_switch_core_volt(u32 vdd)
-{
- return 0;
-}
-
static int setup_core_volt(u32 vdd)
{
return board_setup_core_volt(vdd);
--
2.31.1.windows.1
Re: Pull request: u-boot-rockchip-20230728
Hi Kever, On Fri, Jul 28, 2023 at 5:04 PM Kever Yang wrote: > > Hi Tom, > > Please pull the updates for rockchip platform: > - Enable pcie support for rk3568; > - Add boards: > rk3399: Radxa ROCK 4SE; > rk3328: Orange Pi R1 Plus, Orange Pi R1 Plus LTS > rk3568: FriendlyARM NanoPi R5S/R5C, Hardkernel ODROID-M1 > rk3588: Edgeble Neu6B > - support OP-TEE with binman; > - support Winbond SPI flash; > - rk3588 usbdp phy support; > - dts and config updates for different boards; > > > CI: > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/17104 > > Thanks, > - Kever > > The following changes since commit c98c401dfb485b39c7453a4147b17cd4b8d10c67: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-07-27 > 10:35:36 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20230728 > > for you to fetch changes up to 94da929b933668c4b9ece7d56a2a2bb5543198c9: > > board: rockchip: Add Hardkernel ODROID-M1 (2023-07-28 18:45:03 +0800) > > > Alex Bee (4): > rockchip: Support OP-TEE for ARM in FIT images created by binman > configs: evb-rk3229: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN > rockchip: RK322x: Select SPL_OPTEE_IMAGE > rockchip: evb_rk3229: Update/fix README > > Alper Nebi Yasak (1): > rockchip: veyron: Enable Winbond SPI flash > > Chris Morgan (7): > rockchip: board: Update Odroid Go2 to Support Additional Revisions > board: rockchip: Correct i2c2 pinctrl for RGxx3 > board: rockchip: add DSI and DSI-DPHY for Anbernic RGxx3 > board: rockchip: Add support for RG353PS to RGxx3 > board: rockchip: Add panel auto-detection for Anbernic RGxx3 > configs: Update anbernic-rgxx3_defconfig for panel detection > doc: anbernic: Update RGxx3 Docs for panel detection > > Christopher Obbard (3): > configs: rockchip: rock5b-rk3588: Enable CONFIG_PCI_INIT_R > arm: rockchip: sync ROCK Pi 4 SoCs from Linux > arm: rockchip: Add Radxa ROCK 4SE > > Eugen Hristev (4): > configs: rock5b-rk3588: add rtl8169 driver > ARM: dts: rockchip: rk3588: sync with Linux > ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB3 support > configs: rock5b-rk3588: enable USB 3.0 controller, command, gadget > > Frank Wang (1): > phy: rockchip: add usbdp combo phy driver > > Jagan Teki (5): > arch: rockchip: rk3588: Fix missing suffix 'A' for Edgeble Neu6A > arm64: dts: rockchip: Add Rockchip RK3588J > ARM: dts: rockchip: Add rk3588j-u-boot.dtsi > arm64: dts: rockchip: Add rk3588 Edgeble Neu6B > board: rockchip: Add Edgeble Neural Compute Module 6B > > Johan Jonker (1): > mtd: nand: raw: rockchip_nfc: copy hwecc PA data to oob_poi buffer > > Jon Lin (1): > pci: pcie_dw_rockchip: Disable unused BARs of the root complex > > Jonas Karlman (12): > rockchip: rk3568: Fix alloc space exhausted in SPL > core: read: add dev_read_addr_size_index_ptr function > pci: pcie_dw_rockchip: Get config region from reg prop > pci: pcie_dw_rockchip: Use regulator_set_enable_if_allowed > pci: pcie_dw_rockchip: Speed up link probe > regulator: fixed: Add support for gpios prop > rockchip: clk: clk_rk3568: Add CLK_PCIEPHY2_REF support > rockchip: rk3568-rock-3a: Enable PCIe and NVMe support > rockchip: rk356x: Update PCIe config, IO and memory regions > ata: dwc_ahci: Fix support for other platforms > cmd: ini: Fix build warning > board: rockchip: Add Hardkernel ODROID-M1 > > Joseph Chen (1): > ARM: dts: rockchip: rk3588: add support for USB 3.0 devices > > Ondrej Jirman (1): > video: rockchip: Add support for RK3399 to dw-mipi-dsi bridge > > Paul Kocialkowski (1): > rockchip: px30: Define variables for compressed image support > > Quentin Schulz (2): > rockchip: rk3399: pass platform parameter to TF-A by default for new > RK3399 boards > rockchip: puma: pass platform parameter to TF-A > > Tianling Shen (4): > rockchip: rk3328: Add support for Orange Pi R1 Plus > rockchip: rk3328: Add support for Orange Pi R1 Plus LTS > rockchip: rk3568: Add support for FriendlyARM NanoPi R5S > rockchip: rk3568: Add support for FriendlyARM NanoPi R5C Look like this PR missed USB fixes (RK3328), Will it be a separate PR soon? Thanks, Jagan.
[PATCH v2 2/2] rockchip: rk3588-rock-5b: Fix SPI Flash alias
The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
NOR flash") enabled SPI flash support by adding a spi0 alias.
Correct this by adding spi0-spi5 aliases in rk3588s-u-boot.dtsi and
SF_DEFAULT_BUS=5 and SPL_DM_SEQ_ALIAS=y in defconfig. Also enabled
support for parsing and auto discovery of parameters, SFDP.
Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash")
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- Rebase on u-boot-rockchip/master
- Collect r-b tag
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 -
arch/arm/dts/rk3588s-u-boot.dtsi| 9 +
configs/rock5b-rk3588_defconfig | 3 +++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 5a3292699640..549b242be0a0 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -12,7 +12,6 @@
/ {
aliases {
mmc1 =
- spi0 =
};
chosen {
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index acb1cfe20063..489c5edd6249 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -7,6 +7,15 @@
#include
/ {
+ aliases {
+ spi0 =
+ spi1 =
+ spi2 =
+ spi3 =
+ spi4 =
+ spi5 =
+ };
+
dmc {
compatible = "rockchip,rk3588-dmc";
bootph-all;
diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 3976a6c0f05c..3fa65cbf9b07 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -60,6 +60,7 @@ CONFIG_CMD_REGULATOR=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
assigned-clock-rates assigned-clock-parents"
+CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_SPL_REGMAP=y
CONFIG_SPL_SYSCON=y
CONFIG_SPL_CLK=y
@@ -73,6 +74,8 @@ CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=5
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_MACRONIX=y
CONFIG_SPI_FLASH_XTX=y
CONFIG_ETH_DESIGNWARE=y
--
2.41.0
[PATCH v2 1/2] rockchip: rk3568-rock-3a: Fix SPI Flash alias
The commit 64f79f88a751 ("rockchip: rk3568-rock-3a: Enable boot from SPI
NOR flash") enabled SPI flash support by overriding the spi0 alias.
Correct this by adding a new spi4 alias in rk356x-u-boot.dtsi and
SF_DEFAULT_BUS=4 and SPL_DM_SEQ_ALIAS=y in defconfig. Also enabled
support for parsing and auto discovery of parameters, SFDP.
Fixes: 64f79f88a751 ("rockchip: rk3568-rock-3a: Enable boot from SPI NOR flash")
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- Rebase on u-boot-rockchip/master
- Collect r-b tag
arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 4
arch/arm/dts/rk356x-u-boot.dtsi | 1 +
configs/rock-3a-rk3568_defconfig| 3 +++
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
index e4f1637500f4..68d5935348bb 100644
--- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
@@ -7,10 +7,6 @@
#include "rk356x-u-boot.dtsi"
/ {
- aliases {
- spi0 =
- };
-
chosen {
stdout-path =
};
diff --git a/arch/arm/dts/rk356x-u-boot.dtsi b/arch/arm/dts/rk356x-u-boot.dtsi
index 5644f78ec774..d21b18205220 100644
--- a/arch/arm/dts/rk356x-u-boot.dtsi
+++ b/arch/arm/dts/rk356x-u-boot.dtsi
@@ -9,6 +9,7 @@
aliases {
mmc0 =
mmc1 =
+ spi4 =
};
chosen {
diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig
index 8e3fe0a25e1d..42fd47eb57be 100644
--- a/configs/rock-3a-rk3568_defconfig
+++ b/configs/rock-3a-rk3568_defconfig
@@ -57,6 +57,7 @@ CONFIG_CMD_REGULATOR=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
assigned-clock-rates assigned-clock-parents"
+CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_SPL_REGMAP=y
CONFIG_SPL_SYSCON=y
CONFIG_SCSI_AHCI=y
@@ -71,6 +72,8 @@ CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=4
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_MACRONIX=y
CONFIG_SPI_FLASH_XTX=y
CONFIG_ETH_DESIGNWARE=y
--
2.41.0
[PATCH v2 0/2] rockchip: rk35xx: Fix SPI Flash alias
The series "rockchip: rk35xx: Update defconfigs and enable boot from SPI NOR flash" enabled SPI flash boot support on ROCK 3A and ROCK 5B using a spi0 alias. This spi0 alias should be used for the spi0 device tree node and not the sfc node. Correct this by adding spi4 and spi5 aliases to -u-boot.dtsi and use SF_DEFAULT_BUS option to define the SPI flash bus. Also enabled support for parsing and auto discovery of parameters, SFDP, for the affected boards. Changes in v2: - Rebase on u-boot-rockchip/master - Collect r-b tags Jonas Karlman (2): rockchip: rk3568-rock-3a: Fix SPI Flash alias rockchip: rk3588-rock-5b: Fix SPI Flash alias arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 4 arch/arm/dts/rk356x-u-boot.dtsi | 1 + arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-u-boot.dtsi| 9 + configs/rock-3a-rk3568_defconfig| 3 +++ configs/rock5b-rk3588_defconfig | 3 +++ 6 files changed, 16 insertions(+), 5 deletions(-) -- 2.41.0
[PATCH v2 4/4] rockchip: rk356x-u-boot: Use relaxed u-boot,spl-boot-order
BootRom will try to load TPL+SPL from media in the following order:
- SPI NOR Flash
- SPI NAND Flash
- NAND Flash
- eMMC
- SDMMC
SPL will try to load FIT from media in the order defined in the device
tree u-boot,spl-boot-order property.
Change the default order to load FIT from to:
- same media as TPL+SPL
- SDMMC
- eMMC
Boards with strict load order requirements should override the
u-boot,spl-boot-order property in the board specific u-boot.dtsi.
Fixes: 42f67fb51cb4 ("rockchip: rk3568: Fix boot device detection")
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- No change
arch/arm/dts/rk356x-u-boot.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk356x-u-boot.dtsi b/arch/arm/dts/rk356x-u-boot.dtsi
index 89c0d830b632..5644f78ec774 100644
--- a/arch/arm/dts/rk356x-u-boot.dtsi
+++ b/arch/arm/dts/rk356x-u-boot.dtsi
@@ -12,7 +12,7 @@
};
chosen {
- u-boot,spl-boot-order = "same-as-spl", ,
+ u-boot,spl-boot-order = "same-as-spl", ,
};
dmc: dmc {
--
2.41.0
[PATCH v2 3/4] rockchip: rk356x-u-boot: Add bootph-all to common pinctrl nodes
Add bootph-all prop to common pinctrl nodes for eMMC, FSPI, SD-card and
UART2 that are typically used by multiple boards. Unreferenced nodes are
removed from the SPL device tree during a normal build.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- Rebase on u-boot-rockchip/master
- Collect r-b tag
arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 56 -
arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 54 -
arch/arm/dts/rk356x-u-boot.dtsi | 64
3 files changed, 64 insertions(+), 110 deletions(-)
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
index f91740c1c0c8..a8c31fecafd8 100644
--- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
+++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
@@ -11,67 +11,11 @@
};
};
-_bus8 {
- bootph-all;
-};
-
-_clk {
- bootph-all;
-};
-
-_cmd {
- bootph-all;
-};
-
-_datastrobe {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
-_pull_none {
- bootph-all;
-};
-
-_pull_up_drv_level_2 {
- bootph-all;
-};
-
-_pull_up {
- bootph-all;
-};
-
-_bus4 {
- bootph-all;
-};
-
-_clk {
- bootph-all;
-};
-
-_cmd {
- bootph-all;
-};
-
-_det {
- bootph-all;
-};
-
-_pwren {
- bootph-all;
-};
-
{
cap-mmc-highspeed;
mmc-ddr-1_8v;
};
-_xfer {
- bootph-all;
-};
-
{
clock-frequency = <2400>;
bootph-all;
diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
index 9ee7b494ee25..e4f1637500f4 100644
--- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
@@ -16,26 +16,6 @@
};
};
-_bus8 {
- bootph-all;
-};
-
-_clk {
- bootph-all;
-};
-
-_cmd {
- bootph-all;
-};
-
-_datastrobe {
- bootph-all;
-};
-
-_pins {
- bootph-all;
-};
-
{
pinctrl-0 = <_pins _reset_h>;
};
@@ -45,8 +25,6 @@
};
{
- bootph-all;
-
pcie {
pcie3x2_reset_h: pcie3x2-reset-h {
rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO _pull_none>;
@@ -54,34 +32,6 @@
};
};
-_pull_none {
- bootph-all;
-};
-
-_pull_up_drv_level_2 {
- bootph-all;
-};
-
-_pull_up {
- bootph-all;
-};
-
-_bus4 {
- bootph-all;
-};
-
-_clk {
- bootph-all;
-};
-
-_cmd {
- bootph-all;
-};
-
-_det {
- bootph-all;
-};
-
{
cap-mmc-highspeed;
mmc-ddr-1_8v;
@@ -115,10 +65,6 @@
status = "disabled";
};
-_xfer {
- bootph-all;
-};
-
{
clock-frequency = <2400>;
bootph-all;
diff --git a/arch/arm/dts/rk356x-u-boot.dtsi b/arch/arm/dts/rk356x-u-boot.dtsi
index c340c2bba6ff..89c0d830b632 100644
--- a/arch/arm/dts/rk356x-u-boot.dtsi
+++ b/arch/arm/dts/rk356x-u-boot.dtsi
@@ -59,6 +59,70 @@
status = "okay";
};
+ {
+ bootph-all;
+};
+
+_pull_none {
+ bootph-all;
+};
+
+_pull_up_drv_level_2 {
+ bootph-all;
+};
+
+_pull_up {
+ bootph-all;
+};
+
+_bus8 {
+ bootph-all;
+};
+
+_clk {
+ bootph-all;
+};
+
+_cmd {
+ bootph-all;
+};
+
+_datastrobe {
+ bootph-all;
+};
+
+_rstnout {
+ bootph-all;
+};
+
+_pins {
+ bootph-all;
+};
+
+_bus4 {
+ bootph-all;
+};
+
+_clk {
+ bootph-all;
+};
+
+_cmd {
+ bootph-all;
+};
+
+_det {
+ bootph-all;
+};
+
+_pwren {
+ bootph-all;
+};
+
+_xfer {
+ bootph-all;
+};
+
{
bootph-pre-ram;
status = "okay";
--
2.41.0
[PATCH v2 2/4] rockchip: rk3566-radxa-cm3-io: Sync dts from linux v6.4
Sync rk3566-radxa-cm3-io.dts from linux v6.4.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- No change
arch/arm/dts/rk3566-radxa-cm3-io.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io.dts
b/arch/arm/dts/rk3566-radxa-cm3-io.dts
index d89d5263cb5e..5e4236af4fcb 100644
--- a/arch/arm/dts/rk3566-radxa-cm3-io.dts
+++ b/arch/arm/dts/rk3566-radxa-cm3-io.dts
@@ -254,6 +254,14 @@
status = "okay";
};
+_otg {
+ status = "okay";
+};
+
+_host0_xhci {
+ status = "okay";
+};
+
{
assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
--
2.41.0
[PATCH v2 1/4] rockchip: rk356x: Sync dtsi from linux v6.4
Sync rk356x.dtsi from linux v6.4.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- No change
arch/arm/dts/rk3568-pinctrl.dtsi | 94
arch/arm/dts/rk356x.dtsi | 14 +++--
2 files changed, 102 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/rk3568-pinctrl.dtsi b/arch/arm/dts/rk3568-pinctrl.dtsi
index 8f90c66dd9e9..0a979bfb63d9 100644
--- a/arch/arm/dts/rk3568-pinctrl.dtsi
+++ b/arch/arm/dts/rk3568-pinctrl.dtsi
@@ -3117,4 +3117,98 @@
<0 RK_PA1 0 _pull_none>;
};
};
+
+ lcdc {
+ /omit-if-no-ref/
+ lcdc_clock: lcdc-clock {
+ rockchip,pins =
+ /* lcdc_clk */
+ <3 RK_PA0 1 _pull_none>,
+ /* lcdc_den */
+ <3 RK_PC3 1 _pull_none>,
+ /* lcdc_hsync */
+ <3 RK_PC1 1 _pull_none>,
+ /* lcdc_vsync */
+ <3 RK_PC2 1 _pull_none>;
+ };
+
+ /omit-if-no-ref/
+ lcdc_data16: lcdc-data16 {
+ rockchip,pins =
+ /* lcdc_d3 */
+ <2 RK_PD3 1 _pull_none>,
+ /* lcdc_d4 */
+ <2 RK_PD4 1 _pull_none>,
+ /* lcdc_d5 */
+ <2 RK_PD5 1 _pull_none>,
+ /* lcdc_d6 */
+ <2 RK_PD6 1 _pull_none>,
+ /* lcdc_d7 */
+ <2 RK_PD7 1 _pull_none>,
+ /* lcdc_d10 */
+ <3 RK_PA3 1 _pull_none>,
+ /* lcdc_d11 */
+ <3 RK_PA4 1 _pull_none>,
+ /* lcdc_d12 */
+ <3 RK_PA5 1 _pull_none>,
+ /* lcdc_d13 */
+ <3 RK_PA6 1 _pull_none>,
+ /* lcdc_d14 */
+ <3 RK_PA7 1 _pull_none>,
+ /* lcdc_d15 */
+ <3 RK_PB0 1 _pull_none>,
+ /* lcdc_d19 */
+ <3 RK_PB4 1 _pull_none>,
+ /* lcdc_d20 */
+ <3 RK_PB5 1 _pull_none>,
+ /* lcdc_d21 */
+ <3 RK_PB6 1 _pull_none>,
+ /* lcdc_d22 */
+ <3 RK_PB7 1 _pull_none>,
+ /* lcdc_d23 */
+ <3 RK_PC0 1 _pull_none>;
+ };
+
+ /omit-if-no-ref/
+ lcdc_data18: lcdc-data18 {
+ rockchip,pins =
+ /* lcdc_d2 */
+ <2 RK_PD2 1 _pull_none>,
+ /* lcdc_d3 */
+ <2 RK_PD3 1 _pull_none>,
+ /* lcdc_d4 */
+ <2 RK_PD4 1 _pull_none>,
+ /* lcdc_d5 */
+ <2 RK_PD5 1 _pull_none>,
+ /* lcdc_d6 */
+ <2 RK_PD6 1 _pull_none>,
+ /* lcdc_d7 */
+ <2 RK_PD7 1 _pull_none>,
+ /* lcdc_d10 */
+ <3 RK_PA3 1 _pull_none>,
+ /* lcdc_d11 */
+ <3 RK_PA4 1 _pull_none>,
+ /* lcdc_d12 */
+ <3 RK_PA5 1 _pull_none>,
+ /* lcdc_d13 */
+ <3 RK_PA6 1 _pull_none>,
+ /* lcdc_d14 */
+ <3 RK_PA7 1 _pull_none>,
+ /* lcdc_d15 */
+ <3 RK_PB0 1 _pull_none>,
+ /* lcdc_d18 */
+ <3 RK_PB3 1 _pull_none>,
+ /* lcdc_d19 */
+ <3 RK_PB4 1 _pull_none>,
+ /* lcdc_d20 */
+ <3 RK_PB5 1 _pull_none>,
+ /* lcdc_d21 */
+ <3 RK_PB6 1 _pull_none>,
+ /* lcdc_d22 */
+ <3 RK_PB7 1 _pull_none>,
+ /* lcdc_d23 */
+ <3 RK_PC0 1 _pull_none>;
+ };
+ };
+
};
diff --git
[PATCH v2 0/4] rockchip: rk3568: Device Tree updates
This series sync rk356x.dtsi and rk3566-radxa-cm3-io.dts from linux v6.4, add bootph-all to common pinctrl nodes and relax FIT load order in rk356x-u-boot.dtsi. Patch 1-2 sync rk356x device tree from linux v6.4. Patch 3 move common pinctrl nodes to rk356x-u-boot.dtsi. Patch 4 change to try and load FIT from SD-card before eMMC when loading FIT from TPL+SPL media fails. Changes in v2: - Rebase on u-boot-rockchip/master - Collect r-b tags Jonas Karlman (4): rockchip: rk356x: Sync dtsi from linux v6.4 rockchip: rk3566-radxa-cm3-io: Sync dts from linux v6.4 rockchip: rk356x-u-boot: Add bootph-all to common pinctrl nodes rockchip: rk356x-u-boot: Use relaxed u-boot,spl-boot-order arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 56 arch/arm/dts/rk3566-radxa-cm3-io.dts | 8 ++ arch/arm/dts/rk3568-pinctrl.dtsi | 94 arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 54 --- arch/arm/dts/rk356x-u-boot.dtsi | 66 +- arch/arm/dts/rk356x.dtsi | 14 +-- 6 files changed, 175 insertions(+), 117 deletions(-) -- 2.41.0
Re: [PATCH] tpm: Add TPM2_GetTestResult command support
Hi Julia,
Apologies for the late response, I was on vacation.
On Mon, 3 Jul 2023 at 16:03, Julia Daxenberger
wrote:
>
> Add TPM2_GetTestResult command support and change the command file and the
> help accordingly. Add Python tests and sandbox driver functionality.
>
> The TPM2_GetTestResult command is performed after the TPM2_SelfTest command
> and returns manufacturer-specific information regarding the results of the
> self-test and an indication of the test status.
What the code does is quite obvious, can you please elaborate on why
we need this applied?
[...]
> +#define TEST_RESULT_DATA_BUFFER_SIZE 256
> +
> static int do_tpm2_startup(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
> {
> @@ -356,6 +359,57 @@ static int do_tpm_pcr_setauthvalue(struct cmd_tbl
> *cmdtp, int flag,
> key, key_sz));
> }
>
> +static int do_tpm2_get_test_result(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct udevice *dev;
> + int ret;
> + u8 data[TEST_RESULT_DATA_BUFFER_SIZE];
> + size_t data_len = TEST_RESULT_DATA_BUFFER_SIZE;
= sizeof(data)
> + u32 test_result;
> + u32 rc;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + if (argc != 1)
> + return CMD_RET_USAGE;
Can you move this one above the get_tpm?
> +
> + rc = tpm2_get_test_result(dev, data, _len, _result);
> + if (rc)
> + goto out;
> +
> + printf("Test Result:\n\t0x%08X", test_result);
> + switch (test_result) {
> + case 0x:
We have enum tpm2_return_codes. Please add the missing cases there
and use that instead of magic values
> + printf("\tTPM2_RC_SUCCESS\n");
> + break;
> + case 0x0101:
> + printf("\tTPM2_RC_FAILURE\n");
> + break;
> + case 0x0153:
> + printf("\tTPM2_RC_NEEDS_TEST\n");
> + break;
> + case 0x090A:
> + printf("\tTPM2_RC_TESTING\n");
> + break;
> + }
> +
> + if (!data_len) {
> + printf("No Test Result Data available\n");
> + goto out;
> + }
> +
> + printf("Test Result Data of Self Test:\n\t0x");
> + for (int i = 0; i < data_len; i++)
> + printf("%02X", data[i]);
> + printf("\n");
> +
> +out:
> + return report_return_code(rc);
> +}
> +
> static struct cmd_tbl tpm2_commands[] = {
> U_BOOT_CMD_MKENT(device, 0, 1, do_tpm_device, "", ""),
> U_BOOT_CMD_MKENT(info, 0, 1, do_tpm_info, "", ""),
> @@ -374,6 +428,8 @@ static struct cmd_tbl tpm2_commands[] = {
> do_tpm_pcr_setauthpolicy, "", ""),
> U_BOOT_CMD_MKENT(pcr_setauthvalue, 0, 1,
> do_tpm_pcr_setauthvalue, "", ""),
> + U_BOOT_CMD_MKENT(get_test_result, 0, 1,
> +do_tpm2_get_test_result, "", ""),
> };
>
> struct cmd_tbl *get_tpm2_commands(unsigned int *size)
> @@ -447,4 +503,8 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
> TPMv2.x command",
> ": index of the PCR\n"
> ": secret to protect the access of PCR #\n"
> ": optional password of the PLATFORM hierarchy\n"
> +"get_test_result\n"
> +"Show manufacturer-specific information regarding the results of a\n"
> +"self-test and an indication of the test status.\n"
> +
> );
> diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
> index e4004cfcca..17979cd33a 100644
> --- a/drivers/tpm/tpm2_tis_sandbox.c
> +++ b/drivers/tpm/tpm2_tis_sandbox.c
> @@ -2,6 +2,7 @@
> /*
> * Copyright (c) 2018, Bootlin
> * Author: Miquel Raynal
> + * Copyright (C) 2023 Infineon Technologies AG
> */
>
> #include
> @@ -231,6 +232,7 @@ static int sandbox_tpm2_check_session(struct udevice
> *dev, u32 command, u16 tag,
> case TPM2_CC_SELF_TEST:
> case TPM2_CC_GET_CAPABILITY:
> case TPM2_CC_PCR_READ:
> + case TPM2_CC_GET_TEST_RESULT:
> if (tag != TPM2_ST_NO_SESSIONS) {
> printf("No session required for command 0x%x\n",
>command);
> @@ -364,6 +366,13 @@ static int sandbox_tpm2_check_readyness(struct udevice
> *dev, int command)
> if (!tpm->startup_done)
> return TPM2_RC_INITIALIZE;
>
> + break;
> + case TPM2_CC_GET_TEST_RESULT:
> + if (!tpm->init_done || !tpm->startup_done)
> + return TPM2_RC_INITIALIZE;
> + if (!tpm->tests_done)
> + return TPM2_RC_NEEDS_TEST;
> +
> break;
> default:
> /* Skip this, since the startup may have happened in SPL
> @@ -458,7 +467,7 @@ static int sandbox_tpm2_xfer(struct udevice *dev,
