[PATCH v2 0/5] Add support for USB DFU boot on AM62Px
Hello,
This series add support for USB DFU boot on TI's AM62Px SoC which has two instances of USB Controllers, of which the USB0 instance of USB which is a DWC3 USB Controller is used for USB DFU Boot: ROM => tiboot3.bin => tispl.bin => u-boot.img
v1 of this series is at: https://patchwork.ozlabs.org/project/uboot/cover/20241217131658.2920799-1-s-... Changes since v1: - Dropped the first patch of the v1 series since its equivalent has been posted by Jonathan Humphreys j-humphreys@ti.com at: https://patchwork.ozlabs.org/project/uboot/patch/20241217204835.3312765-1-j-... - Based on the feedback from Mattijs Korpershoek on the second patch of the v1 series, the patches in this series have been updated. More details regarding the changes have been described below the tearline of the respective patches. - Collected Reviewed-by tags.
NOTE: I did *not* collect the Tested-by tag since this series has significant changes when compared to the v1 series. Though I have tested this series before posting it, I intend to get a Tested-by on this v2 series itself after it gets tested.
Series is based on commit 3b3c7280b82 smbios: address build warning of the next branch of U-Boot.
NOTE: Series *depends* on: https://patchwork.ozlabs.org/project/uboot/patch/20241217204835.3312765-1-j-... since the corresponding patch has been dropped in this series when compared with the v1 of this series.
The USB DFU config fragments for AM62x are to be re-used for enabling USB DFU boot on AM62Px as follows: R5 => am62px_evm_r5_defconfig + am62x_r5_usbdfu.config A53 => am62px_evm_a53_defconfig + am62x_a53_usbdfu.config
Series has been tested on AM62P5-SK. Logs validating USB DFU boot on AM62P5-SK with this series: https://gist.github.com/Siddharth-Vadapalli-at-TI/d70cff3bfff53ef094d3a775e4...
Since am62px_evm_a53_defconfig has significant changes in this series, SD Boot has also been validated on AM62P5-SK with the am62px_evm_a53_defconfig of this series. Logs for the same are at: https://gist.github.com/Siddharth-Vadapalli-at-TI/971df121c8b69a2b8fb17f1c58...
Series has also been validated on AM625-SK to ensure that the changes made to "am62x_r5_usbdfu.config" config fragment being used by AM625-SK for USB DFU boot do not cause a regression on AM625-SK w.r.t. USB DFU boot. Logs validating USB DFU Boot on AM625-SK with this series: https://gist.github.com/Siddharth-Vadapalli-at-TI/627c69150c34171b065204839c...
Regards, Siddharth.
Siddharth Vadapalli (5): board: ti: am62px: env: include environment for DFU Boot configs: am62x_r5_usbdfu: extend for AM62Px configs: am62px_evm_a53_defconfig: enable USB DFU support arm: dts: k3-am62p5-sk-u-boot: enable USB0 for USB DFU boot doc: board: document support for USB DFU boot on AM62Px SoC
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 +++++++++ board/ti/am62px/am62px.env | 5 +++-- configs/am62px_evm_a53_defconfig | 24 +-------------------- configs/am62x_r5_usbdfu.config | 3 +++ doc/board/ti/am62px_sk.rst | 31 +++++++++++++++++++++++++++ 5 files changed, 48 insertions(+), 25 deletions(-)
Include the TI K3 DFU environment to support DFU Boot and DFU Flash. Also add "usb" to the list of "boot_targets". While at it, add a newline at the end of the file.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com --- v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-... Changes since v1: - Updated commit message indicating that a newline is also being added at the end of this file based on feedback from Mattijs Korpershoek on the v1 patch.
board/ti/am62px/am62px.env | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/board/ti/am62px/am62px.env b/board/ti/am62px/am62px.env index 7ef54079aa8..e0838196e3a 100644 --- a/board/ti/am62px/am62px.env +++ b/board/ti/am62px/am62px.env @@ -1,5 +1,6 @@ #include <env/ti/ti_common.env> #include <env/ti/mmc.env> +#include <env/ti/k3_dfu.env>
name_kern=Image console=ttyS2,115200n8 @@ -7,7 +8,7 @@ args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x02800000 ${mtdparts} run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
-boot_targets=mmc1 mmc0 pxe dhcp +boot_targets=mmc1 mmc0 usb pxe dhcp boot=mmc mmcdev=1 bootpart=1:2 @@ -17,4 +18,4 @@ rd_spec=- #if CONFIG_BOOTMETH_ANDROID #include <env/ti/android.env> adtb_idx=3 -#endif \ No newline at end of file +#endif
Hi Siddharth,
Thank you for the patch.
On mer., déc. 18, 2024 at 18:15, Siddharth Vadapalli s-vadapalli@ti.com wrote:
Include the TI K3 DFU environment to support DFU Boot and DFU Flash. Also add "usb" to the list of "boot_targets". While at it, add a newline at the end of the file.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com
Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-... Changes since v1:
- Updated commit message indicating that a newline is also being added at the end of this file based on feedback from Mattijs Korpershoek on the v1 patch.
board/ti/am62px/am62px.env | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/board/ti/am62px/am62px.env b/board/ti/am62px/am62px.env index 7ef54079aa8..e0838196e3a 100644 --- a/board/ti/am62px/am62px.env +++ b/board/ti/am62px/am62px.env @@ -1,5 +1,6 @@ #include <env/ti/ti_common.env> #include <env/ti/mmc.env> +#include <env/ti/k3_dfu.env>
name_kern=Image console=ttyS2,115200n8 @@ -7,7 +8,7 @@ args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x02800000 ${mtdparts} run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
-boot_targets=mmc1 mmc0 pxe dhcp +boot_targets=mmc1 mmc0 usb pxe dhcp boot=mmc mmcdev=1 bootpart=1:2 @@ -17,4 +18,4 @@ rd_spec=- #if CONFIG_BOOTMETH_ANDROID #include <env/ti/android.env> adtb_idx=3 -#endif \ No newline at end of file
+#endif
2.43.0
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Include the TI K3 DFU environment to support DFU Boot and DFU Flash. Also add "usb" to the list of "boot_targets". While at it, add a newline at the end of the file.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com
Reviewed-by: Roger Quadros rogerq@kernel.org
Disable configs which are not required for USB DFU functionality, in order to allow reusing this fragment for AM62Px SoC.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com --- v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-4-s-... Changes since v1: - Collected Reviewed-by tag.
configs/am62x_r5_usbdfu.config | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/configs/am62x_r5_usbdfu.config b/configs/am62x_r5_usbdfu.config index 772bb2ab935..f094ed127e6 100644 --- a/configs/am62x_r5_usbdfu.config +++ b/configs/am62x_r5_usbdfu.config @@ -26,3 +26,6 @@ CONFIG_SPL_DFU=y # CONFIG_CMD_MMC is not set # CONFIG_CMD_FAT is not set # CONFIG_MMC_SDHCI is not set +# CONFIG_SPL_MTD is not set +# CONFIG_DMA_CHANNELS is not set +# CONFIG_TI_K3_NAVSS_UDMA is not set
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Disable configs which are not required for USB DFU functionality, in order to allow reusing this fragment for AM62Px SoC.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
Reviewed-by: Roger Quadros rogerq@kernel.org
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it in "am62px_evm_a53_defconfig" in order to enable support for USB DFU flash and boot. Remove those configs from "am62px_evm_a53_defconfig" which are present in the "am62x_a53_usbdfu.config" config fragment that is being included.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com --- This patch has been newly introduced in this series based on the discussion at: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-...
configs/am62px_evm_a53_defconfig | 24 +----------------------- 1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig index 9635beb1b27..9862b1f9a16 100644 --- a/configs/am62px_evm_a53_defconfig +++ b/configs/am62px_evm_a53_defconfig @@ -41,14 +41,11 @@ CONFIG_SPL_SYS_MMCSD_RAW_MODE=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 CONFIG_SPL_DMA=y -CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" CONFIG_SPL_I2C=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_POWER_DOMAIN=y -CONFIG_SPL_RAM_SUPPORT=y -CONFIG_SPL_RAM_DEVICE=y # CONFIG_SPL_SPI_FLASH_TINY is not set CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y @@ -58,14 +55,12 @@ CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_BOOTEFI_SELFTEST=y CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_CLK=y -CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_MTD=y CONFIG_CMD_REMOTEPROC=y -CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y @@ -85,17 +80,12 @@ CONFIG_SPL_DM_DEVICE_REMOVE=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y -CONFIG_SPL_SYSCON=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y -CONFIG_DFU_MMC=y CONFIG_DFU_MTD=y -CONFIG_DFU_RAM=y CONFIG_DFU_SF=y -CONFIG_SYS_DFU_DATA_BUF_SIZE=0x40000 -CONFIG_SYS_DFU_MAX_FILE_SIZE=0x800000 CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_USB_FUNCTION_FASTBOOT=y @@ -164,22 +154,10 @@ CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y CONFIG_DM_THERMAL=y -CONFIG_USB=y -CONFIG_DM_USB_GADGET=y -CONFIG_SPL_DM_USB_GADGET=y CONFIG_SPL_USB_HOST=y -CONFIG_USB_XHCI_HCD=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y -CONFIG_SPL_USB_DWC3_GENERIC=y CONFIG_SPL_USB_STORAGE=y -CONFIG_USB_GADGET=y -CONFIG_SPL_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" -CONFIG_USB_GADGET_VENDOR_NUM=0x0451 -CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 -CONFIG_SPL_DFU=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 CONFIG_EFI_SET_TIME=y
#include <configs/k3_efi_capsule.config> +#include <configs/am62x_a53_usbdfu.config>
Hi Siddharth,
Thank you for the patch.
On mer., déc. 18, 2024 at 18:15, Siddharth Vadapalli s-vadapalli@ti.com wrote:
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it in "am62px_evm_a53_defconfig" in order to enable support for USB DFU flash and boot. Remove those configs from "am62px_evm_a53_defconfig" which are present in the "am62x_a53_usbdfu.config" config fragment that is being included.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com
Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
This patch has been newly introduced in this series based on the discussion at: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-...
configs/am62px_evm_a53_defconfig | 24 +----------------------- 1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig index 9635beb1b27..9862b1f9a16 100644 --- a/configs/am62px_evm_a53_defconfig +++ b/configs/am62px_evm_a53_defconfig @@ -41,14 +41,11 @@ CONFIG_SPL_SYS_MMCSD_RAW_MODE=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 CONFIG_SPL_DMA=y -CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" CONFIG_SPL_I2C=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_POWER_DOMAIN=y -CONFIG_SPL_RAM_SUPPORT=y -CONFIG_SPL_RAM_DEVICE=y # CONFIG_SPL_SPI_FLASH_TINY is not set CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y @@ -58,14 +55,12 @@ CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_BOOTEFI_SELFTEST=y CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_CLK=y -CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_MTD=y CONFIG_CMD_REMOTEPROC=y -CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y @@ -85,17 +80,12 @@ CONFIG_SPL_DM_DEVICE_REMOVE=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y -CONFIG_SPL_SYSCON=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y -CONFIG_DFU_MMC=y CONFIG_DFU_MTD=y -CONFIG_DFU_RAM=y CONFIG_DFU_SF=y -CONFIG_SYS_DFU_DATA_BUF_SIZE=0x40000 -CONFIG_SYS_DFU_MAX_FILE_SIZE=0x800000 CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_USB_FUNCTION_FASTBOOT=y @@ -164,22 +154,10 @@ CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y CONFIG_DM_THERMAL=y -CONFIG_USB=y -CONFIG_DM_USB_GADGET=y -CONFIG_SPL_DM_USB_GADGET=y CONFIG_SPL_USB_HOST=y -CONFIG_USB_XHCI_HCD=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y -CONFIG_SPL_USB_DWC3_GENERIC=y CONFIG_SPL_USB_STORAGE=y -CONFIG_USB_GADGET=y -CONFIG_SPL_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" -CONFIG_USB_GADGET_VENDOR_NUM=0x0451 -CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 -CONFIG_SPL_DFU=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 CONFIG_EFI_SET_TIME=y
#include <configs/k3_efi_capsule.config>
+#include <configs/am62x_a53_usbdfu.config>
2.43.0
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it
Apparently "am62x_a53_usbdfu.config" adds USB Host and Gadget and DFU support.
in "am62px_evm_a53_defconfig" in order to enable support for USB DFU flash and boot. Remove those configs from "am62px_evm_a53_defconfig" which are present in the "am62x_a53_usbdfu.config" config fragment that is being included.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com
Reviewed-by: Roger Quadros rogerq@kernel.org
On Wed, Dec 18, 2024 at 03:47:20PM +0200, Roger Quadros wrote:
Hello Roger,
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it
Apparently "am62x_a53_usbdfu.config" adds USB Host and Gadget and DFU support.
Do you propose that the Host configs should be moved into the respective defconfigs of SoCs which include am62x_a53_usbdfu.config, while dropping them from am62x_a53_usbdfu.config? Please let me know. This can be implemented by a separate series if that is what you are suggesting.
Regards, Siddharth.
Hi Siddharth,
On 19/12/2024 07:43, Siddharth Vadapalli wrote:
On Wed, Dec 18, 2024 at 03:47:20PM +0200, Roger Quadros wrote:
Hello Roger,
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it
Apparently "am62x_a53_usbdfu.config" adds USB Host and Gadget and DFU support.
Do you propose that the Host configs should be moved into the respective defconfigs of SoCs which include am62x_a53_usbdfu.config, while dropping them from am62x_a53_usbdfu.config? Please let me know. This can be implemented by a separate series if that is what you are suggesting.
No. The commit that introduced am62x_a53_usbdfu.config mentions that it is for USB Host and Gadget and DFU.
Your commit message seems to indicate that it is for DFU. I leave it to you if you want to update the commit message or not.
Regards, Siddharth.
On Thu, Dec 19, 2024 at 11:38:23AM +0200, Roger Quadros wrote:
Hi Siddharth,
On 19/12/2024 07:43, Siddharth Vadapalli wrote:
On Wed, Dec 18, 2024 at 03:47:20PM +0200, Roger Quadros wrote:
Hello Roger,
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support for AM62x SoC is applicable to the AM62Px SoC as well. Hence, include it
Apparently "am62x_a53_usbdfu.config" adds USB Host and Gadget and DFU support.
Do you propose that the Host configs should be moved into the respective defconfigs of SoCs which include am62x_a53_usbdfu.config, while dropping them from am62x_a53_usbdfu.config? Please let me know. This can be implemented by a separate series if that is what you are suggesting.
No. The commit that introduced am62x_a53_usbdfu.config mentions that it is for USB Host and Gadget and DFU.
Your commit message seems to indicate that it is for DFU. I leave it to you if you want to update the commit message or not.
Ok. In that case I will leave the commit message as it is. It seemed to me that you were pointing to the inconsistency between the name of the config fragment and the configs that it enables.
Regards, Siddharth.
Enable USB0 instance of the USB controller for USB DFU boot functionality which requires the "bootph-all" property in order to have USB enabled at all stages of the USB DFU boot.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com --- v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-5-s-... Changes since v1: - Collected Reviewed-by tag.
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi index cf087c6e343..c2091fc1a51 100644 --- a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi +++ b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi @@ -16,3 +16,13 @@ &dmsc { bootph-pre-ram; }; + +/* Required for USB DFU boot */ +&usbss0 { + status = "okay"; +}; + +/* Required for USB DFU boot */ +&usb0 { + bootph-all; +};
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Enable USB0 instance of the USB controller for USB DFU boot functionality which requires the "bootph-all" property in order to have USB enabled at all stages of the USB DFU boot.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-5-s-... Changes since v1:
- Collected Reviewed-by tag.
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi index cf087c6e343..c2091fc1a51 100644 --- a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi +++ b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi @@ -16,3 +16,13 @@ &dmsc { bootph-pre-ram; };
+/* Required for USB DFU boot */ +&usbss0 {
- status = "okay";
+};
This should come via upstream DT sync?
+/* Required for USB DFU boot */ +&usb0 {
- bootph-all;
+};
This as well? But I don't see it upstream. Do you have a patch for upstream DT?
On Wed, Dec 18, 2024 at 04:05:47PM +0200, Roger Quadros wrote:
Hello Roger,
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Enable USB0 instance of the USB controller for USB DFU boot functionality which requires the "bootph-all" property in order to have USB enabled at all stages of the USB DFU boot.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-5-s-... Changes since v1:
- Collected Reviewed-by tag.
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi index cf087c6e343..c2091fc1a51 100644 --- a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi +++ b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi @@ -16,3 +16,13 @@ &dmsc { bootph-pre-ram; };
+/* Required for USB DFU boot */ +&usbss0 {
- status = "okay";
+};
This should come via upstream DT sync?
+/* Required for USB DFU boot */ +&usb0 {
- bootph-all;
+};
This as well? But I don't see it upstream. Do you have a patch for upstream DT?
I haven't posted the patch for Linux device-tree yet. I will post it and it can be synced with U-Boot later. In order to avoid blocking USB DFU support on the Linux device-tree sync, I have posted this patch for this series to be complete in terms of functionality. If Linux device-tree based sync is the only way to enable this, then the following patch in this series for documentation should also be dropped since the feature will not be functional without the changes made by this patch.
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Regards, Siddharth.
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
On Wed, Dec 18, 2024 at 04:05:47PM +0200, Roger Quadros wrote:
Hello Roger,
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Enable USB0 instance of the USB controller for USB DFU boot functionality which requires the "bootph-all" property in order to have USB enabled at all stages of the USB DFU boot.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-5-s-... Changes since v1:
- Collected Reviewed-by tag.
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi index cf087c6e343..c2091fc1a51 100644 --- a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi +++ b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi @@ -16,3 +16,13 @@ &dmsc { bootph-pre-ram; };
+/* Required for USB DFU boot */ +&usbss0 {
- status = "okay";
+};
This should come via upstream DT sync?
+/* Required for USB DFU boot */ +&usb0 {
- bootph-all;
+};
This as well? But I don't see it upstream. Do you have a patch for upstream DT?
I haven't posted the patch for Linux device-tree yet. I will post it and it can be synced with U-Boot later. In order to avoid blocking USB DFU support on the Linux device-tree sync, I have posted this patch for this series to be complete in terms of functionality. If Linux device-tree based sync is the only way to enable this, then the following patch in this series for documentation should also be dropped since the feature will not be functional without the changes made by this patch.
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
On Wed, Dec 18, 2024 at 04:05:47PM +0200, Roger Quadros wrote:
Hello Roger,
Hi Siddharth,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Enable USB0 instance of the USB controller for USB DFU boot functionality which requires the "bootph-all" property in order to have USB enabled at all stages of the USB DFU boot.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
v1: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-5-s-... Changes since v1:
- Collected Reviewed-by tag.
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi index cf087c6e343..c2091fc1a51 100644 --- a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi +++ b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi @@ -16,3 +16,13 @@ &dmsc { bootph-pre-ram; };
+/* Required for USB DFU boot */ +&usbss0 {
- status = "okay";
+};
This should come via upstream DT sync?
+/* Required for USB DFU boot */ +&usb0 {
- bootph-all;
+};
This as well? But I don't see it upstream. Do you have a patch for upstream DT?
I haven't posted the patch for Linux device-tree yet. I will post it and it can be synced with U-Boot later. In order to avoid blocking USB DFU support on the Linux device-tree sync, I have posted this patch for this series to be complete in terms of functionality. If Linux device-tree based sync is the only way to enable this, then the following patch in this series for documentation should also be dropped since the feature will not be functional without the changes made by this patch.
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
On Thu, Dec 19, 2024 at 11:00:44AM -0600, Tom Rini wrote:
Hello Tom,
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
[...]
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
Thank you for the clarification. If you merge this series partially (i.e. this patch is dropped), please drop the next patch for documentation as well since the feature will not be functional without this patch and hence shouldn't be documented as being functional.
Regards, Siddharth.
On Fri, Dec 20, 2024 at 10:19:31AM +0530, Siddharth Vadapalli wrote:
On Thu, Dec 19, 2024 at 11:00:44AM -0600, Tom Rini wrote:
Hello Tom,
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
[...]
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
Thank you for the clarification. If you merge this series partially (i.e. this patch is dropped), please drop the next patch for documentation as well since the feature will not be functional without this patch and hence shouldn't be documented as being functional.
I have posted the equivalent of this patch for Linux at: https://lore.kernel.org/r/20241220054550.153360-1-s-vadapalli@ti.com/
Regards, Siddharth.
On Fri, Dec 20, 2024 at 10:19:31AM +0530, Siddharth Vadapalli wrote:
On Thu, Dec 19, 2024 at 11:00:44AM -0600, Tom Rini wrote:
Hello Tom,
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
[...]
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
Thank you for the clarification. If you merge this series partially (i.e. this patch is dropped), please drop the next patch for documentation as well since the feature will not be functional without this patch and hence shouldn't be documented as being functional.
Please post a v3 of this patch with that can be taken now, off-hand I don't know how well the kernel cycle will sync up with taking the dts change such that we'll also get it.
On Fri, Dec 20, 2024 at 08:25:28AM -0600, Tom Rini wrote:
On Fri, Dec 20, 2024 at 10:19:31AM +0530, Siddharth Vadapalli wrote:
On Thu, Dec 19, 2024 at 11:00:44AM -0600, Tom Rini wrote:
Hello Tom,
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
[...]
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
Thank you for the clarification. If you merge this series partially (i.e. this patch is dropped), please drop the next patch for documentation as well since the feature will not be functional without this patch and hence shouldn't be documented as being functional.
Please post a v3 of this patch with that can be taken now, off-hand I
Did you mean "v3 of this *series*, with this DT patch and the Documentation patch dropped in the v3 series?
don't know how well the kernel cycle will sync up with taking the dts change such that we'll also get it.
Regards, Siddharth.
On Fri, Dec 20, 2024 at 09:49:46PM +0530, Siddharth Vadapalli wrote:
On Fri, Dec 20, 2024 at 08:25:28AM -0600, Tom Rini wrote:
On Fri, Dec 20, 2024 at 10:19:31AM +0530, Siddharth Vadapalli wrote:
On Thu, Dec 19, 2024 at 11:00:44AM -0600, Tom Rini wrote:
Hello Tom,
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
[...]
Please let me know if this patch can be merged on the condition that I post the patch for making the same set of changes in the Linux device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
Thank you for the clarification. If you merge this series partially (i.e. this patch is dropped), please drop the next patch for documentation as well since the feature will not be functional without this patch and hence shouldn't be documented as being functional.
Please post a v3 of this patch with that can be taken now, off-hand I
Did you mean "v3 of this *series*, with this DT patch and the Documentation patch dropped in the v3 series?
Yes, sorry for being confusing.
On Fri, Dec 20, 2024 at 10:37:49AM -0600, Tom Rini wrote:
On Fri, Dec 20, 2024 at 09:49:46PM +0530, Siddharth Vadapalli wrote:
On Fri, Dec 20, 2024 at 08:25:28AM -0600, Tom Rini wrote:
On Fri, Dec 20, 2024 at 10:19:31AM +0530, Siddharth Vadapalli wrote:
On Thu, Dec 19, 2024 at 11:00:44AM -0600, Tom Rini wrote:
Hello Tom,
On Thu, Dec 19, 2024 at 11:41:10AM +0200, Roger Quadros wrote:
On 19/12/2024 07:50, Siddharth Vadapalli wrote:
[...]
> > Please let me know if this patch can be merged on the condition that I > post the patch for making the same set of changes in the Linux > device-tree as well.
Tom, what do you suggest?
I feel like Nishanth will say it if I don't, so, it's blocked until it comes in via OF_UPSTREAM being re-synced. That's the rule to avoid the problems we've had in the past.
Thank you for the clarification. If you merge this series partially (i.e. this patch is dropped), please drop the next patch for documentation as well since the feature will not be functional without this patch and hence shouldn't be documented as being functional.
Please post a v3 of this patch with that can be taken now, off-hand I
Did you mean "v3 of this *series*, with this DT patch and the Documentation patch dropped in the v3 series?
Yes, sorry for being confusing.
Thank you for the confirmation. I have posted the v3 series at: https://patchwork.ozlabs.org/project/uboot/cover/20241221025229.361625-1-s-v...
Regards, Siddharth.
Since USB DFU boot is supported on AM62Px SoC, document the steps required to build the image for USB DFU boot along with the steps to send images using the "dfu-util" tool.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com --- This patch has been newly introduced in this series based on the discussion at: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-...
NOTE: This patch should only be merged if all other patches in this series will also be merged, in order to ensure that the feature is documented only if it is supported (i.e. all patches in this series which are required for the feature to be functional have been merged).
doc/board/ti/am62px_sk.rst | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst index 99bdc034869..75451ad76b5 100644 --- a/doc/board/ti/am62px_sk.rst +++ b/doc/board/ti/am62px_sk.rst @@ -124,6 +124,18 @@ Set the variables corresponding to this platform: :start-after: .. k3_rst_include_start_build_steps_spl_r5 :end-before: .. k3_rst_include_end_build_steps_spl_r5
+* 3.1.1 Alternative build of R5 for DFU boot: + + As the SPL size can exceed the limit when building it with support for + booting from both local storage *and* DFU, in order to disable the + configs not required for DFU boot, a config fragment should be used + to not only enable configs for DFU boot, but also disabled the unneeded + configs. + +.. prompt:: bash $ + + export UBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} am62x_r5_usbdfu.config" + * 3.2 A53:
.. include:: ../ti/k3.rst @@ -290,6 +302,25 @@ https://www.ti.com/lit/pdf/spruj83 under the `Boot Mode Pins` section.
For SW2 and SW1, the switch state in the "ON" position = 1.
+DFU based boot +-------------- + +To boot the board over DFU, set the switches to DFU mode and connect to the +USB type C DRD port on the board. After power-on the build artifacts needs to be +uploaded one by one with a tool like dfu-util. + +The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl +upload. The next stages as exposed by U-Boot have target alts matching the name +of the artifacts, for these a USB reset has to be done after each upload. + +When using dfu-util the following commands can be used to boot to a U-Boot shell: + +.. prompt:: bash $ + + dfu-util -a bootloader -D tiboot3.bin + dfu-util -R -a tispl -D tispl.bin + dfu-util -R -a u-boot.img -D u-boot.img + Debugging U-Boot ----------------
Hi Siddharth,
Thank you for the patch.
On mer., déc. 18, 2024 at 18:15, Siddharth Vadapalli s-vadapalli@ti.com wrote:
Since USB DFU boot is supported on AM62Px SoC, document the steps required to build the image for USB DFU boot along with the steps to send images using the "dfu-util" tool.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com
Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
This patch has been newly introduced in this series based on the discussion at: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-...
NOTE: This patch should only be merged if all other patches in this series will also be merged, in order to ensure that the feature is documented only if it is supported (i.e. all patches in this series which are required for the feature to be functional have been merged).
doc/board/ti/am62px_sk.rst | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst index 99bdc034869..75451ad76b5 100644 --- a/doc/board/ti/am62px_sk.rst +++ b/doc/board/ti/am62px_sk.rst @@ -124,6 +124,18 @@ Set the variables corresponding to this platform: :start-after: .. k3_rst_include_start_build_steps_spl_r5 :end-before: .. k3_rst_include_end_build_steps_spl_r5
+* 3.1.1 Alternative build of R5 for DFU boot:
- As the SPL size can exceed the limit when building it with support for
- booting from both local storage *and* DFU, in order to disable the
- configs not required for DFU boot, a config fragment should be used
- to not only enable configs for DFU boot, but also disabled the unneeded
- configs.
+.. prompt:: bash $
- export UBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} am62x_r5_usbdfu.config"
- 3.2 A53:
.. include:: ../ti/k3.rst @@ -290,6 +302,25 @@ https://www.ti.com/lit/pdf/spruj83 under the `Boot Mode Pins` section.
For SW2 and SW1, the switch state in the "ON" position = 1.
+DFU based boot +--------------
+To boot the board over DFU, set the switches to DFU mode and connect to the +USB type C DRD port on the board. After power-on the build artifacts needs to be +uploaded one by one with a tool like dfu-util.
+The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl +upload. The next stages as exposed by U-Boot have target alts matching the name +of the artifacts, for these a USB reset has to be done after each upload.
+When using dfu-util the following commands can be used to boot to a U-Boot shell:
+.. prompt:: bash $
- dfu-util -a bootloader -D tiboot3.bin
- dfu-util -R -a tispl -D tispl.bin
- dfu-util -R -a u-boot.img -D u-boot.img
Debugging U-Boot
-- 2.43.0
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
Since USB DFU boot is supported on AM62Px SoC, document the steps required to build the image for USB DFU boot along with the steps to send images using the "dfu-util" tool.
Signed-off-by: Siddharth Vadapalli s-vadapalli@ti.com
This patch has been newly introduced in this series based on the discussion at: https://patchwork.ozlabs.org/project/uboot/patch/20241217131658.2920799-3-s-...
NOTE: This patch should only be merged if all other patches in this series will also be merged, in order to ensure that the feature is documented only if it is supported (i.e. all patches in this series which are required for the feature to be functional have been merged).
doc/board/ti/am62px_sk.rst | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst index 99bdc034869..75451ad76b5 100644 --- a/doc/board/ti/am62px_sk.rst +++ b/doc/board/ti/am62px_sk.rst @@ -124,6 +124,18 @@ Set the variables corresponding to this platform: :start-after: .. k3_rst_include_start_build_steps_spl_r5 :end-before: .. k3_rst_include_end_build_steps_spl_r5
+* 3.1.1 Alternative build of R5 for DFU boot:
- As the SPL size can exceed the limit when building it with support for
- booting from both local storage *and* DFU, in order to disable the
- configs not required for DFU boot, a config fragment should be used
- to not only enable configs for DFU boot, but also disabled the unneeded
- configs.
+.. prompt:: bash $
- export UBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} am62x_r5_usbdfu.config"
- 3.2 A53:
.. include:: ../ti/k3.rst @@ -290,6 +302,25 @@ https://www.ti.com/lit/pdf/spruj83 under the `Boot Mode Pins` section.
For SW2 and SW1, the switch state in the "ON" position = 1.
+DFU based boot +--------------
+To boot the board over DFU, set the switches to DFU mode and connect to the +USB type C DRD port on the board. After power-on the build artifacts needs to be +uploaded one by one with a tool like dfu-util.
+The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl +upload. The next stages as exposed by U-Boot have target alts matching the name +of the artifacts, for these a USB reset has to be done after each upload.
+When using dfu-util the following commands can be used to boot to a U-Boot shell:
+.. prompt:: bash $
- dfu-util -a bootloader -D tiboot3.bin
- dfu-util -R -a tispl -D tispl.bin
- dfu-util -R -a u-boot.img -D u-boot.img
Is there a known reason why -R was not used for the first command but required in last two? What about if -R is not used for all 3 commands?
Debugging U-Boot
On Wed, Dec 18, 2024 at 04:08:01PM +0200, Roger Quadros wrote:
Hello Roger,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
[...]
+DFU based boot +--------------
+To boot the board over DFU, set the switches to DFU mode and connect to the +USB type C DRD port on the board. After power-on the build artifacts needs to be +uploaded one by one with a tool like dfu-util.
+The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl +upload. The next stages as exposed by U-Boot have target alts matching the name +of the artifacts, for these a USB reset has to be done after each upload.
+When using dfu-util the following commands can be used to boot to a U-Boot shell:
+.. prompt:: bash $
- dfu-util -a bootloader -D tiboot3.bin
- dfu-util -R -a tispl -D tispl.bin
- dfu-util -R -a u-boot.img -D u-boot.img
Is there a known reason why -R was not used for the first command but required in last two? What about if -R is not used for all 3 commands?
According to the "dfu-util" help menu, the "-R" option is defined as: "Issue USB Reset signalling once we're finished"
While the "-R" option is not required in the first stage / command, it is required in the next stages. Without "-R", the user would have to press "Ctrl+C" to proceed i.e. tispl.bin / u-boot.img are transferred / downloaded onto the device but not executed until user presses "Ctrl+C".
As to why "-R" is not required in the first stage, I suppose that ROM automatically executes tiboot3.bin after it has been transferred.
Regards, Siddharth.
On 19/12/2024 08:43, Siddharth Vadapalli wrote:
On Wed, Dec 18, 2024 at 04:08:01PM +0200, Roger Quadros wrote:
Hello Roger,
On 18/12/2024 14:45, Siddharth Vadapalli wrote:
[...]
+DFU based boot +--------------
+To boot the board over DFU, set the switches to DFU mode and connect to the +USB type C DRD port on the board. After power-on the build artifacts needs to be +uploaded one by one with a tool like dfu-util.
+The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl +upload. The next stages as exposed by U-Boot have target alts matching the name +of the artifacts, for these a USB reset has to be done after each upload.
+When using dfu-util the following commands can be used to boot to a U-Boot shell:
+.. prompt:: bash $
- dfu-util -a bootloader -D tiboot3.bin
- dfu-util -R -a tispl -D tispl.bin
- dfu-util -R -a u-boot.img -D u-boot.img
Is there a known reason why -R was not used for the first command but required in last two? What about if -R is not used for all 3 commands?
According to the "dfu-util" help menu, the "-R" option is defined as: "Issue USB Reset signalling once we're finished"
While the "-R" option is not required in the first stage / command, it is required in the next stages. Without "-R", the user would have to press "Ctrl+C" to proceed i.e. tispl.bin / u-boot.img are transferred / downloaded onto the device but not executed until user presses "Ctrl+C".
As to why "-R" is not required in the first stage, I suppose that ROM automatically executes tiboot3.bin after it has been transferred.
Thanks Siddharth for the clarification.
Hi Siddharth,
Thank you for the series.
On mer., déc. 18, 2024 at 18:15, Siddharth Vadapalli s-vadapalli@ti.com wrote:
Hello,
This series add support for USB DFU boot on TI's AM62Px SoC which has two instances of USB Controllers, of which the USB0 instance of USB which is a DWC3 USB Controller is used for USB DFU Boot: ROM => tiboot3.bin => tispl.bin => u-boot.img
v1 of this series is at: https://patchwork.ozlabs.org/project/uboot/cover/20241217131658.2920799-1-s-... Changes since v1:
- Dropped the first patch of the v1 series since its equivalent has been posted by Jonathan Humphreys j-humphreys@ti.com at: https://patchwork.ozlabs.org/project/uboot/patch/20241217204835.3312765-1-j-...
- Based on the feedback from Mattijs Korpershoek on the second patch of the v1 series, the patches in this series have been updated. More details regarding the changes have been described below the tearline of the respective patches.
- Collected Reviewed-by tags.
I have tested this on the AM62Px SK EVM. I did *not* apply the dependency (20241217204835.3312765-1-j-humphreys@ti.com) and it worked fine for me:
I did: $ snagrecover -s am625 -f ./am62px-sk-evm.yaml
Boot logs: https://paste.debian.net/1340393/
Also tested that I could enumerate the board with "fastboot".
Tested-by: Mattijs Korpershoek mkorpershoek@baylibre.com
NOTE: I did *not* collect the Tested-by tag since this series has significant changes when compared to the v1 series. Though I have tested this series before posting it, I intend to get a Tested-by on this v2 series itself after it gets tested.
Series is based on commit 3b3c7280b82 smbios: address build warning of the next branch of U-Boot.
NOTE: Series *depends* on: https://patchwork.ozlabs.org/project/uboot/patch/20241217204835.3312765-1-j-... since the corresponding patch has been dropped in this series when compared with the v1 of this series.
The USB DFU config fragments for AM62x are to be re-used for enabling USB DFU boot on AM62Px as follows: R5 => am62px_evm_r5_defconfig + am62x_r5_usbdfu.config A53 => am62px_evm_a53_defconfig + am62x_a53_usbdfu.config
Series has been tested on AM62P5-SK. Logs validating USB DFU boot on AM62P5-SK with this series: https://gist.github.com/Siddharth-Vadapalli-at-TI/d70cff3bfff53ef094d3a775e4...
Since am62px_evm_a53_defconfig has significant changes in this series, SD Boot has also been validated on AM62P5-SK with the am62px_evm_a53_defconfig of this series. Logs for the same are at: https://gist.github.com/Siddharth-Vadapalli-at-TI/971df121c8b69a2b8fb17f1c58...
Series has also been validated on AM625-SK to ensure that the changes made to "am62x_r5_usbdfu.config" config fragment being used by AM625-SK for USB DFU boot do not cause a regression on AM625-SK w.r.t. USB DFU boot. Logs validating USB DFU Boot on AM625-SK with this series: https://gist.github.com/Siddharth-Vadapalli-at-TI/627c69150c34171b065204839c...
Regards, Siddharth.
Siddharth Vadapalli (5): board: ti: am62px: env: include environment for DFU Boot configs: am62x_r5_usbdfu: extend for AM62Px configs: am62px_evm_a53_defconfig: enable USB DFU support arm: dts: k3-am62p5-sk-u-boot: enable USB0 for USB DFU boot doc: board: document support for USB DFU boot on AM62Px SoC
arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 10 +++++++++ board/ti/am62px/am62px.env | 5 +++-- configs/am62px_evm_a53_defconfig | 24 +-------------------- configs/am62x_r5_usbdfu.config | 3 +++ doc/board/ti/am62px_sk.rst | 31 +++++++++++++++++++++++++++ 5 files changed, 48 insertions(+), 25 deletions(-)
-- 2.43.0
On Wed, Dec 18, 2024 at 01:59:37PM +0100, Mattijs Korpershoek wrote:
Hello Mattijs,
Hi Siddharth,
Thank you for the series.
On mer., déc. 18, 2024 at 18:15, Siddharth Vadapalli s-vadapalli@ti.com wrote:
Hello,
This series add support for USB DFU boot on TI's AM62Px SoC which has two instances of USB Controllers, of which the USB0 instance of USB which is a DWC3 USB Controller is used for USB DFU Boot: ROM => tiboot3.bin => tispl.bin => u-boot.img
v1 of this series is at: https://patchwork.ozlabs.org/project/uboot/cover/20241217131658.2920799-1-s-... Changes since v1:
- Dropped the first patch of the v1 series since its equivalent has been posted by Jonathan Humphreys j-humphreys@ti.com at: https://patchwork.ozlabs.org/project/uboot/patch/20241217204835.3312765-1-j-...
- Based on the feedback from Mattijs Korpershoek on the second patch of the v1 series, the patches in this series have been updated. More details regarding the changes have been described below the tearline of the respective patches.
- Collected Reviewed-by tags.
I have tested this on the AM62Px SK EVM. I did *not* apply the dependency (20241217204835.3312765-1-j-humphreys@ti.com) and it worked fine for me:
I did: $ snagrecover -s am625 -f ./am62px-sk-evm.yaml
Boot logs: https://paste.debian.net/1340393/
Also tested that I could enumerate the board with "fastboot".
Tested-by: Mattijs Korpershoek mkorpershoek@baylibre.com
Thank you for testing this series. The dependency that has been mentioned is for USB DFU *Boot*, while you seem to have tested USB DFU *Flash*.
Regards, Siddharth.
participants (4)
-
Mattijs Korpershoek -
Roger Quadros -
Siddharth Vadapalli -
Tom Rini